Reactive and opportunistic: Iran’s role in the Israel-Hamas war

This presentation compares and contrasts activity attributed to Iranian groups before and after the October 7, 2023 start of the Israel-Hamas war. It highlights a number of instances where Iranian operators leveraged existing access, infrastructure, and tooling, ostensibly to meet new objectives.

With the physical conflict approximately one month old, this analysis offers early conclusions in a rapidly evolving space, specific to observed Iranian actors, such as those linked to Iran’s Ministry of Intelligence and Security (MOIS) and Islamic Revolutionary Guard Corps (IRGC). While the presentation details attack techniques observed in specific regions, Microsoft is sharing this information to inform and help protect wider organizations around the world facing attack methods similar to those used by Iranian operators, such as social engineering methods for deceiving victims, and exploitation of vulnerable devices and sign-in credentials.

First, Microsoft does not see any evidence suggesting Iranian groups (IRGC and MOIS) had coordinated, pre-planned cyberattacks aligned to Hamas’ plans and the start of the Israel-Hamas war on October 7​. Although media and other public accounts may suggest that Iran played an active role in planning the October 7 physical attacks on Israel, Microsoft data tells a different part of the story.

Observations from Microsoft telemetry suggest that, at least in the cyber domain, Iranian operators have largely been reactive since the war began, exploiting opportunities to try and take advantage of events on the ground as they unfold​. It took 11 days from the start of the ground conflict before Microsoft saw Iran enter the war in the cyber domain. On October 18, 2023 Microsoft observed the first of two separate destructive attacks targeting infrastructure in Israel. While online personas controlled by Iran exaggerated the claims of impact from these attacks, the data suggests that both attacks were likely opportunistic in nature. Specifically, operators leveraged existing access or acquired access to the first available target. Further, the data shows that, in the case of a ransomware attack, Iranian actors’ claims of impact and precision targeting were almost certainly fabricated.

Second, Microsoft observes Iranian operators continuing to employ their tried-and-true tactics, notably exaggerating the success of their computer network attacks and amplifying those claims and activities via a well-integrated deployment of information operations. This is essentially creating online propaganda seeking to inflate the notoriety and impact of opportunistic attacks, in an effort to increase their effects. For example, Microsoft observed Iranian actors compromising connected webcams and framing the activity as more strategic, claiming they targeted and successfully compromised cameras at a specific Israeli military installation. In reality, the compromised cameras were located at scattered sites outside any one defined region. This suggests that despite Iran actors’ strategic claims, this camera example was ultimately a case of adversaries continuing to opportunistically discover and compromise vulnerable connected devices and try to reframe this routine work as more impactful in the context of the current conflict.

Third, Microsoft recognizes that, as more physical conflicts around the world spur cyber operations of varying levels of sophistication, this is a rapidly evolving space requiring close monitoring to assess potential escalations and impact on wider industries, regions, and customers. Microsoft Threat Intelligence anticipates Iranian operators will move from a reactive posture to more proactive activities the longer the current war plays out and continue to evolve their tactics in pursuit of their objectives.

The digital reality: A surge on critical infrastructure

In this presentation, Microsoft Threat Intelligence experts walk the audience through the timeline of Microsoft’s discovery of Volt Typhoon, a threat actor linked to China, and the adversary group’s activity observed against critical infrastructure and key resources in the U.S. and its territories, such as Guam. The presentation highlights some of the specific techniques, tactics, and procedures (TTPs) Volt Typhoon uses to carry out its operations. The talk features insights on how Microsoft tracked the threat actor and assessed that Volt Typhoon’s activity was consistent with laying the groundwork for use in potential future conflict situations. These insights show the backstory of threat intelligence collection and analysis, leading to Microsoft’s May 2023 blog on Volt Typhoon, sharing the actor’s reach and capabilities with the community.

At CYBERWARCON, Microsoft provides an update on Volt Typhoon activity, highlighting shifts in TTPs and targeting since Microsoft released the May blog post. Specifically, Microsoft sees Volt Typhoon trying to improve its operational security and stealthily attempting to return to previously compromised victims. The threat actor is also targeting university environments, for example, in addition to previously targeted industries. In this presentation, Microsoft experts compare their Volt Typhoon analysis with third-party research and studies of China’s military doctrine and the current geopolitical climate. This adds additional context for the security community on possible motivations behind the threat actor’s current and future operations.

Microsoft also describes gaps and limitations in tracking Volt Typhoon’s activity and how the security community can work together to develop strategies to mitigate future threats from this threat actor.

“You compile me. You had me at RomCom.” – When cybercrime met espionage

For many years, the security community has watched various Russian state-aligned actors intersect with cybercrime ecosystems to varying degrees and with different purposes. At CYBERWARCON 2022, Microsoft discussed the development of a never-before-seen “ransomware” strain known as Prestige by Seashell Blizzard (IRIDIUM), a group reported to be comprised of Russian military intelligence officers. The cyberattack, disguised as a new “ransomware” strain, was meant to cause disruption while providing a thin veneer of plausible deniability for the sponsoring organization.

This year at CYBERWARCON, Microsoft experts profile a different threat actor, Storm-0978, which emerged in the early 2022 as credibly conducting both cybercrime operations, as well as espionage/enablement operations benefiting Russia’s military and other geopolitical interests, with possible ties to Russian security services. The duality of this Storm-0978 adversary’s activity intersecting with both crime and espionage leads to questions Microsoft are engaging conference attendees in exploring. Is Storm-0978 a cybercrime group conducting espionage, or a government-sponsored espionage group conducting cybercrime? Why are we seeing the confluence of what historically have been separate crime and geopolitical objectives? Is this duality in some way a reflection of Russia becoming limited in its ability to scale wartime cyber operations? Is Russia activating cybercriminal elements for operations in order to provide a level of plausible deniability for future destructive attacks? The Ukraine war has illustrated that Russia has likely had to activate other capabilities on the periphery. Storm-0978 is one probable example where it’s clear that other elements have been co-opted to achieve objectives of both a wartime environment and strategic landscape either to achieve effects-led operations or prepositioning.

Microsoft’s extensive insight on the ransomware economy and other cybercrime trends, coupled with experience tracking Russian nation-state adversaries, allows for presenting this profile of the Storm-0978 actor at CYBERWARCON, which Microsoft hopes will be further enriched and analyzed by the wider security community’s experiences, data sets and conclusions.  

A LinkedIn update on combating fake accounts

This presentation focuses on what LinkedIn’s Threat Prevention and Defense team has learned from its investigations of cyber mercenaries, also referred to as private-sector offensive actors (PSOAs), on the platform. The focus of this presentation is on Black Cube (Microsoft tracks this actor as Blue Tsunami), a well-known mercenary actor, and what we’ve learned about how they attempt to operate on LinkedIn. The discussion includes insights on how Black Cube has previously leveraged honeypot profiles, fake jobs, and fake companies to engage in reconnaissance or human intelligence (HUMINT) operations against targets with access to organizations of interest and/or concern to Black Cube’s clients.

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on X at https://twitter.com/MsftSecIntel.

The post Microsoft shares threat intelligence at CYBERWARCON 2023 appeared first on Microsoft Security Blog.

April 19, 2023 update – We have published a JSON file mapping old threat actor names with their new names in the updated taxonomy, summarized here: https://aka.ms/threatactors. We also added hunting queries that Microsoft customers can use while transitioning to the new taxonomy. See the Resources section.

Today, Microsoft is excited to announce that we are shifting to a new threat actor naming taxonomy aligned to the theme of weather. The complexity, scale, and volume of threats is increasing, driving the need to reimagine not only how Microsoft talks about threats but also how we enable customers to understand those threats quickly and with clarity. With the new taxonomy, we intend to bring better context to customers and security researchers that are already confronted with an overwhelming amount of threat intelligence data. It will offer a more organized, memorable, and easy way to reference adversary groups so that organizations can better prioritize threats and protect themselves. Simply put, security professionals will instantly have an idea of the type of threat actor they are up against, just by reading the name.

The Microsoft Threat Intelligence community has spent over a decade discovering, tracking, and identifying targeted malicious activity and sharing that critical intelligence with customers. Our threat research has grown to track more than 300 unique threat actors, including 160 nation-state actors, 50 ransomware groups, and hundreds of others. A global multi-disciplinary assembly of threat intelligence analysts, pen testers, and data scientists work together alongside experts in geopolitics and disinformation to take a whole-of-adversary approach. This helps Microsoft Threat Intelligence teams fully understand the what of an attack, make assessments on the why, then forecast and implement protections for where an attacker might go next. Our vision is that this new naming model helps our customers and the industry move to a more proactive approach to defense.

We realize that other vendors in the industry also have unique naming taxonomies representing their distinct view of threats based on their intelligence. However, there are often overlaps or close alignments with tracked actors, and keeping track of these names can be challenging for defenders. Microsoft Threat Intelligence is committed to helping customers understand threats, no matter which naming taxonomy they are familiar with. Therefore, we will strive to also include other threat actor names within our security products to reflect these analytic overlaps and help customers make well-informed decisions.

The Microsoft threat actor taxonomy explained

In our new taxonomy, threat actor groups will be named after weather events. A weather event or “family name” represents either a nation-state actor attribution (e.g., Typhoon indicates origin or attribution to China) or a motivation (e.g., Tempest indicates financially motivated actors). The table below shows the threat actor groups Microsoft tracks and their assigned weather events in the new naming convention.

Threat actors within the same weather family are given an adjective to distinguish actor groups that have distinct TTPs, infrastructure, objectives, or other identified patterns. The examples below show how the naming system works for Russia and Iran.

Note: Our latest blog about the Iranian threat actor Mint Sandstorm (previously PHOSPHORUS) reflects the new naming taxonomy: Nation-state threat actor Mint Sandstorm refines tradecraft to attack high-value targets.

Where there is a newly discovered, unknown, or emerging cluster of threat activity, we use a temporary designation of Storm (previously DEV) and a four-digit number, allowing us to track it as a unique set of information until we can reach high confidence about the origin or identity of the actor behind the operation. Once our analysis has developed to meet high confidence criteria, a Storm is converted to a named actor.

We believe this new approach, along with the new icon system shown in some of the examples above, makes it even easier to identify and remember Microsoft’s threat actors. Each icon uniquely represents a family name, and where it makes sense will accompany the threat actor names as a visual aid. This new naming approach does not in any way change who the threat actors are that we are tracking, or our current analysis behind the names.

The naming approach we have used previously (Elements, Trees, Volcanoes, and DEVs) has been retired. We have reassigned all existing threat actors to the new taxonomy, and going forward will be using the new threat actor names. Over the next few weeks, you will start seeing changes across public facing content and in-product experiences. We estimate to complete prioritized in-product updates by September 2023. There will be some surfaces that will not be updated. To ease the transition from old names to new names, we developed a reference guide at https://aka.ms/threatactors. Make sure to bookmark it for future reference.

Microsoft’s approach to threat actor tracking

