Alert virus activity detected

January 10, recap — The Log4j vulnerabilities represent a complex and high-risk situation for companies across the globe. By nature of Log4j being a component, the vulnerabilities affect not only applications that use vulnerable libraries, but also any services that use these applications, so customers may not readily know how widespread the issue is in their environment. Customers are encouraged to utilize scripts and scanning tools to assess their risk and impact.

Microsoft has observed attackers using many of the same inventory techniques to locate targets. Sophisticated adversaries like nation-state actors and commodity attackers alike have been observed taking advantage of these vulnerabilities.

There is high potential for the expanded use of the vulnerabilities. In January, we started seeing attackers taking advantage of the vulnerabilities in internet-facing systems, eventually deploying ransomware. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks.

Organizations may not realize their environments may already be compromised. Microsoft recommends customers to do additional review of devices where vulnerable installations are discovered. At this juncture, customers should assume broad availability of exploit code and scanning capabilities to be a real and present danger to their environments. Due to the many software and services that are impacted and given the pace of updates, this is expected to have a long tail for remediation, requiring ongoing, sustainable vigilance.

January 11, update — We have just released new threat and vulnerability management capabilities, including providing the ability to turn off JNDI lookup directly on the Microsoft Defender portal. With nation-state actors testing and implementing the exploit and known ransomware-associated access brokers using it, we highly recommend applying security patches and updating affected products and services as soon as possible.

Refer to the Microsoft Security Response Center blog for technical information about the vulnerabilities and mitigation recommendations. Meanwhile, defenders need to be diligent in detecting, hunting for, and investigating related threats.

This blog reports our observations and analysis of attacks that take advantage of the Log4j 2 vulnerabilities. It also provides our recommendations for using Microsoft security solutions to 1 find and remediate vulnerable services and systems and 2 detect, investigate, and respond to attacks.

The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers.

An example pattern of attack would appear in a web request log with strings like the following:. An attacker performs an HTTP request against a target system, which generates a log using Log4j 2 that leverages JNDI to perform a request to the attacker-controlled site. The vulnerability then causes the exploited process to reach out to the site and execute the payload. In many observed attacks, the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems.

The specially crafted string that enables exploitation of the vulnerabilities can be identified through several components.

As security teams work to detect the exploitation, attackers have added obfuscation to these requests to evade detections based on request patterns. The vast majority of observed activity has been scanning, but exploitation and post-exploitation activities have also been observed.

Based on the nature of the vulnerabilities, once the attacker has full access and control of an application, they can perform a myriad of objectives. Microsoft has observed activities including installing coin miners, using Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems.

Minecraft customers running their own servers are encouraged to deploy the latest Minecraft server update as soon as possible to protect their users. Microsoft can confirm public reports of the Khonsari ransomware family being delivered as payload post-exploitation, as discussed by Bitdefender.

In Microsoft Defender Antivirus data we have observed a small number of cases of this being launched from compromised Minecraft clients connected to modified Minecraft servers running a vulnerable version of Log4j 2 via the use of a third-party Minecraft mods loader. In these cases, an adversary sends a malicious in-game message to a vulnerable Minecraft server, which exploits CVE to retrieve and execute an attacker-hosted payload on both the server and on connected vulnerable clients.

We observed exploitation leading to a malicious Java class file that is the Khonsari ransomware, which is then executed in the context of javaw. These techniques are typically associated with enterprise compromises with the intent of lateral movement.

Microsoft has not observed any follow-on activity from this campaign at this time, indicating that the attacker may be gathering access for later use. Due to the shifts in the threat landscape, Microsoft reiterates the guidance for Minecraft customers running their own servers to deploy the latest Minecraft server update and for players to exercise caution by only connecting to trusted Minecraft servers.

In addition, HAFNIUM, a threat actor group operating out of China, has been observed utilizing the vulnerability to attack virtualization infrastructure to extend their typical targeting. MSTIC and the Microsoft Defender team have confirmed that multiple tracked activity groups acting as access brokers have begun using the vulnerability to gain initial access to target networks. These access brokers then sell access to these networks to ransomware-as-a-service affiliates.

We have observed these groups attempting exploitation on both Linux and Windows systems, which may lead to an increase in human-operated ransomware impact on both of these operating system platforms. The vast majority of traffic observed by Microsoft remains mass scanners by both attackers and security researchers.

