The talk DPRK – All grown up will cover how the Democratic People’s Republic of Korea (DPRK) has successfully built computer network exploitation capability over the past 10 years and how threat actors have enabled North Korea to steal billions of dollars in cryptocurrency as well as target organizations associated with satellites and weapons systems. Over this period, North Korean threat actors have developed and used multiple zero-day exploits and have become experts in cryptocurrency, blockchain, and AI technology.

This presentation will also include information on North Korea overcoming sanctions and other financial barriers by the United States and multiple other countries through the deployment of North Korean IT workers in Russia, China, and, other countries. These IT workers masquerade as individuals from countries other than North Korea to perform legitimate IT work and generate revenue for the regime. North Korean threat actors’ focus areas are:

• Stealing money or cryptocurrency to help fund the North Korea weapons programs
• Stealing information pertaining to weapons systems, sanctions information, and policy-related decisions before they occur
• Performing IT work to generate revenue to help fund the North Korea IT weapons program

Meanwhile, in the talk No targets left behind, Microsoft Threat Intelligence analysts will present research on Storm-2077, a Chinese threat actor that conducts intelligence collection targeting government agencies and non-governmental organizations. This presentation will trace how Microsoft assembled the pieces of threat activity now tracked as Storm-2077 to demonstrate how we overcome challenges in tracking overlapping activities and attributing cyber operations originating from China.

This blog summarizes intelligence on threat actors covered by the two Microsoft presentations at CYBERWARCON.

Sapphire Sleet: Social engineering leading to cryptocurrency theft

The North Korean threat actor that Microsoft tracks as Sapphire Sleet has been conducting cryptocurrency theft as well as computer network exploitation activities since at least 2020. Microsoft’s analysis of Sapphire Sleet activity indicates that over 10 million US dollars’ worth of cryptocurrency was stolen by the threat actor from multiple companies over a six-month period.

Masquerading as a venture capitalist

While their methods have changed throughout the years, the primary scheme used by Sapphire Sleet over the past year and a half is to masquerade as a venture capitalist, feigning interest in investing in the target user’s company. The threat actor sets up an online meeting with a target user. On the day of the meeting, when the target user attempts to connect to the meeting, the user receives either a frozen screen or an error message stating that the user should contact the room administrator or support team for assistance.

When the target contacts the threat actor, the threat actor sends a script – a .scpt file (Mac) or a Visual Basic Script (.vbs) file (Windows) – to “fix the connection issue”. This script leads to malware being downloaded onto the target user’s device. The threat actor then works towards obtaining cryptocurrency wallets and other credentials on the compromised device, enabling the threat actor to steal cryptocurrency.  

Posing as recruiters

As a secondary method, Sapphire Sleet masquerades as a recruiter on professional platforms like LinkedIn and reaches out to potential victims. The threat actor, posing as a recruiter, tells the target user that they have a job they are trying to fill and believe that the user would be a good candidate. To validate the skills listed on the target user’s profile, the threat actor asks the user to complete a skills assessment from a website under the threat actor’s control. The threat actor sends the target user a sign-in account and password. In signing in to the website and downloading the code associated with the skills assessment, the target user downloads malware onto their device, allowing the attackers to gain access to the system.

Ruby Sleet: Sophisticated phishing targeting satellite and weapons systems-related targets

Ruby Sleet, a threat actor that Microsoft has been tracking since 2020, has significantly increased the sophistication of their phishing operations over the past several years. The threat actor has been observed signing their malware with legitimate (but compromised) certificates obtained from victims they have compromised. The threat actor has also distributed backdoored virtual private network (VPN) clients, installers, and various other legitimate software.

Ruby Sleet has also been observed conducting research on targets to find what specific software they run in their environment. The threat actor has developed custom capabilities tailored to specific targets. For example, in December 2023, Microsoft Threat Intelligence observed Ruby Sleet carrying out a supply chain attack in which the threat actor successfully compromised a Korean construction company and replaced a legitimate version of VeraPort software with a version that communicates with known Ruby Sleet infrastructure.

Ruby Sleet has targeted and successfully compromised aerospace and defense-related organizations. Stealing aerospace and defense-related technology may be used by North Korea to increase its understanding of missiles, drones, and other related technologies.

North Korean IT workers: The triple threat

In addition to utilizing computer network exploitation through the years, North Korea has dispatched thousands of IT workers abroad to earn money for the regime. These IT workers have brought in hundreds of millions of dollars for North Korea. We consider these North Korean IT workers to be a triple threat, because they:

• Make money for the regime by performing “legitimate” IT work
• May use their access to obtain sensitive intellectual property, source code, or trade secrets at the company
• Steal sensitive data from the company and in some cases ransom the company into paying them in exchange for not publicly disclosing the company’s data

Microsoft Threat Intelligence has observed North Korean IT workers operating out of North Korea, Russia, and China.

Facilitators complicate tracking of IT worker ecosystem

Microsoft Threat Intelligence observed that the activities of North Korean IT workers involved many different parties, from creating accounts on various platforms to accepting payments and moving money to North Korean IT worker-controlled accounts. This makes tracking their activities more challenging than traditional nation-state threat actors.

Since it’s difficult for a person in North Korea to sign up for things such as a bank account or phone number, the IT workers must utilize facilitators to help them acquire access to platforms where they can apply for remote jobs. These facilitators are used by the IT workers for tasks such as creating an account on a freelance job website. As the relationship builds, the IT workers may ask the facilitator to perform other tasks such as:

• Creating or renting their bank account to the North Korean IT worker
• Creating LinkedIn accounts to be used for contacting recruiters to obtain work
• Purchasing mobile phone numbers or SIM cards
• Creating additional accounts on freelance job sites

Fake profiles and portfolios with the aid of AI

One of the first things a North Korean IT worker does is set up a portfolio to show supposed examples of their previous work. Microsoft Threat Intelligence has observed hundreds of fake profiles and portfolios for North Korean IT workers on developer platforms like GitHub.

Additionally, the North Korean IT workers have used fake profiles on LinkedIn to communicate with recruiters and apply for jobs. 

In October 2024, Microsoft found a public repository containing North Korean IT worker files. The repository contained the following information:

• Resumes and email accounts used by the North Korean IT workers
• Infrastructure used by these workers (VPS and VPN accounts along with specific VPS IP addresses)
• Playbooks on conducting identity theft and creating and bidding jobs on freelancer websites without getting flagged
• Actual images and AI-enhanced images of suspected North Korean IT workers
• Wallet information and suspected payments made to facilitators
• LinkedIn, GitHub, Upwork, TeamViewer, Telegram, and Skype accounts
• Tracking sheet of work performed and payments received by these IT workers

Review of the repository indicates that the North Korean IT workers are conducting identity theft and using AI tools such as Faceswap to move their picture over to documents that they have stolen from victims. The attackers are also using Faceswap to take pictures of the North Korean IT workers and move them to more professional looking settings. The pictures created by the North Korean IT workers using AI tools are then utilized on resumes or profiles, sometimes for multiple personas, that are submitted for job applications.

In the same repository, Microsoft Threat Intelligence found photos that appear to be of North Korean IT workers:

Microsoft has observed that, in addition to using AI to assist with creating images used with job applications, North Korean IT workers are experimenting with other AI technologies such as voice-changing software. This aligns with observations shared in earlier blogs showing threat actors using AI as a productivity tool to refine their attack techniques. While we do not see threat actors using combined AI voice and video products as a tactic, we do recognize that if actors were to combine these technologies, it’s possible that future campaigns may involve IT workers using these programs to attempt to trick interviewers into thinking they are not communicating with a North Korean IT worker. If successful, this could allow the North Korean IT workers to do interviews directly and not have to rely on facilitators obtaining work for them by standing in on interviews or selling account access to them.

Getting payment for remote work

The North Korean IT workers appear to be very organized when it comes to tracking payments received.  Overall, this group of North Korean IT workers appears to have made at least 370,000 US dollars through their efforts. 

Protecting organizations from North Korean IT workers

Unfortunately, computer network exploitation and use of IT workers is a low-risk, high-reward technique used by North Korean threat actors. Here are some steps that organizations can take to be better protected:

• Follow guidance from the US Department of State, US Department of the Treasury, and the Federal Bureau of Investigation on how to spot North Korean IT workers.
• Educate human resources managers, hiring managers, and program managers for signs to look for when dealing with suspected North Korean IT workers.
• Use simple non-technical techniques such as asking IT workers to turn on their camera periodically and comparing the person on camera with the one that picked up the laptop from your organization.
• Ask the person on camera to walk through or explain code that they purportedly wrote.

Storm-2077: No targets left behind

Over the past decade, following numerous government indictments and the public disclosure of threat actors’ activities, tracking and attributing cyber operations originating from China has become increasingly challenging as the attackers adjust their tactics. These threat actors continue to conduct operations while using tooling and techniques against targets that often overlap with another threat actor’s operation. While analyzing activity that was affecting a handful of customers, Microsoft Threat Intelligence assembled the pieces of what would be tracked as Storm-2077. Undoubtably, this actor had some victimology and operational techniques that overlapped with a couple of threat actors that Microsoft was already tracking.  

Microsoft assesses that Storm-2077 is a China state threat actor that has been active since at least January 2024. Storm-2077 has targeted a wide variety of sectors, including government agencies and non-governmental organizations in the United States. As we continued to track Storm-2077, we observed that they went after several other industries worldwide, including the Defense Industrial Base (DIB), aviation, telecommunications, and financial and legal services. Storm-2077 overlaps with activity tracked by other security vendors as TAG-100.

We assess that Storm-2077 likely operates with the objective of conducting intelligence collection. Storm-2077 has used phishing emails to gain credentials and, in certain cases, likely exploited edge-facing devices to gain initial access. We have observed techniques that focus on email data theft, which could allow them to analyze the data later without risking immediate loss of access. In some cases, Storm-2077 has used valid credentials harvested from the successful compromise of a system.

We’ve also observed Storm-2077 successfully exfiltrate emails by stealing credentials to access legitimate cloud applications such as eDiscovery applications. In other cases, Storm-2077 has been observed gaining access to cloud environments by harvesting credentials from compromised endpoints. Once administrative access was gained, Storm-2077 created their own application with mail read rights.

Access to email data is crucial for threat actors because it often contains sensitive information that could be utilized later for malicious purposes. Emails can include sign-in credentials, confidential communication, financial records, business secrets, intellectual property, and credentials for accessing critical systems, or employee information. Access to email accounts and the ability to steal email communication could enable an attacker to further their operations.

Microsoft’s talk on Storm-2077 at CYBERWARCON will highlight how vast their targeting interest covers. All sectors appear to be on the table, leaving no targets behind. Our analysts will talk about the challenges of tracking China-based threat actors and how they had to distinctly carve out Storm-2077.

CYBERWARCON Recap

At this year’s CYBERWARCON, Microsoft Security is sponsoring the post-event Fireside Recap. Hosted by Sherrod DeGrippo, this session will feature special guests who will dive into the highlights, key insights, and emerging themes that defined CYBERWARCON 2024. Interviews with speakers will offer exclusive insights and bring the conference’s biggest moments into sharp focus.

Learn more

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 Microsoft shares latest intelligence on North Korean and Chinese threat actors at CYBERWARCON appeared first on Microsoft Security Blog.

Microsoft assesses that credentials acquired from CovertNetwork-1658 password spray operations are used by multiple Chinese threat actors. In particular, Microsoft has observed the Chinese threat actor Storm-0940 using credentials from CovertNetwork-1658. Active since at least 2021, Storm-0940 obtains initial access through password spray and brute-force attacks, or by exploiting or misusing network edge applications and services. Storm-0940 is known to target organizations in North America and Europe, including think tanks, government organizations, non-governmental organizations, law firms, defense industrial base, and others.

As with any observed nation-state threat actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to help secure their environments. In this blog, we provide more information about CovertNetwork-1658 infrastructure, and associated Storm-0940 activity. We also share mitigation recommendations, detection information, and hunting queries that can help organizations identify, investigate, and mitigate associated activity.

What is CovertNetwork-1658?

Microsoft tracks a network of compromised small office and home office (SOHO) routers as CovertNetwork-1658. SOHO routers manufactured by TP-Link make up most of this network. Microsoft uses “CovertNetwork” to refer to a collection of egress IPs consisting of compromised or leased devices that may be used by one or more threat actors.

CovertNetwork-1658 specifically refers to a collection of egress IPs that may be used by one or more Chinese threat actors and is wholly comprised of compromised devices. Microsoft assesses that a threat actor located in China established and maintains this network. The threat actor exploits a vulnerability in the routers to gain remote code execution capability. We continue to investigate the specific exploit by which this threat actor compromises these routers. Microsoft assesses that multiple Chinese threat actors use the credentials acquired from CovertNetwork-1658 password spray operations to perform computer network exploitation (CNE) activities.

Post-compromise activity on compromised routers

After successfully gaining access to a vulnerable router, in some instances, the following steps are taken by the threat actor to prepare the router for password spray operations:

1. Download Telnet binary from a remote File Transfer Protocol (FTP) server
2. Download xlogin backdoor binary from a remote FTP server
3. Utilize the downloaded Telnet and xlogin binaries to start an access-controlled command shell on TCP port 7777
4. Connect and authenticate to the xlogin backdoor listening on TCP port 7777
5. Download a SOCKS5 server binary to router
6. Start SOCKS5 server on TCP port 11288

CovertNetwork-1658 is observed conducting their password spray campaigns through this proxy network to ensure the password spray attempts originate from the compromised devices.

Password spray activity from CovertNetwork-1658 infrastructure

Microsoft has observed multiple password spray campaigns originating from CovertNetwork-1658 infrastructure. In these campaigns, CovertNetwork-1658 submits a very small number of sign-in attempts to many accounts at a target organization. In about 80 percent of cases, CovertNetwork-1658 makes only one sign-in attempt per account per day. Figure 2 depicts this distribution in greater detail.

CovertNetwork-1658 infrastructure is difficult to monitor due to the following characteristics:

• The use of compromised SOHO IP addresses
• The use of a rotating set of IP addresses at any given time. The threat actors had thousands of available IP addresses at their disposal. The average uptime for a CovertNetwork-1658 node is approximately 90 days.
• The low-volume password spray process; for example, monitoring for multiple failed sign-in attempts from one IP address or to one account will not detect this activity

Various security vendors have reported on CovertNetwork-1658 activities, including Sekoia (July 2024) and Team Cymru (August 2024). Microsoft assesses that after these blogs were published, the usage of CovertNetwork-1658 network has declined substantially. The below chart highlights a steady and steep decline in the use of CovertNetwork-1658’s original infrastructure since their activities have been exposed in public reporting as observed in Censys.IO data.

Microsoft assesses that CovertNetwork-1658 has not stopped operations as indicated in recent activity but is likely acquiring new infrastructure with modified fingerprints from what has been publicly disclosed. An observed increase in recent activity may be early evidence supporting this assessment.

Historically, Microsoft has observed an average of 8,000 compromised devices actively engaged in the CovertNetwork-1658 network at any given time. On average, about 20 percent of these devices perform password spraying at any given time. Any threat actor using the CovertNetwork-1658 infrastructure could conduct password spraying campaigns at a larger scale and greatly increase the likelihood of successful credential compromise and initial access to multiple organizations in a short amount of time. This scale, combined with quick operational turnover of compromised credentials between CovertNetwork-1658 and Chinese threat actors, allows for the potential of account compromises across multiple sectors and geographic regions.

Below are User Agent Strings* observed in the password spray activity:

• Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

*Note: We updated this list of User Agent Strings on November 4, 2024 to fix typos.

Observed activity tied to Storm-0940