The way Microsoft Threat Intelligence approaches identifying and naming threat actors is outlined below in Figure 4. As is sometimes the case, when a new threat surfaces, we don’t know all the details. We might know about a subset of victims and the malware they were infected with, and/or the command-and-control infrastructure, but we sometimes don’t immediately know the full scope of the actor’s capability or victimology. Microsoft maintains an internal process for tracking these ‘in-development’ activity clusters (now Storm-###) for reference across our hunting teams. In-development names (e.g., Storm-0257) apply to all actor types (nation-state, financially motivated, PSOA, etc.).

Storm names may persist indefinitely, but we strive to progress our understanding of all clusters of threat activity to either merge them with existing fully named actors (thereby expanding the definition), or merge multiple in-development clusters together to define a new fully named actor.

To meet the requirements of a full name, we aim to gain knowledge of the actor’s infrastructure, tooling, victimology, and motivation. We expand and update the definitions supporting our actor names based on our own telemetry, industry reporting, and a combination thereof.

The new centralized home of Microsoft threat actor intelligence

As a security industry leader, Microsoft has unique capabilities to track threats and the expectation to provide timely, consistent analysis will only increase. In a growing industry of complexity, confusion, and an overwhelming amount of data, we see an opportunity to provide customers with hyper relevant threat intelligence enabling them to implement even more proactive defenses.

We know defenders benefit from context and actionable insight– they need to understand what threat actor is behind an attack and how they can take steps to mitigate the issue. This is where Intel Profiles in Microsoft Defender Threat Intelligence can bring crucial information and context about threats.  Integrated into Microsoft 365 Defender, Intel Profiles are updated daily and put the wealth of information tracked by the Microsoft Threat Intelligence community about threat actors and their tools and techniques directly into the hands of security operations professionals so that they can investigate, analyze, and hunt for threats.

We’re excited to share this new threat actor update with you, our defenders, and help bring clarity and relevance to the threat intelligence you are getting from Microsoft.

Resources

To ease the transition to the new naming taxonomy, use this reference guide to look up the old and new names of Microsoft threat actors: https://aka.ms/threatactors.

In addition to the reference guide, we have also published a JSON file that contains the most up-to-date and comprehensive mapping of old threat actor names with their new names:  https://github.com/microsoft/mstic/blob/master/PublicFeeds/ThreatActorNaming/MicrosoftMapping.json

Microsoft customers can use the following queries to transition to the new taxonomy.

Name lookup

Use this query on Microsoft Sentinel, Microsoft 365 Defender, Azure Data Explorer, and other products that support Kusto Query Language (KQL) to get information about a threat actor using the old name, new name, or industry name:

let TANames = externaldata(PreviousName: string, NewName: string, Origin: string, OtherNames: dynamic)[@"https://raw.githubusercontent.com/microsoft/mstic/master/PublicFeeds/ThreatActorNaming/MicrosoftMapping.json"] with(format="multijson", ingestionMapping='[{"Column":"PreviousName","Properties":{"Path":"$.Previous name"}},{"Column":"NewName","Properties":{"Path":"$.New name"}},{"Column":"Origin","Properties":{"Path":"$.Origin/Threat"}},{"Column":"OtherNames","Properties":{"Path":"$.Other names"}}]');
let GetThreatActorAlias = (Name: string) {
TANames
| where Name =~ NewName or Name =~ PreviousName or OtherNames has Name
};
GetThreatActorAlias("ZINC")

TI indicator rename

Use this query on Microsoft Sentinel to look up TI indicators that have been tagged with threat actor name to get the new name.

let TANames = externaldata(PreviousName: string, NewName: string, Origin: string, OtherNames: dynamic)[@"https://raw.githubusercontent.com/microsoft/mstic/master/PublicFeeds/ThreatActorNaming/MicrosoftMapping.json"] with(format="multijson", ingestionMapping='[{"Column":"PreviousName","Properties":{"Path":"$.Previous name"}},{"Column":"NewName","Properties":{"Path":"$.New name"}},{"Column":"Origin","Properties":{"Path":"$.Origin/Threat"}},{"Column":"OtherNames","Properties":{"Path":"$.Other names"}}]');
let TIIndicatorNewTAName = (T:(Tags: string)) {
TANames
| join kind=inner T on $left.PreviousName == $right.Tags
};
TIIndicatorNewTAName((ThreatIntelligenceIndicator
| mv-expand todynamic(Tags) | extend Tags = tostring(Tags)))
| extend Indicator = case(NetworkSourceIP != "", NetworkSourceIP, 
NetworkIP != "", NetworkIP, 
DomainName != "", DomainName, 
FileHashValue != "", FileHashValue, 
Url != "", Url,
"")
| project IndicatorId, Type, Indicator, ConfidenceScore, ExpirationDateTime, PreviousName, NewName, Origin, OtherNames

Further reading

Our latest blog about the Iranian threat actor Mint Sandstorm (previously PHOSPHORUS) reflects the new naming taxonomy: Nation-state threat actor Mint Sandstorm refines tradecraft to attack high-value targets.

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

For additional insights into the threat landscape, visit the Microsoft Security Insider.

The post Microsoft shifts to a new threat actor naming taxonomy appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-0196 is now tracked as Carmine Tsunami.

To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Microsoft Threat Intelligence analysts assess with high confidence that a threat group tracked by Microsoft as DEV-0196 is linked to an Israel-based private sector offensive actor (PSOA) known as QuaDream. QuaDream reportedly sells a platform they call REIGN to governments for law enforcement purposes. REIGN is a suite of exploits, malware, and infrastructure designed to exfiltrate data from mobile devices.  

In this blog, Microsoft analyzes DEV-0196, discusses technical details of the actor’s iOS malware, which we call KingsPawn, and shares both host and network indicators of compromise that can be used to aid in detection.

Over the course of our investigation into DEV-0196, Microsoft collaborated with multiple partners. One of those partners, Citizen Lab of the University of Toronto’s Munk School, identified at least five civil society victims of the DEV-0196 malware that included journalists, political opposition figures, and a non-government organisation (NGO) worker, in North America, Central Asia, Southeast Asia, Europe, and the Middle East. Furthermore, Citizen Lab was able to identify operator locations for QuaDream systems in the following countries: Bulgaria, Czechia, Hungary, Ghana, Israel, Mexico, Romania, Singapore, United Arab Emirates, and Uzbekistan. Read the Citizen Lab report here.

Microsoft is sharing information about DEV-0196 with our customers, industry partners, and the public to improve collective knowledge of how PSOAs operate and raise awareness about how PSOAs facilitate the targeting and exploitation of civil society. For more info, read Standing up for democratic values and protecting stability of cyberspace.

DEV-0196: A private-sector offensive actor based in Israel

PSOAs, which Microsoft also refers to as cyber mercenaries, sell hacking tools or services through a variety of business models, including access as a service. In access as a service, the actor sells full end-to-end hacking tools that can be used by the purchaser in cyber operations. The PSOA itself is not involved in any targeting or running of the operations.

Microsoft Threat Intelligence analysts assess with high confidence that DEV-0196 uses this model, selling exploitation services and malware to governments. It’s not directly involved in targeting. Microsoft also assesses with high confidence that DEV-0196 is linked to an Israel-based private company called QuaDream. According to the Israeli Corporations Authority, QuaDream, under the Israeli name קוודרים בע”מ, was incorporated in August 2016. The company has no website, and there is little public reporting about the company, with a few notable exceptions.

QuaDream came to international attention in a 2022 Reuters report, which cited a company brochure that described the REIGN platform and a list of capabilities, the report also notably suggested that QuaDream used a zero-click iOS exploit that leveraged the same vulnerability seen in NSO Group’s ForcedEntry exploit. An earlier report by Israeli news outlet Haaretz, also citing a QuaDream brochure, revealed that QuaDream did not sell REIGN directly to customers but instead did so through a Cypriot company. Haaretz also reported that Saudi Arabia’s government was among QuaDream’s clients, as was the government of Ghana. However, Haaretz could not confirm allegations made in the Ghanian press and repeated in the Israeli press that QuaDream employees were among 14 Israeli tech workers from different companies who travelled to Accra, Ghana in 2020 to meet with the incumbent administration three months prior to the presidential election for the purposes of a special project relating to it.

QuaDream was mentioned in a December 2022 report from Meta, which reportedly took down 250 accounts associated with the company. According to the report, Meta observed QuaDream testing its ability to exploit iOS and Android mobile devices with the intent “to exfiltrate various types of data including messages, images, video and audio files, and geolocation.”

Technical investigation: DEV-0196 malware

Microsoft Threat Intelligence analysts assess with high confidence that the malware, which we call KingsPawn, is developed by DEV-0196 and therefore strongly linked to QuaDream. We assess with medium confidence that the mobile malware we associate with DEV-0196 is part of the system publicly discussed as REIGN.

The captured samples targeted iOS devices, specifically iOS 14, but there were indications that some of the code could also be used on Android devices. Since the malware sample targets iOS 14, some of the techniques used in this sample may no longer work or be relevant on newer iOS versions. However, we assess it’s highly likely that DEV-0196 will have updated their malware, targeting newer versions to account for this. Analysis of the malware revealed that it is split into multiple components. The sections below focus on two of those components: a monitor agent and the main malware agent.

Monitor agent

The monitor agent is a native Mach-O file written in Objective-C. It is responsible for reducing the forensic footprint of the malware to prevent detection and hinder investigations. It has multiple techniques to do this, one of which is monitoring various directories, such as /private/var/db/analyticsd/ and /private/var/mobile/Library/Logs/CrashReporter, for any malware execution artifacts or crash-related files. Once these artifacts or files are identified, the monitor agent deletes them.

The monitor agent is also in charge of managing the various processes and threads spawned on behalf of the malware to avoid artifacts created from unexpected process crashes. The agent uses the waitpid function to monitor all child processes that are spawned, and the child process IDs are added to a tracking list. The monitor agent attempts to safely shut down tracked child processes by calling sigaction with the SIGTSTP parameter, if sigaction returns successfully this means the child process is reachable and a SIGKILL command is sent to kill it. This avoids sending a kill command to a non-existent PID, which can leave error messages and artifacts behind.

Main agent

The main agent is also a native Mach-O file. However, it is written in Go, a highly portable language, which was likely chosen because it allows compilation across multiple platforms, reducing development effort.

This agent includes capabilities to:

• Get device information (such as iOS version and battery status)
• Wi-Fi information (such as SSID and airplane mode status)
• Cellular information (such as carrier, SIM card data, and phone number)
• Search for and retrieve files
• Use the device camera in the background
• Get device location
• Monitor phone calls
• Access the iOS keychain
• Generate an iCloud time-based one-time password (TOTP)

It achieves some of these functionalities, for example the surreptitious camera use, by leveraging two key binaries, tccd and mediaserverd, a technique described by ZecOps. The name tccd stands for Transparency, Consent, and Control (TCC) Daemon, and the process manages the access permissions for various peripherals such as the camera and microphone. Normally, users are met with a pop-up prompt from the tccd process, alerting them that something has requested access to the camera, microphone, or other peripheral, and the user is required to either allow or deny it. In this compromise scenario, the agent injects itself into the tccd binary, which allows the agent to spawn both new processes and threads as part of the exploitation process, and also allows it to bypass any tccd prompts on the device meaning the user would be unaware of camera compromise. In concert with tccd, the agent also provisions itself permission to run in the background via mediaserverd. This binary handles the interface that other apps interact with when utilizing the camera. For more details on iOS process injection, tccd and other system components, see Jonathan Levin’s macOS and iOS internals books and blog.

The techniques used in the main agent include a PMAP bypass, an Apple Mobile File Integrity (AMFI) bypass, and a sandbox escape. PMAP is one of the mechanisms that works with the Page Protection Layer (PPL) to prevent unsigned code from running on iOS devices. AMFI is a protection mechanism comprised of multiple components including a kernel extension, AppleFileMobileIntegrity.kext, as well as userland daemon, amfid. The sandbox limits access to system resources and user data via an entitlements system. Although PMAP, PPL, AMFI, and the sandbox have been hardened over the years, advanced attackers attempt to circumvent these protection mechanisms in order to run unsigned code.

The agent also creates a secure channel for XPC messaging by creating a nested app extension called fud.appex. XPC messaging allows the agent to query various system binaries for sensitive device information, such as location details. Although there is a legitimate binary called fud on iOS devices that is part of the Mobile Accessory updater service, fud.appex is not part of a legitimate Apple service. The agent creates the malicious app extension inside the folder /private/var/db/com.apple.xpc.roleaccountd.staging/PlugIns/. The primary reason for performing XPC messaging from within this application extension is to establish a covert channel that enables the agent to avoid being monitored. This nested directory technique means that the XPC service is registered such a way that it is only visible to the app extension itself, so any external monitoring by other applications and system processes is far more difficult. Upon unhooking and restoring tccd to its original state, the entire PlugIns folder is removed to further hide any artifacts of its existence.

In their blog, Citizen Lab discusses the presence of likely malicious calendar events on devices compromised by DEV-0196’s malware, so another notable function of the main agent is that it contains specific code to remove events from the device’s calendar. The agent searches all calendar events from two years prior to the current time and up to the furthest possible allowed future time, removing any events that are tied to a given email address as the “organizer”. The agent also removes the email address from the idstatuscache.plist, which is a database containing records of the first contact of the device with other iCloud accounts. This list would contain the email address that sent the malicious calendar invitation, as well as a time stamp of the original interaction, such as when the invite was received.

There is additional functionality within the agent to cover its tracks by removing artifacts of location monitoring from the locationd process’ records. To first query locations from locationd, the agent must register a client that communicates with locationd via XPC messaging. The locationd process then stores a record of these connections in /private/var/root/Library/Caches/locationd/clients.plist. The malicious agent searches for items in the client plist that have a suffix of subridged, and then removes them, which indicates that the name of their location monitoring client likely ends in that word. This is another example of malicious activity attempting to masquerade as benign system processes, since subridged is the name of a legitimate Apple binary, a part of the SoftwareUpdateBridge Framework.

Technical investigation: DEV-0196 infrastructure

Microsoft developed unique network detections that could be used to fingerprint DEV-0196’s infrastructure on the internet. The group heavily utilized domain registrars and inexpensive cloud hosting providers that accepted cryptocurrency as payment. They tended to only use a single domain per IP address and domains were very rarely reused across multiple IP addresses. Many of the observed domains were deployed using free Let’s Encrypt SSL certificates, while others used self-signed certificates designed to blend in with normal Kubernetes deployments.

We have included network-based indicators at the end of this post for detection purposes. Often, threat actors employ domains that carry country-specific TLDs or themes that align with the location of intended targets. Notably, our list of DEV-0196 domains includes domains strongly associated with some countries that Citizen Lab has identified as locations of victims, countries where QuaDream platforms were operating, or both. To be clear, the identification of victims of the malware in a country doesn’t necessarily mean that an entity in that country is a DEV-0196 customer, as international targeting is common.

Prevention and detection

Preventing exploitation of mobile devices by advanced actors who potentially have zero-click exploits is difficult. There are also significant challenges in detecting an attack on mobile devices, both during and after the compromise. This section discusses some methods for minimizing the risk of malicious actors compromising mobile devices, and then provides some indicators of compromise we associate with DEV-0196 activity.

Basic cyber hygiene is important in helping prevent mobile device compromise. Specific best practices include keeping the device’s software updated to the latest version, enabling automatic software updates if available, using anti-malware software, and being vigilant about not clicking links in any unexpected or suspicious messages.

If you believe you may be targeted by advanced attackers and use an iOS device, we recommend enabling Lockdown Mode. Lockdown Mode offers enhanced security for iOS devices by reducing the attack surface available to threat actors.

Sentinel detections

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here: https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

In addition, customers can access the shared indicators in a structured format via GitHub so that they can be integrated into custom analytics and other queries: https://github.com/microsoft/mstic/blob/master/RapidReleaseTI/Indicators.csv.

Indicators of compromise (IOCs)

Host-based indicators

These host-based indicators are indicative of DEV-0196 activity; however, they shouldn’t be used solely as attribution since other actors may also use the same or similar TTPs.

The file existing, or process activity from, /private/var/db/com.apple.xpc.roleaccountd.staging/subridged

The file existing, or process activity from, com.apple.avcapture

The folder /private/var/db/com.apple.xpc.roleaccountd.staging/PlugIns/fud.appex/ existing, or having activity detected from the folder.

Network indicators

Based on the results of our C2 investigation, Microsoft Threat Intelligence associate the following domains with DEV-0196 activity. The dates the domains were first detected as likely in use is given, along with the last seen active date.

The post DEV-0196: QuaDream’s “KingsPawn” malware used to target civil society in Europe, North America, the Middle East, and Southeast Asia appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. KNOTWEED is now tracked as Denim Tsunami.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The Microsoft Threat Intelligence Center (MSTIC) and the Microsoft Security Response Center (MSRC) found a private-sector offensive actor (PSOA) using multiple Windows and Adobe 0-day exploits, including one for the recently patched CVE-2022-22047, in limited and targeted attacks against European and Central American customers. The PSOA, which MSTIC tracks as KNOTWEED, developed malware called Subzero which was used in these attacks.

This blog details Microsoft’s analysis of the observed KNOTWEED activity and related malware used in targeted attacks against our customers. This information is shared with our customers and industry partners to improve detection of these attacks. Customers are encouraged to expedite deployment of the July 2022 Microsoft security updates to protect their systems against exploits using CVE-2022-22047. Microsoft Defender Antivirus and Microsoft Defender for Endpoint have also implemented detections against KNOTWEED’s malware and tools.

PSOAs, which Microsoft also refers to as cyber mercenaries, sell hacking tools or services through a variety of business models. Two common models for this type of actor are access-as-a-service and hack-for-hire. In access-as-a-service, the actor sells full end-to-end hacking tools that can be used by the purchaser in operations, with the PSOA not involved in any targeting or running of the operation. In hack-for-hire, detailed information is provided by the purchaser to the actor, who then runs the targeted operations. Based on observed attacks and news reports, MSTIC believes that KNOTWEED may blend these models: they sell the Subzero malware to third parties but have also been observed using KNOTWEED-associated infrastructure in some attacks, suggesting more direct involvement.

Who is KNOTWEED?

KNOTWEED is an Austria-based PSOA named DSIRF. The DSIRF website [web archive link] says they provide services “to multinational corporations in the technology, retail, energy and financial sectors” and that they have “a set of highly sophisticated techniques in gathering and analyzing information.” They publicly offer several services including “an enhanced due diligence and risk analysis process through providing a deep understanding of individuals and entities” and “highly sophisticated Red Teams to challenge your company’s most critical assets.”

However, multiple news reports have linked DSIRF to the development and attempted sale of a malware toolset called Subzero. MSTIC found the Subzero malware being deployed through a variety of methods, including 0-day exploits in Windows and Adobe Reader, in 2021 and 2022. As part of our investigation into the utility of this malware, Microsoft’s communications with a Subzero victim revealed that they had not commissioned any red teaming or penetration testing, and confirmed that it was unauthorized, malicious activity. Observed victims to date include law firms, banks, and strategic consultancies in countries such as Austria, the United Kingdom, and Panama. It’s important to note that the identification of targets in a country doesn’t necessarily mean that a DSIRF customer resides in the same country, as international targeting is common.

MSTIC has found multiple links between DSIRF and the exploits and malware used in these attacks. These include command-and-control infrastructure used by the malware directly linking to DSIRF, a DSIRF-associated GitHub account being used in one attack, a code signing certificate issued to DSIRF being used to sign an exploit, and other open-source news reports attributing Subzero to DSIRF.

Observed actor activity

KNOTWEED initial access

MSTIC found KNOTWEED’s Subzero malware deployed in a variety of ways. In the succeeding sections, the different stages of Subzero are referred to by their Microsoft Defender detection names: Jumplump for the persistent loader and Corelump for the main malware.

KNOTWEED exploits in 2022

In May 2022, MSTIC found an Adobe Reader remote code execution (RCE) and a 0-day Windows privilege escalation exploit chain being used in an attack that led to the deployment of Subzero. The exploits were packaged into a PDF document that was sent to the victim via email. Microsoft was not able to acquire the PDF or Adobe Reader RCE portion of the exploit chain, but the victim’s Adobe Reader version was released in January 2022, meaning that the exploit used was either a 1-day exploit developed between January and May, or a 0-day exploit. Based on KNOTWEED’s extensive use of other 0-days, we assess with medium confidence that the Adobe Reader RCE is a 0-day exploit. The Windows exploit was analyzed by MSRC, found to be a 0-day exploit, and then patched in July 2022 as CVE-2022-22047. Interestingly, there were indications in the Windows exploit code that it was also designed to be used from Chromium-based browsers, although we’ve seen no evidence of browser-based attacks.

The CVE-2022-22047 vulnerability is related to an issue with activation context caching in the Client Server Run-Time Subsystem (CSRSS) on Windows. At a high level, the vulnerability could enable an attacker to provide a crafted assembly manifest, which would create a malicious activation context in the activation context cache, for an arbitrary process. This cached context is used the next time the process spawned.

CVE-2022-22047 was used in KNOTWEED related attacks for privilege escalation. The vulnerability also provided the ability to escape sandboxes (with some caveats, as discussed below) and achieve system-level code execution. The exploit chain starts with writing a malicious DLL to disk from the sandboxed Adobe Reader renderer process. The CVE-2022-22047 exploit was then used to target a system process by providing an application manifest with an undocumented attribute that specified the path of the malicious DLL. Then, when the system process next spawned, the attribute in the malicious activation context was used, the malicious DLL was loaded from the given path, and system-level code execution was achieved.

It’s important to note that exploiting CVE-2022-22047 requires attackers to be able to write a DLL to disk. However, in the threat model of sandboxes, such as that of Adobe Reader and Chromium, the ability to write out files where the attacker cannot control the path isn’t considered dangerous. Hence, these sandboxes aren’t a barrier to the exploitation of CVE-2022-22047.

KNOTWEED exploits in 2021

In 2021, MSRC received a report of two Windows privilege escalation exploits (CVE-2021-31199 and CVE-2021-31201) being used in conjunction with an Adobe Reader exploit (CVE-2021-28550), all of which were patched in June 2021. MSTIC was able to confirm the use of these in an exploit chain used to deploy Subzero.

We were later able to link the deployment of Subzero to a fourth exploit, one related to a Windows privilege escalation vulnerability in the Windows Update Medic Service (CVE-2021-36948), which allowed an attacker to force the service to load an arbitrary signed DLL. The malicious DLL used in the attacks was signed by ‘DSIRF GmbH’.

Malicious Excel documents

In addition to the exploit chains, another method of access that led to the deployment of Subzero was an Excel file masquerading as a real estate document. The file contained a malicious macro that was obfuscated with large chunks of benign comments from the Kama Sutra, string obfuscation, and use of Excel 4.0 macros.

After de-obfuscating strings at runtime, the VBA macro uses the ExecuteExcel4Macro function to call native Win32 functions to load shellcode into memory allocated using VirtualAlloc. Each opcode is individually copied into a newly allocated buffer using memset before CreateThread is called to execute the shellcode.

The following section describes the shellcode executed by the macro.

KNOTWEED malware and tactics, techniques, and procedures (TTPs)

Corelump downloader and loader shellcode

The downloader shellcode is the initial shellcode executed from either the exploit chains or malicious Excel documents. The shellcode’s purpose is to retrieve the Corelump second-stage malware from the actor’s command-and-control (C2) server. The downloader shellcode downloads a JPEG image that contains extra encrypted data appended to the end of the file (past the 0xFF 0xD9 marker that signifies the end of a JPEG file). The JPEG is then written to the user’s %TEMP% directory.

The downloader shellcode searches for a 16-byte marker immediately following the end of JPEG. After finding the marker, the downloader shellcode RC4 decrypts the loader shellcode using the next 16 bytes as the RC4 key. Finally, the loader shellcode RC4 decrypts the Corelump malware using a second RC4 key and manually loads it into memory.

Corelump malware

Corelump is the main payload and resides exclusively in memory to evade detection. It contains a variety of capabilities including keylogging, capturing screenshots, exfiltrating files, running a remote shell, and running arbitrary plugins downloaded from KNOTWEED’s C2 server.

As part of installation, Corelump makes copies of legitimate Windows DLLs and overwrites sections of them with malicious code. As part of this process, Corelump also modifies the fields in the PE header to accommodate the nefarious changes, such as adding new exported functions, disabling Control Flow Guard, and modifying the image file checksum with a computed value from CheckSumMappedFile. These trojanized binaries (Jumplump) are dropped to disk in C:\Windows\System32\spool\drivers\color\, and COM registry keys are modified for persistence (see the Behaviors section for more information on COM hijacking).

Jumplump loader

Jumplump is responsible for loading Corelump into memory from the JPEG file in the %TEMP% directory. If Corelump is not present, Jumplump attempts to download it again from the C2 server. Both Jumplump and the downloader shellcode are heavily obfuscated to make analysis difficult, with most instructions being followed by a jmp to another instruction/jmp combination, giving a convoluted control flow throughout the program.

Mex and PassLib

KNOTWEED was also observed using the bespoke utility tools Mex and PassLib. These tools are developed by KNOTWEED and bear capabilities that are derived from publicly available sources. Mex, for example, is a command-line tool containing several red teaming or security plugins copied from GitHub (listed below):

PassLib is a custom password stealer tool capable of dumping credentials from a variety of sources including web browsers, email clients, LSASS, LSA secrets, and the Windows credential manager.

Post-compromise actions

In victims where KNOTWEED malware had been used, a variety of post-compromise actions were observed:

• Setting of UseLogonCredential to “1” to enable plaintext credentials:
  • reg  add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f

• Credential dumping via comsvcs.dll:
  • rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump

• Attempt to access emails with dumped credentials from a KNOTWEED IP address
• Using Curl to download KNOTWEED tooling from public file shares such as vultrobjects[.]com
• Running PowerShell scripts directly from a GitHub gist created by an account associated with DSIRF

KNOTWEED infrastructure connections to DSIRF

Pivoting off a known command-and-control domain identified by MSTIC, acrobatrelay[.]com, RiskIQ expanded the view of KNOTWEED’s attack infrastructure. Leveraging unique patterns in the use of SSL certificates and other network fingerprints specific to the group and associated with that domain, RiskIQ identified a host of additional IP addresses under the control of KNOTWEED.  This infrastructure, largely hosted by Digital Ocean and Choopa, has been actively serving malware since at least February of 2020 and continues through the time of this writing.

RiskIQ next utilized passive DNS data to determine which domains those IPs resolved to at the time they were malicious. This process yielded several domains with direct links to DSIRF, including demo3[.]dsirf[.]eu (the company’s own website), and several subdomains that appear to have been used for malware development, including debugmex[.]dsirflabs[.]eu (likely a server used for debugging malware with the bespoke utility tool Mex) and szstaging[.]dsirflabs[.]eu (likely a server used to stage Subzero malware).

Detection and prevention

Microsoft will continue to monitor KNOTWEED activity and implement protections for our customers. The current detections and IOCs detailed below are in place and protecting Microsoft customers across our security products. Additional advanced hunting queries are also provided below to help organizations extend their protections and investigations of these attacks.

Behaviors

Corelump drops the Jumplump loader DLLs to C:\Windows\System32\spool\drivers\color\. This is a common directory used by malware as well as some legitimate programs, so writes of PE files to the folder should be monitored.

Jumplump uses COM hijacking for persistence, modifying COM registry keys to point to the Jumplump DLL in C:\Windows\System32\spool\drivers\color\. Modifications of default system CLSID values should be monitored to detect this technique (e.g., HKLM\SOFTWARE\Classes\CLSID\{GUID}\InProcServer32 Default value). The five CLSIDs used by Jumplump are listed below with their original clean values on Windows 11:

• {ddc05a5a-351a-4e06-8eaf-54ec1bc2dcea} = “%SystemRoot%\System32\ApplicationFrame.dll“
• {1f486a52-3cb1-48fd-8f50-b8dc300d9f9d} = “%SystemRoot%\system32\propsys.dll“
• {4590f811-1d3a-11d0-891f-00aa004b2e24} = “%SystemRoot%\system32\wbem\wbemprox.dll“
• {4de225bf-cf59-4cfc-85f7-68b90f185355} = “%SystemRoot%\system32\wbem\wmiprvsd.dll“
• {F56F6FDD-AA9D-4618-A949-C1B91AF43B1A} = “%SystemRoot%\System32\Actioncenter.dll“

Many of the post-compromise actions can be detected based on their command lines. Customers should monitor for possible malicious activity such as PowerShell executing scripts from internet locations, modification of commonly abused registry keys such as HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest, and LSASS credential dumping via minidumps.

Recommended customer actions

The techniques used by the actor and described in the Observed actor activity section can be mitigated by adopting the security considerations provided below:

• All customers should prioritize patching of CVE-2022-22047.
• Confirm that Microsoft Defender Antivirus is updated to security intelligence update 1.371.503.0 or later to detect the related indicators.
• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Change Excel macro security settings to control which macros run and under what circumstances when you open a workbook. Customers can also stop malicious XLM or VBA macros by ensuring runtime macro scanning by Antimalware Scan Interface (AMSI) is on. This feature—enabled by default—is on if the Group Policy setting for Macro Run Time Scan Scope is set to “Enable for All Files” or “Enable for Low Trust Files”.
• Enable multifactor authentication (MFA) to mitigate potentially compromised credentials and ensure that MFA is enforced for all remote connectivity. Note: Microsoft strongly encourages all customers download and use password-less solutions like Microsoft Authenticator to secure accounts.
• Review all authentication activity for remote access infrastructure, with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.

Indicators of compromise (IOCs)

The following list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems. All sample hashes are available in VirusTotal.

NOTE: These indicators should not be considered exhaustive for this observed activity.

Detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware tools and implants used by KNOTWEED starting with signature build  1.371.503.0 as the following family names:

• Backdoor:O97M/JumplumpDropper
• Trojan:Win32/Jumplump
• Trojan:Win32/Corelump
• HackTool:Win32/Mexlib
• Trojan:Win32/Medcerc
• Behavior:Win32/SuspModuleLoad

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see the following alerts as an indication of a possible attack. These alerts are not necessarily an indication of KNOTWEED compromise:

• COM Hijacking – Detects multiple behaviors, including JumpLump malware persistence techniques.
• Possible privilege escalation using CTF module – Detects a possible privilege escalation behavior associated with CVE-2022-2204; also detects an attempt to perform local privilege escalation by launching an elevated process and loading an untrusted module to perform malicious activities
• KNOTWEED actor activity detected – Detects KNOTWEED actor activities
• WDigest configuration change – Detects potential retrieval of clear text password from changes to UseLogonCredential registry key
• Sensitive credential memory read – Detects LSASS credential dumping via minidumps
• Suspicious Curl behavior – Detects the use of Curl to download KNOTWEED tooling from public file shares
• Suspicious screen capture activity – Detects Corelump behavior of capturing screenshots of the compromised system

Hunting queries

Microsoft Sentinel

The following resources are available to Microsoft Sentinel customers to identify the activity outlined in the blog post.

Microsoft Defender Antivirus detections related to KNOTWEED

This query identifies occurrences of Microsoft Defender Antivirus detections listed in this blog post:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/KNOTWEEDAVDetection.yaml

File hash IOCs related to KNOTWEED

This query identifies matches based on file hash IOCs related to KNOTWEED across a range of common Microsoft Sentinel data sets:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/KNOTWEEDFileHashesJuly2022.yaml

Domain IOCs related to KNOTWEED

This query identifies matches based on domain IOCs related to KNOTWEED across a range of common Microsoft Sentinel data sets:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/KNOTWEEDC2DomainsJuly2022.yaml

COM registry key modified to point to Color Profile folder

This query identifies modifications to COM registry keys to point to executable files in C:\Windows\System32\spool\drivers\color\:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/COMRegistryKeyModifiedtoPointtoFileinColorDrivers.yaml

PE file dropped in Color Profile folder

This query looks for PE files being created in the C:\Windows\System32\spool\drivers\color\ folder:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/DeviceFileEvents/PEfiledroppedinColorDriversFolder.yaml

Abnormally large JPEG downloaded from new source

This query looks for downloads of JPEG files from remote sources, where the file size is abnormally large, and not from a common source:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/CommonSecurityLog/AbnormallyLargeJPEGFiledDownloadedfromNewSource.yaml

Downloading new file using Curl

This query looks for new files being downloaded using Curl.

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/DownloadofNewFileUsingCurl.yaml

Suspected credential dumping

This query looks for attackers using comsvcs.dll to dump credentials from memory

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SecurityEvent/SuspectedLSASSDump.yaml

Downgrade to plaintext credentials

This query looks for registry key being set to enabled plain text credentials

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityEvent/WDigestDowngradeAttack.yaml

Microsoft 365 Defender advanced hunting

Microsoft 365 Defender customers can run the following advanced hunting queries to locate IOCs and related malicious activity in their environments.

Microsoft Defender Antivirus detections related to KNOTWEED

This query identifies detection of related malware and tools by Microsoft Defender Antivirus:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-AVDetections.yaml

File hash IOCs related to KNOTWEED

This query surfaces KNOTWEED file hash IOCs across Microsoft Defender for Endpoint tables:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-FileHashIOCsJuly2022.yaml

Domain IOCs related to KNOTWEED

This query identifies matches based on domain IOCs related to KNOTWEED against Microsoft Defender for Endpoint device network connections:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-DomainIOCsJuly2022.yaml

COM registry key modified to point to Color Profile folder

This query identifies modifications to COM registry keys to point to executable files in C:\Windows\System32\spool\drivers\color\:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-COMRegistryKeyModifiedtoPointtoColorProfileFolder.yaml

PE file dropped in Color Profile folder

This query looks for PE files being created in the C:\Windows\System32\spool\drivers\color\ folder:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-PEFileDroppedinColorProfileFolder.yaml

Downloading new file using Curl

This query looks for new files being downloaded using Curl.

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/Microsoft%20365%20Defender/Campaigns/KNOTWEED/KNOTWEED-DownloadingnewfileusingCurl.yaml

The post Untangling KNOTWEED: European private-sector offensive actor using 0-day exploits appeared first on Microsoft Security Blog.

Updated September 12, 2022: New information has been added to the initial access and payload analysis sections in this blog, including details on a rootkit component that we found while investigating a XorDdos sample we saw in June 2022.

In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in 2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux endpoints and servers as well as its usage of XOR-based encryption for its communications.

XorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices, XorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to perform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated in August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can also be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.

Botnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables encrypted communications over insecure networks for remote system administration purposes, making it an attractive vector for attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and installs XorDdos on the target device.

XorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion capabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions. 

XorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other dangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and distributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.

Microsoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular attacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our in-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy malware.

This blog post covers the following topics:

• Initial access
• XorDdos payload analysis
  • Detection evasion capabilities
  • Persistence mechanisms
  • Argument-based code-flow
  • Malicious activity threads
  • DDoS attack thread pool
• Defending against Linux platform threats
• Detection details
• Hunting queries
• Indicators

Initial access

XorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential combinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed sign-in attempts on devices successfully infected by the malware:

Our analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file to temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus concealing the source of infection during forensic analysis.

The second method involves running a bash script that performs the following activities via the command line:

1. Iterates the following folders to find a writable directory:
   • /bin
   • /home
   • /root
   • /tmp
   • /usr
   • /etc
2. If a writable directory is found, changes the working directory to the discovered writable directory.
3. Uses the curl command to download the ELF file payload from the remote location hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as  ygljglkjgfg0.
4. Changes the file mode to “executable”.
5. Runs the ELF file payload.
6. Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary. In this case, it renames the Wget binary to good and moves the file to the following locations:
   • mv /usr/bin/wget /usr/bin/good
   • mv /bin/wget /bin/good
7. Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.
8. After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:

Whichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos malware. In the next section, we do a deep dive into the XorDdos payload.

Other XorDdos variants that we recently saw in our investigations use this bash script installation method to either download or build its rootkit remotely. This installation method differentiates itself by matching the kernel build of the target device with the rootkit available on the attacker’s command and control (C2) server.

After enumerating the target device, the script communicates with the attacker’s C2 server, and checks if a rootkit that matches the kernel build of the target device exists on the server. If it finds an existing rootkit that matches with the target device, the script downloads the rootkit. The following steps initiate the matching and downloading of the XorDdos malware and rootkit:

1. The bash script gets the target device’s kernel-related information using the following sequence of commands and sends it to the attacker’s server:
   • lsmod with tail to get the list of loaded Linux kernel modules
   • Modinfo extracts the vermagic number, a string containing information such as the kernel version number and CPU type used by the kernel module to load into kernel space. The vermagic number is gathered from the listed kernel modules.
2. The vermagic string is sent to the attacker’s server in encoded form.

3. If the rootkit binary specific to the kernel build exists on the server, it is downloaded along with the XorDdos ELF as a compressed .tar file.
4. The .tar file is further uncompressed in a new directory named after the string obtained by encoding the MD5 hash of the vermagic string and created under the location /tmp on the target device. After the .tar file is uncompressed, the XorDdos ELF malware installs the XorDdos rootkit.

If the kernel build of the target device does not match any of the rootkits on the attacker’s server, the bash script initiates the following steps to build and compile the rootkit remotely:

1. The bash script prepares archived Linux kernel headers in the /tmp directory.  Linux kernel headers are defining C-language public kernel APIs and data structures to enable compilation of 3rd party kernel modules.
2. The bash script downloads and launches the ELF binary uploader in /tmp. This binary uses an HTTP POST request to upload the archived kernel headers to the attacker’s server.
3. The ELF binary removes the uploader component from /tmp to minimize XorDdos’ footprint.
4. The uploaded archived kernel headers are used on the C2 server to build and compile the rootkit component. Thus, the newly built rootkit component becomes available for download from the C2 server, also making it available for other future infections.
5. The bash script then initiates the prior set of steps to download and install the XorDdos ELF malware, which installs the rootkit into the target device.

XorDdos payload analysis

The XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug symbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier to debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this case, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part of the .strtab section in the ELF file:

• crtstuff.c
• autorun.c
• crc32.c
• encrypt.c
• execpacket.c
• buildnet.c
• hide.c
• http.c
• kill.c
• main.c
• proc.c
• socket.c
• tcp.c
• thread.c
• findip.c
• dns.c

The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.

Detection evasion capabilities

XorDdos contains modules with specific functionalities to evade detection, as detailed below.

Daemon processes

A daemon process is a process that runs in the background rather than under the control of users and detaches itself from the controlling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos trojan uses daemon processes, as detailed below, to break process tree-based analysis:

1. The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which internally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the calling process.
2. After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is to ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be successful. It then calls setsid() to detach itself from the controlling terminal.
3. The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter __nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root partition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is stopped.  
4. It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to /dev/null. It does this by calling dup2 on the file descriptor for /dev/null.
5. The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the current process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected. Performing this evasive signal suppression helps stop the effects of standard libraries trying to write to standard output or standard error, or trying to read from standard input, which could stop the malware’s child process. The API signal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the signal corresponding to signum.

XOR-based encryption

As its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode encoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated data used across the malware’s various modules to conduct its activities.

Process name spoofing

When a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument is always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and overrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.

Kernel rootkit

Some XorDdos samples install a kernel rootkit, while others embed the rootkit in the XorDdos binary. Upon execution, the XorDdos binary drops the embedded rootkit component into the disk.

A rootkit is a kernel module that hides the presence of malicious code by modifying kernel data structures. The XorDdos kernel rootkit generally has the following capabilities:

• Provide root access
• Hide the kernel module
• Hide the malware’s processes
• Hide the malware’s network connections and ports

Based on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by open-source projects like Suterusu and Rooty.

XorDdos attempts to hide itself by invoking its rootkit. The user mode malware calls the function getself(), which invokes readlink() to fetch the location of the malware file image on disk.

After this step, the malware tries to read the contents of its image file and loads it into a memory buffer, then sends a request to unhide() the process and deletes the image on disk. The technique allows XorDdos to bypass detection or minimize its malicious footprint.

The XorDdos rootkit parses the in-kernel list of loaded modules to remove itself and the protected malware from the list. This approach prevents tools like Ismod from listing kernel-loaded modules.

The following table describes the symbols found in the rootkit and their corresponding functionalities:

Process and port hiding

The malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in evading rule-based detections.

The /proc filesystem contains information related to all running processes. A user-mode process can get any process specific information by reading the /proc directory that contains the subdirectory for each running process on the system, such as:

• /proc/7728 – Contains process-id (PID) 7728-related information
• /proc/698 – Contains PID 698-related information

Running the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running processes as part of the ps command.

> strace -e open ps
open(“/proc/3922/status”, O_RDONLY)     = 6
open(“/proc/4324/stat”, O_RDONLY)       = 6
open(“/proc/4324/status”, O_RDONLY)     = 6
open(“/proc/5559/stat”, O_RDONLY)       = 6
open(“/proc/5559/status”, O_RDONLY)     = 6
open(“/proc/5960/stat”, O_RDONLY)       = 6
open(“/proc/5960/status”, O_RDONLY)     = 6
open(“/proc/5978/stat”, O_RDONLY)       = 6
open(“/proc/5978/status”, O_RDONLY)     = 6

If the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.

In this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and output control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate between the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its IOCTL calls from other IOCTL calls in the system.

Along with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the second entry stores the value to act on, such as $pid.

Hiding network connections

The rootkit also leverages kernel hooking to disrupt the regular invocation of various kernel system calls by substituting the original system call handler in the sys_call_table with its own. The hook functions ensure that the events associated with XorDdos’s malicious activity are filtered out, thus evading detection.

The /proc/net interface provides information about currently active TCP connections and is implemented by kernel APIs tcp4_seq_show() and tcp6_seq_show() .

Utilities, such as netstat, acquire TCP/UDP connection information from files named /proc/net/tcp and /proc/net/udp. These files contain one entry per line, each indicating the source and destination port, the source and destination IP addresses, and other relevant information about the active connection.

The rootkit replaces the default read() system call with hook functions, filters the file read entries, and skips the port it intends to hide, further obfuscating C2 communications.

The following table lists kernel APIs and their hook names used by the rootkit:

Persistence mechanisms

XorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon system startup, as detailed below.

Init script

The malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the system starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions, and dependencies.

Cron script

The malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the following content:

It then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:

System V runlevel

A runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style operating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system configuration and allows access to a different combination of processes. Some system administrators set a system’s default runlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is operational. The /etc/rc<run_level> directory contains symbolic links (symlinks), which are soft links that point to the original file. These symlinks point to the scripts that should run at the specified runlevel.

The malware creates a symlink for the init script dropped at the location /etc/init.d/<base_file_name> with the directories associated with runlevels 1 through 5 at /etc/rc<run_level>.d/S90<base_file_name> and /etc/rc.d/rc<run_level>.d/S90<base_file_name>.

Auto-start services

The malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s LinuxExec_Argv2 subroutine runs the system API with the provided arguments.

The commands chkconfig –add <service_name> and update-rc.d then add a service that starts the daemon process at boot.

Argument-based code-flow

XorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes its operation more robust and stealthy. The malware first runs without any argument and then later runs another instance with different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.

Before handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its full process path. The full path is used later to create auto-start service entries and read the file’s content.

In this section, we will cover the main tasks carried out as part of the different arguments provided:

1: Standard code path without any provided arguments

This code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of the entries created in system start-up locations.

The malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these locations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.

It also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the following steps, which modify the file hash to make every file unique:

• Opens the file for writing only
• Calls lseek (fd, 0, SEEK_END) to point at the last position in the file
• Creates a random 10-character string
• Writes the string at the end of the file with an additional null byte

After modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.

2: Clean-up code path

In this code path, the malware runs with another argument provided as the PID, for example:

• /usr/bin/jwvwvxoupv 4849

Using the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check for another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the fork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by the init process, which disconnects it from the process tree and acts as an anti-forensic technique.

Additionally, it performs the following tasks on a provided $pid:

• Fetches the process file name corresponding to the provided $pid
• Deletes the file for the provided $pid
• Deletes the installed init services:
  • Deletes /etc/init.d/<file_name>
  • For runlevels 1-5, unlinks and deletes /etc/rc<runlevel>.d/S90<file_name>
  • Performs the command chkconfig –del <file_name>
  • Performs the command update-rc.d <file_name> remove
• Ends the process that was provided as an argument.

3: Process name spoofing code path

The malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:

• /usr/bin/jwvwvxoupv “cat resolv.conf” 4849
• /usr/bin/jwvwvxoupv gnome-terminal 4849
• /usr/bin/jwvwvxoupv top 4849
• /usr/bin/jwvwvxoupv pwd 4849
• /usr/bin/kagbjahdic id 4849

The fake commands can include:

• cat resolv.conf
• netstat -an
• bash
• whoami
• id
• cd /etc
• ifconfig eth0
• ifconfig
• echo “find”
• uptime
• sh
• top
• gnome-terminal
• su
• netstat -antop
• grep “A”
• who
• ls -la
• pwd
• route -n
• ps -ef
• ls
• sleep 1

In this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line at runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk related to the current process.

It then enters a five-second loop to perform the following checks:

• Fetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on /proc/$pid/exe.
• If the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:
  • Intends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that allows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a successful readlink API call.
  • Creates directories similar to the standard code path scenario.
  • Calls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy the content of the current process’s image-file fetched earlier to the following locations with a random name:
    • /usr/bin/
    • /bin/
    • /tmp/   
  • Copies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on /lib/libudev.so.
  • Changes the hash of the written or copied file and then runs it without passing any parameters.
• If the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the remaining time out of five seconds.
• Unhides the current process and the $pid that was provided as part of the third argument.
• Deletes the on-disk file for the current process.

4: Known locations code path without any provided arguments

This code path is similar to the standard code path, with the main difference being that the malware runs from one of the following locations:

• /usr/bin/
• /bin/
• /tmp/

Once it runs from one of these locations, the malware calls the following functions to perform various tasks:

1. InstallSYS – this function sets up the rootkit by extracting it under /usr/bin folder using a random name and loading it into the kernel.  

As mentioned in the XOR-based encryption section, the encoded string m7A4nQ_/nA translates to the folder path /usr/bin when decoded with the multi-byte key 0xBB2FA36AAA9541F0. The /usr/bin folder path is where the rootkit is dropped.

The dropped rootkit is further inserted into the Linux kernel module using the insmod command. This is followed by the removal of the dropped rootkit from the disk.

XorDdos uses /proc/rs_dev character device to communicate with the rootkit. It calls the CheckLKM() function to see if the rootkit meets the installation requirements, such as an exact kernel header match and no technologies present that can block the rootkit’s installation, like secure boot or enforced signed loadable kernel module (LKM) loading.

XorDdos attempts to open /proc/rs_dev. If the Linux kernel module interface is up, XorDdos sends an IOCTL request with the unique identifier 0x9748712 with argument “0” to open two-way communication between the XorDdos binary and its rootkit.

2. AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system starts.
3. HidePidPort – Hides the malware’s ports and processes.
4. CheckLKM – Checks whether the rootkit device is active or not, and to see if the rootkit meets the installation requirements, such as an exact kernel header match and no secure boot or other technologies that can block the rootkit’s installation. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the rootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to change the ownership of dropped files with the function lchown(<filename>, 0xAD1473B8, 0xAD1473B8).
5. decrypt_remotestr – Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar and the other directories. After decoding the URLs, it adds them into a remote list, which is later used to communicate and fetch commands from the command and control (C2) server:
   • www[.]enoan2107[.]com:3306
   • www[.]gzcfr5axf6[.]com:3306

Malicious activity threads

After creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a cyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is initialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is used to maintain concurrency between threads accessing a shared object, such as kill_cfg data.

The malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP connection, and retrieving kill_cfg data.

 kill_process

The kill_process thread performs the following tasks:

• Decodes encrypted strings
• Fetches file stats for /var/run/gcc.pid or, if none exist, then creates the file
• Fetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the location /lib/libudev.so
• Fetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the current process
• Reads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files, based on the matching specified keys in the configuration file, such as:
  • md5=
  • filename=
  • rmfile=
  • denyip=

tcp_thread

The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:

• Reads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while connecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte string.
• Calculates the CRC header, including details of the device such as the magic string, OS release version, malware version, rootkit presence, memory stats, CPU information, and LAN speed.
• Encrypts the data and sends it to the C2 server.
• Waits to receive any of the following commands from the C2 server and then acts on the command using the exec_packet subroutine.

daemon_get_killed_process

The daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier (hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30 minutes.

DDoS attack thread pool

The malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates threads with twice the number of processors found on the device.

Invoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands received from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.

Defending against Linux platform threats

XorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system architectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a number of potential targets.

Adept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and performing DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems. Moreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.

XorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with comprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft Defender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation antimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat data, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring, Microsoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes detecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a world-writable location, and any potential follow-on activities on endpoints.

Defenders can apply the following mitigations to reduce the impact of this threat:

• Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
• Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants. 
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet. 
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume. 

As threats across all platforms continue to grow in number and sophistication, security solutions must be capable of providing advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will continue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting all the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.

Detection details

Microsoft Defender for Endpoint detects and blocks XorDdos’s installer script and rootkit binary as the following malware:

• DoS:Linux/Xorddos.A
• DoS:Linux/Xorddos!rfn
• Trojan:Linux/Xorddos
• Trojan:Linux/Xorddos.AA
• Trojan:Linux/Xorddos!rfn
• Behavior:Linux/Xorddos.A
• Backdoor:Linux/XorDDoSRootkit.A
• Trojan:SH/XorDDoSinstaller.A

When XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain, including the process tree, file information, user information, and prevention details.

The timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the MITRE ATT&CK techniques and tactics, remediation status, and event entities graph.

Events with the following titles indicate threat activity related to XorDdos:

• The content of libudev.so was collected into libudev.so.6
• bash process performed System Information Discovery by invoking ifconfig
• gcc.sh was executed after being dropped by HFLgGwYfSC.elf
• A shell command was executed by crond
• SUID/SGID process unix_chkpwd executed

Hunting queries

To locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center:

Failed sign-ins

DeviceLogonEvents
| where InitiatingProcessFileName == "sshd"
    and ActionType == "LogonFailed"
| summarize count() by dayOfYear = datetime_part("dayOfYear", Timestamp)
| sort by dayOfYear 
| render linechart

Creation of the XorDdos-specific dropped files

DeviceFileEvents
| extend FullPath=strcat(FolderPath, FileName)
| where FullPath in ("/etc/cron.hourly/gcc.sh", "/lib/libudev.so.6", "/lib/libudev.so", "/var/run/gcc.pid")

Command-line of malicious process

DeviceProcessEvents
| where ProcessCommandLine contains "cat resolv.conf"

Indicators

File information

Dropped files

Download URLs

• www[.]enoan2107[.]com:3306
• www[.]gzcfr5axf6[.]com:3306
• hxxp://aa[.]hostasa[.]org/config.rar

Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or
with Saurabh Swaroop
Microsoft 365 Defender Research Team

The post Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices appeared first on Microsoft Security Blog.

January 10, 2022 recap – The Log4j vulnerabilities represent a complex and high-risk situation for companies across the globe. This open-source component is widely used across many suppliers’ software and services. 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 19, 2022 update – We added new information about an unrelated vulnerability we discovered while investigating Log4j attacks.

January 21, 2022 update – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

The remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell” (CVE-2021-44228, CVE-2021-45046, CVE-2021-44832) has presented a new attack vector and gained broad attention due to its severity and potential for widespread exploitation. The majority of attacks we have observed so far have been mainly mass-scanning, coin mining, establishing remote shells, and red-team activity, but it’s highly likely that attackers will continue adding exploits for these vulnerabilities to their toolkits.

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.

This blog covers the following topics:

1. Attack vectors and observed activity
2. Finding and remediating vulnerable apps and systems
   • Threat and vulnerability management
     • Discovering affected components, software, and devices via a unified Log4j dashboard
     • Applying mitigation directly in the Microsoft 365 Defender portal
   • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
     • Microsoft Defender for servers
     • Microsoft Defender for Containers
   • Microsoft Sentinel queries
   • RiskIQ EASM and Threat Intelligence
3. Detecting and responding to exploitation attempts and other related attacker activity
   • Microsoft 365 Defender
     • Microsoft Defender Antivirus
     • Microsoft Defender for Endpoint
     • Microsoft Defender for Cloud Apps
     • Microsoft Defender for Office 365
     • Microsoft 365 Defender advanced hunting
   • Microsoft Defender for Cloud
   • Microsoft Defender for IoT
   • Microsoft Sentinel
     • Microsoft Sentinel queries
   • Azure Firewall Premium
   • Azure Web Application Firewall (WAF)
4. Indicators of compromise (IoCs)

Attack vectors and observed activity

Microsoft’s unified threat intelligence team, comprising the Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), among others, have been tracking threats taking advantage of the remote code execution (RCE) vulnerabilities in Apache Log4j 2 referred to as “Log4Shell”.

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. The string contains “jndi”, which refers to the Java Naming and Directory Interface. Following this, the protocol, such as “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, or “http”, precedes the attacker domain.

As security teams work to detect the exploitation, attackers have added obfuscation to these requests to evade detections based on request patterns. We’ve seen things like running a lower or upper command within the exploitation string and even more complicated obfuscation attempts, such as the following, that are all trying to bypass string-matching detections:

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.

Exploitation continues on non-Microsoft hosted Minecraft servers

Minecraft customers running their own servers are encouraged to deploy the latest Minecraft server update as soon as possible to protect their users. More information can be found here: https://aka.ms/mclog.

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-2021-44228 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.exe to ransom the device.

While it’s uncommon for Minecraft to be installed in enterprise networks, we have also observed PowerShell-based reverse shells being dropped to Minecraft client systems via the same malicious message technique, giving an actor full access to a compromised system, which they then use to run Mimikatz to steal credentials. 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.

Nation-state activity

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

MSTIC has also observed the CVE-2021-44228 vulnerability being used by multiple tracked nation-state activity groups originating from China, Iran, North Korea, and Turkey. This activity ranges from experimentation during development, integration of the vulnerabilities to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.

For example, MSTIC has observed PHOSPHORUS, an Iranian actor known to deploy ransomware, acquiring and making modifications of the Log4j exploit. We assess that PHOSPHORUS has operationalized these modifications.

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. In these attacks, HAFNIUM-associated systems were observed using a DNS service typically associated with testing activity to fingerprint systems.

Access brokers associated with ransomware

MSTIC and the Microsoft 365 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.

Mass scanning activity continues

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. Many of these campaigns are running concurrent scanning and exploitation activities for both Windows and Linux systems, using Base64 commands included in the JDNI:ldap:// request to launch bash commands on Linux and PowerShell on Windows.

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.

Additional RAT payloads

We’ve observed the dropping of additional remote access toolkits and reverse shells via exploitation of CVE-2021-44228, which actors then use for hands-on-keyboard attacks. In addition to the Cobalt Strike and PowerShell reverse shells seen in earlier reports, we’ve also seen Meterpreter, Bladabindi, and HabitsRAT. 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-2021-44428 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.

Webtoos

The Webtoos malware has DDoS capabilities and persistence mechanisms that could allow an attacker to perform additional activities. As reported by RiskIQ, Microsoft has seen Webtoos being deployed via the vulnerability. Attackers’ use of this malware or intent is not known at this time, but the campaign and infrastructure have been in use and have been targeting both Linux and Windows systems prior to this vulnerability.

A note on testing services and assumed benign activity

While services such as interact.sh, canarytokens.org, burpsuite, and dnslog.cn may be used by IT organizations to profile their own threat footprints, Microsoft encourages including these services in your hunting queries and validating observations of these in environments to ensure they are intentional and legitimate activity.

Exploitation in internet-facing systems leads to ransomware

As early as January 4, attackers started exploiting the CVE-2021-44228 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.

These attacks are performed by a China-based ransomware operator that we’re tracking as DEV-0401. DEV-0401 has previously deployed multiple ransomware families including LockFile, AtomSilo, and Rook, and has similarly exploited Internet-facing systems running Confluence (CVE-2021-26084) and on-premises Exchange servers (CVE-2021-34473).

Based on our analysis, the attackers are using command and control (CnC) servers that spoof legitimate domains. These include service[.]trendmrcio[.]com, api[.]rogerscorp[.]org, api[.]sophosantivirus[.]ga, apicon[.]nvidialab[.]us, w2zmii7kjb81pfj0ped16kg8szyvmk.burpcollaborator[.]net, and 139[.]180[.]217[.]203.

Attackers propagating Log4j attacks via previously undisclosed vulnerability

During our sustained monitoring of threats taking advantage of the Log4j 2 vulnerabilities, we observed activity related to attacks being propagated via a previously undisclosed vulnerability in the SolarWinds Serv-U software. We discovered that the vulnerability, now tracked as CVE-2021-35247, is an input validation vulnerability that could allow attackers to build a query given some input and send that query over the network without sanitation.

We reported our discovery to SolarWinds, and we’d like to thank their teams for immediately investigating and working to remediate the vulnerability. We strongly recommend affected customers to apply security updates released by referring to the SolarWinds advisory here: https://www.solarwinds.com/trust-center/security-advisories/cve-2021-35247.

Microsoft customers can use threat and vulnerability management in Microsoft Defender for Endpoint to identify and remediate devices that have this vulnerability. In addition, Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect malicious behavior related to the observed activity.

Finding and remediating vulnerable apps and systems

Threat and vulnerability management

Threat and vulnerability management capabilities in Microsoft Defender for Endpoint monitor an organization’s overall security posture and equip customers with real-time insights into organizational risk through continuous vulnerability discovery, intelligent prioritization, and the ability to seamlessly remediate vulnerabilities.

Discovering affected components, software, and devices via a unified Log4j dashboard

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. Microsoft continues to iterate on these features based on the latest information from the threat landscape. This section will be updated as those new features become available for customers.

The wide use of Log4j across many supplier’s products challenge defender teams to mitigate and address the risks posed by the vulnerabilities (CVE-2021-44228 or CVE-2021-45046).  The threat and vulnerability management capabilities within Microsoft 365 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 2008, 2012, and 2016. They are also supported on Linux, but they require updating the Microsoft Defender for Endpoint Linux client to version 101.52.57 (30.121092.15257.0) or later. The updates include the following:

• Discovery of vulnerable Log4j library components (paths) on devices
• Discovery of vulnerable installed applications that contain the Log4j library on devices
• A dedicated Log4j dashboard that provides a consolidated view of various findings across vulnerable devices, vulnerable software, and vulnerable files
• Introduction of a new schema in advanced hunting, DeviceTvmSoftwareEvidenceBeta, which surfaces file-level findings from the disk and provides the ability to correlate them with additional context in advanced hunting:

DeviceTvmSoftwareEvidenceBeta
| mv-expand DiskPaths
| where DiskPaths contains "log4j"
| project DeviceId, SoftwareName, SoftwareVendor, SoftwareVersion, DiskPaths

To complement this new table, the existing DeviceTvmSoftwareVulnerabilities table in advanced hunting can be used to identify vulnerabilities in installed software on devices:

DeviceTvmSoftwareVulnerabilities 
| where CveId in ("CVE-2021-44228", "CVE-2021-45046")

These capabilities integrate with the existing threat and vulnerability management experience and are gradually rolling out. As of December 27, 2021, discovery is based on installed application CPEs that are known to be vulnerable to Log4j RCE, as well as the presence of vulnerable Log4j Java Archive (JAR) files.

As of January 20, 2022, threat and vulnerability management can discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files. This capability is supported on Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022. It is also supported on Windows Server 2012 R2 and Windows Server 2016 using the Microsoft Defender for Endpoint solution for earlier Windows server versions.

Threat and vulnerability management provides layers of detection to help customers discover and mitigate vulnerable Log4j components. Specifically, it:

1. determines if a JAR file contains a vulnerable Log4j file by examining JAR files and searching for the following file: \META-INF\maven\org.apache.logging.log4j\log4j-core\pom.properties; if the said file exists, the Log4j version is read and extracted 
2. searches for the JndiLookup.class file inside the JAR file by looking for paths that contain the string “/log4j/core/lookup/JndiLookup.class”; if the JndiLookup.class file exists, threat and vulnerability management determines if this JAR contains a Log4j file with the version defined in pom.properties 
3. searches for any vulnerable Log4j-core JAR files embedded within nested-JAR by searching for paths that contain any of these strings:
   • lib/log4j-core- 
   • WEB-INF/lib/log4j-core- 
   • App-INF/lib/log4j-core- 

Figure 1. Threat and Vulnerability recommendation “Attention required: Devices found with vulnerable Apache Log4j versions”

In the Microsoft 365 Defender portal, go to Vulnerability management > Dashboard > Threat awareness, then click View vulnerability details to see the consolidated view of organizational exposure to the Log4j 2 vulnerability (for example, CVE-2021-44228 dashboard, as shown in the following screenshots) on the device, software, and vulnerable component level.

Figure 2. Threat and vulnerability management dedicated CVE-2021-44228 dashboard

Figure 3. Threat and vulnerability management finds exposed paths

Figure 4. Threat and vulnerability management finds exposed devices based on vulnerable software and vulnerable files detected on disk

Note: Scan results may take some time to reach full coverage, and the number of discovered devices may be low at first but will grow as the scan reaches more devices. A regularly updated list of vulnerable products can be viewed in the Microsoft 365 Defender portal with matching recommendations. We will continue to review and update this list as new information becomes available.

Through device discovery, unmanaged devices with products and services affected by the vulnerabilities are also surfaced so they can be onboarded and secured.

Figure 5. Finding vulnerable applications and devices via software inventory

Applying mitigation directly in the Microsoft 365 Defender portal

We have released two new threat and vulnerability management capabilities that can significantly simplify the process of turning off JNDI lookup, a workaround that can prevent the exploitation of the Log4j vulnerabilities on most devices, using an environment variable called LOG4J_FORMAT_MSG_NO_LOOKUPS. These new capabilities provide security teams with the following:

1. View the mitigation status for each affected device. This can help prioritize mitigation and/or patching of devices based on their mitigation status.

To use this feature, open the Exposed devices tab in the dedicated CVE-2021-44228 dashboard and review the Mitigation status column. Note that it may take a few hours for the updated mitigation status of a device to be reflected.

Figure 6. Viewing each device’s mitigation status

2. Apply the mitigation (that is, turn off JNDI lookup) on devices directly from the portal. This feature is currently available for Windows devices only.

The mitigation will be applied directly via the Microsoft Defender for Endpoint client. To view the mitigation options, click on the Mitigation options button in the Log4j dashboard:

You can choose to apply the mitigation to all exposed devices or select specific devices for which you would like to apply it. To complete the process and apply the mitigation on devices, click Create mitigation action.

Figure 7. Creating mitigation actions for exposed devices.

In cases where the mitigation needs to be reverted, follow these steps:

1. Open an elevated PowerShell window
2. Run the following command:

[Environment]::SetEnvironmentVariable("LOG4J_FORMAT_MSG_NO_LOOKUPS", $null, [EnvironmentVariableTarget]::Machine)

The change will take effect after the device restarts.

Microsoft 365 Defender advanced hunting

Advance hunting can also surface affected software. This query looks for possibly vulnerable applications using the affected Log4j component. Triage the results to determine applications and programs that may need to be patched and updated.

DeviceTvmSoftwareInventory
| where SoftwareName contains "log4j"
| project DeviceName, SoftwareName, SoftwareVersion

Figure 8. Finding vulnerable software via advanced hunting

Microsoft Defender for Cloud

Microsoft Defender for servers

Organizations using Microsoft Defender for Cloud can use Inventory tools to begin investigations before there’s a CVE number. With Inventory tools, there are two ways to determine exposure across hybrid and multi-cloud resources:

• Vulnerability assessment findings – Organizations who have enabled any of the vulnerability assessment tools (whether it’s Microsoft Defender for Endpoint’s threat and vulnerability management module, the built-in Qualys scanner, or a bring your own license solution), they can search by CVE identifier:

Figure 9. Searching vulnerability assessment findings by CVE identifier

• Software inventory – With the combined integration with Microsoft Defender for Endpoint and Microsoft Defender for servers, organizations can search for resources by installed applications and discover resources running the vulnerable software:

Figure 10. Searching software inventory by installed applications

Note that this doesn’t replace a search of your codebase. It’s possible that software with integrated Log4j libraries won’t appear in this list, but this is helpful in the initial triage of investigations related to this incident. For more information about how Microsoft Defender for Cloud finds machines affected by CVE-2021-44228, read this tech community post.

Microsoft Defender for Containers

Microsoft Defender for Containers is capable of discovering images affected by the vulnerabilities recently discovered in Log4j 2: CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105. Images are automatically scanned for vulnerabilities in three different use cases: when pushed to an Azure container registry, when pulled from an Azure container registry, and when container images are running on a Kubernetes cluster. Additional information on supported scan triggers and Kubernetes clusters can be found here. 

Log4j binaries are discovered whether they are deployed via a package manager, copied to the image as stand-alone binaries, or included within a JAR Archive (up to one level of nesting). 

We will continue to follow up on any additional developments and will update our detection capabilities if any additional vulnerabilities are reported.

Finding affected images

To find vulnerable images across registries using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Container Registry images should have vulnerability findings resolved recommendation and search findings for the relevant CVEs. 

Figure 11. Finding images with the CVE-2021-45046 vulnerability 

Find vulnerable running images on Azure portal [preview] 

To view only vulnerable images that are currently running on a Kubernetes cluster using the Azure portal, navigate to the Microsoft Defender for Cloud service under Azure Portal. Open the Vulnerabilities in running container images should be remediated (powered by Qualys) recommendation and search findings for the relevant CVEs: 

Figure 12. Finding running images with the CVE-2021-45046 vulnerability

Note: This recommendation requires clusters to run Microsoft Defender security profile to provide visibility on running images.

Search Azure Resource Graph data 

Azure Resource Graph (ARG) provides instant access to resource information across cloud environments with robust filtering, grouping, and sorting capabilities. It’s a quick and efficient way to query information across Azure subscriptions programmatically or from within the Azure portal. ARG provides another way to query resource data for resources found to be affected by the Log4j vulnerability.

The following query finds resources affected by the Log4j vulnerability across subscriptions. Use the additional data field across all returned results to obtain details on vulnerable resources: 

securityresources 
| where type =~ "microsoft.security/assessments/subassessments"
| extend assessmentKey=extract(@"(?i)providers/Microsoft.Security/assessments/([^/]*)", 1, id), subAssessmentId=tostring(properties.id), parentResourceId= extract("(.+)/providers/Microsoft.Security", 1, id)
| extend Props = parse_json(properties)
| extend additionalData = Props.additionalData
| extend cves = additionalData.cve
| where isnotempty(cves) and array_length(cves) > 0
| mv-expand cves
| where tostring(cves) has "CVE-2021-44228" or tostring(cves) has "CVE-2021-45046" or tostring(cves) has "CVE-2021-45105" 

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection query to look for devices that have applications with the vulnerability:

• Vulnerable machines related to Log4j CVE-2021-44228

This query uses the Microsoft Defender for Cloud nested recommendations data to find machines vulnerable to Log4j CVE-2021-44228.

Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Linux/demos/CVE-2021-44228-Log4Shell

RiskIQ EASM and Threat Intelligence

RiskIQ has published a few threat intelligence articles on this CVE, with mitigation guidance and IOCs. The latest one with links to previous articles can be found here. Both Community users and enterprise customers can search within the threat intelligence portal for data about potentially vulnerable components exposed to the Internet. For example, it’s possible to surface all observed instances of Apache or Java, including specific versions. Leverage this method of exploration to aid in understanding the larger Internet exposure, while also filtering down to what may impact you. 

For a more automated method, registered users can view their attack surface to understand tailored findings associated with their organization. Note, you must be registered with a corporate email and the automated attack surface will be limited. Digital Footprint customers can immediately understand what may be vulnerable and act swiftly and resolutely using the Attack Surface Intelligence Dashboard Log4J Insights tab. 

Detecting and responding to exploitation attempts and other related attacker activity

Microsoft 365 Defender

Microsoft 365 Defender coordinates multiple security solutions that detect components of observed attacks taking advantage of this vulnerability, from exploitation attempts to remote code execution and post-exploitation activity.

Figure 13. Microsoft 365 Defender solutions protect against related threats

Customers can click Need help? in the Microsoft 365 Defender portal to open up a search widget. Customers can key in “Log4j” to search for in-portal resource, check if their network is affected, and work on corresponding actionable items to mitigate them.

Microsoft Defender Antivirus

Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants. Microsoft Defender Antivirus detects components and behaviors related to this threat as the following detection names:

On Windows:

• Trojan:Win32/Capfetox.AA– detects attempted exploitation on the attacker machine
• HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
• VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders
• TrojanDownloader:Win32/CoinMiner – detects post-exploitation coin miner
• Trojan:Win32/WebToos.A – detects post-exploitation PowerShell
• Ransom:MSIL/Khonsari.A – detects a strain of the Khonsari ransomware family observed being distributed post-exploitation
• Trojan:Win64/DisguisedXMRigMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Java/Agent.S – detects suspicious class files used in post-exploitation
• TrojanDownloader:PowerShell/NitSky.A – detects attempts to download CobaltStrike Beacon payload

On Linux:

• Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B, Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
• Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/CoinMiner – detects post-exploitation cryptocurrency miner
• TrojanDownloader:Linux/Tusnami – detects post-exploitation Backdoor Tsunami downloader
• Backdoor:Linux/Tusnami.C – detects post-exploitation Tsunami backdoor
• Backdoor:Linux/Setag.C – detects post-exploitation Gates backdoor
• Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation
• TrojanDownloader:Linux/Capfetox.A, TrojanDownloader:Linux/Capfetox.B
• TrojanDownloader:Linux/ShAgnt!MSR, TrojanDownloader:Linux/ShAgnt.A!MTB
• Trojan:Linux/Kinsing.L – detects post-exploitation cryptocurrency Kinsing miner
• Trojan:Linux/Mirai.TS!MTB – detects post-exploitation Mirai malware capable of performing DDoS
• Backdoor:Linux/Dakkatoni.az!MTB – detects post-exploitation Dakkatoni backdoor trojan capable of downloading more payloads
• Trojan:Linux/JavaExploitRevShell.A – detects reverse shell attack post-exploitation
• Trojan:Linux/BashMiner.A, Trojan:Linux/BashMiner.B – detects post-exploitation cryptocurrency miner

Microsoft Defender for Endpoint

Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Due to the broad network exploitation nature of vectors through which this vulnerability can be exploited and the fact that applying mitigations holistically across large environments will take time, we encourage defenders to look for signs of post-exploitation rather than fully relying on prevention. Observed post exploitation activity such as coin mining, lateral movement, and Cobalt Strike are detected with behavior-based detections.

Alerts with the following titles in the Security Center indicate threat activity related to exploitation of the Log4j vulnerability on your network and should be immediately investigated and remediated. These alerts are supported on both Windows and Linux platforms: 

• Log4j exploitation detected – detects known behaviors that attackers perform following successful exploitation of the CVE-2021-44228 vulnerability
• Log4j exploitation artifacts detected (previously titled Possible exploitation of CVE-2021-44228) – detects coin miners, shells, backdoor, and payloads such as Cobalt Strike used by attackers post-exploitation
• Log4j exploitation network artifacts detected (previously titled Network connection seen in CVE-2021-44228 exploitation) – detects network traffic connecting traffic connecting to an address associated with CVE-2021-44228 scanning or exploitation activity 

The following alerts may indicate exploitation attempts or testing/scanning activity. Microsoft advises customers to investigate with caution, as these alerts don’t necessarily indicate successful exploitation:

• Possible target of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication received by this device
• Possible target of Log4j vulnerability scanning – detects a possible attempt to scan for the remote code execution vulnerability in a Log4j component of an Apache server in communication received by this device
• Possible source of Log4j exploitation – detects a possible attempt to exploit the remote code execution vulnerability in the Log4j component of an Apache server in communication initiated from this device  
• Possible Log4j exploitation – detects multiple behaviors, including suspicious command launch post-exploitation
• Possible Log4j exploitation (CVE-2021-44228) – inactive, initially covered several of the above, now replaced with more specific titles

The following alerts detect activities that have been observed in attacks that utilize at least one of the Log4j vulnerabilities. However, these alerts can also indicate activity that is not related to the vulnerability. We are listing them here, as it is highly recommended that they are triaged and remediated immediately given their severity and the potential that they could be related to Log4j exploitation:

• Suspicious remote PowerShell execution 
• Download of file associated with digital currency mining 
• Process associated with digital currency mining 
• Cobalt Strike command and control detected 
• Suspicious network traffic connection to C2 Server 
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike) 