Microsoft has observed rapid uptake of the vulnerability into existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor to Linux systems.

Microsoft has also continued to observe malicious activity performing data leakage via the vulnerability without dropping a payload. This attack scenario could be especially impactful against network devices that have SSL termination, where the actor could leak secrets and data. Follow-on activities from these shells have not been observed at this time, but these tools have the ability to steal passwords and move laterally. This activity is split between a percentage of small-scale campaigns that may be more targeted or related to testing, and the addition of CVE to existing campaigns that were exploiting vulnerabilities to drop remote access tools.

In the HabitsRAT case, the campaign was seen overlapping with infrastructure used in prior campaigns. The Webtoos malware has DDoS capabilities and persistence mechanisms that could allow an attacker to perform additional activities.

While services such as interact. As early as January 4, attackers started exploiting the CVE vulnerability in internet-facing systems running VMware Horizon. Our investigation shows that successful intrusions in these campaigns led to the deployment of the NightSky ransomware. Based on our analysis, the attackers are using command and control CnC servers that spoof legitimate domains.

These include service[. Threat and vulnerability management automatically and seamlessly identifies devices affected by the Log4j vulnerabilities and the associated risk in the environment and significantly reduces time-to-mitigate. The threat and vulnerability management capabilities within Microsoft Defender can help identify vulnerable installations.

On December 15, we began rolling out updates to provide a consolidated view of the organizational exposure to the Log4j 2 vulnerabilities—on the device, software, and vulnerable component level—through a range of automated, complementing capabilities. These capabilities are supported on Windows 10, Windows 11, and Windows Server , , and They are also supported on Linux, but they require updating the Microsoft Defender for Endpoint Linux client to version This section describes alerts indicating that a malicious actor may be attempting to steal data from your organization.

Manipulation rules, such as forward all or specific emails to another email account may be an attempt to exfiltrate information from your organization. TP : If you're able to confirm that a malicious inbox forwarding rule was created and the account was compromised. FP : If you're able to confirm that the user created a forwarding rule to a new or personal external email account for legitimate reasons.

Review all user activity for additional indicators of compromise such as the alert is followed by an Impossible Travel alert. Review activities performed from the IP address used to create the rule to detect other compromised users.

Activities indicating that a user performed an unusual number of file downloads from a cloud storage platform when compared to the baseline learned. This can indicate an attempt to gain information about the organization. FP Unusual behavior : If you can confirm that the user legitimately performed more file download activities than the established baseline.

FP Software sync : If you're able to confirm that software, such as OneDrive, synced with an external backup that caused the alert. Activities indicating that a user performed an unusual number of file accesses in SharePoint or OneDrive to files that contain financial data or network data as compared to the baseline learned.

This can indicate an attempt to gain information about the organization, whether for financial purposes or for credential access and lateral movement. The learning period depends on the user's activity. Generally, the learning period is between 21 and 45 days for most users. FP Unusual behavior : If you can confirm that the user legitimately performed more file access activities than the established baseline. Activities indicating that a user performed an unusual number of file sharing actions from a cloud storage platform when compared to the baseline learned.

FP Unusual behavior : If you're able to confirm that the user legitimately performed more file sharing activities than the established baseline. This section describes alerts indicating that a malicious actor may be attempting to manipulate, interrupt, or destroy you systems and data in your organization.

Activities in a single session indicating that a user performed an unusual number of VM deletions when compared to the baseline learned. Multiple VM deletions could indicate an attempt to disrupt or destroy an environment. However, there are many normal scenarios where VMs are deleted. To improve accuracy and alert only when there is a strong indication of a breach, this detection establishes a baseline on each environment in the organization to reduce B-TP incidents and only alert when the unusual behavior is detected.

B-TP : If after your investigation, you're able to confirm that the administrator was authorized to perform these deletion activities. Ransomware is a cyberattack in which an attacker locks victims out of their devices or blocks them from accessing their files until the victim pays a ransom.

Ransomware can be spread by a malicious shared file or compromised network. Defender for Cloud Apps uses security research expertise, threat intelligence, and learned behavioral patterns to identify ransomware activity. For example, a high rate of file uploads, or files deletions, may represent an encryption process that is common among ransomware operations.

This detection establishes a baseline of the normal working patterns of each user in your organization, such as when the user accesses the cloud and what they commonly do in the cloud. The Defender for Cloud Apps automated threat detection policies start running in the background from the moment you connect. Using our security research expertise to identify behavioral patterns that reflect ransomware activity in our organization, Defender for Cloud Apps provides comprehensive coverage against sophisticated ransomware attacks.

FP Unusual behavior : The user legitimately performed multiple deletion and upload activities of similar files in a short period of time. Recommended action : After reviewing the activity log and confirming that the file extensions are not suspicious, dismiss the alert.

FP Common ransomware file extension : If you are able to confirm that the extensions of the affected files are a match for a known ransomware extension. Recommended action : Contact the user and confirm the files are safe and then dismiss the alert. Activities indicating that a user performed an unusual file deletion activity when compared to the baseline learned.

This can indicate ransomware attack. For example, an attacker can encrypt a user's files and delete all the originals, leaving only the encrypted versions that can be used to coerce the victim to pay a ransom.

Defender for Cloud Apps creates a baseline based on the user's normal behavior and triggers an alert when the unusual behavior is detected. FP : If you're able to confirm that the user legitimately performed more file deletion activities than the established baseline.

Anomalous activities and activities that triggered alerts are given scores based on severity, user impact, and behavioral analysis of the user.

The analysis is done based on other users in the tenants. When there's a significant and anomalous increase in the investigation priority score of a certain user, the alert will be triggered. This alert enables detecting potential breaches that are characterized by activities that don't necessarily trigger specific alerts but accumulate to a suspicious behavior for the user.

Establishing a new user's activity pattern requires an initial learning period of seven days, during which alerts aren't triggered for any score increase.

TP : If you're able to confirm that the activities of the user aren't legitimate. B-TP : If you're able to confirm that user indeed significantly deviated from usual behavior, but there's no potential breach. For most activities, you can define additional conditions that must be met to trigger an alert. Common conditions include IP addresses so that an alert is triggered when the user performs the activity on a computer with a specific IP address or within an IP address range , whether an alert is triggered if a specific user or users perform that activity, and whether the activity is performed on a specific file name or URL.

You can also configure a condition that triggers an alert when the activity is performed by any user in your organization. The available conditions are dependent on the selected activity. You can also define user tags as a condition of an alert policy. This results in the alerts triggered by the policy to include the context of the impacted user.

You can use system user tags or custom user tags. For more information, see User tags in Microsoft Defender for Office When the alert is triggered. You can configure a setting that defines how often an activity can occur before an alert is triggered. This allows you to set up a policy to generate an alert every time an activity matches the policy conditions, when a certain threshold is exceeded, or when the occurrence of the activity the alert is tracking becomes unusual for your organization.

If you select the setting based on unusual activity, Microsoft establishes a baseline value that defines the normal frequency for the selected activity. It takes up to seven days to establish this baseline, during which alerts won't be generated. After the baseline is established, an alert is triggered when the frequency of the activity tracked by the alert policy greatly exceeds the baseline value. For auditing-related activities such as file and folder activities , you can establish a baseline based on a single user or based on all users in your organization; for malware-related activities, you can establish a baseline based on a single malware family, a single recipient, or all messages in your organization.

Alert category. To help with tracking and managing the alerts generated by a policy, you can assign one of the following categories to a policy. When an activity occurs that matches the conditions of the alert policy, the alert that's generated is tagged with the category defined in this setting.

This allows you to track and manage alerts that have the same category setting on the Alerts page in the compliance center because you can sort and filter alerts based on category. Alert severity. Similar to the alert category, you assign a severity attribute Low , Medium , High , or Informational to alert policies.

Like the alert category, when an activity occurs that matches the conditions of the alert policy, the alert that's generated is tagged with the same severity level that's set for the alert policy.

Again, this allows you to track and manage alerts that have the same severity setting on the Alerts page.

For example, you can filter the list of alerts so that only alerts with a High severity are displayed. When setting up an alert policy, consider assigning a higher severity to activities that can result in severely negative consequences, such as detection of malware after delivery to users, viewing of sensitive or classified data, sharing data with external users, or other activities that can result in data loss or security threats.

This can help you prioritize alerts and the actions you take to investigate and resolve the underlying causes. Email notifications. You can set up the policy so that email notifications are sent or not sent to a list of users when an alert is triggered. You can also set a daily notification limit so that once the maximum number of notifications has been reached, no more notifications are sent for the alert during that day.

In addition to email notifications, you or other administrators can view the alerts that are triggered by a policy on the Alerts page.

Consider enabling email notifications for alert policies of a specific category or that have a higher severity setting.

Microsoft provides built-in alert policies that help identify Exchange admin permissions abuse, malware activity, potential external and internal threats, and information governance risks. On the Alert policies page, the names of these built-in policies are in bold and the policy type is defined as System.

These policies are turned on by default. You can turn off these policies or back on again , set up a list of recipients to send email notifications to, and set a daily notification limit.

The other settings for these policies can't be edited. The following table lists and describes the available default alert policies and the category each policy is assigned to. The category is used to determine which alerts a user can view on the Alerts page.

We're working to improve it, and will replace it with a new version in the near future. Until then, you can create a custom alert policy to replace this functionality by using the following settings: Activity is Phish email detected at time of delivery Mail is not ZAP'd Mail direction is Inbound Mail delivery status is Delivered Detection technology is Malicious URL retention, URL detonation, Advanced phish filter, General phish filter, Domain impersonation, User impersonation, and Brand impersonation For more information about anti-phishing in Office , see Set up anti-phishing and anti-phishing policies.

The unusual activity monitored by some of the built-in policies is based on the same process as the alert threshold setting that was previously described. Microsoft establishes a baseline value that defines the normal frequency for "usual" activity. Alerts are then triggered when the frequency of activities tracked by the built-in alert policy greatly exceeds the baseline value.

When an activity performed by users in your organization matches the settings of an alert policy, an alert is generated and displayed on the Alerts page in the compliance center or the Defender portal. Depending on the settings of an alert policy, an email notification is also sent to a list of specified users when an alert is triggered.

For each alert, the dashboard on the Alerts page displays the name of the corresponding alert policy, the severity and category for the alert defined in the alert policy , and the number of times an activity has occurred that resulted in the alert being generated.

This value is based on the threshold setting of the alert policy. The dashboard also shows the status for each alert. For more information about using the status property to manage alerts, see Managing alerts. You can use the following filters to view a subset of all the alerts on the Alerts page. Use this filter to show alerts that are assigned a particular status. The default status is Active.

You or other administrators can change the status value. Use this filter to show alerts that match the setting of one or more alert policies.

Or you can display all alerts for all alert policies. Time range. Use this filter to show alerts that were generated within a specific date and time range.

Use this filter to show alerts from one or more user tags. Tags are reflected based on tagged mailboxes or users that appear in the alerts. Use this filter to show alerts triggered by alert policies in the compliance center or alerts triggered by Office Cloud App Security policies, or both.

Filtering and sorting by user tags is currently in public preview. It may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided about it.

When multiple events that match the conditions of an alert policy occur with a short period of time, they are added to an existing alert by a process called alert aggregation.

When an event triggers an alert, the alert is generated and displayed on the Alerts page and a notification is sent. If the same event occurs within the aggregation interval, then Microsoft adds details about the new event to the existing alert instead of triggering a new alert. The goal of alert aggregation is to help reduce alert "fatigue" and let you focus and take action on fewer alerts for the same event.

In most cases, users don't need to take any further action. As soon as a malicious file or program is detected on a device, Microsoft Defender Antivirus blocks it and prevents it from running. Plus, newly detected threats are added to the antivirus and antimalware engine so that other devices and users are protected, as well. If there's an action a user needs to take, such as approving the removal of a malicious file, they'll see that in the notification they receive.

To learn more about actions that Microsoft Defender Antivirus takes on a user's behalf, or actions users might need to take, see Protection History. To learn more about different threats, visit the Microsoft Security Intelligence Threats site , where you can perform the following actions:.

Secure Windows 10 devices article Evaluate Microsoft Defender Antivirus article How to turn on real-time and cloud-delivered antivirus protection article How to turn on and use Microsoft Defender Antivirus from the Windows Security app article How to turn on Microsoft Defender Antivirus by using Group Policy article How to update your antivirus definitions article How to submit malware and non-malware to Microsoft for analysis article.

Skip to main content.