Microsoft has observed numerous cases where Storm-0940 has gained initial access to target organizations using valid credentials obtained through CovertNetwork-1658’s password spray operations. In some instances, Storm-0940 was observed using compromised credentials that were obtained from CovertNetwork-1658 infrastructure on the same day. This quick operational hand-off of compromised credentials is evidence of a likely close working relationship between the operators of CovertNetwork-1658 and Storm-0940.

After successfully gaining access to a victim environment, in some instances, Storm-0940 has been observed:        

• Using scanning and credential dumping tools to move laterally within the network;
• Attempting to access network devices and install proxy tools and remote access trojans (RATs) for persistence; and
• Attempting to exfiltrate data.

Recommendations

Organizations can defend against password spraying by building credential hygiene and hardening cloud identities. Microsoft recommends the following mitigations to reduce the impact of this threat:

• Educate users on the importance of credential hygiene and avoiding password reuse.
• Enforce multi-factor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times. Microsoft continues to expand MFA defaults for products and services like Azure to broaden MFA adoption.
  • Consider transitioning to a passwordless primary authentication method, such as Azure MFA, certificates, or Windows Hello for Business.
  • Secure Remote Desktop Protocol (RDP) or Windows Virtual Desktop endpoints with MFA to harden against password spray or brute force attacks.
• Enable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA.
• Disable legacy authentication.
• Use a cloud-based identity security solution to identify and detect threats or compromised identities.
• Disable stale or unused accounts.
• Reset account passwords for any accounts targeted during a password spray attack. If a targeted account had system-level permissions, further investigation may be warranted.
• Implement the Azure Security Benchmark and general best practices for securing identity infrastructure, including:
  • Create conditional access policies to allow or disallow access to the environment based on defined criteria.
• • Block legacy authentication with Azure AD by using Conditional Access. Legacy authentication protocols don’t have the ability to enforce MFA, so blocking such authentication methods will prevent password spray attackers from taking advantage of the lack of MFA on those protocols.
  • Enable AD FS web application proxy extranet lockout to protect users from potential password brute force compromise.
• Secure accounts with credential hygiene:
  • Practice the principle of least privilege and audit privileged account activity in your Azure AD environments to slow and stop attackers.
  • Deploy Azure AD Connect Health for ADFS. This captures failed attempts as well as IP addresses recorded in ADFS logs for bad requests via the Risky IP report.
  • Use Azure AD password protection to detect and block known weak passwords and their variants.
  • Turn on identity protection in Azure AD to monitor for identity-based risks and create policies for risky sign ins.
• Educate users about phishing attempts and MFA fatigue attacks. Encourage users to report unsolicited MFA authentication prompts.
• Review your Anomaly detection policies in Defender for Cloud Apps under Microsoft 365 Defender Policies by going to Cloud Apps > Policies > Policy management. Then select Anomaly detection policy.

Detection details

Alerts with the following titles in the Security Center can indicate threat activity on your network:

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alert can indicate associated threat activity:

• Storm-0940 actor activity detected

Microsoft Defender XDR

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

• Password spray attacks originating from single ISP

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

• Password Spray
• Unfamiliar Sign-in properties
• Atypical travel
• Suspicious behavior: Impossible travel activity

Microsoft Defender for Cloud Apps

The following Microsoft Defender for Cloud Apps alerts can indicate associated threat activity:

• Suspicious Administrative Activity
• Impossible travel activity

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Potential Storm-0940 activity           

This query identifies UserAgents obtained from observed activity and AAD SignInEvent attributes that identify potential activity to guide investigation:

//Advanced Hunting Query
let suspAppRes = datatable(appId:string, resourceId:string)
[
    "1950a258-227b-4e31-a9cf-717495945fc2", "00000003-0000-0000-c000-000000000000"
];
let userAgents = datatable(userAgent:string)
[
    "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko",
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" //Low fidelity
];
AADSignInEventsBeta
| where Timestamp >=ago(30d)
| where ApplicationId in ((suspAppRes | project appId)) and ResourceId in ((suspAppRes | project resourceId)) and UserAgent in ((userAgents| project userAgent))
Failed sign-in activity
The following query identifies failed attempts to sign-in from multiple sources that originate from a single ISP. Attackers distribute attacks from multiple IP addresses across a single service provider to evade detection
IdentityLogonEvents
| where Timestamp > ago(4h)
| where ActionType == "LogonFailed"
| where isnotempty(AccountObjectId)
| summarize TargetCount = dcount(AccountObjectId), TargetCountry = dcount(Location), TargetIPAddress = dcount(IPAddress) by ISP
| where TargetCount >= 100
| where TargetCountry >= 5
| where TargetIPAddress >= 25

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.

Potential Storm-0940 activity

This query identifies UserAgents obtained from observed activity and AAD SignInEvent attributes that identify potential activity to guide investigation:

//sentinelquery
let suspAppRes = datatable(appId:string, resourceId:string)
[
    "1950a258-227b-4e31-a9cf-717495945fc2", "00000003-0000-0000-c000-000000000000"
];
let userAgents = datatable(userAgent:string)
[
    "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko",
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36" //Low fidelity
];
SigninLogs
| where TimeGenerated >=ago(30d)
| where AppId  in ((suspAppRes | project appId)) and ResourceIdentity in ((suspAppRes | project resourceId)) and UserAgent in ((userAgents| project userAgent))

Learn more

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 Chinese threat actor Storm-0940 uses credentials from password spray attacks from a covert network appeared first on Microsoft Security Blog.

Storm-0501 has been active as early as 2021, initially observed deploying the Sabbath(54bb47h) ransomware in attacks targeting US school districts, publicly leaking data for extortion, and even directly messaging school staff and parents. Since then, most of the threat actor’s attacks have been opportunistic, as the group began operating as a ransomware-as-a-service (RaaS) affiliate deploying multiple ransomware payloads developed and maintained by other threat actors over the years, including Hive, BlackCat (ALPHV), Hunters International, LockBit, and most recently, Embargo ransomware. The threat actor was also recently observed targeting hospitals in the US.

Storm-0501 is the latest threat actor observed to exploit weak credentials and over-privileged accounts to move from organizations’ on-premises environment to cloud environments. They stole credentials and used them to gain control of the network, eventually creating persistent backdoor access to the cloud environment and deploying ransomware to the on-premises. Microsoft previously observed threat actors such as Octo Tempest and Manatee Tempest targeting both on-premises and cloud environments and exploiting the interfaces between the environments to achieve their goals.

As hybrid cloud environments become more prevalent, the challenge of securing resources across multiple platforms grows ever more critical for organizations. Microsoft is committed to helping customers understand these attacks and build effective defenses against them.

In this blog post, we will go over Storm-0501’s tactics, techniques, and procedures (TTPs), typical attack methods, and expansion to the cloud. We will also provide information on how Microsoft detects activities related to this kind of attack, as well as provide mitigation guidance to help defenders protect their environment.

Analysis of the recent Storm-0501 campaign

On-premises compromise

Initial access and reconnaissance

Storm-0501 previously achieved initial access through intrusions facilitated by access brokers like Storm-0249 and Storm-0900, leveraging possibly stolen compromised credentials to sign in to the target system, or exploiting various known remote code execution vulnerabilities in unpatched public-facing servers. In a recent campaign, Storm-0501 exploited known vulnerabilities in Zoho ManageEngine (CVE-2022-47966), Citrix NetScaler (CVE-2023-4966), and ColdFusion 2016 application (possibly CVE-2023-29300 or CVE-2023-38203). In cases observed by Microsoft, these initial access techniques, combined with insufficient operational security practices by the targets, provided the threat actor with administrative privileges on the target device.

After gaining initial access and code execution capabilities on the affected device in the network, the threat actor performed extensive discovery to find potential desirable targets such as high-value assets and general domain information like Domain Administrator users and domain forest trust. Common native Windows tools and commands, such as systeminfo.exe, net.exe, nltest.exe, tasklist.exe, were leveraged in this phase. The threat actor also utilized open-source tools like ossec-win32 and OSQuery to query additional endpoint information. Additionally, in some of the attacks, we observed the threat actor running an obfuscated version of ADRecon.ps1 called obfs.ps1 or recon.ps1 for Active Directory reconnaissance.

Following initial access and reconnaissance, the threat actor deployed several remote monitoring and management tools (RMMs), such as Level.io, AnyDesk, and NinjaOne to interact with the compromised device and maintain persistence.

Credential access and lateral movement

The threat actor took advantage of admin privileges on the local devices it compromised during initial access and attempted to gain access to more accounts within the network through several methods. The threat actor primarily utilized Impacket’s SecretsDump module, which extracts credentials over the network, and leveraged it across an extensive number of devices to obtain credentials. The threat actor used the compromised credentials to access more devices in the network and then leveraged Impacket again to collect additional credentials. The threat actor then repeated this process until they compromised a large set of credentials that potentially included multiple Domain Admin credentials.

In addition, the threat actor was observed attempting to gather secrets by reading sensitive files and in some cases gathering KeePass secrets from the compromised devices. The threat actor used EncryptedStore’s Find-KeePassConfig.ps1 PowerShell script to output the database location and keyfile/user master key information and launch the KeePass executable to gather the credentials. We assess with medium confidence that the threat actor also performed extensive brute force activity on a few occasions to gain additional credentials for specific accounts.

The threat actor was observed leveraging Cobalt Strike to move laterally across the network using the compromised credentials and using the tool’s command-and-control (C2) capabilities to directly communicate with the endpoints and send further commands. The common Cobalt Strike Beacon file types used in these campaigns were .dll files and .ocx files that were launched by rundll32.exe and regsvr32.exe respectively. Moreover, the “license_id” associated with this Cobalt Strike Beacon is “666”.  The “license_id” definition is commonly referred to as Watermark and is a nine-digit value that is unique per legitimate license provided by Cobalt Strike. In this case, the “license_id” was modified with 3-digit unique value in all the beacon configurations.

In cases we observed, the threat actor’s lateral movement across the campaign ended with a Domain Admin compromise and access to a Domain Controller that eventually enabled them to deploy ransomware across the devices in the network.

Data collection and exfiltration

The threat actor was observed exfiltrating sensitive data from compromised devices. To exfiltrate data, the threat actor used the open-source tool Rclone and renamed it to known Windows binary names or variations of them, such as svhost.exe or scvhost.exe as masquerading means. The threat actor employed the renamed Rclone binaries to transfer data to the cloud, using a dedicated configuration that synchronized files to public cloud storage services such as MegaSync across multiple threads. The following are command line examples used by the threat actor in demonstrating this behavior:

• Svhost.exe copy –filter-from [REDACTED] [REDACTED] config:[REDACTED] -q –ignore-existing –auto-confirm –multi-thread-streams 11 –transfers 11
• scvhost.exe –config C:\Windows\Debug\a.conf copy [REDACTED UNC PATH] [REDACTED]

Defense evasion

The threat actor attempted to evade detection by tampering with security products in some of the devices they got hands-on-keyboard access to. They employed an open-source tool, resorted to PowerShell cmdlets and existing binaries to evade detection, and in some cases, distributed Group Policy Object (GPO) policies to tamper with security products.

On-premises to cloud pivot

In their recent campaign, we noticed a shift in Storm-0501’s methods. The threat actor used the credentials, specifically Microsoft Entra ID (formerly Azure AD), that were stolen from earlier in the attack to move laterally from the on-premises to the cloud environment and establish persistent access to the target network through a backdoor.

Storm-0501 was observed using the following attack vectors and pivot points on the on-premises side to gain subsequent control in Microsoft Entra ID:

Microsoft Entra Connect Sync account compromise

Microsoft Entra Connect, previously known as Azure AD Connect, is an on-premises Microsoft application that plays a critical role in synchronizing passwords and sensitive data between Active Directory (AD) objects and Microsoft Entra ID objects. Microsoft Entra Connect synchronizes the on-premises identity and Microsoft Entra identity of a user account to allow the user to sign in to both realms with the same password. To deploy Microsoft Entra Connect, the application must be installed on an on-premises server or an Azure VM. To decrease the attack surface, Microsoft recommends that organizations deploy Microsoft Entra Connect on a domain-joined server and restrict administrative access to domain administrators or other tightly controlled security groups. Microsoft Incident Response also published recommendations on preventing cloud identity compromise.

Microsoft Entra Connect Sync is a component of Microsoft Entra Connect that synchronizes identity data between on-premises environments and Microsoft Entra ID. During the Microsoft Entra Connect installation process, at least two new accounts (more accounts are created if there are multiple forests) responsible for the synchronization are created, one in the on-premises AD realm and the other in the Microsoft Entra ID tenant. These service accounts are responsible for the synchronization process.

The on-premises account name is prefixed with “MSOL_” and has permissions to replicate directory changes, modify passwords, modify users, modify groups, and more (see full permissions here).

The cloud Microsoft Entra ID account is prefixed with “sync_<Entra Connect server name>_” and has the account display name set to “On-Premises Directory Synchronization Service Account”. This user account is assigned with the Directory Synchronization Accounts role (see detailed permissions of this role here). Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync and helps prevent abuse.

The on-premises and cloud service accounts conduct the syncing operation every few minutes, similar to Password Hash Synchronization (PHS), to uphold real time user experience. Both user accounts mentioned above are crucial for the Microsoft Entra Connect Sync service operations and their credentials are saved encrypted via DPAPI (Data Protection API) on the server’s disk or a remote SQL server.

We can assess with high confidence that in the recent Storm-0501 campaign, the threat actor specifically located Microsoft Entra Connect Sync servers and managed to extract the plain text credentials of the Microsoft Entra Connect cloud and on-premises sync accounts. We assess that the threat actor was able to achieve this because of the previous malicious activities described in this blog post, such as using Impacket to steal credentials and DPAPI encryption keys, and tampering with security products.

Following the compromise of the cloud Directory Synchronization Account, the threat actor can authenticate using the clear text credentials and get an access token to Microsoft Graph. The compromise of the Microsoft Entra Connect Sync account presents a high risk to the target, as it can allow the threat actor to set or change Microsoft Entra ID passwords of any hybrid account (on-premises account that is synced to Microsoft Entra ID).

Cloud session hijacking of on-premises user account

Another way to pivot from on-premises to Microsoft Entra ID is to gain control of an on-premises user account that has a respective user account in the cloud. In some of the Storm-0501 cases we investigated, at least one of the Domain Admin accounts that was compromised had a respective account in Microsoft Entra ID, with multifactor authentication (MFA) disabled, and assigned with a Global Administrator role. It is important to mention that the sync service is unavailable for administrative accounts in Microsoft Entra, hence the passwords and other data are not synced from the on-premises account to the Microsoft Entra account in this case. However, if the passwords for both accounts are the same, or obtainable by on-premises credential theft techniques (i.e. web browsers passwords store), then the pivot is possible.

If a compromised on-premises user account is not assigned with an administrative role in Microsoft Entra ID and is synced to the cloud and no security boundaries such as MFA or Conditional Access are set, then the threat actor could escalate to the cloud through the following:

1. If the password is known, then logging in to Microsoft Entra is possible from any device.
2. If the password is unknown, the threat actor can reset the on-premises user password, and after a few minutes the new password will be synced to the cloud.
3. If they hold credentials of a compromised Microsoft Entra Directory Synchronization Account, they can set the cloud password using AADInternals’ Set-AADIntUserPassword cmdlet.

If MFA for that user account is enabled, then authentication with the user will require the threat actor to tamper with the MFA or gain control of a device owned by the user and subsequently hijack its cloud session or extract its Microsoft Entra access tokens along with their MFA claims.