Some of the alerts mentioned above utilize the enhanced network inspection capabilities in Microsoft Defender for Endpoint. These alerts correlate several network and endpoint signals into high-confidence detection of successful exploitation, as well as providing detailed evidence artifacts valuable for triage and investigation of detected activities.

Figure 14. Example detection leveraging network inspection provides details about the Java class returned following successful exploitation

Microsoft Defender for Cloud Apps (previously Microsoft Cloud App Security)

Microsoft 365 Defender detects exploitation patterns in different data sources, including cloud application traffic reported by Microsoft Defender for Cloud Apps. The following alert surfaces exploitation attempts via cloud applications that use vulnerable Log4j components:

• Log4j exploitation attempt via cloud application (previously titled Exploitation attempt against Log4j (CVE-2021-44228))

Figure 15. Microsoft 365 Defender alert “Exploitation attempt against Log4j (CVE-2021-44228)”

Microsoft Defender for Office 365

To add a layer of protection against exploits that may be delivered via email, Microsoft Defender for Office 365 flags suspicious emails (e.g., emails with the “jndi” string in email headers or the sender email address field), which are moved to the Junk folder.

We also added the following new alert, which detects attempts to exploit CVE-2021-44228 through email headers:

• Log4j exploitation attempt via email (previously titled Log4j Exploitation Attempt – Email Headers (CVE-2021-44228))

Figure 16. Sample alert on malicious sender display name found in email correspondence

This detection looks for exploitation attempts in email headers, such as the sender display name, sender, and recipient addresses. The alert covers known obfuscation attempts that have been observed in the wild. If this alert is surfaced, customers are recommended to evaluate the source address, email subject, and file attachments to get more context regarding the authenticity of the email.

Figure 17. Sample email with malicious sender display name

In addition, this email event as can be surfaced via advanced hunting:

Figure 18. Sample email event surfaced via advanced hunting

Microsoft 365 Defender advanced hunting queries

To locate possible exploitation activity, run the following queries:

Possible malicious indicators in cloud application events

This query is designed to flag exploitation attempts for cases where the attacker is sending the crafted exploitation string using vectors such as User-Agent, Application or Account name. The hits returned from this query are most likely unsuccessful attempts, however the results can be useful to identity attackers’ details such as IP address, Payload string, Download URL, etc.

CloudAppEvents
| where Timestamp > datetime("2021-12-09")
| where UserAgent contains "jndi:" 
or AccountDisplayName contains "jndi:"
or Application contains "jndi:"
or AdditionalFields contains "jndi:"
| project ActionType, ActivityType, Application, AccountDisplayName, IPAddress, UserAgent, AdditionalFields

Alerts related to Log4j vulnerability