MFA is a security practice that requires users to provide two or more verification factors to gain access to a resource and is a recommended security practice for all users, especially for privileged administrators. A lack of MFA or Conditional Access policies limiting the sign-in options opens a wide door of possibilities for the attacker to pivot to the cloud environment, especially if the user has administrative privileges. To increase the security of admin accounts, Microsoft is rolling out additional tenant-level security measures to require MFA for all Azure users.

Impact

Cloud compromise leading to backdoor

Following a successful pivot from the on-premises environment to the cloud through the compromised Microsoft Entra Connect Sync user account or the cloud admin account compromised through cloud session hijacking, the threat actor was able to connect to Microsoft Entra (portal/MS Graph) from any device, using a privileged Microsoft Entra ID account, such as a Global Administrator, and was no longer limited to the compromised devices.

Once Global Administrator access is available for Storm-0501, we observed them creating a persistent backdoor access for later use by creating a new federated domain in the tenant. This backdoor enables an attacker to sign in as any user of the Microsoft Entra ID tenant in hand if the Microsoft Entra ID user property ImmutableId is known or set by the attackers. For users that are configured to be synced by the Microsoft Entra Connect service, the ImmutableId property is automatically populated, while for users that are not synced the default value is null. However, users with administrative privileges can add an ImmutableId value, regardless.

The threat actor used the open-source tool AADInternals, and its Microsoft Entra ID capabilities to create the backdoor. AADInternals is a PowerShell module designed for security researchers and penetration testers that provides various methods for interacting and testing Microsoft Entra ID and is commonly used by Storm-0501. To create the backdoor, the threat actor first needed to have a domain of their own that is registered to Microsoft Entra ID. The attacker’s next step is to determine whether the target domain is managed or federated. A federated domain in Microsoft Entra ID is a domain that is configured to use federation technologies, such as Active Directory Federation Services (AD FS), to authenticate users. If the target domain is managed, then the attackers need to convert it to a federated one and provide a root certificate to sign future tokens upon user authentication and authorization processes. If the target domain is already federated, then the attackers need to add the root certificate as “NextSigningCertificate”.

Once a backdoor domain is available for use, the threat actor creates a federation trust between the compromised tenant, and their own tenant. The threat actor uses the AADInternals commands that enable the creation of Security Assertion Markup Language (SAML or SAML2) tokens, which can be used to impersonate any user in the organization and bypass MFA to sign in to any application. Microsoft observed the actor using the SAML token sign in to Office 365.

On-premises compromise leading to ransomware

Once the threat actor achieved sufficient control over the network, successfully extracted sensitive files, and managed to move laterally to the cloud environment, the threat actor then deployed the Embargo ransomware across the organization. We observed that the threat actor did not always resort to ransomware distribution, and in some cases only maintained backdoor access to the network.

Embargo ransomware is a new strain developed in Rust, known to use advanced encryption methods. Operating under the RaaS model, the ransomware group behind Embargo allows affiliates like Storm-0501 to use its platform to launch attacks in exchange for a share of the ransom. Embargo affiliates employ double extortion tactics, where they first encrypt a victim’s files and threaten to leak stolen sensitive data unless a ransom is paid.

In the cases observed by Microsoft, the threat actor leveraged compromised Domain Admin accounts to distribute the Embargo ransomware via a scheduled task named “SysUpdate” that was registered via GPO on the devices in the network. The ransomware binaries names that were used were PostalScanImporter.exe and win.exe. Once the files on the target devices were encrypted, the encrypted files extension changed to .partial, .564ba1, and .embargo.

Mitigation and protection guidance

Microsoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory Synchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync as part of ongoing security hardening. This change helps prevent threat actors from abusing Directory Synchronization Accounts in attacks.

Customers may also refer to Microsoft’s human-operated ransomware overview for general hardening recommendations against ransomware attacks.

The other techniques used by threat actors and described in this blog can be mitigated by adopting the following security measures:

• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID environments to slow and stop attackers.
• Enable Conditional Access policies – Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
  • Set a Conditional Access policy to limit the access of Microsoft Entra ID sync accounts from untrusted IP addresses to all cloud apps. The Microsoft Entra ID sync account is identified by having the role ‘Directory Synchronization Accounts’. Please refer to the Advanced Hunting section and check the relevant query to get those IP addresses.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Follow Microsoft’s best practices for securing Active Directory Federation Services.  
• Refer to Azure Identity Management and access control security best practices for further steps and recommendations to manage, design, and secure your Azure AD environment can be found by referring.
• Ensure Microsoft Defender for Cloud Apps connectors are turned on for your organization to receive alerts on the Microsoft Entra ID sync account and all other users.
• Enable protection to prevent by-passing of cloud Microsoft Entra MFA when federated with Microsoft Entra ID.
• Set the validatingDomains property of federatedTokenValidationPolicy to “all” to block attempts to sign-in to any non-federated domain (like .onmicrosoft.com) with SAML tokens.
• Turn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based conditional access policies to remediate risky sign-ins.
• Turn on tamper protection features to prevent attackers from stopping security services such as Microsoft Defender for Endpoint, which can help prevent hybrid cloud environment attacks such as Microsoft Entra Connect abuse.
• Refer to the recommendations in our attacker technique profile, including use of Windows Defender Application Control or AppLocker to create policies to block unapproved information technology (IT) management tools to protect against the abuse of legitimate remote management tools like AnyDesk or Level.io.
• Run endpoint detection and response (EDR) in block mode so that 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 detected post-breach.
• Turn on investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to help remediate alerts, significantly reducing alert volume.

Detection details

Alerts with the following names can be in use when investigating the current campaign of Storm-0501.

Microsoft Defender XDR detections

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects the Cobalt Strike Beacon as the following:

• Behavior:Win32/CobaltStrike
• Backdoor:Win64/CobaltStrike
• HackTool:Win64/CobaltStrike

Additional Cobalt Strike components are detected as the following:

• TrojanDropper:PowerShell/Cobacis
• Trojan:Win64/TurtleLoader.CS
• Exploit:Win32/ShellCode.BN

Microsoft Defender Antivirus detects tools that enable Microsoft Entra ID enumeration as the following malware: 

• Backdoor:Win32/SuspAadInternalsUsage

Embargo Ransomware threat components are detected as the following:

• Ransom:Win32/Embargo

Microsoft Defender for Endpoint 

Alerts with the following titles in the security center can indicate threat activity related to Storm-0501 on your network:

• Ransomware-linked Storm-0501 threat actor detected

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report. 

• Possible Adobe ColdFusion vulnerability exploitation
• Compromised account conducting hands-on-keyboard attack
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike)
• Ongoing hands-on-keyboard attack via Impacket toolkit
• Suspicious Microsoft Defender Antivirus exclusion
• Attempt to turn off Microsoft Defender Antivirus protection
• Renaming of legitimate tools for possible data exfiltration
• BlackCat ransomware
• ‘Embargo’ ransomware was detected and was active
• Suspicious Group Policy action detected
• An active ‘Embargo’ ransomware was detected

The following alerts might indicate on-premises to cloud pivot through Microsoft Entra Connect:

• Entra Connect Sync credentials extraction attempt
• Suspicious cmdlets launch using AADInternals
• Potential Entra Connect Tampering
• Indication of local security authority secrets theft

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate activity related to this threat:

• Data exfiltration over SMB
• Suspected DCSync attack

Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps can detect abuse of permissions in Microsoft Entra ID and other cloud apps. Activities related to the Storm-0501 campaign described in this blog are detected as the following:

• Backdoor creation using AADInternals tool
• Compromised Microsoft Entra ID Cloud Sync account
• Suspicious sign-in to Microsoft Entra Connect Sync account
• Entra Connect Sync account suspicious activity following a suspicious login
• AADInternals tool used by a Microsoft Entra Sync account
• Suspicious login from AADInternals tool

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

• CVE-2022-47966

Threat intelligence reports 

Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments: 

• Storm-0501

Advanced hunting 

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Microsoft Entra Connect Sync account exploration

Explore sign-in activity from IdentityLogonEvents, look for uncommon behavior, such as sign-ins from newly seen IP addresses or sign-ins to new applications that are non-sync related.

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

Usually, the activity of the sync account is repetitive, coming from the same IP address to the same application, any deviation from the natural flow is worth investigating. Cloud applications that normally accessed by the Microsoft Entra ID sync account are “Microsoft Azure Active Directory Connect”, “Windows Azure Active Directory”, “Microsoft Online Syndication Partner Portal”

Explore the cloud activity (a.k.a ActionType) of the sync account, same as above, this account by nature performs a certain set of actions including ‘update User.’, ‘update Device.’ and so on. New and uncommon activity from this user might indicate an interactive use of the account, even though it could have been from someone inside the organization it could also be the threat actor.

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

Pay close attention to action from different DeviceTypes or OSPlatforms, this account automated service is performed from one specific machine, so there shouldn’t be any variety in these fields.

Check which IP addresses Microsoft Entra Connect Sync account uses

This query reveals all IP addresses that the default Microsoft Entra Connect Sync account uses so those could be added as trusted IP addresses for the Entra ID sync account (make sure the account is not compromised before relying on this list)

IdentityLogonEvents
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| where ActionType == "LogonSuccess"
| distinct IPAddress
| union (CloudAppEvents
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| distinct IPAddress)
| distinct IPAddress

Federation and authentication domain changes

Explore the addition of a new authentication or federation domain, validate that the new domain is valid one and was purposefully added

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType in ("Set domain authentication.", "Set federation settings on domain.")

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.

Assess your environment for Manage Engine, Netscaler, and ColdFusion vulnerabilities.

DeviceTvmSoftwareVulnerabilities  
| where CveId in ("CVE-2022-47966","CVE-2023-4966","CVE-2023-29300","CVE-2023-38203")   
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,  
CveId,VulnerabilitySeverityLevel  
| join kind=inner ( DeviceTvmSoftwareVulnerabilitiesKB | project CveId, CvssScore,IsExploitAvailable,VulnerabilitySeverityLevel,PublishedDate,VulnerabilityDescription,AffectedSoftware ) on CveId  
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,  
CveId,VulnerabilitySeverityLevel,CvssScore,IsExploitAvailable,PublishedDate,VulnerabilityDescription,AffectedSoftware

Search for file IOC

let selectedTimestamp = datetime(2024-09-17T00:00:00.0000000Z);
let fileName = dynamic(["PostalScanImporter.exe","win.exe","name.dll","248.dll","cs240.dll","fel.ocx","theme.ocx","hana.ocx","obfs.ps1","recon.ps1"]); 
let FileSHA256 = dynamic(["efb2f6452d7b0a63f6f2f4d8db49433259249df598391dd79f64df1ee3880a8d","a9aeb861817f3e4e74134622cbe298909e28d0fcc1e72f179a32adc637293a40","caa21a8f13a0b77ff5808ad7725ff3af9b74ce5b67426c84538b8fa43820a031","53e2dec3e16a0ff000a8c8c279eeeca8b4437edb8ec8462bfbd9f64ded8072d9","827f7178802b2e92988d7cff349648f334bc86317b0b628f4bb9264285fccf5f","ee80f3e3ad43a283cbc83992e235e4c1b03ff3437c880be02ab1d15d92a8348a","de09ec092b11a1396613846f6b082e1e1ee16ea270c895ec6e4f553a13716304","d065623a7d943c6e5a20ca9667aa3c41e639e153600e26ca0af5d7c643384670","c08dd490860b54ae20fa9090274da9ffa1ba163f00d1e462e913cf8c68c11ac1"]); 
search in (AlertEvidence,BehaviorEntities,CommonSecurityLog,DeviceBaselineComplianceProfiles,DeviceEvents,DeviceFileEvents,DeviceImageLoadEvents, DeviceLogonEvents,DeviceNetworkEvents,DeviceProcessEvents,DeviceRegistryEvents,DeviceFileCertificateInfo,DynamicEventCollection,EmailAttachmentInfo,OfficeActivity,SecurityEvent,ThreatIntelligenceIndicator) TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d)) // from September 17th runs the search for 90 days, change the selectedTimestamp accordingly. and  (FileName in (fileName) or OldFileName in (fileName)  or ProfileName in (fileName)  or InitiatingProcessFileName in (fileName)  or InitiatingProcessParentFileName in (fileName)  or InitiatingProcessVersionInfoInternalFileName in (fileName)  or InitiatingProcessVersionInfoOriginalFileName in (fileName)  or PreviousFileName in (fileName)  or ProcessVersionInfoInternalFileName in (fileName) or ProcessVersionInfoOriginalFileName in (fileName) or DestinationFileName in (fileName) or SourceFileName in (fileName)or ServiceFileName in (fileName) or SHA256 in (FileSHA256)  or InitiatingProcessSHA256 in (FileSHA256))

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 Defender XDR detections list above.

• Remote Management Monitoring Network Connections
• Level.io RMM File Signature
• AnyDesk RMM File Signature
• NinjaOne RMM File Signature
• Potential Impacket Execution
• Potential ransomware activity related to Cobalt Strike
• Cobalt DNS Beacon
• C2-NamedPipe
• Renamed Rclone Exfiltration
• Disable Or Modify Windows Defender
• Clearing of forensic evidence from event logs using wevtutil
• Suspicious Signin By AAD Connect Account

Indicators of compromise (IOCs)

The following list provides indicators of compromise (IOCs) observed during our investigation. We encourage our customers to investigate these indicators within their environments and implement detections and protections to identify any past related activity and prevent future attacks against their systems.

References

• The Rust Revolution: New Embargo Ransomware Steps In – Cyble
• Embargo Ransomware Group: The Interview (suspectfile.com)
• https://aadinternals.com/post/aadbackdoor/
• https://aadinternals.com/post/aad-deepdive/

Omri Refaeli, Tafat Gaspar, Vaibhav Deshmukh, Naya Hashem, Charles-Edouard Bettan

Microsoft Threat Intelligence Community

Learn more

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 Storm-0501: Ransomware attacks expanding to hybrid cloud environments appeared first on Microsoft Security Blog.

The vulnerability, identified as CVE-2024-37085, involves a domain group whose members are granted full administrative access to the ESXi hypervisor by default without proper validation. Microsoft disclosed the findings to VMware through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR), and VMWare released a security update. Microsoft recommends ESXi server administrators to apply the updates released by VMware to protect their servers from related attacks, and to follow the mitigation and protection guidance we provide in this blog post. We thank VMWare for their collaboration in addressing this issue.

This blog post presents analysis of the CVE-2024-37085, as well as details of an attack that was observed by Microsoft to exploit the vulnerability. We’re sharing this research to emphasize the importance of collaboration among researchers, vendors, and the security community to continuously advance defenses for the larger ecosystem. As part of Microsoft’s commitment to improve security for all, we will continue to share intelligence and work with the security community to help protect users and organizations across platforms.

CVE-2024-37085 vulnerability analysis

Microsoft security researchers identified a new post-compromise technique utilized by ransomware operators like Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest in numerous attacks. In several cases, the use of this technique has led to Akira and Black Basta ransomware deployments. The technique includes running the following commands, which results in the creation of a group named “ESX Admins” in the domain and adding a user to it:

net group “ESX Admins” /domain /add

net group “ESX Admins” username /domain /add

While investigating the attacks and the described behavior, Microsoft researchers discovered that the threat actors’ purpose for using this command was to utilize a vulnerability in domain-joined ESXi hypervisors that allows the threat actor to elevate their privileges to full administrative access on the ESXi hypervisor. This finding was reported as part of a vulnerability disclosure to VMware earlier this year.

Further analysis of the vulnerability revealed that VMware ESXi hypervisors joined to an Active Directory domain consider any member of a domain group named “ESX Admins” to have full administrative access by default. This group is not a built-in group in Active Directory and does not exist by default. ESXi hypervisors do not validate that such a group exists when the server is joined to a domain and still treats any members of a group with this name with full administrative access, even if the group did not originally exist. Additionally, the membership in the group is determined by name and not by security identifier (SID).