This query looks for alert activity pertaining to the Log4j vulnerability.

AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation',
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previously titled Log4j Exploitation Attempt
)

Devices with Log4j vulnerability alerts and additional other alert-related context

This query surfaces devices with Log4j-related alerts and adds additional context from other alerts on the device.  

// Get any devices with Log4J related Alert Activity
let DevicesLog4JAlerts = AlertInfo
| where Title in~('Suspicious script launched',
'Exploitation attempt against Log4j (CVE-2021-44228)',
'Suspicious process executed by a network service',
'Possible target of Log4j exploitation (CVE-2021-44228)',
'Possible target of Log4j exploitation',
'Possible Log4j exploitation',
'Network connection seen in CVE-2021-44228 exploitation',
'Log4j exploitation detected',
'Possible exploitation of CVE-2021-44228',
'Possible target of Log4j vulnerability (CVE-2021-44228) scanning',
'Possible source of Log4j exploitation'
'Log4j exploitation attempt via cloud application', // Previously titled Exploitation attempt against Log4j
'Log4j exploitation attempt via email' // Previouskly titled Log4j Exploitation Attempt
)
// Join in evidence information
| join AlertEvidence on AlertId
| where DeviceId != ""
| summarize by DeviceId, Title;
// Get additional alert activity for each device
AlertEvidence
| where DeviceId in(DevicesLog4JAlerts)
// Add additional info
| join kind=leftouter AlertInfo on AlertId
| summarize DeviceAlerts = make_set(Title), AlertIDs = make_set(AlertId) by DeviceId, bin(Timestamp, 1d)

Suspected exploitation of Log4j vulnerability

This query looks for exploitation of the vulnerability using known parameters in the malicious string. It surfaces exploitation but may surface legitimate behavior in some environments.

DeviceProcessEvents
| where ProcessCommandLine has_all('${jndi') and ProcessCommandLine has_any('ldap', 'ldaps', 'http', 'rmi', 'dns', 'iiop')
//Removing FPs 
| where not(ProcessCommandLine has_any('stackstorm', 'homebrew')) 

Regex to identify malicious exploit string

This query looks for the malicious string needed to exploit this vulnerability.

DeviceProcessEvents
| where ProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'     
or InitiatingProcessCommandLine matches regex @'(?i)\$\{jndi:(ldap|http|https|ldaps|dns|rmi|iiop):\/\/(\$\{([a-z]){1,20}:([a-z]){1,20}\})?(([a-zA-Z0-9]|-){2,100})?(\.([a-zA-Z0-9]|-){2,100})?\.([a-zA-Z0-9]|-){2,100}\.([a-z0-9]){2,20}(\/).*}'

Suspicious process event creation from VMWare Horizon TomcatService

This query identifies anomalous child processes from the ws_TomcatService.exe process associated with the exploitation of the Log4j vulnerability in VMWare Horizon installations. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where InitiatingProcessFileName has "ws_TomcatService.exe"
| where FileName != "repadmin.exe"