Microsoft researchers identified three methods for exploiting this vulnerability:

1. Adding the “ESX Admins” group to the domain and adding a user to it – This method is actively exploited in the wild by the abovementioned threat actors. In this method, if the “ESX Admins” group doesn’t exist, any domain user with the ability to create a group can escalate privileges to full administrative access to domain-joined ESXi hypervisors by creating such a group, and then adding themselves, or other users in their control, to the group.
2. Renaming any group in the domain to “ESX Admins” and adding a user to the group or use an existing group member – This method is similar to the first, but in this case the threat actor needs a user that has the capability to rename some arbitrary groups and rename one of them to “ESX Admins”. The threat actor can then add a user or use a user that already exists in the group, to escalate privileges to full administrative access. This method was not observed in the wild by Microsoft.
3. ESXi hypervisor privileges refresh – Even if the network administrator assigns any other group in the domain to be the management group for the ESXi hypervisor, the full administrative privileges to members of the “ESX Admins” group are not immediately removed and threat actors still could abuse it. This method was not observed in the wild by Microsoft.

Successful exploitation leads to full administrative access to the ESXi hypervisors, allowing threat actors to encrypt the file system of the hypervisor, which could affect the ability of the hosted servers to run and function. It also allows the threat actor to access hosted VMs and possibly to exfiltrate data or move laterally within the network.

Ransomware operators targeting ESXi hypervisors

Over the last year, we have seen ransomware actors targeting ESXi hypervisors to facilitate mass encryption impact in few clicks, demonstrating that ransomware operators are constantly innovating their attack techniques to increase impact on the organizations they target.

ESXi is a popular product in many corporate networks, and in recent years, we have observed ESXi hypervisors become a favored target for threat actors. These hypervisors could be convenient targets if ransomware operators want to stay under the SOC’s radar because of the following factors:

1. Many security products have limited visibility and protection for an ESXi hypervisor.
2. Encrypting an ESXi hypervisor file system allows one-click mass encryption, as hosted VMs are impacted. This could provide ransomware operators with more time and complexity in lateral movement and credential theft on each device they access.

Therefore, many ransomware threat actors like Storm-0506, Storm-1175, Octo Tempest, Manatee Tempest, and others support or sell ESXi encryptors like Akira, Black Basta, Babuk, Lockbit, and Kuiper (Figure 1). The number of Microsoft Incident Response (Microsoft IR) engagements that involved the targeting and impacting ESXi hypervisors have more than doubled in the last three years.

Storm-0506 Black Basta ransomware deployment

Earlier this year, an engineering firm in North America was affected by a Black Basta ransomware deployment by Storm-0506. During this attack, the threat actor used the CVE-2024-37085 vulnerability to gain elevated privileges to the ESXi hypervisors within the organization.

The threat actor gained initial access to the organization via Qakbot infection, followed by the exploitation of a Windows CLFS vulnerability (CVE-2023-28252) to elevate their privileges on affected devices. The threat actor then used Cobalt Strike and Pypykatz (a Python version of Mimikatz) to steal the credentials of two domain administrators and to move laterally to four domain controllers.

On the compromised domain controllers, the threat actor installed persistence mechanisms using custom tools and a SystemBC implant. The actor was also observed attempting to brute force Remote Desktop Protocol (RDP) connections to multiple devices as another method for lateral movement, and then again installing Cobalt Strike and SystemBC. The threat actor then tried to tamper with Microsoft Defender Antivirus using various tools to avoid detection.

Microsoft observed that the threat actor created the “ESX Admins” group in the domain and added a new user account to it, following these actions, Microsoft observed that this attack resulted in encrypting of the ESXi file system and losing functionality of the hosted virtual machines on the ESXi hypervisor.   The actor was also observed to use PsExec to encrypt devices that are not hosted on the ESXi hypervisor. Microsoft Defender Antivirus and automatic attack disruption in Microsoft Defender for Endpoint were able to stop these encryption attempts in devices that had the unified agent for Defender for Endpoint installed.

Mitigation and protection guidance

Microsoft recommends organizations that use domain-joined ESXi hypervisors to apply the security update released by VMware to address CVE-2024-37085. The following guidelines will also help organizations protect their network from attacks:

• Install software updates – Make sure to install the latest security updates released by VMware on all domain-joined ESXi hypervisors. If installing software updates is not possible, you can use the following recommendations to reduce the risk:
  • Validate the group “ESX Admins” exists in the domain and is hardened.
  • Manually deny access by this group by changing settings in the ESXi hypervisor itself. If full admin access for the Active Directory ESX admins group is not desired, you can disable this behavior using the advanced host setting: ‘Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd’.
  • Change the admin group to a different group in the ESXi hypervisor.
  • Add custom detections in XDR/SIEM for the new group name.  
  • Configure sending ESXi logs to a SIEM system and monitor suspicious full administrative access.
• Credential hygiene – To utilize the different vulnerability methods, threat actors require control of a highly privileged user in the organization. Therefore, our recommendation is making sure to protect your highly privileged accounts in the organization, especially those that can manage other domain groups:
  • Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, always.
  • Enable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Isolate privileged accounts from productivity accounts to protect administrative access to the environment. Refer to this article to understand best practices.
• Improve critical assets posture – Identify your critical assets in the network, such as  ESXi hypervisors and vCenters (a centralized platform for controlling VMware vSphere environments), and make sure to get them protected with latest security updates, proper monitoring procedures and backup and recovery plans. More information can be found in this article.
• Identify vulnerable assets – Use Microsoft Defender Vulnerability Management to reduce risk with continuous vulnerability assessment of ESXi hypervisor out of the box.

Microsoft Defender XDR detections

Microsoft Defender for Endpoint             

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Suspicious modifications to ESX Admins group

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

• New group added suspiciously
• Suspicious Windows account manipulation
• Compromised account conducting hands-on-keyboard attack

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

• Suspicious creation of ESX group

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft Defender Threat Intelligence to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:

• Storm-0506
• Storm-1175
• Octo Tempest 
• Manatee Tempest
• Akira
• Black Basta

Hunting queries

Microsoft Defender XDR

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

This query identifies ESXi hypervisors in the organization:

DeviceInfo
| where OSDistribution =~ "ESXi"
| summarize arg_max(Timestamp, *) by DeviceId

This query identifies ESX Admins group changes in the Active directory:

IdentityDirectoryEvents
| where Timestamp >= ago(30d)
| where AdditionalFields has ('esx admins')

The following queries are for assessing the already discovered ESXi with the Microsoft Defender Vulnerability Management information:

DeviceInfo
| where OSDistribution =~ "ESXi"
| summarize arg_max(Timestamp, *) by DeviceId
| join kind=inner (DeviceTvmSoftwareVulnerabilities) on DeviceId
DeviceInfo
| where OSDistribution =~ "ESXi"
| summarize arg_max(Timestamp, *) by DeviceId
| join kind=inner (DeviceTvmSecureConfigurationAssessment) on DeviceId

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.

Microsoft Sentinel also has a range of hunting queries available in Sentinel GitHub repo or as part of Sentinel solutions that customers can use to detect the activity detailed in this blog in addition to Microsoft Defender detections. These hunting queries include the following:

Qakbot:

• Qakbot hunting queries

Cobalt Strike:

• Cobalt Strike DNS Beaconing
• Potential ransomware activity related to Cobalt Strike
• Suspicious named pipes
• Cobalt Strike Invocation using WMI

References

• https://knowledge.broadcom.com/external/article?legacyId=1025569
• https://core.vmware.com/vmware-vsphere-8-security-configuration-guide
• https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html
• https://blogs.vmware.com/security/2022/09/esxi-targeting-ransomware-the-threats-that-are-after-your-virtual-machines-part-1.html
• https://www.sygnia.co/blog/esxi-ransomware-attacks/?blaid=6088911https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/
• https://www.darkreading.com/cloud-security/agenda-ransomware-vmware-esxi-servers
• https://blog.checkpoint.com/2023/02/06/massive-ransomware-attack-targets-vmware-esxi-servers/amp/
• https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/amp/

Learn more

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 Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption appeared first on Microsoft Security Blog.

In attacks observed by Microsoft Threat Intelligence, threat actors launched phishing or password spraying attacks to compromise user accounts that did not have strong authentication mechanisms and had permissions to create or modify OAuth applications. The threat actors misused the OAuth applications with high privilege permissions to deploy virtual machines (VMs) for cryptocurrency mining, establish persistence following business email compromise (BEC), and launch spamming activity using the targeted organization’s resources and domain name.

Microsoft continuously tracks attacks that misuse of OAuth applications for a wide range of malicious activity. This visibility enhances the detection of malicious OAuth applications via Microsoft Defender for Cloud Apps and prevents compromised user accounts from accessing resources via Microsoft Defender XDR and Microsoft Entra Identity Protection. In this blog post, we present cases where threat actors compromised user accounts and misused OAuth applications for their financially driven attacks, outline recommendations for organizations to mitigate such attacks, and provide detailed information on how Microsoft detects related activity:

• OAuth applications to deploy VMs for cryptomining
• OAuth applications for BEC and phishing
• OAuth applications for spamming activity
• Mitigation steps
• Detections for related techniques
• Hunting guidance

OAuth applications to deploy VMs for cryptomining

Microsoft observed the threat actor tracked as Storm-1283 using a compromised user account to create an OAuth application and deploy VMs for cryptomining. The compromised account allowed Storm-1283 to sign in via virtual private network (VPN), create a new single-tenant OAuth application in Microsoft Entra ID named similarly as the Microsoft Entra ID tenant domain name, and add a set of secrets to the application. As the compromised account had an ownership role on an Azure subscription, the actor also granted ‘Contributor’ role permission for the application to one of the active subscriptions using the compromised account.

The actor also leveraged existing line-of-business (LOB) OAuth applications that the compromised user account had access to in the tenant by adding an additional set of credentials to those applications. The actor initially deployed a small set of VMs in the same compromised subscriptions using one of the existing applications and initiated the cryptomining activity. The actor then later returned to deploy more VMs using the new application. Targeted organizations incurred compute fees ranging from 10,000 to 1.5 million USD from the attacks, depending on the actor’s activity and duration of the attack.

Storm-1283 looked to maintain the setup as long as possible to increase the chance of successful cryptomining activity. We assess that, for this reason, the actor used the naming convention [DOMAINNAME]_[ZONENAME]_[1-9] (the tenant name followed by the region name) for the VMs to avoid suspicion.  

One of the ways to recognize the behavior of this actor is to monitor VM creation in Azure Resource Manager audit logs and look for the activity “Microsoft.Compute/virtualMachines/write” performed by an OAuth application. While the naming convention used by the actor may change in time, it may still include the domain name or region names like “east|west|south|north|central|japan|france|australia|canada|korea|uk|poland|brazil”

Microsoft Threat Intelligence analysts were able to detect the threat actor’s actions and worked with the Microsoft Entra team to block the OAuth applications that were part of this attack. Affected organizations were also informed of the activity and recommended further actions.

OAuth applications for BEC and phishing

In another attack observed by Microsoft, a threat actor compromised user accounts and created OAuth applications to maintain persistence and to launch email phishing activity. The threat actor used an adversary-in-the-middle (AiTM) phishing kit to send a significant number of emails with varying subject lines and URLs to target user accounts in multiple organizations. In AiTM attacks, threat actors attempt to steal session tokens from their targets by sending phishing emails with a malicious URL that leads to a proxy server that facilitates a genuine authentication process.

We observed the following email subjects used in the phishing emails:

• <Username> shared “<Username> contracts” with you.
• <Username> shared “<User domain>” with you.
• OneDrive: You have received a new document today
• <Username> Mailbox password expiry
• Mailbox password expiry
• <Username> You have Encrypted message
• Encrypted message received

After the targets clicked the malicious URL in the email, they were redirected to the Microsoft sign-in page that was proxied by the threat actor’s proxy server. The proxy server set up by the threat actor allowed them to steal the token from the user’s session cookie. Later, the stolen token was leveraged to perform session cookie replay activity. Microsoft was able to confirm during further investigation that the compromised user account was flagged for risky sign-ins when the account was used to sign in from an unfamiliar location and from an uncommon user agent.

For persistence following business email compromise

In some cases, following the stolen session cookie replay activity, the actor leveraged the compromised user account to perform BEC financial fraud reconnaissance by opening email attachments in Microsoft Outlook Web Application (OWA) that contain specific keywords such as “payment” and “invoice”. This action typically precedes financial fraud attacks where the threat actor seeks out financial conversations and attempts to socially engineer one party to modify payment information to an account under attacker control.

Later, to maintain persistence and carry out malicious actions, the threat actor created an OAuth application using the compromised user account. The actor then operated under the compromised user account session to add new credentials to the OAuth application.  

For email phishing activity

In other cases, instead of performing BEC reconnaissance, the threat actor created multitenant OAuth applications following the stolen session cookie replay activity. The threat actor used the OAuth applications to maintain persistence, add new credentials, and then access Microsoft Graph API resource to read emails or send phishing emails.

At the time of analysis, we observed that threat actor created around 17,000 multitenant OAuth applications across different tenants using multiple compromised user accounts. The created applications mostly had two different sets of application metadata properties, such as display name and scope:

• Malicious multitenant OAuth applications with the display name set as “oauth” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.read; people.read” and access to Microsoft Graph API and read emails.
• Malicious multitenant OAuth applications with the display name set as “App” were granted permissions “user.read; mail.readwrite; email; profile; openid; mail.send” and access to Microsoft Graph API to send high volumes of phishing emails to both intra-organizational and external organizations.

In addition, we observed that the threat actor, before using the OAuth applications to send phishing emails, leveraged the compromised user accounts to create inbox rules with suspicious rule names like “…” to move emails to the junk folder and mark them as read. This is to evade detection by the compromised user that the account was used to send phishing emails.

Based on the email telemetry, we observed that the malicious OAuth applications created by the threat actor sent more than 927,000 phishing emails. Microsoft has taken down all the malicious OAuth applications found related to this campaign, which ran from July to November 2023.

OAuth applications for spamming activity

Microsoft also observed large-scale spamming activity through OAuth applications by a threat actor tracked as Storm-1286. The actor launched password spraying attacks to compromise user accounts, the majority of which did not have multifactor authentication (MFA) enabled. We also observed the user agent BAV2ROPC in the sign-in activities related to the compromised accounts, which indicated the use of legacy authentication protocols such as IMAP and SMTP that do not support MFA.

We observed the actor using the compromised user accounts to create anywhere from one to three new OAuth applications in the targeted organization using Azure PowerShell or a Swagger Codegen-based client. The threat actor then granted consent to the applications using the compromised accounts. These applications were set with permissions like email, profile, openid, Mail.Send, User.Read and Mail.Read, which allowed the actor to control the mailbox and send thousands of emails a day using the compromised user account and the organization domain. In some cases, the actor waited for months after the initial access and setting up of OAuth applications before starting the spam activity using the applications. The actor also used legitimate domains to avoid phishing and spamming detectors.

In previous large-scale spam activities, we observed threat actors attempting to compromise admin accounts without MFA and create new LOB applications with high administrative permissions to abuse Microsoft Exchange Online and spread spam. While the activity of the actor then was limited due to actions taken by Microsoft Threat Intelligence such as blocking clusters of the OAuth applications in the past, Storm-1286 continues to try new ways to set a similar high-scale spamming platform in victim organizations by using non-privileged users.

Mitigation steps

Microsoft recommends the following mitigations to reduce the impact of these types of threats.