Suspicious JScript staging comment

This query identifies a unique string present in malicious PowerShell commands attributed to threat actors exploiting vulnerable Log4j applications. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has "VMBlastSG"

Suspicious PowerShell curl flags

This query identifies unique, uncommon PowerShell flags used by curl to post the results of an attacker-executed command back to the command-and-control infrastructure. If the event is a true positive, the contents of the “Body” argument are Base64-encoded results from an attacker-issued comment. These events warrant further investigation to determine if they are in fact related to a vulnerable Log4j application.

DeviceProcessEvents
| where FileName has "powershell.exe"
| where ProcessCommandLine has_all("-met", "POST", "-Body")

Microsoft Defender for Cloud

Microsoft Defender for Cloud’s threat detection capabilities have been expanded to surface exploitation of CVE-2021-44228 in several relevant security alerts:

On Windows:

• Detected obfuscated command line
• Suspicious use of PowerShell detected

On Linux:

• Suspicious file download
• Possible Cryptocoinminer download detected
• Process associated with digital currency mining detected
• Potential crypto coin miner started
• A history file has been cleared
• Suspicious Shell Script Detected
• Suspicious domain name reference
• Digital currency mining related behavior detected
• Behavior similar to common Linux bots detected

Microsoft Defender for IoT

Microsoft Defender for IoT has released a dedicated threat Intelligence update package for detecting Log4j 2 exploit attempts on the network (example below).  