Mitigate credential guessing attacks risks

A key step in reducing the attack surface is securing the identity infrastructure. The most common initial access vector observed in this attack was account compromise through credential stuffing, phishing, and reverse proxy (AiTM) phishing. In most cases the compromised accounts did not have MFA enabled. Implementing security practices that strengthen account credentials such as enabling MFA reduced the chance of attack dramatically.

Enable conditional access policies

Conditional access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies for User and Sign-in Risk, device compliance and trusted IP address requirements. If your organization has a Microsoft-Managed Conditional Access policy, make sure it is enforced.

Ensure continuous access evaluation is enabled

Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.

Enable security defaults

While some of the features mentioned above require paid subscriptions, the security defaults in Azure AD, which is mainly for organizations using the free tier of Azure Active Directory licensing, are sufficient to better protect the organizational identity platform, as they provide preconfigured security settings such as MFA, protection for privileged activities, and others.

Enable Microsoft Defender automatic attack disruption

Microsoft Defender automatic attack disruption capabilities minimize lateral movement and curbs the overall impact of an attack in its initial stages.

Audit apps and consented permissions

Audit apps and consented permissions in your organization ensure applications are only accessing necessary data and adhering to the principles of least privilege. Use Microsoft Defender for Cloud Apps and its app governance add-on for expanded visibility into cloud activity in your organization and control over applications that access your Microsoft 365 data. 

Educate your organization on application permissions and data accessible by applications with respective permissions to identify malicious apps. 

Enhance suspicious OAuth application investigation with the recommended approach to investigate and remediate risky OAuth apps.

Enable “Review admin consent requests” for forcing new applications review in the tenant.

In addition to the recommendations above, Microsoft has published incident response playbooks for App consent grant investigation and compromised and malicious applications investigation that defenders can use to respond quickly to related threats.

Secure Azure Cloud resources

Deploy MFA to all users, especially for tenant administrators and accounts with Azure VM Contributor privileges. Limit unused quota and monitor for unusual quota increases in your Azure subscriptions, with an emphasis on the resource’s originating creation or modification. Monitor for unexpected sign-in activity from IP addresses associated with free VPN services on high privilege accounts. Connect Microsoft Defender for Cloud Apps connector to ARM or use Microsoft Defender for ARM

With the rise of hybrid work, employees might use their personal or unmanaged devices to access corporate resources, leading to an increased possibility of token theft. To mitigate this risk, organizations can enhance their security measures by obtaining complete visibility into their users’ authentication methods and locations. Refer to the comprehensive blog post Token tactics: How to prevent, detect, and respond to cloud token theft. 

Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links upon time of click and delete sent mail in response to newly acquired threat intelligence. Turn on Safe Attachments policies to check attachments in inbound emails. 

Detections for related techniques

Leveraging its cross-signal capabilities, Microsoft Defender XDR alerts customers using Microsoft Defender for Office 365, Microsoft Defender for Cloud Apps, Application governance add-on, Microsoft Defender for Cloud, and Microsoft Entra ID Protection to detect the techniques covered in the attack through the attack chain. Each product can provide a different aspect for protection to cover the techniques observed in this attack:

Microsoft Defender XDR

Microsoft Defender XDR detects threat components associated with the following activities:

• User compromised in AiTM phishing attack
• User compromised via a known AiTM phishing kit
• BEC financial fraud-related reconnaissance
• BEC financial fraud

Microsoft Defender for Cloud Apps

Using Microsoft Defender for Cloud Apps connectors for Microsoft 365 and Azure, Microsoft Defender XDR raises the following alerts:

• Stolen session cookie was used
• Activity from anonymous IP address
• Activity from a password-spray associated IP address
• User added or updated a suspicious OAuth app
• Risky user created or updated an app that was observed creating a bulk of Azure virtual machines in a short interval
• Risky user updated an app that accessed email and performed email activity through Graph API
• Suspicious creation of OAuth app by compromised user
• Suspicious secret addition to OAuth app followed by creation of Azure virtual machines
• Suspicious OAuth app creation
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app-related activity by compromised user
• Suspicious user signed into a newly created OAuth app
• Suspicious addition of OAuth app permissions
• Suspicious inbox manipulation rule
• Impossible travel activity
• Multiple failed login attempts

App governance

App governance is an add-on to Microsoft Defender for Cloud Apps, which can detect malicious OAuth applications that make sensitive Exchange Online administrative activities along with other threat detection alerts. Activity related to this campaign triggers the following alerts:

• Entra Line-of-Business app initiating an anomalous spike in virtual machine creation
• OAuth app with high scope privileges in Microsoft Graph was observed initiating virtual machine creation
• Suspicious OAuth app used to send numerous emails

To receive this alert, turn on app governance for Microsoft Defender for Cloud Apps.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects threat activity associated with this spamming campaign through the following email security alerts. Note, however, that these alerts may also be triggered by unrelated threat activity. We’re listing them here because we recommend that these alerts be investigated and remediated immediately.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• User restricted from sending email
• Email sending limit exceeded

Microsoft Defender for Cloud

Microsoft Defender for Cloud detects threat components associated with the activities outlined in this article with the following alerts:

• Azure Resource Manager operation from suspicious proxy IP address
• Crypto-mining activity
• Digital currency mining activity
• Suspicious Azure role assignment detected
• Suspicious creation of compute resources detected
• Suspicious invocation of a high-risk ‘Execution’ operation by a service principal detected
• Suspicious invocation of a high-risk ‘Execution’ operation detected
• Suspicious invocation of a high-risk ‘Impact’ operation by a service principal detected

Microsoft Entra Identity Protection

Microsoft Entra Identity Protection detects the threats described with the following alerts:

• Anomalous Token
• Unfamiliar sign-in properties
• Anonymous IP address
• Verified threat actor IP
• Atypical travel

Hunting guidance

Microsoft 365 Defender

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

OAuth application interacting with Azure workloads

let OAuthAppId = <OAuth app ID in question>;
CloudAppEvents
| where Timestamp >ago (7d)  
| where AccountId == OAuthAppId 
| where AccountType== "Application"
| extend Azure_Workloads = RawEventData["operationName"]
| distinct Azure_Workloads by AccountId

Password spray attempts

This query identifies failed sign-in attempts to Microsoft Exchange Online from multiple IP addresses and locations.

IdentityLogonEvents
| where Timestamp > ago(3d)
| where ActionType == "LogonFailed" and LogonType == "OAuth2:Token" and Application == "Microsoft Exchange Online"
| summarize count(), dcount(IPAddress), dcount(CountryCode) by AccountObjectId, AccountDisplayName, bin(Timestamp, 1h)

Suspicious application creation

This query finds new applications added in your tenant.

CloudAppEvents
| where ActionType in ("Add application.", "Add service principal.")
| mvexpand modifiedProperties = RawEventData.ModifiedProperties
| where modifiedProperties.Name == "AppAddress"
| extend AppAddress = tolower(extract('\"Address\": \"(.*)\",',1,tostring(modifiedProperties.NewValue)))
| mvexpand ExtendedProperties = RawEventData.ExtendedProperties
| where ExtendedProperties.Name == "additionalDetails"
| extend OAuthApplicationId = tolower(extract('\"AppId\":\"(.*)\"',1,tostring(ExtendedProperties.Value)))
| project Timestamp, ReportId, AccountObjectId, Application, ApplicationId, OAuthApplicationId, AppAddress

Suspicious email events

NOTE: These queries need to be updated with timestamps related to application creation time before running.

//Identify High Outbound Email Sender
EmailEvents 
| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId)
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| sort by UniqueEmailSentCount desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender sent more than the threshold
//| take 100 //Optional, return only top 100
 
//Identify Suspicious Outbound Email Sender
EmailEvents 
//| where Timestamp between (<start> .. <end>) //Timestamp from the app creation time to few hours upto 24 hours or more 
| where EmailDirection in ("Outbound") 
| project
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId, 
    DetectionMethods,
    NetworkMessageId 
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    UniqueEmailSentCount = dcount(NetworkMessageId),
    SuspiciousEmailCount = dcountif(NetworkMessageId,isnotempty(DetectionMethods))
    by SenderFromAddress, SenderMailFromAddress, SenderObjectId
| extend SuspiciousEmailPercentage = SuspiciousEmailCount/UniqueEmailSentCount * 100 //Calculate the percentage of suspicious email compared to all email sent
| sort by SuspiciousEmailPercentage desc 
//| where UniqueEmailSentCount > <threshold> //Optional, return only if the sender suspicious email percentage is more than the threshold
//| take 100 //Optional, return only top 100

//Identify Recent Emails Sent by Restricted Email Sender
AlertEvidence
| where Title has "User restricted from sending email"
| project AccountObjectId //Identify the user who are restricted to send email
| join EmailEvents on $left.AccountObjectId == $right.SenderObjectId //Join information from Alert Evidence and Email Events
| project
    Timestamp,
    RecipientEmailAddress,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderObjectId,
    SenderIPv4,
    Subject,
    UrlCount,
    AttachmentCount,
    DetectionMethods,
    AuthenticationDetails, 
    NetworkMessageId
| sort by Timestamp desc 
//| take 100 //Optional, return only first 100

BEC recon and OAuth application activity

//High and Medium risk SignIn activity
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode==0
| where RiskLevelDuringSignIn >= 50
| project
    AccountUpn,
    AccountObjectId,
    SessionId,
    RiskLevelDuringSignIn,
    ApplicationId,
    Application

//Oauth Application creation or modification by user who has suspicious sign in activities
AADSignInEventsBeta
| where Timestamp >ago (7d)
| where ErrorCode == 0
| where RiskLevelDuringSignIn >= 50
| project SignInTime=AccountUpn, AccountObjectId, SessionId, RiskLevelDuringSignIn, ApplicationId, Application
| join kind=leftouter (CloudAppEvents | where Timestamp > ago(7d)
| where ActionType in ("Add application.", "Update application.", "Update application – Certificates and secrets management ")
| extend appId = tostring(parse_json(RawEventData.Target[4].ID))
| project
    Timestamp,
    ActionType,
    Application,
    ApplicationId,
    UserAgent,
    ISP,
    AccountObjectId,
    AppName=ObjectName,
    OauthApplicationId=appId,
    RawEventData ) on AccountObjectId
| where isnotempty(ActionType)

 
//Suspicious BEC reconnaisance activity 
let bec_keywords = pack_array("payment", "receipt", "invoice", "inventory"); 
let reconEvents = 
    CloudAppEvents
    | where Timestamp >ago (7d)
    | where ActionType in ("MailItemsAccessed", "Update")
    | where AccountObjectId in ("<Impacted AccountObjectId>")
    | extend SessionId = tostring(parse_json(RawEventData.SessionId))
    | project
        Timestamp,
        ActionType,
        AccountObjectId,
        UserAgent,
        ISP,
        IPAddress,
        SessionId,
        RawEventData;
reconEvents;
let updateActions = reconEvents
    | where ActionType == "Update" 
    | extend Subject=tostring(RawEventData["Item"].Subject)
    | where isnotempty(Subject)
    | where Subject has_any (bec_keywords)
    | summarize UpdateCount=count() by bin (Timestamp, 15m), Subject, AccountObjectId, SessionId, IPAddress;
updateActions;
let mailItemsAccessedActions = reconEvents 
    | where ActionType == "MailItemsAccessed" 
    | extend OperationCount = toint(RawEventData["OperationCount"])
    | summarize TotalCount = sum(OperationCount) by bin (Timestamp, 15m), AccountObjectId, SessionId, IPAddress;
mailItemsAccessedActions;
 
//SignIn to newly created app within Risky Session
AADSignInEventsBeta
| where Timestamp >ago (7d) 
| where AccountObjectId in ("<Impacted AccountObjectId>") and 
SessionId in ("<Risky Session Id>")
| where ApplicationId in ("<Oauth appId>") // Recently added or modified App Id
| project
    AccountUpn,
    AccountObjectId,
    ApplicationId,
    Application,
    SessionId,
    RiskLevelDuringSignIn,
    RiskLevelAggregated,
    Country

// To check suspicious Mailbox rules
CloudAppEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours, usually before spam emails sent
| where AccountObjectId in ("<Impacted AccountObjectId>")
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox", "Set-TransportRule", "New-TransportRule", "Enable-InboxRule", "UpdateInboxRules")
| where isnotempty(IPAddress)
| mvexpand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
| project Timestamp, ReportId, ActionType, AccountObjectId, IPAddress, ISP, RuleName

// To check any suspicious Url clicks from emails before risky signin by the user
UrlClickEvents
| where Timestamp between (start .. end) //Timestamp around time proximity of Risky signin by user
| where AccountUpn has "<Impacted User’s UPN or Email address>" and ActionType has "ClickAllowed"
| project Timestamp,Url,NetworkMessageId

// To fetch the suspicious email details
EmailEvents
| where Timestamp between (start .. end) //Timestamp lookback to be increased gradually to find the email received
| where EmailDirection has "Inbound"
| where RecipientEmailAddress has "<Impacted User’s UPN or Email address>" and NetworkMessageId == "<NetworkMessageId from UrlClickEvents>"
| project SenderFromAddress,SenderMailFromAddress,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount
    
    
// To check if suspicious emails sent for spamming (with similar email subjects, urls etc.)
EmailEvents
| where Timestamp between (start .. end) //Timestamp from the app creation time to few hours upto 24 hours or more
| where EmailDirection in ("Outbound","Intra-org")
| where SenderFromAddress has "<Impacted User’s UPN or Email address>"  or SenderMailFromAddress has "<Impacted User’s UPN or Email address>"
| project RecipientEmailAddress,RecipientObjectId,SenderIPv4,SenderFromDomain, Subject,UrlCount,AttachmentCount,NetworkMessageId

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.

Analytic rules:

• Phishing Link Execution Observed
• Possible AiTM Phishing Attempt Against AAD
• Successful Signins from a Phishing Link
• Signin Password Spray
• Malicious Inbox Rule
• BEC Mailbox Rule

Hunting queries:

• Open Email Link
• Creation of an anomalous number of resources
• Creation of expensive computes in Azure

Learn more

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 Threat actors misuse OAuth applications to automate financially driven attacks appeared first on Microsoft Security Blog.

Storm-0324 (DEV-0324), which overlaps with threat groups tracked by other researchers as TA543 and Sagrid, acts as a distributor in the cybercriminal economy, providing a service to distribute the payloads of other attackers through phishing and exploit kit vectors.  Storm-0324’s tactics focus on highly evasive infection chains with payment and invoice lures. The actor is known to distribute the JSSLoader malware, which facilitates access for the ransomware-as-a-service (RaaS) actor Sangria Tempest (ELBRUS, Carbon Spider, FIN7). Previous distribution activity associated with Storm-0324 included the Gozi infostealer and the Nymaim downloader and locker.

In this blog, we provide a comprehensive analysis of Storm-0324 activity, covering their established tools, tactics, and procedures (TTPs) as observed in past campaigns as well as their more recent attacks. To defend against this threat actor, Microsoft customers can use Microsoft 365 Defender to detect Storm-0324 activity and significantly limit the impact of these attacks on networks. Additionally, by using the principle of least privilege, building credential hygiene, and following the other recommendations we provide in this blog, administrators can limit the destructive impact of ransomware even if the attackers can gain initial access.

Historical malware distribution activity

Storm-0324 manages a malware distribution chain and has used exploit kit and email-based vectors to deliver malware payloads. The actor’s email chains are highly evasive, making use of traffic distribution systems (TDS) like BlackTDS and Keitaro, which provide identification and filtering capabilities to tailor user traffic. This filtering capability allows attackers to evade detection by certain IP ranges that might be security solutions, like malware sandboxes, while also successfully redirecting victims to their malicious download site.