Figure 19. Microsoft Defender for IoT alert 

The package is available for download from the Microsoft Defender for IoT portal (Click Updates, then Download file (MD5: 4fbc673742b9ca51a9721c682f404c41).  

Figure 20. Microsoft Defender for IoT sensor threat intelligence update

Microsoft Defender for IoT now pushes new threat intelligence packages to cloud-connected sensors upon release, click here for more information. Starting with sensor version 10.3, users can automatically receive up-to-date threat intelligence packages through Microsoft Defender for IoT.

Working with automatic updates reduces operational effort and ensures greater security. Enable automatic updating on the Defender for IoT portal by onboarding your cloud-connected sensor with the toggle for Automatic Threat Intelligence Updates turned on. For more information about threat intelligence packages in Defender for IoT, please refer to the documentation.

Microsoft Sentinel

A new Microsoft Sentinel solution has been added to the Content Hub that provides a central place to install Microsoft Sentinel specific content to monitor, detect, and investigate signals related to exploitation of the CVE-2021-44228 vulnerability.

Figure 21. Log4j Vulnerability Detection solution in Microsoft Sentinel

To deploy this solution, in the Microsoft Sentinel portal, select Content hub (Preview) under Content Management, then search for Log4j in the search bar. Select the Log4j vulnerability detection solution, and click Install. Learn how to centrally discover and deploy Microsoft Sentinel out-of-the-box content and solutions.

Figure 22. Microsoft Sentinel Analytics showing detected Log4j vulnerability

Note: We recommend that you check the solution for updates periodically, as new collateral may be added to this solution given the rapidly evolving situation. This can be verified on the main Content hub page.

Microsoft Sentinel queries

Microsoft Sentinel customers can use the following detection queries to look for this activity:

• Possible exploitation of Apache Log4j component detected

This hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache. Attackers may attempt to launch arbitrary code by passing specific commands to a server, which are then logged and executed by the Log4j component.

• Cryptocurrency miners EXECVE

This query hunts through EXECVE syslog data generated by AUOMS to find instances of cryptocurrency miners being downloaded. It returns a table of suspicious command lines.

• Azure WAF Log4j CVE-2021-44228 hunting

This hunting query looks in Azure Web Application Firewall data to find possible exploitation attempts for CVE-2021-44228 involving Log4j vulnerability.

• Log4j vulnerability exploit aka Log4Shell IP IOC

This hunting query identifies a match across various data feeds for IP IOCs related to the Log4j exploit described in CVE-2021-44228.

• Suspicious shell script detected

This hunting query helps detect post-compromise suspicious shell scripts that attackers use for downloading and executing malicious files. This technique is often used by attackers and was recently used to exploit the vulnerability in Log4j component of Apache to evade detection and stay persistent or for more exploitation in the network.

• Azure WAF matching for CVE-2021-44228 Log4j vulnerability

This query alerts on a positive pattern match by Azure WAF for CVE-2021-44228 Log4j exploitation attempt. If possible, it then decodes the malicious command for further analysis.

• Suspicious Base64 download activity detected

This hunting query helps detect suspicious encoded Base64 obfuscated scripts that attackers use to encode payloads for downloading and executing malicious files. This technique is often used by attackers and was recently used to the Log4j vulnerability in order to evade detection and stay persistent in the network.

• Linux security-related process termination activity detected

This query alerts on attempts to terminate processes related to security monitoring. Attackers often try to terminate such processes post-compromise as seen recently to exploit the CVE-2021-44228 vulnerability.

• Suspicious manipulation of firewall detected via Syslog data

This query uses syslog data to alert on any suspicious manipulation of firewall to evade defenses. Attackers often perform such operations as seen recently to exploit the CVE-2021-44228 vulnerability for C2 communications or exfiltration.

• User agent search for Log4j exploitation attempt

This query uses various log sources having user agent data to look for CVE-2021-44228 exploitation attempt based on user agent pattern.

• Network connections to LDAP port for CVE-2021-44228 vulnerability

This hunting query looks for connection to LDAP port to find possible exploitation attempts for CVE-2021-44228.

• Linux toolkit detected

This query uses syslog data to alert on any attack toolkits associated with massive scanning or exploitation attempts against a known vulnerability

• Container miner activity

This query uses syslog data to alert on possible artifacts associated with containers running images related to digital cryptocurrency mining.

• Network connection to new external LDAP server

This query looks for outbound network connections using the LDAP protocol to external IP addresses, where that IP address has not had an LDAP network connection to it in the 14 days preceding the query timeframe. This could indicate someone exploiting a vulnerability such as CVE-2021-44228 to trigger the connection to a malicious LDAP server.

Azure Firewall Premium 

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios including UDP, TCP, HTTP/S protocols since December 10th, 2021. Below screenshot shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Recommendation: Customers are recommended to configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2021-44228 exploit.  

Figure 23. Azure Firewall Premium portal

Customers using Azure Firewall Standard can migrate to Premium by following these directions. Customers new to Azure Firewall premium can learn more about Firewall Premium.

Azure Web Application Firewall (WAF)

In response to this threat, Azure Web Application Firewall (WAF) has updated Default Rule Set (DRS) versions 1.0/1.1 available for Azure Front Door global deployments, and OWASP ModSecurity Core Rule Set (CRS) version 3.0/3.1 available for Azure Application Gateway V2 regional deployments.

To help detect and mitigate the Log2Shell vulnerability by inspecting requests’ headers, URI, and body, we have released the following:

• For Azure Front Door deployments, we have updated the rule 944240 “Remote Command Execution” under Managed Rules
• For Azure Application Gateway V2 regional deployments, we have introduced a new rule Known-CVEs/800100 in the rule group Known-CVEs under Managed Rules

These rules are already enabled by default in block mode for all existing WAF Default Rule Set (DRS) 1.0/1.1 and OWASP ModSecurity Core Rule Set (CRS) 3.0/3.1 configurations. Customers using WAF Managed Rules would have already received enhanced protection for Log4j 2 vulnerabilities (CVE-2021-44228 and CVE-2021-45046); no additional action is needed.

Recommendation: Customers are recommended to enable WAF policy with Default Rule Set 1.0/1.1 on their Front Door deployments, or with OWASP ModSecurity Core Rule Set (CRS) versions 3.0/3.1 on Application Gateway V2 to immediately enable protection from this threat, if not already enabled. For customers who have already enabled DRS 1.0/1.1 or CRS 3.0/3.1, no action is needed. We will continue to monitor threat patterns and modify the above rule in response to emerging attack patterns as required.

Figure 24. Remote Code Execution rule for Default Rule Set (DRS) versions 1.0/1.1 

Figure 25. Remote Code Execution rule for OWASP ModSecurity Core Rule Set (CRS) version 3.1

Note: The above protection is also available on Default Rule Set (DRS) 2.0 preview version and OWASP ModSecurity Core Rule Set (CRS) 3.2 preview version, which are available on Azure Front Door Premium and Azure Application Gateway V2 respectively. Customers using Azure CDN Standard from Microsoft can also turn on the above protection by enabling DRS 1.0.

More information about Managed Rules and Default Rule Set (DRS) on Azure Web Application Firewall can be found here. More information about Managed Rules and OWASP ModSecurity Core Rule Set (CRS) on Azure Web Application Firewall can be found here.

Indicators of compromise (IOCs)

Microsoft Threat Intelligence Center (MSTIC) has provided a list of IOCs related to this attack and will update them with new indicators as they are discovered: https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample Data/Feeds/Log4j_IOC_List.csv

Microsoft will continue to monitor this dynamic situation and will update this blog as new threat intelligence and detections/mitigations become available.

Revision history

[01/21/2022] – Threat and vulnerability management can now discover vulnerable Log4j libraries, including Log4j files and other files containing Log4j, packaged into Uber-JAR files.

[01/19/2022] New information about an unrelated vulnerability we discovered while investigating Log4j attacks

[01/11/2022] New threat and vulnerability management capabilities to apply mitigation directly from the portal, as well as new advanced hunting queries

[01/10/2022] Added new information about a China-based ransomware operator targeting internet-facing systems and deploying the NightSky ransomware

[01/07/2022] Added a new rule group in Azure Web Application Firewall (WAF)

[12/27/2021] New capabilities in threat and vulnerability management including a new advanced hunting schema and support for Linux, which requires updating the Microsoft Defender for Linux client; new Microsoft Defender for Containers solution.

[12/22/2021] Added new protections across Microsoft 365 Defender, including Microsoft Defender for Office 365.

[12/21/2021] Added a note on testing services and assumed benign activity and additional guidance to use the Need help? button in the Microsoft 365 Defender portal.

[12/17/2021] New updates to observed activity, including more information about limited ransomware attacks and additional payloads; additional updates to protections from Microsoft 365 Defender and Azure Web Application Firewall (WAF), and new Microsoft Sentinel queries.

[12/16/2021] New Microsoft Sentinel solution and additional Microsoft Defender for Endpoint detections.

[12/15/2021] Details about ransomware attacks on non-Microsoft hosted Minecraft servers, as well as updates to product guidance, including threat and vulnerability management.

[12/14/2021] New insights about multiple threat actors taking advantage of this vulnerability, including nation-state actors and access brokers linked to ransomware.

The post Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability appeared first on Microsoft Security Blog.