Storm-0324’s email themes typically reference invoices and payments, mimicking services such as DocuSign, Quickbooks, and others. Users are ultimately redirected to a SharePoint-hosted compressed file containing JavaScript that downloads the malicious DLL payload. Storm-0324 has used many file formats to launch the malicious JavaScript including Microsoft Office documents, Windows Script File (WSF), and VBScript, among others.

Storm-0324 has distributed a range of first-stage payloads since at least 2016, including:

• Nymaim, a first-stage downloader and locker
• Gozi version 3, an infostealer
• Trickbot, a modular malware platform
• Gootkit, a banking trojan
• Dridex, a banking trojan
• Sage ransomware
• GandCrab ransomware
• IcedID, a modular information-stealing malware

Since 2019, however, Storm-0324 has primarily distributed JSSLoader, handing off access to ransomware actor Sangria Tempest.

Ongoing Storm-0324 and Sangria Tempest JSSLoader email-based infection chain

Since as early as 2019, Storm-0324 has handed off access to the cybercrime group Sangria Tempest after delivering the group’s first-stage malware payload, JSSLoader. Storm-0324’s delivery chain begins with phishing emails referencing invoices or payments and containing a link to a SharePoint site that hosts a ZIP archive. Microsoft continues to work across its platforms to identify abuse, take down malicious activity, and implement new proactive protections to discourage malicious actors from using our services.

The ZIP archive contains a file with embedded JavaScript code. Storm-0324 has used a variety of files to host the JavaScript code, including WSF and Ekipa publisher files exploiting the CVE-2023-21715 local security feature bypass vulnerability.

When the JavaScript launches, it drops a JSSLoader variant DLL. The JSSLoader malware is then followed by additional Sangria Tempest tooling.

In some cases, Storm-0324 uses protected documents for additional social engineering. By adding the security code or password in the initial communications to the user, the lure document may acquire an additional level of believability for the user. The password also serves as an effective anti-analysis measure because it requires user interaction after launch.

New Teams-based phishing activity

In July 2023, Storm-0324 began using phishing lures sent over Teams with malicious links leading to a malicious SharePoint-hosted file. For this activity, Storm-0324 most likely relies on a publicly available tool called TeamsPhisher. TeamsPhisher is a Python-language program that enables Teams tenant users to attach files to messages sent to external tenants, which can be abused by attackers to deliver phishing attachments. These Teams-based phishing lures by threat actors are identified by the Teams platform as “EXTERNAL” users if external access is enabled in the organization.

Microsoft takes these phishing campaigns very seriously and has rolled out several improvements to better defend against these threats. In accordance with Microsoft policies, we have suspended identified accounts and tenants associated with inauthentic or fraudulent behavior. We have also rolled out enhancements to the Accept/Block experience in one-on-one chats within Teams, to emphasize the externality of a user and their email address so Teams users can better exercise caution by not interacting with unknown or malicious senders . We rolled out new restrictions on the creation of domains within tenants and improved notifications to tenant admins when new domains are created within their tenant.  In addition to these specific enhancements, our development teams will continue to introduce additional preventative and detective measures to further protect customers from phishing attacks.

Recommendations

To harden networks against Storm-0324 attacks, defenders are advised to implement the following:

• Pilot and start deploying phishing-resistant authentication methods for users.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Apply security best practices for Microsoft Teams. Refer to the security guide for Microsoft Teams.
  • Understand and select the best access settings for external collaboration for your organization.
  • Specify trusted Microsoft 365 organizations to define which external domains are allowed or blocked to chat and meet.
• Keep Microsoft 365 auditing enabled so that audit records could be investigated if required.
• Allow only known devices that adhere to Microsoft’s recommended security baselines.
• Educate users about social engineering and credential phishing attacks, including refraining from entering MFA codes sent via any form of unsolicited messages.
  • Educate Microsoft Teams users to verify ‘External’ tagging on communication attempts from external entities, be cautious about what they share, and never share their account information or authorize sign-in requests over chat.
  • Educate Microsoft Teams users about accepting or blocking people outside the organization who send messages in Microsoft Teams.
• Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Enable Zero-hour auto purge (ZAP) in Microsoft Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Practice the principle of least privilege and maintain credential hygiene. Avoid the use of domain-wide, administrator-level service accounts. Restricting local administrative privileges can help limit installation of RATs and other unwanted applications.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• For additional recommendations on hardening your organization against ransomware attacks, refer to our threat overview on human-operated ransomware.

Microsoft customers can turn on attack surface reduction rules to prevent common attack techniques:

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block JavaScript or VBScript from launching downloaded executable content
• Use advanced protection against ransomware

Detection details

Microsoft 365 Defender

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• TrojanSpy:MSIL/JSSLoader
• Trojan:Win32/Gootkit
• Trojan:Win32/IcedId
• Trojan:Win64/IcedId
• Trojan:Win32/Trickbot

Microsoft Defender for Endpoint

Alerts with the following titles in the security center can indicate threat activity on your network:

• Ransomware-linked Storm-0324 threat activity group detected

Hunting queries

Microsoft 365 Defender

Possible TeamsPhisher downloads The following query looks for downloaded files that were potentially facilitated by use of the TeamsPhisher tool. Defenders should customize the SharePoint domain name (‘mysharepointname’) in the query.

let allowedSharepointDomain = pack_array(
'mysharepointname' //customize Sharepoint domain name and add more domains as needed for your query
);
//
let executable = pack_array(
'exe',
'dll',
'xll',
'msi',
'application'
);
let script = pack_array(
'ps1',
'py',
'vbs',
'bat'
);
let compressed = pack_array(
'rar',
'7z',
'zip',
'tar',
'gz'
);
//
let startTime = ago(1d);
let endTime = now();
DeviceFileEvents
| where Timestamp between (startTime..endTime)
| where ActionType =~ 'FileCreated'
| where InitiatingProcessFileName has 'teams.exe'
    or InitiatingProcessParentFileName has 'teams.exe'
| where InitiatingProcessFileName !has 'update.exe'
    and InitiatingProcessParentFileName !has 'update.exe'
| where FileOriginUrl has 'sharepoint'
    and FileOriginReferrerUrl has_any ('sharepoint', 'teams.microsoft')
| extend fileExt = tolower(tostring(split(FileName,'.')[-1]))
| where fileExt in (executable)
    or fileExt in (script)
    or fileExt in (compressed)
| extend fileGroup = iff( fileExt in (executable),'executable','')
| extend fileGroup = iff( fileExt in (script),'script',fileGroup)
| extend fileGroup = iff( fileExt in (compressed),'compressed',fileGroup)
//
| extend sharePoint_domain = tostring(split(FileOriginUrl,'/')[2])
| where not (sharePoint_domain has_any (allowedSharepointDomain))
| project-reorder Timestamp, DeviceId, DeviceName, sharePoint_domain, FileName, FolderPath, SHA256, FileOriginUrl, FileOriginReferrerUrl

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.

• Suspicious Javascript
• Javascript file creation
• Ransomware Triggered
• Signs of Ransomware Activity
• Suspicious Image Load

References

• Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself
• JSSLoader: Recoded and Reloaded (Proofpoint)

Further reading

Microsoft customers can refer to the report on this activity in Microsoft Defender Threat Intelligence and Microsoft 365 Defender for detections, assessment of impact, mitigation and recovery actions, and hunting guidance.

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 Malware distributor Storm-0324 facilitates ransomware access 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.

August 8, 2023 update: Microsoft released security updates to address CVE-2023-36884. Customers are advised to apply patches, which supersede the mitigations listed in this blog, as soon as possible.

Microsoft has identified a phishing campaign conducted by the threat actor tracked as Storm-0978 targeting defense and government entities in Europe and North America. The campaign involved the abuse of CVE-2023-36884, which included a remote code execution vulnerability exploited before disclosure to Microsoft via Word documents, using lures related to the Ukrainian World Congress.

Storm-0978 (DEV-0978; also referred to as RomCom, the name of their backdoor, by other vendors) is a cybercriminal group based out of Russia, known to conduct opportunistic ransomware and extortion-only operations, as well as targeted credential-gathering campaigns likely in support of intelligence operations. Storm-0978 operates, develops, and distributes the RomCom backdoor. The actor also deploys the Underground ransomware, which is closely related to the Industrial Spy ransomware first observed in the wild in May 2022. The actor’s latest campaign detected in June 2023 involved abuse of CVE-2023-36884 to deliver a backdoor with similarities to RomCom.

Storm-0978 is known to target organizations with trojanized versions of popular legitimate software, leading to the installation of RomCom. Storm-0978’s targeted operations have impacted government and military organizations primarily in Ukraine, as well as organizations in Europe and North America potentially involved in Ukrainian affairs. Identified ransomware attacks have impacted the telecommunications and finance industries, among others.

Microsoft 365 Defender detects multiple stages of Storm-0978 activity. Customers who use Microsoft Defender for Office 365 are protected from attachments that attempt to exploit CVE-2023-36884. In addition, customers who use Microsoft 365 Apps (Versions 2302 and later) are protected from exploitation of the vulnerability via Office. Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. More mitigation recommendations are outlined in this blog.

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

Targeting

Storm-0978 has conducted phishing operations with lures related to Ukrainian political affairs and targeting military and government bodies primarily in Europe. Based on the post-compromise activity identified by Microsoft, Storm-0978 distributes backdoors to target organizations and may steal credentials to be used in later targeted operations.

The actor’s ransomware activity, in contrast, has been largely opportunistic in nature and entirely separate from espionage-focused targets. Identified attacks have impacted the telecommunications and finance industries.

Tools and TTPs

Tools

Storm-0978 uses trojanized versions of popular, legitimate software, leading to the installation of RomCom, which Microsoft assesses is developed by Storm-0978. Observed examples of trojanized software include Adobe products, Advanced IP Scanner, Solarwinds Network Performance Monitor, Solarwinds Orion, KeePass, and Signal. To host the trojanized installers for delivery, Storm-0978 typically registers malicious domains mimicking the legitimate software (for example, the malicious domain advanced-ip-scaner[.]com).

In financially motivated attacks involving ransomware, Storm-0978 uses the Industrial Spy ransomware, a ransomware strain first observed in the wild in May 2022, and the Underground ransomware. The actor has also used the Trigona ransomware in at least one identified attack.

Additionally, based on attributed phishing activity, Storm-0978 has acquired exploits targeting zero-day vulnerabilities. Identified exploit activity includes abuse of CVE-2023-36884, including a remote code execution vulnerability exploited via Microsoft Word documents in June 2023, as well as abuse of vulnerabilities contributing to a security feature bypass.

Ransomware activity

In known ransomware intrusions, Storm-0978 has accessed credentials by dumping password hashes from the Security Account Manager (SAM) using the Windows registry. To access SAM, attackers must acquire SYSTEM-level privileges. Microsoft Defender for Endpoint detects this type of activity with alerts such as Export of SAM registry hive.

Storm-0978 has then used the Impacket framework’s SMBExec and WMIExec functionalities for lateral movement.

Microsoft has linked Storm-0978 to previous management of the Industrial Spy ransomware market and crypter. However, since as early as July 2023, Storm-0978 began to use a ransomware variant called Underground, which contains significant code overlaps with the Industrial Spy ransomware.

The code similarity between the two ransomware variants, as well as Storm-0978’s previous involvement in Industrial Spy operations, may indicate that Underground is a rebranding of the Industrial Spy ransomware.

Espionage activity

Since late 2022, Microsoft has identified the following campaigns attributable to Storm-0978. Based on the post-compromise activity and the nature of the targets, these operations were likely driven by espionage-related motivations:

June 2023 – Storm-0978 conducted a phishing campaign containing a fake OneDrive loader to deliver a backdoor with similarities to RomCom. The phishing emails were directed to defense and government entities in Europe and North America, with lures related to the Ukrainian World Congress. These emails led to exploitation via the CVE-2023-36884 vulnerability.

Microsoft Defender for Office 365 detected Storm-0978’s initial use of the exploit targeting CVE-2023-36884 in this phishing activity. Additional recommendations specific to this vulnerability are detailed below.

Notably, during this campaign, Microsoft identified concurrent, separate Storm-0978 ransomware activity against an unrelated target using the same initial payloads. The subsequent ransomware activity against a different victim profile further emphasizes the distinct motivations observed in Storm-0978 attacks.

December 2022 – According to CERT-UA, Storm-0978 compromised a Ukrainian Ministry of Defense email account to send phishing emails. Identified lure PDFs attached to emails contained links to a threat actor-controlled website hosting information-stealing malware.

October 2022 – Storm-0978 created fake installer websites mimicking legitimate software and used them in phishing campaigns. The actor targeted users at Ukrainian government and military organizations to deliver RomCom and likely to obtain credentials of high-value targets.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of activity associated with Storm-0978’s operations.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Defender for Office 365 customers should ensure that Safe Attachments and Safe Links protection is enabled for users with  Zero-hour Auto Purge (ZAP) to remove emails when a URL gets weaponized post-delivery.
• Microsoft 365 Defender customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block process creations originating from PsExec and WMI commands – Some organizations might 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, including Impacket’s WMIexec.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Use advanced protection against ransomware
  • Block all Office applications from creating child processes

CVE-2023-36884 specific recommendations

August 8, 2023 update: Microsoft released security updates to address CVE-2023-36884. Customers are advised to apply patches, which supersede the mitigations below, as soon as possible.

• Customers who use Microsoft Defender for Office 365 are protected from attachments that attempt to exploit CVE-2023-36884.
• In addition, customers who use Microsoft 365 Apps (Versions 2302 and later) are protected from exploitation of the vulnerability via Office.
• In current attack chains, the use of the Block all Office applications from creating child processes attack surface reduction rule prevents the vulnerability from being exploited
• Organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. 
  • No OS restart is required, but restarting the applications that have had the registry key added for them is recommended in case the value was already queried and is cached.
  • Please note that while these registry settings would mitigate exploitation of this issue, it could affect regular functionality for certain use cases related to these applications. For this reason, we suggest testing. To disable the mitigation, delete the registry key or set it to “0”.

Detection details

Microsoft Defender for Office 365

Microsoft Defender for Office 365 customers are protected from attachments that attempt to exploit CVE-2023-36884.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects post-compromise components of this threat as the following malware:

• Ransom:Win32/IndustrialSpy
• Trojan:Win32/RomCom
• Trojan:Win64/RomCom
• HackTool:Win32/Impacket
• HackTool:Python/Impacket
• Exploit:Script/Teefey

Microsoft Defender for Endpoint

Alerts with the following titles in the security center can indicate threat activity on your network:

• Emerging threat activity group Storm-0978 detected

Microsoft Sentinel

Microsoft Sentinel also has 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.

The following content can be used to identify activity described in this blog post:

• Potential Impacket Execution
• Commands executed by WMI on new hosts – potential Impacket

References

• Void Rabisu’s Use of RomCom Backdoor Shows a Growing Shift in Threat Actors’ Goals. Trend Micro
• Technical Analysis of Industrial Spy Ransomware. ZScaler
• CERT-UA#6940. CERT-UA

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 Storm-0978 attacks reveal financial and espionage motives appeared first on Microsoft Security Blog.

While the attack achieved the end goal of a typical AiTM phishing attack followed by business email compromise, notable aspects, such as the use of indirect proxy rather than the typical reverse proxy techniques, exemplify the continuous evolution of these threats. The use of indirect proxy in this campaign provided attackers control and flexibility in tailoring the phishing pages to their targets and further their goal of session cookie theft. After signing in with the stolen cookie through a session replay attack, the threat actors leveraged multifactor authentication (MFA) policies that have not been configured using security best practices in order to update MFA methods without an MFA challenge. A second-stage phishing campaign followed, with more than 16,000 emails sent to the target’s contacts.

This attack highlights the complexity of AiTM attacks and the comprehensive defenses they necessitate. This sophisticated AiTM attack requires beyond the typical remediation measures for identity compromise such as a password reset. Affected organizations need to revoke session cookies and roll back MFA modifications made by the threat actor. The incident also highlights the importance of proactive threat hunting to discover new TTPs on previously known campaigns to surface and remediate these types of threats.

To launch this attack, the attackers used an AiTM phishing kit developed, maintained, and operated by a threat actor that Microsoft tracks as Storm-1167. As part of our threat actor tracking and naming taxonomy, Microsoft uses Storm-#### designations as a temporary name given to an unknown, emerging, or developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

AiTM with indirect proxy

Adversary-in-the-middle (T1557, T1111) is a type of attack that aims to intercept authentication between users and a legitimate authentication service for the purpose of compromising identities or performing other actions. The attackers position themselves between a user and the service to steal credentials and intercept MFA in order to capture the session cookie. The attackers can then replay the session with the stolen session cookie before the token expiration time and impersonate the user without user intervention or MFA. With this session, the attackers could access the affected user’s resources and applications and perform business email compromise attacks and other malicious activities. More details about AiTM campaigns can be found on the blog Attackers use AiTM phishing sites as entry point to further financial fraud.

Unlike campaigns we have previously reported, this attack did not use the reverse proxy method that AiTM kits like EvilProxy and NakedPages use, in which the attacker’s server proxies the request from the application’s legitimate sign-in page. Instead, the attack used AiTM attack with indirect proxy method, in which the attacker presented targets with a website that mimicked the sign-in page of the targeted application, as in traditional phishing attacks, hosted on a cloud service. The said sign-in page contained resources loaded from an attacker-controlled server, which initiated an authentication session with the authentication provider of the target application using the victim’s credentials.

In this AiTM attack with indirect proxy method, since the phishing website is set up by the attackers, they have more control to modify the displayed content according to the scenario. In addition, since the phishing infrastructure is controlled by the attackers, they have the flexibility to create multiple servers to evade detections. Unlike typical AiTM attacks, there are no HTTP packets proxied between the target and the actual website.

When MFA is requested after successful password validation, the server displays a fake MFA page. Once the MFA is provided by the user, the attacker uses the same MFA token in the initiated session with the authentication provider. Following successful authentication, the session token is granted to the attacker, and victim is redirected to another page. The following diagram illustrates the AiTM attack observed in this scenario:

Attack chain: AiTM phishing attack leads to second-stage BEC

Our investigation into an AiTM phishing attack using the Storm-1167 AiTM kit uncovered details of a campaign that led to BEC activity. In the following sections, we present our in-depth analysis of the end-to-end attack chain.

Stage 1: Initial access via trusted vendor compromise

The attack started with a phishing email from one of the target organizations’ trusted vendors. The phishing email was sent with a seven-digit code as the subject. This code was unique for every target organization, which is likely a tracking mechanism for the attacker. The email body included a link to view or download a fax document. The link pointed to a malicious URL hosted on canva[.]com.

Sending phishing emails from a trusted vendor was one of the common behaviors that was observed for this threat actor across multiple targeted organizations. The intent of this behavior is to abuse the trusted vendor relationship and to blend with legitimate email traffic. A few of the target organizations had policies that automatically allow emails from trusted vendors, enabling the attacker to slip past detections.

Stage 2: Malicious URL click

Threat actors often abuse legitimate services and brands to avoid detection. In this scenario, we observed that the attacker leveraged the legitimate service Canva for the phishing campaign. Canva is a graphic design platform that allows users to create social media graphics, presentations, posters, and other visual content. Attackers abused the Canva platform to host a page that shows a fake OneDrive document preview and links to a phishing URL:

Stage 3: AiTM attack

Accessing the URL redirected the user to a phishing page hosted on the Tencent cloud platform that spoofed a Microsoft sign-in page. The final URL was different for every user but showed the same spoofed sign-in page.

After the target provided the password on the phishing page, the attacker then used the credentials in an authentication session created on the target website. When the attacker is prompted with MFA in the authentication session, the attacker modified the phishing page into a forged MFA page (as seen below). Once the target completed the multifactor authentication, the session token was then captured by the attacker.

The phishing pages for the AiTM attack were hosted on IP addresses located in Indonesia. The follow-on sign-ins described in the following sections were also observed from the same IP addresses.

Stage 4: Session cookie replay

In a stolen session cookie replay attack, the attacker uses the valid stolen cookie to impersonate the user, circumventing authentication mechanisms of passwords and MFA. In this campaign, we observed that the attacker signed in with the stolen cookie after a few hours from an IP address based in the United States. The attacker masqueraded as the target with this session replay attack and accessed email conversations and documents hosted in the cloud. In addition, the attacker generated a new access token, allowing them to persist longer in the environment.

Stage 5: MFA method modification

The attacker then proceeded to add a new MFA method for the target’s account, which was through phone based one-time password (OTP), in order to sign in using the user’s stolen credentials undetected. Adding a new MFA method, by default, does not require re-authentication. In this campaign, a common behavior that was observed was the attacker adding OneWaySMS, a phone-based OTP service, as a new MFA method in addition to the existing method used by the target. A phone number with the Iranian country code was observed added as the number used to receive the phone-based OTP.

Stage 6: Inbox rule creation

The attacker later signed in with the new session token and created an Inbox rule with parameters that moved all incoming emails on the user’s mailbox to the Archive folder and marked all the emails as read.

Stage 7: Phishing campaign

Followed by Inbox rule creation, the attacker initiated a large-scale phishing campaign involving more than 16,000 emails with a slightly modified Canva URL. The emails were sent to the compromised user’s contacts, both within and outside of the organization, as well as distribution lists. The recipients were identified based on the recent email threads in the compromised user’s inbox. The subject of the emails contained a unique seven-digit code, possibly a tactic by the attacker to keep track of the organizations and email chains.

Stage 8: BEC tactics

The attacker then monitored the victim user’s mailbox for undelivered and out of office emails and deleted them from the Archive folder. The attacker read the emails from the recipients who raised questions regarding the authenticity of the phishing email and responded, possibly to falsely confirm that the email is legitimate. The emails and responses were then deleted from the mailbox. These techniques are common in any BEC attacks and are intended to keep the victim unaware of the attacker’s operations, thus helping in persistence.

Stage 9: Accounts compromise

The recipients of the phishing emails from within the organization who clicked on the malicious URL were also targeted by another AiTM attack. Microsoft Defender Experts identified all compromised users based on the landing IP and the sign-in IP patterns. 

Stage 10: Second-stage BEC

The attacker was observed initiating another phishing campaign from the mailbox of one of the users who was compromised by the second AiTM attack. Microsoft revoked the compromised user’s session cookie, intervening with the second-stage attack.  

Microsoft Defender Experts: Extending security and threat defense

This AiTM attack’s use of indirect proxy is an example of the threat’s increasingly complex and evolving TTPs to evade and even challenge conventional solutions and best practices. Proactively hunting for and quickly responding to threats thus becomes an even more important aspect in securing organization networks because it provides an added layer to other security remediations and can help address areas of defense evasion.

Microsoft Defender Experts is part of Microsoft’s global network of more than 8,000 security analysts and researchers who, through our managed services like Microsoft Defender Experts for Hunting, help extend organizations’ ability to defend their environment, manage security, and even augment SOC teams. Our experts also enrich our vast cross-domain signals and let us deliver coordinated threat defense in our security products and solutions.

In this incident, because our experts actively research for new AiTM and BEC techniques, they were able to create advanced hunting detections for the Defender Experts service. These detections, combined with our experts’ own analyses of the anomalous emails and user behavior, enabled them to uncover the attack at its early stages, analyze the entire attack chain, and identify and promptly reach out to affected and targeted customers through Defender Experts Notifications. They then continuously monitored the attack for any additional compromised users or changes in the phishing patterns as it rapidly unfolded into a large-scale campaign.

Defender Experts also initiated rapid response with Microsoft 365 Defender to contain the attack including:

• Automatically disrupting the AiTM attack on behalf of the impacted users based on the signals observed in the campaign
• Initiating zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to find and take automated actions on the emails that are a part of the phishing campaign

Defender Experts further worked with customers to remediate compromised identities through the following recommendations:

• Revoking session cookies in addition to resetting passwords
• Revoking the MFA setting changes made by the attacker on the compromised user’s accounts
• Require re-challenging MFA for MFA updates as the default

Mitigation and protection guidance

Microsoft 365 Defender detects suspicious activities related to AiTM phishing attacks and their follow-on activities, such as session cookie theft and attempts to use the stolen cookie to sign into Exchange Online. To further protect themselves from similar attacks, organizations should also consider complementing MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals like user or group membership, IP location information, and device status, among others.

Mitigating AiTM phishing attacks

The general remediation measure for any identity compromise is to reset the password for the compromised user. However, in AiTM attacks, since the sign-in session is compromised, password reset is not an effective solution. Additionally, even if the compromised user’s password is reset and sessions are revoked, the attacker can set up persistence methods to sign-in in a controlled manner by tampering with MFA. For instance, the attacker can add a new MFA policy to sign in with a one-time password (OTP) sent to attacker registered mobile number. With this persistence mechanisms in place, the attacker can have control over the victim’s account despite conventional remediation measures.

While AiTM phishing attempts to circumvent MFA, implementation of MFA still remains an essential pillar in identity security and highly effective at stopping a wide variety of threats. MFA is the reason that threat actors developed the AiTM session cookie theft technique in the first place. Organizations are advised to work with their identity provider to ensure security controls like MFA are in place. Microsoft customers can implement through various methods, such as using the Microsoft Authenticator, FIDO2 security keys, and certificate-based authentication. 

Defenders can also complement MFA with the following solutions and best practices to further protect their organizations from such attacks: 

• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable conditional access policies, especially risk-based access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices, trusted IP address requirements, or risk-based policies with proper access control.
• Implement continuous access evaluation.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Continuously monitor suspicious or anomalous activities. Hunt for sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services). 

Detections

Because AiTM phishing attacks are complex threats, they require solutions that leverage signals from multiple sources. Microsoft 365 Defender uses its cross-domain visibility to detect malicious activities related to AiTM, such as session cookie theft and attempts to use stolen cookies for signing in.

Using Microsoft Defender for Cloud Apps connectors, Microsoft 365 Defender raises AiTM-related alerts in multiple scenarios. For Azure AD customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Defender for Cloud Apps connectors for Office 365 and Azure. In such scenarios, Microsoft 365 Defender raises the following alert:

• Stolen session cookie was used

In addition, signals from these Defender for Cloud Apps connectors, combined with data from the Defender for Endpoint network protection capabilities, also triggers the following Microsoft 365 Defender alert on Azure AD environments:

• Possible AiTM phishing attempt

A specific Defender for Cloud Apps connector for Okta, together with Defender for Endpoint, also helps detect AiTM attacks on Okta accounts using the following alert:

• Possible AiTM phishing attempt in Okta

Other detections that show potentially related activity are the following:

Microsoft Defender for Office 365

• Email messages containing malicious file removed after delivery​
• Email messages from a campaign removed after delivery​
• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL​
• Suspicious email sending patterns detected

Microsoft Defender for Cloud Apps

• Suspicious inbox manipulation rule
• Impossible travel activity
• Activity from infrequent country
• Suspicious email deletion activity

Azure AD Identity Protection

• Anomalous Token
• Unfamiliar sign-in properties
• Unfamiliar sign-in properties for session cookies

Microsoft 365 Defender

• BEC-related credential harvesting attack
• Suspicious phishing emails sent by BEC-related user

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the following analytic templates to find BEC related activities similar to those described in this post:

• Exchange workflow MailItemsAccessed operation anomaly
• Malicious Inbox Rule
• SharePointFileOperation via previously unseen IPs
• SharePointFileOperation via devices with previously unseen user agents
• User login from different countries within 3 hours
• TI Matching Analytics

In addition to the analytic templates listed above Microsoft Sentinel customers can use the following hunting content to perform Hunts for BEC related activities:

• Possible AiTM phishing attempt against Azure AD
• Unfamiliar Signin Correlation with AzurePortal Signin Attempts and AuditLogs
• Multiple users email forwarded to same destination
• Office Mail Rule Creation with suspicious archive mail move activity
• Sign-ins From VPS providers
• Successful sign-in from non-compliant device
• Risky sign-in with new MFA method

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 Detecting and mitigating a multi-stage AiTM phishing and BEC campaign 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. MERCURY is now tracked as Mango Sandstorm and DEV-1084 is now tracked as Storm-1084.

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

Microsoft Threat Intelligence has detected destructive operations enabled by MERCURY, a nation-state actor linked to the Iranian government, that attacked both on-premises and cloud environments. While the threat actors attempted to masquerade the activity as a standard ransomware campaign, the unrecoverable actions show destruction and disruption were the ultimate goals of the operation.

Previous MERCURY attacks have been observed targeting on-premises environments, however, the impact in this case notably also included destruction of cloud resources. Microsoft assesses that MERCURY likely worked in partnership with another actor that Microsoft tracks as DEV-1084, who carried out the destructive actions after MERCURY’s successful operations had gained access to the target environment.

MERCURY likely exploited known vulnerabilities in unpatched applications for initial access before handing off access to DEV-1084 to perform extensive reconnaissance and discovery, establish persistence, and move laterally throughout the network, oftentimes waiting weeks and sometimes months before progressing to the next stage. DEV-1084 was then later observed leveraging highly privileged compromised credentials to perform en masse destruction of resources, including server farms, virtual machines, storage accounts, and virtual networks, and send emails to internal and external recipients.

In this blog post, we detail our analysis of the observed actor activity and related tools. We also share information to the community and industry partners on ways to detect these attacks, including detection details of MERCURY and DEV-1084’s tools in Microsoft 365 Defender, Microsoft Defender for Identity, Microsoft Defender for Cloud Applications, Microsoft Defender Antivirus, and Microsoft Defender for Endpoint. 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.

Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

Who is DEV-1084?

Microsoft tracks the destructive actions documented in this blog post as DEV-1084. DEV-1084 likely worked in partnership with MERCURY—an Iran-based actor that the US Cyber Command has publicly linked to Iran’s Ministry of Intelligence and Security (MOIS). DEV-1084 publicly adopted the DarkBit persona and presented itself as a criminal actor interested in extortion, likely as an attempt to obfuscate Iran’s link to and strategic motivation for the attack.

The link between the DEV-1084 cluster and MERCURY was established based on the following evidence:

• DEV-1084 operators were observed sending threatening emails from 146.70.106[.]89, an IP address previously linked to MERCURY.
• DEV-1084 used MULLVAD VPN, the same VPN provider historically used by MERCURY.
• DEV-1084 used Rport and a customized version of Ligolo. MERCURY has also been observed using Rport and a similar version of Ligolo in previous attacks.
• DEV-1084 used the vatacloud[.]com domain for command and control (C2) during this incident. Microsoft assesses with high-confidence that the vatacloud[.]com domain is controlled by MERCURY operators.

Microsoft assesses that MERCURY gains access to the targets through remote exploitation of an unpatched internet-facing device. MERCURY then handed off access to DEV-1084. It is not currently clear if DEV-1084 operates independently of MERCURY and works with other Iranian actors or if DEV-1084 is an ‘effects based’ sub-team of MERCURY that only surfaces when MERCURY operators are instructed to carry out a destructive attack.

Early activities, related attacker tools and techniques

Microsoft assesses with moderate confidence that the threat actors attempted several times and succeeded to perform initial intrusion leveraging exposed vulnerable applications, for example, continuing to exploit Log4j 2 vulnerabilities in unpatched systems in July 2022.

After gaining access, the threat actors deploy several tools and leverage techniques to maintain persistence, which provide effective and continued access to compromised devices, such as the following:

• Installing web shells
• Adding a local user account and elevating privileges to local administrator
• Installing legitimate remote access tools, such as RPort, Ligolo and eHorus
• Installing a customized PowerShell script backdoor
• Stealing credentials

Once the persistence is established, the threat actors perform extensive discovery leveraging common native Windows tools and commands such as netstat and nltest. Such reconnaissance activities were seen leveraged throughout the attack chain.

The threat actors consistently perform extensive lateral movement actions using the acquired credentials within a targeted environment. These actions mainly involved:

• Remote scheduled tasks to launch their customized PowerShell backdoor
• Windows Management Instrumentation (WMI) to launch commands on devices
• Remote services to run encoded PowerShell commands

After infecting the new devices, the threat actors often installed the same persistence mechanisms as described above. Interestingly, after each main attack step, the actors did not always immediately continue their operations but would wait weeks and sometimes months before moving to the next step.

For execution and communication, the threat actors leverage several C2 servers and sometimes deploy tunnelling tools, such as Ligolo and OpenSSH, commonly leveraged to stay under the radar of security teams and solutions.

On-premises destructive impact

In observed activity, the threat actors leveraged highly privileged credentials and access to domain controllers on on-premises destructive operations to prepare for large-scale encryption of targeted devices.

To do so, they first interfered with security tools using Group Policy Objects (GPO). With defenses impaired, the threat actors proceeded to stage the ransomware payload in the NETLOGON shares on several domain controllers.

GPO was leveraged again to register a scheduled task used to launch the ransomware payload. Finally, the ransomware payload encrypted files found on the file system of the targeted devices by changing the file name extension to DARKBIT and dropped ransom notes.

Moving from on-premises to cloud

To move from on-premises to the cloud, the threat actors had to first compromise two privileged accounts and leverage them to manipulate the Azure Active Directory (Azure AD) Connect agent. Two weeks before the ransomware deployment, the threat actors first used a compromised, highly privileged account to access the device where the Azure Active Directory (Azure AD) Connect agent is installed. We assess with high confidence that the threat actors then used the AADInternals tool to extract the plaintext credentials of a privileged Azure AD account. The threat actors then used these credentials to pivot from the on-premises environment to the Azure AD environment.

Azure AD Connect is an on-premises application for managing hybrid identities through features like password hash synchronization, pass-through authentication, objects synchronization, and others. As part of the express settings installation process, multiple accounts are created both in the on-premises (Windows Server Active Directory) and cloud (Azure AD) environments. The first account is the AD DS Connector Account. The account name is prefixed with MSOL_ and it is created with a long complex password.

This account’s permissions are set based on features enabled during the service’s installation, but in most common scenarios, the account has permissions to replicate directory changes, modify passwords, modify users, modify groups, and so on (see all the permissions here). In addition, during installation, an Azure AD account called the Azure AD Connector Account is also created. This account is used by the synchronization service to manage Azure AD objects. The account is created with a long complex password as well, and by default (if using the express settings) prefixed with Sync_[ServerName]. This user is assigned with the Directory Synchronization Accounts role (see detailed permissions of this role here). In older versions, this account might be assigned with the Global Administrator role.

There are other entities detailed here that are created but are less relevant to this topic.

Extracting credentials

Two weeks before the ransomware deployment, the threat actors were observed using compromised credentials to access the Azure AD Connect device. Next, they set up an SSH tunnel to an attacker-controlled device. On a separate attacker-controlled compromised device, evidence indicates cloning of the AADInternals tool. One of the functions available in this tool’s library is Get-AADIntSyncCredentials, which allows any local administrator on a device where Azure AD Connect is installed to extract the plaintext credentials of both the Azure AD Connector account and the AD DS Connector account.

Shortly before the ransomware deployment, we observed authentication from a known attacker IP address into the Azure AD Connector cloud account. Investigating this sign-in showed that the threat actors were able to access the account on the first attempt without any guessing or modification of the password, indicating that the actors possessed the password for this account. The Azure AD Connector account is configured with single-factor authentication, making it easier for the attacker to gain entry and elevate privileges.

Cloud destructive impact

On the day of the ransomware attack, the threat actors executed multiple actions in the cloud using two privileged accounts. The first account was the compromised Azure AD Connector account, which had Global Administrator permissions as it was set up for an old solution (DirSync). For the second account, which also had Global Administrator permissions, the threat actors leveraged RDP for access into the account. Even though this account had MFA in place, the threat actors accessed it through RDP, which is an open session that evades MFA blocking their activities.

Mass Azure resource deletion

On the same day, a successful sign-in to the Microsoft Azure environment was observed. The threat actors claimed the Global Administrator permission through Azure Privileged Identity Management (PIM) and elevated access to get permissions to the target’s management groups and Azure subscriptions. The Azure AD Connector account and the compromised administrator account were then used to perform significant destruction of the Azure environment—deleting within a few hours server farms, virtual machines, storage accounts, and virtual networks. We assess that the attacker’s goal was to cause data loss and a denial of service (DoS) of the target’s services.

Exchange Web Server API abuse

The actors went on to provide an existing legitimate OAuth application with both the full_access_as_app permission and administrator consent, which granted the threat actors full access to mailboxes through Exchange Web Services.

With the obtained cloud administrator privileges, the threat actors updated the OAuth application with certificates to conduct malicious activities.  These newly added credentials could then be used to issue access tokens and authenticate on behalf of the application to access cloud resources.

We then observed the threat actors using this application’s permissions to perform GetItem operations over many mailboxes in the target environment. They also performed thousands of search activities, which we suspect were attempts to dump mailboxes and/or search for sensitive data in them.

Email impersonation

The threat actors used the compromised administrator account to grant SMTP Send on behalf permissions to the Azure AD Connector account over a high-ranking employee’s mailbox, using the Set-Mailbox PowerShell cmdlet.

Emails were then created and sent both internally and externally.

The timeline below summarizes the sequence of events:

Mitigations for destructive attacks

The techniques used by the actors and described in this blog can be mitigated by adopting the following security measures: 

Recommendations to secure your on-prem environment

• Refer to Microsoft’s blog Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself for recommendations on building strong credential hygiene and other robust measures to defend against ransomware and human operated attacks.
• Enable tamper protection – Tamper protection is a feature in Microsoft Defender for Endpoint that prevents antivirus tampering and misconfiguration by malicious apps and actors. Customers running Intune can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.

Recommendations to secure your Azure AD environment

• Enable Conditional Access policies – Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
• Enable continuous access evaluation – Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.
• Search unified audit logs for the SendAs operation to identify and track emails sent on behalf of a user mailbox.
• Further steps and recommendation to manage, design, and secure your Azure AD environment can be found by referring to Azure Identity Management and access control security best practices.

Detections

Microsoft 365 Defender

The following alerts in Microsoft 365 Defender can be used to detect suspicious operations in Azure related to the attacker activities described in this blog, including destructive activity:

• Access elevation by risky user
• Suspicious Azure resource deletions
• Suspicious Addition of an Exchange related App Role

In addition, the following alert can help detect compromised Azure AD Connect accounts:

• Unusual activities by Azure AD Connect sync account

Microsoft Defender for Cloud Apps

For Microsoft Defender for Cloud Apps with Azure Connector enabled, the following alerts can be used to detect destructive operations in Azure:

• Multiple storage deletion activities
• Multiple delete VM activities

Azure AD Identity Protection

Monitor medium and high severity alerts for highly privileged accounts as they can indicate malicious activity. For example:

• Unfamiliar sign-in properties

Find details of Azure AD Identity Protection alerts here.

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

• Suspicious additions to sensitive groups

For relevant accounts with Honeytoken configured, the following alert can indicate malicious activity:

• Honeytoken activity

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects attempted exploitation and post-exploitation activity and payloads. Turn on cloud-delivered protection to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block most new and unknown threats. Refer to the list of detection names related to exploitation of Log4j 2 vulnerabilities. Detections for the IOCs listed above are listed below:

• Backdoor:PHP/Remoteshell.V
• HackTool:Win32/LSADump
• VirTool:Win32/RemoteExec
• Trojan:PowerShell/Downloader.SB
• Trojan:Win32/Nibtse.G!tsk
• Backdoor:ASP/Shellman.SA
• Ransom:Win64/DarkBit
• VirTool:Win32/AtExecCommand

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate possible presence of the indicators of compromise listed below.

• Mercury actor activity detected
• Ransomware-linked emerging threat actor DEV-1084 detected

Reducing the attack surface

Microsoft Defender for Endpoint customers 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.
• Implement controlled folder access and add folders to the protected folders list to help prevent files from being altered or encrypted by ransomware. Set controlled folder access to Enabled.

Detecting Log4j 2 exploitation

Alerts that indicate threat activity related to the exploitation of the Log4j 2 exploitation should be immediately investigated and remediated. Refer to our Log4j related blogs to learn about this vulnerability and for a list of Microsoft Defender for Endpoint alerts that can indicate exploitation and exploitation attempts.

Detecting post-exploitation activity

Alerts with the following titles may indicate post-exploitation threat activity related to MERCURY activity described in this blog and should be immediately investigated and remediated. These alerts are supported on both Windows and Linux platforms:

Any alert title related to web shell threats, for example:

• ‘WebShell’ backdoor was prevented on an IIS Web server

Any alert title that mentions the DarkBit ransomware threat or DEV-1084, for example:

• ‘DarkBit’ ransomware was blocked
• ‘DarkBit’ ransomware was detected
• ‘DarkBit’ ransomware was prevented
• Ransomware-linked emerging threat actor DEV-1084 detected

Any alert title that mentions suspicious scheduled task creation or execution, for example:

• Suspicious scheduled task

Any alert title that mentions suspected tunneling activity, for example:

• Suspicious SSH tunneling activity

Any alert title that mentions suspected tampering activity, for example:

• Suspicious Microsoft Defender Antivirus exclusion
• Microsoft Defender Antivirus tampering

Any alert title that mentions PowerShell, for example:

• Suspicious process executed PowerShell command
• A malicious PowerShell Cmdlet was invoked on the machine
• Suspicious PowerShell command line
• Suspicious PowerShell download or encoded command execution
• Suspicious remote PowerShell execution

Any alert title related to suspicious remote activity, for example:

• Suspicious RDP session
• An active ‘RemoteExec’ malware was blocked
• Suspicious service registration

Any alert related to persistence:

• Anomaly detected in ASEP registry
• User account created under suspicious circumstances

Any alert title that mentions credential dumping activity or tools, for example:

• Malicious credential theft tool execution detected
• Credential dumping activity observed
• Mimikatz credential theft tool
• ‘DumpLsass’ malware was blocked on a Microsoft SQL server

Microsoft Defender Vulnerability Management

In addition to the mitigations above being presented and managed through Microsoft Defender Vulnerability Management, Microsoft 365 Defender customers can use threat and vulnerability management to identify and remediate devices that are vulnerable to Log4j 2 exploitation. More comprehensive guidance on this capability can be found on this blog: Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability.

Advanced hunting queries

Microsoft 365 Defender

To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:

// Advanced Hunting Query to surface potential Mercury PowerShell script backdoor installation

DeviceFileEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where FolderPath in~ (@"c:\programdata\db.ps1", @"c:\programdata\db.sqlite")
| summarize min(Timestamp), max(Timestamp) by DeviceId, SHA256, InitiatingProcessParentFileName

DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where InitiatingProcessCommandLine has_cs "-EP BYPASS -NoP -W h"
| summarize makeset(ProcessCommandLine), min(Timestamp), max(Timestamp) by DeviceId

// Advanced Hunting Query to surface potential Mercury PowerShell script backdoor initiating commands

DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where InitiatingProcessCommandLine contains_cs @"c:\programdata\db.ps1"
| summarize makeset(ProcessCommandLine), min(Timestamp), max(Timestamp) by DeviceId

//Advanced Hunting Query for Azure resource deletion activity

let PrivEscalation = CloudAppEvents 
| where Application == "Microsoft Azure"
| where ActionType == "ElevateAccess Microsoft.Authorization"
| where ActivityObjects has "Azure Subscription" and ActivityObjects has "Azure Resource Group"
| extend PrivEscalationTime = Timestamp
| project AccountObjectId, PrivEscalationTime ,ActionType;
CloudAppEvents
| join kind = inner PrivEscalation on AccountObjectId
| extend DeletionTime = Timestamp
| where (DeletionTime - PrivEscalationTime) <= 1h
| where Application == "Microsoft Azure"
| where ActionType has "Delete"
|summarize min(DeletionTime), TotalResourcersDeleted =count(), CountOfDistinctResources= dcount(ActionType), DistinctResources=make_set(ActionType) by AccountObjectId

//AHQ used to detect attacker abusing OAuth application during the attack

CloudAppEvents
    | where Application == "Office 365"
    | where ActionType == "Consent to application."
    | where RawEventData.ResultStatus =~ "success"
    | extend UserId = tostring(RawEventData.UserId)
    | mv-expand AdminConsent = RawEventData.ModifiedProperties 
    | where AdminConsent.Name == "ConsentContext.IsAdminConsent" and AdminConsent.NewValue == "True"
    | project ConsentTimestamp =Timestamp, UserId, AccountObjectId, ReportId, ActionType
    | join kind = leftouter (CloudAppEvents  
        | where Application == "Office 365"      
        | where ActionType == "Add app role assignment to service principal."   
        | extend PermissionAddedTo = tostring(RawEventData.Target[3].ID)
        | extend FullAccessPermission = RawEventData.ModifiedProperties 
        | extend OuthAppName = tostring(FullAccessPermission[6].NewValue) // Find app name
        | extend OAuthApplicationId = tostring(FullAccessPermission[7].NewValue) // Find appId
        | extend AppRoleValue = tostring(FullAccessPermission[1].NewValue) // Permission Level
        | where AppRoleValue == "full_access_as_app"
        | project PermissionTime=Timestamp, InitiatingUser=AccountDisplayName, OuthAppName, OAuthApplicationId, AppRoleValue, AccountObjectId, FullAccessPermission
    ) on AccountObjectId

Microsoft Sentinel

Microsoft Sentinel 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 Defender detections list above.

• full_access_as_app Granted To Application
• Potential SSH Tunnel to AAD Connect Host
• Suspicious Sign In by AAD Connect Sync Account
• Malicious web application requests linked with Microsoft Defender for Endpoint
• Web Shell Activity
• Tracking Privileged Account Rare Activity
• Mass Cloud resource deletions Time Series Anomaly
• Consent to Application discovery
• OAuth Application Required Resource Access Update
• Rare application consent
• Credential added after admin consented to ApplicationNew access credential added to Application or Service Principal

Microsoft Sentinel customers can use the TI Mapping analytic (a series of analytics all prefixed with “TI map”) to automatically match the 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

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 protections to identify past related activity and prevent future attacks against their systems.

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

Microsoft Defender Threat Intelligence

Community members and customers can find summary information and all IOCs from this blog post in the linked Microsoft Defender Threat Intelligence article.

References

• https://www.cybercom.mil/Media/News/Article/2897570/iranian-intel-cyber-suite-of-malware-uses-open-source-tools/
• https://ehorus.com/
• https://github.com/nicocha30/ligolo-ng
• https://www.openssh.com/
• https://github.com/Gerenios/AADInternals/blob/master/AADSyncSettings.ps1#L97

The post MERCURY and DEV-1084: Destructive attack on hybrid environment appeared first on Microsoft Security Blog.