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","edx.exe","name.dll","248.dll","cs240.dll","fel.ocx","theme.ocx","hana.ocx","obfs.ps1","recon.ps1"]); 
let FileSHA256 = dynamic(["efb2f6452d7b0a63f6f2f4d8db49433259249df598391dd79f64df1ee3880a8d","a9aeb861817f3e4e74134622cbe298909e28d0fcc1e72f179a32adc637293a40","cbb9c91b5a86887c89d3217af0a4708c5c87852a4be0d37397be89b453ca8cb8","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.

June 2024 update: At the end of May 2024, Microsoft Threat Intelligence observed Storm-1811 using Microsoft Teams as another vector to contact target users. Microsoft assesses that the threat actor uses Teams to send messages and initiate calls in an attempt to impersonate IT or help desk personnel. This activity leads to Quick Assist misuse, followed by credential theft using EvilProxy, execution of batch scripts, and use of SystemBC for persistence and command and control.

Since mid-April 2024, Microsoft Threat Intelligence has observed the threat actor Storm-1811 misusing the client management tool Quick Assist to target users in social engineering attacks. Storm-1811 is a financially motivated cybercriminal group known to deploy Black Basta ransomware. The observed activity begins with impersonation through voice phishing (vishing), followed by delivery of malicious tools, including remote monitoring and management (RMM) tools like ScreenConnect and NetSupport Manager, malware like Qakbot, Cobalt Strike, and ultimately Black Basta ransomware.

Quick Assist is an application that enables a user to share their Windows or macOS device with another person over a remote connection. This enables the connecting user to remotely connect to the receiving user’s device and view its display, make annotations, or take full control, typically for troubleshooting. Threat actors misuse Quick Assist features to perform social engineering attacks by pretending, for example, to be a trusted contact like Microsoft technical support or an IT professional from the target user’s company to gain initial access to a target device.

In addition to protecting customers from observed malicious activity, Microsoft is investigating the use of Quick Assist in these attacks and is working on improving the transparency and trust between helpers and sharers, and incorporating warning messages in Quick Assist to alert users about possible tech support scams. Microsoft Defender for Endpoint detects components of activity originating from Quick Assist sessions as well as follow-on activity, and Microsoft Defender Antivirus detects the malware components associated with this activity.

Organizations can also reduce the risk of attacks by blocking or uninstalling Quick Assist and other remote management tools if the tools are not in use in their environment. Quick Assist is installed by default on devices running Windows 11. Additionally, tech support scams are an industry-wide issue where scammers use scare tactics to trick users into unnecessary technical support services. Educating users on how to recognize such scams can significantly reduce the impact of social engineering attacks. 

Social engineering

One of the social engineering techniques used by threat actors to obtain initial access to target devices using Quick Assist is through vishing attacks. Vishing attacks are a form of social engineering that involves callers luring targets into revealing sensitive information under false pretenses or tricking targets into carrying out actions on behalf of the caller.

For example, threat actors might attempt to impersonate IT or help desk personnel, pretending to conduct generic fixes on a device. In other cases, threat actors initiate link listing attacks – a type of email bombing attack, where threat actors sign up targeted emails to multiple email subscription services to flood email addresses indirectly with subscribed content. Following the email flood, the threat actor impersonates IT support through phone calls to the target user, claiming to offer assistance in remediating the spam issue.

At the end of May 2024, Microsoft observed Storm-1811 using Microsoft Teams to send messages to and call target users. Tenants created by the threat actor are used to impersonate help desk personnel with names displayed as “Help Desk”, “Help Desk IT”, “Help Desk Support”, and “IT Support”. Microsoft has taken action to mitigate this by suspending identified accounts and tenants associated with inauthentic behavior. Apply security best practices for Microsoft Teams to safeguard Teams users.

During the call, the threat actor persuades the user to grant them access to their device through Quick Assist. The target user only needs to press CTRL + Windows + Q and enter the security code provided by the threat actor, as shown in the figure below.

After the target enters the security code, they receive a dialog box asking for permission to allow screen sharing. Selecting Allow shares the user’s screen with the actor.

Once in the session, the threat actor can select Request Control, which if approved by the target, grants the actor full control of the target’s device.

Follow-on activity leading to Black Basta ransomware

Once the user allows access and control, the threat actor runs a scripted cURL command to download a series of batch files or ZIP files used to deliver malicious payloads. Some of the batch scripts observed reference installing fake spam filter updates requiring the targets to provide sign-in credentials. In several cases, Microsoft Threat Intelligence identified such activity leading to the download of Qakbot, RMM tools like ScreenConnect and NetSupport Manager, and Cobalt Strike.

Qakbot has been used over the years as a remote access vector to deliver additional malicious payloads that led to ransomware deployment. In this recent activity, Qakbot was used to deliver a Cobalt Strike Beacon attributed to Storm-1811.

ScreenConnect was used to establish persistence and conduct lateral movement within the compromised environment. NetSupport Manager is a remote access tool used by multiple threat actors to maintain control over compromised devices. An attacker might use this tool to remotely access the device, download and install additional malware, and launch arbitrary commands.

The mentioned RMM tools are commonly used by threat actors because of their extensive capabilities and ability to blend in with the environment. In some cases, the actors leveraged the OpenSSH tunneling tool to establish a secure shell (SSH) tunnel for persistence. 

After the threat actor installs the initial tooling and the phone call is concluded, Storm-1811 leverages their access and performs further hands-on-keyboard activities such as domain enumeration and lateral movement.

In cases where Storm-1811 relies on Teams messages followed by phone calls and remote access through Quick Assist, the threat actor uses BITSAdmin to download batch files and ZIP files from a malicious site, for example antispam3[.]com. Storm-1811 also provides the target user with malicious links that redirect the user to an EvilProxy phishing site to input credentials. EvilProxy is an adversary-in-the-middle (AiTM) phishing kit used to capture passwords, hijack a user’s sign-in session, and skip the authentication process. Storm-1811 was also observed deploying SystemBC, a post-compromise commodity remote access trojan (RAT) and proxy tool typically used to establish command-and-control communication, establish persistence in a compromised environment, and deploy follow-on malware, notably ransomware.

In several cases, Storm-1811 uses PsExec to deploy Black Basta ransomware throughout the network. Black Basta is a closed ransomware offering (exclusive and not openly marketed like ransomware as a service) distributed by a small number of threat actors who typically rely on other threat actors for initial access, malicious infrastructure, and malware development. Since Black Basta first appeared in April 2022, Black Basta attackers have deployed the ransomware after receiving access from Qakbot and other malware distributors, highlighting the need for organizations to focus on attack stages prior to ransomware deployment to reduce the threat. In the next sections, we share recommendations for improving defenses against this threat, including best practices when using Quick Assist and mitigations for reducing the impact of Black Basta and other ransomware.

Recommendations

Microsoft recommends the following best practices to protect users and organizations from attacks and threat actors that misuse Quick Assist:

• Consider blocking or uninstalling Quick Assist and other remote monitoring and management tools if these tools are not in use in your environment. If your organization utilizes another remote support tool such as Remote Help, block or remove Quick Assist as a best practice. Remote Help is part of the Microsoft Intune Suite and provides authentication and security controls for helpdesk connections.
• Educate users about protecting themselves from tech support scams. Tech support scams are an industry-wide issue where scammers use scary tactics to trick users into unnecessary technical support services.
• Only allow a helper to connect to your device using Quick Assist if you initiated the interaction by contacting Microsoft Support or your IT support staff directly. Don’t provide access to anyone claiming to have an urgent need to access your device.
• If you suspect that the person connecting to your device is conducting malicious activity, disconnect from the session immediately and report to your local authorities and/or any relevant IT members within your organization.
• Users who have been affected by a tech support scam can also use the Microsoft technical support scam form to report it.

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Educate users about protecting personal and business information in social media, filtering unsolicited communication, identifying lure links in phishing emails, and reporting reconnaissance attempts and other suspicious activity.
• Educate users about preventing malware infections, such as ignoring or deleting unsolicited and unexpected emails or attachments sent through instant messaging applications or social networks as well as suspicious phone calls.
• Invest in advanced anti-phishing solutions that monitor incoming emails and visited websites. Microsoft Defender for Office 365 brings together incident and alert management across email, devices, and identities, centralizing investigations for email-based threats.
• Educate Microsoft Teams users to verify ‘External’ tagging on communication attempts from external entities, be cautious about what they share, and never share their account information or authorize sign-in requests over chat.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Apply Microsoft’s security best practices for Microsoft Teams to safeguard Teams users.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Enable investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Refer to Microsoft’s human-operated ransomware overview for general hardening recommendations against ransomware attacks.

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

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block execution of potentially obfuscated scripts
• Block process creations originating from PSExec and WMI commands
• Use advanced protection against ransomware

Detection details

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects Qakbot downloaders, implants, and behavior as the following malware:

• TrojanDownloader:O97M/Qakbot
• Trojan:Win32/QBot
• Trojan:Win32/Qakbot
• TrojanSpy:Win32/Qakbot
• Behavior:Win32/Qakbot

Black Basta threat components are detected as the following:

• Behavior:Win32/Basta
• Ransom:Win32/Basta
• Trojan:Win32/Basta

Microsoft Defender Antivirus detects Beacon running on a victim process 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

SystemBC components are detected as:

• Behavior:Win32/SystemBC
• Trojan: Win32/SystemBC

Microsoft Defender for Endpoint

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

• Suspicious activity using Quick Assist

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

• Suspicious curl behavior
• Suspicious bitsadmin activity
• Suspicious file creation by BITSAdmin tool
• A file or network connection related to a ransomware-linked emerging threat activity group detected —This alert captures Storm-1811 activity
• Ransomware-linked emerging threat activity group Storm-0303 detected — This alert captures some Qakbot distributor activity
• Possible Qakbot activity
• Possible NetSupport Manager activity
• Possibly malicious use of proxy or tunneling tool
• Suspicious usage of remote management software
• Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike)
• Human-operated attack using Cobalt Strike
• Human-operated attack implant tool detected
• Ransomware behavior detected in the file system

Indicators of compromise

Domain names:

• upd7a[.]com
• upd7[.]com
• upd9[.]com
• upd5[.]pro
• antispam3[.]com
• antispam2[.]com

SHA-256:

• 71d50b74f81d27feefbc2bc0f631b0ed7fcdf88b1abbd6d104e66638993786f8
• 0f9156f91c387e7781603ed716dcdc3f5342ece96e155115708b1662b0f9b4d0
• 1ad05a4a849d7ed09e2efb38f5424523651baf3326b5f95e05f6726f564ccc30
• 93058bd5fe5f046e298e1d3655274ae4c08f07a8b6876e61629ae4a0b510a2f7
• 1cb1864314262e71de1565e198193877ef83e98823a7da81eb3d59894b5a4cfb

ScreenConnect relay:

• instance-olqdnn-relay.screenconnect[.]com

NetSupport C2:

• greekpool[.]com

Cobalt Strike Beacon C2:

• zziveastnews[.]com
• realsepnews[.]com

Advanced hunting 

Microsoft Defender XDR

To locate possible malicious activity, run the following query in the Microsoft Defender portal:

This query looks for possible email bombing activity:

EmailEvents
| where EmailDirection == "Inbound"
| make-series Emailcount = count()
              on Timestamp step 1h by RecipientObjectId
| extend (Anomalies, AnomalyScore, ExpectedEmails) = series_decompose_anomalies(Emailcount)
| mv-expand Emailcount, Anomalies, AnomalyScore, ExpectedEmails to typeof(double), Timestamp
| where Anomalies != 0
| where AnomalyScore >= 10

This query looks for possible Teams phishing activity.

let suspiciousUpns = DeviceProcessEvents
| where DeviceId == "alertedMachine"
| where isnotempty(InitiatingProcessAccountUpn)
| project InitiatingProcessAccountUpn;
CloudAppEvents
| where Application == "Microsoft Teams"
| where ActionType == "ChatCreated"
| where isempty(AccountObjectId)
| where RawEventData.ParticipantInfo.HasForeignTenantUsers == true
| where RawEventData.CommunicationType == "OneonOne"
| where RawEventData.ParticipantInfo.HasGuestUsers == false
| where RawEventData.ParticipantInfo.HasOtherGuestUsers == false
| where RawEventData.Members[0].DisplayName in ("Microsoft  Security", "Help Desk", "Help Desk Team", "Help Desk IT", "Microsoft Security", "office")
| where AccountId has "@"
| extend TargetUPN = tolower(tostring(RawEventData.Members[1].UPN))
| where TargetUPN in (suspiciousUpns)

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

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

Qakbot:

• Qakbot hunting queries

Cobalt Strike:

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

References

• Defense and Mitigations from E-mail Bombing. U.S. Department of Health and Human Services, Health Sector Cybersecurity Coordination Center

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 misusing Quick Assist in social engineering attacks leading to ransomware 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.

Secure Future Initiative

A new world of security.

Learn more

Microsoft’s mission to empower every person and every organization on the planet to achieve more depends on security. We recognize that when Microsoft plays a role in pioneering cutting-edge technology, we also have the responsibility to lead the way in protecting our customers and our own infrastructure from cyberthreats. Against the exponentially increasing pace, scale, and complexity of the security landscape, it’s critical that we evolve to be more dynamic, proactive, and integrated in our security model to continue meeting the changing needs and expectations of our customers and the market. Our rich history in innovation is a testament to our commitment to delivering impactful and trustworthy products and services that that shape industries and transform lives. This legacy continues as we consistently work to set new benchmarks for safeguarding our digital future.

Expanding upon our foundation of built-in security, in November 2023 we launched the Secure Future Initiative (SFI) to directly address the escalating speed, scale, and sophistication of cyberattacks we’re witnessing today. This initiative is an anticipatory strategy reflecting the actions we are taking to “build better and respond better” in security, using automation and AI to scale this work, and strengthen identity protection against highly sophisticated cyberattacks. It’s not about tailoring our defenses to a single cyberattack: SFI underscores the importance of a continually and proactively evolving security model that adapts to the ever-changing digital landscape.

Four months have passed since we introduced SFI, and the achievements in our engineering developments demonstrate the concrete actions we’ve implemented to make sure that Microsoft’s security infrastructure stays strong in a constantly changing digital environment.  Read more below for updates on the initiative.

Transforming software development with automation and AI

As noted in our November 2, 2023 SFI announcement, we’re evolving our security development lifecycle (SDL) to continuous SDL—which we define as applying systematic processes to continuously integrate cybersecurity protection against emerging threat patterns as our engineers code, test, deploy, and operate our systems and service. Read more about continuous SDL here.

As part of our evolution to continuous SDL, we’re deploying CodeQL for code analysis to 100% of our commercial products. CodeQL is a powerful static analysis tool in the software security space. It offers advanced capabilities across numerous programming languages that detect complex security mistakes within source code. While our code repos go through rigorous SDL assessment leveraging traditional tooling, as part of our SFI work we now use CodeQL to cover 86% of our Azure DevOps code repositories from our commercial businesses in our Cloud and AI, enterprise and devices, security and strategic missions, and technology groups. We are expanding this further and anticipate that completing the consolidation process of the last 14% will be a complex, multi-year journey due to specific code repositories and engineering tools requiring additional work. In 2023, we onboarded more than one billion lines of source code to CodeQL, which highlights our commitment toward progress.

As part of efforts to broaden adoption of memory safe languages, we donated USD1 million in December 2023 to the Rust Foundation, an integral partner in stewarding the Rust programming language. Additionally, we’re providing an additional USD3.2 million to the Alpha-Omega project. In partnership with the Open Source Security Foundation (OpenSSF) and co-led with Google and Amazon, Alpha-Omega’s mission is to catalyze security improvements to the most widely deployed open source software projects and ecosystems critical to global infrastructure. Our contribution this year will help expand coverage, more than doubling the number of widely deployed open source projects we analyze, including 100 of the most commonly used open source AI libraries. The Alpha-Omega 2023 Annual Report highlights security and process improvements from last year and strides toward fostering a sustainable culture of security within open source communities.  

Together, our SFI-driven advances in expanding continuous SDL, fostering secure open source updates, and adopting memory safe languages strengthen the foundation of software throughout Microsoft’s own products and platforms, as well as the wider industry.

Strengthening identity protection against highly sophisticated attacks

As part of our SFI engineering advances, we’re enforcing the use of standard identity libraries such as the Microsoft Authentication Library (MSAL) enterprise-wide across Microsoft. This initiative is pivotal in achieving a cohesive and reliable identity verification framework. It facilitates seamless, policy-compliant management of user, device, and service identities across all Microsoft platforms and products, ensuring a fortified and consistent security posture.

Our efforts have already seen noteworthy achievements in several key areas. We’ve reached a major milestone with full integration of MSAL into Microsoft 365 across all four major platforms: Windows, macOS, iOS, and Android marking a significant advancement toward universal standardization. This integration ensures that Microsoft 365 applications are underpinned by a unified authentication mechanism. In the Azure ecosystem, encompassing critical tools such as Microsoft Visual Studio, Azure SDK, and Microsoft Azure CLI, MSAL has been fully adopted, underscoring our commitment to secure and streamlined authentication processes within our development tools. Furthermore, over 99% of internal service-to-service authentication requests, using Microsoft Entra for authorization, now utilize MSAL, highlighting our dedication to boosting security and efficiency in inter-service communications. Ultimately, these milestones further harden identity and authorization across our vast estate, making it increasingly difficult for threats and intruders to move between users and systems.

Looking ahead, we’re setting ambitious objectives to further bolster our security infrastructure. By the end of this year, we aim to fully automate the management of Microsoft Entra ID and Microsoft Account (MSA) keys. This process will include rapid rotation and secure storage of keys within Hardware Security Modules (HSMs), significantly enhancing our security measures. Additionally, we’re on track to ensure that Microsoft’s most widely used applications transition to standard identity libraries by the end of the year. Through these collective efforts we aim to not only enhance security but also improve the user experience and streamline authentication processes across our product suite.

Stay up to date on the latest Secure Future Initiative updates

As we forge ahead with the SFI, Microsoft remains unwavering in its commitment to continuously evolve our security posture and provide transparency in our communications. We’re dedicated to innovating, protecting, and leading in an era where digital threats are constantly changing. The progress we’ve shared today is only a fraction of our comprehensive strategy to safeguard the digital infrastructure and our customers who rely on it.

In the coming months, we will continue to share our progress on enhancing our capabilities, deploying innovative technologies, and strengthening our collaborations to address the complexities of cybersecurity. We’re committed to building a safer, more resilient digital world, with a focus on transparency and safety in every step.

To learn more  about the Microsoft SFI and read more details on our three engineering advances, visit our built-in security site.

Learn more about Microsoft Security solutions and bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Enhancing protection: Updates on Microsoft’s Secure Future Initiative appeared first on Microsoft Security Blog.

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

A principled approach to detecting and blocking threat actors

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

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

These principles include:   

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

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

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

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

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

Microsoft and OpenAI’s complementary defenses protect AI platforms

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

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

Summary of Microsoft and OpenAI’s findings and threat intelligence

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

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

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

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

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

Forest Blizzard 

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

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

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

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

Emerald Sleet

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

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

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

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

Crimson Sandstorm

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

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

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

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

Charcoal Typhoon

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

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

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

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

Salmon Typhoon

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

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

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

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

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

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

Appendix: LLM-themed TTPs

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

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

Learn more

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

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

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

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

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

We’re inviting the community of analysts and engineers to join us at InfoSec Jupyterthon 2024. This online event, to be held on February 15-16, 2024, serves as an opportunity for infosec analysts and engineers to meet and engage with security practitioners using notebooks in their daily work. It is organized by our friends at Open Threat Research, together with folks from the Microsoft Threat Intelligence community.

Some of the topics to be covered in this year’s talks include:

• Analyzing Active Directory with Bloodhound CE, Jupyter, and Python
• Graphing ransomware & data leak sites trends with Plotly
• Threat hunting in three dimensions
• Guardians of Identity: OKTA’s underworld
• Hacking proprietary protocols with pandas
• Predicting Windows binary download links with Jupyter notebooks
• Comparison of collaboration methods between MSTICpy and Splunk SIEM
• Building a community around notebooks for DFIR and SecOps
• Building data-driven security tools with Streamlit
• Red teaming LLMs with Jupyter notebooks
• Automating adversary emulation
• Applying machine learning for C2 beaconing detection

Although this is not a Microsoft event, our Microsoft Threat Intelligence community is delighted to be involved in helping organize and deliver talks. Registration is free and sessions will be streamed on YouTube Live on both days. We have also set offset times on each day this year to make it easier for people in different time zones to join. Provisional times are:

We’ll also have a dedicated Discord channel for discussions and session Q&A.

We are also inviting analysts and engineers who may be interested in talking about a cool notebook or some interesting techniques or technology to submit their proposal for a session here. There are still some openings for 30-minute, 15-minute, and 5-minute sessions.

For more information, as well as recordings of previous years sessions and workshops, visit the InfoSec Jupyterthon page at: https://infosecjupyterthon.com

We’re looking forward to seeing you there!

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 Join us at InfoSec Jupyterthon 2024 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.

While not a new threat, mobile malware infections pose a significant threat to mobile users, such as unauthorized access to personal information, financial loss due to fraudulent transactions, loss of privacy, device performance issues due to malware consuming system resources, and data theft or corruption. In the past, we observed similar banking trojan campaigns sending malicious links leading users to download malicious apps, as detailed in our blog Rewards plus: Fake mobile banking rewards apps lure users to install info-stealing RAT on Android devices.

The current active campaigns have pivoted to sharing malicious APK files directly to mobile users located in India. Our investigation focused on two malicious applications that falsely present themselves as official banking apps. Spoofing and impersonating legitimate banks, financial institutions, and other official services is a common social engineering tactic for information-stealing malware. Importantly, legitimate banks themselves are not affected by these attacks directly, and the existence of these attacks is not related to legitimate banks’ own authentic mobile banking apps and security posture. That said, cybercriminals often target customers of large financial institutions by masquerading as a legitimate entity. This threat highlights the need for customers to install applications only from official app stores, and to be wary of false lures as we see in these instances.

In this blog, we shed light on the ongoing mobile banking trojan campaigns impacting various sectors by analyzing the attacks of two fraudulent apps targeting Indian banking customers. We also detail some of the additional capabilities of malicious apps observed in similar campaigns and provide recommendations and detections to defend against such threats. As our mobile threat research continuously monitors malware campaigns in the effort to combat attackers’ tactics, tools, and procedures (TTPs), we notified the organizations being impersonated by these fake app campaigns. Microsoft is also reporting on this activity to bring increased awareness to the threat landscape as mobile banking trojans and credential phishing fraud continues to persist, prompting an urgent call for robust and proactive defense strategies.

Case 1: Fake banking app targeting account information

We discovered a recent WhatsApp phishing campaign through our telemetry that led to banking trojan activity. In this campaign, the attacker shares a malicious APK file through WhatsApp with a message asking users to enter sensitive information in the app. The widely circulated fake banking message states “Your [redacted] BANK Account will be Blocked Today please update your PANCARD immediately open [redacted]-Bank.apk for update your PANCARD. Thank You.” and includes a APK file named [redacted]-BANK[.]apk. 

Upon investigation, we discovered that the APK file was malicious and interacting with it installs a fraudulent application on the victim device. The installed app impersonates a legitimate bank located in India and disguises itself as the bank’s official Know Your Customer (KYC) application to trick users into submitting their sensitive information, despite this particular banking organization not being affiliated with an official KYC-related app. This information is then sent to a command and control (C2) server, as well as to the attacker’s hard-coded phone number used in SMS functionality.

What users see

Upon installation, the fake app displays a bank icon posing as a legitimate bank app. Note that the app we analyzed is not an official bank app from the Google Play Store, but a fake app that we’ve observed being distributed through social media platforms.  

The initial screen then proceeds to ask the user to enable SMS-based permissions. Once the user allows the requested permissions, the fake app displays the message “Welcome to [redacted] Bank fast & Secure Online KYC App” and requests users to signin to internet banking by entering their mobile number, ATM pin, and PAN card details.

After clicking the sign-in button, the app displays a verification prompt asking the user to enter the digits on the back of their banking debit card in grid format for authentication—a common security feature used as a form of multifactor authentication (MFA), where banks provide debit cards with 2-digit numbers in the form of a grid on the back of the card. Once the user clicks the authenticate button, the app claims to verify the shared details but fails to retrieve data, instead moving on to the next screen requesting additional user information. This can trick the user into believing that the process is legitimate, while remaining unaware of the malicious activity launching in the background.

Next, the user is asked to enter their account number followed by their account credentials. Once all the requested details are submitted, a suspicious note appears stating that the details are being verified to update KYC. The user is instructed to wait 30 minutes and not to delete or uninstall the app. Additionally, the app has the functionality to hide its icon, causing it to disappear from the user’s device home screen while still running in the background.

Technical analysis

To start our investigation and as part of our proactive research, we located and analyzed the following sample:

We first examined the app’s AndroidManifest file, which lists the permissions and components (such as activities, services, receivers, and providers) that can run in the background without requiring user interaction. We discovered that the malware requests two runtime permissions (also known as dangerous permissions) from users: 

The below image displays the requested Receive_SMS and Send_SMS permissions, the activities, receivers, and providers used in the application, and the launcher activity, which loads the application’s first screen. 

Source code review

Main activity

The main activity, djhgsfjhfdgf[.]gjhdgsfsjde[.]myappl876786ication[.]M1a2i3n4A5c6t7i8v9i0t0y987654321, executes once the app is launched and shows as the first screen of the application. The OnCreate() method of this class requests permissions for Send_SMS and Receive_SMS and displays a form to complete the KYC application with text fields for a user’s mobile number, ATM pin, and PAN card. Once the user’s details are entered successfully, the collected data is added to a JSON object and sent to the attacker’s C2 at: https://biogenetic-flake.000webhostapp[.]com/add.php

The app displays a note saying “Data added successfully”. If the details are not entered successfully, the form fields will be empty, and an error note will be displayed.

Additionally, the malware collects data and sends it to the attacker’s phone number specified in the code using SMS. 

Stealing SMS messages and account information

The malware collects incoming SMS messages from the victim’s device using the newly granted Receive_SMS permission. These incoming messages may contain one-time passwords (OTPs) that can be used to bypass MFA and steal money from the victim’s bank account. Using the Send_SMS permission, the victim’s messages are then sent to the attacker’s C2 server (https[:]//biogenetic-flake[.]000webhostapp[.]com/save_sms[.]php?phone=) and to the attacker’s hardcoded phone number via SMS.

The user’s bank account information is also targeted for exfiltration—once the user submits their requested account number and account credentials, the malware collects the data and similarly sends it to the attacker’s C2 server and hard-coded phone number. 

Hiding app icon

Finally, the app has the functionality to hide its icon from the home screen and run in the background. 

Case 2: Fake banking app targeting payment card details

Similar to the first case, the second case involves a fraudulent app that deceives users into providing personal information. Unlike the first case, the banking trojan in the second case is capable of stealing credit card details, putting users at risk of financial fraud. User information targeted by the fraudulent app to be sent to the attacker’s C2 includes:

• Personal information – Name, email ID, mobile number, date of birth
• Payment information – Card details (16-digit number, CVV number, card expiration date) 
• Incoming SMS 

What users see

When the user interacts with the app, it displays a launch screen featuring the app icon and prompting the user to grant SMS-based permissions. Once the requested permissions are enabled, the app displays a form for the user to enter their personal details, including their name, email address, mobile number, and date of birth. The data provided by the user is then sent to C2 server. After this, the app displays a form for the user to enter their credit card details, including the 16-digit card number, CVV number, and card expiration date, which is also sent to the attacker’s C2.

Additional features in some versions

In related campaigns, we observed some versions of the same malicious app include additional features and capabilities, such as capturing:

• Financial information – Bank details, bank ID, card details
• Personal information – PAN card, Aadhar number, permanent address, state, country, pin code, income
• Verifying and stealing one-time passwords (OTPs)

Similar campaigns

Based on our telemetry, we have been observing similar campaigns using the names of legitimate organizations in the banking, government services, and utilities sectors, as app file names to target Indian mobile users. Like the two cases discussed above, these campaigns involve sharing the fraudulent apps through WhatsApp and Telegram, and possibly other social media platforms. Moreover, these campaigns select legitimate and even well-known institutions and services in the region to imitate and lure users into a false sense of security. Spoofing and impersonating legitimate organizations and official services is a common social engineering tactic for information-stealing malware. While these banks and other organizations themselves are not affected by the attack directly, attackers often target customers by imitating legitimate entities.

Conclusion

Mobile banking trojan infections can pose significant risks to users’ personal information, privacy, device integrity, and financial security. As the campaigns discussed in this blog display, these threats can often disguise themselves as legitimate apps and deploy social engineering tactics to achieve their goals and steal users’ sensitive data and financial assets. Being aware of the risks and common tactics used by banking trojans and other mobile malware can help users identify signs of infection and take appropriate action to mitigate the impacts of these threats.

Finding unfamiliar installed apps, increased data usage or battery drain, unauthorized transactions or account settings changes, device crashes, slow performance, unexpected pop-ups, and other unusual app behaviors can indicate a possible banking trojan infection. To help prevent such threats, we recommend the following precautionary measures:

• Only install apps from trusted sources and official stores, like the Google Play Store and Apple App Store.
• Never click on unknown links received through ads, SMS messages, emails, or similar untrusted sources.
• Use mobile solutions such as Microsoft Defender for Endpoint on Android to detect malicious applications
• Always keep Install unknown apps disabled on the Android device to prevent apps from being installed from unknown sources.

Additionally, various Indian banks, governments services, and other organizations are conducting security awareness campaigns on social media using promotional videos to educate users and help combat the ongoing threat presented by these mobile banking trojan campaigns.

Abhishek Pustakala, Harshita Tripathi, and Shivang Desai

Microsoft Threat Intelligence

Appendix

Microsoft 365 Defender detections

Microsoft Defender Antivirus and Microsoft Defender for Endpoint on Android detect these threats as the following malware:

• Trojan:AndroidOS/Banker.U
• Trojan:AndroidOS/RewardSteal.S 
• Trojan:AndroidOS/RewardSteal.I
• TrojanSpy:AndroidOS/SpyBanker.Y

Indicators of compromise

MITRE ATT&CK techniques

References

• https://developer.android.com/guide/topics/permissions/overview#dangerous_permissions

Acknowledgments

• https://cyble.com/blog/new-wave-of-finacial-fraud-scammers-monitoring-social-media-complaints/  

Further reading

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

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

The post Social engineering attacks lure Indian users to install Android banking trojans appeared first on Microsoft Security Blog.

Octo Tempest is a financially motivated collective of native English-speaking threat actors known for launching wide-ranging campaigns that prominently feature adversary-in-the-middle (AiTM) techniques, social engineering, and SIM swapping capabilities. Octo Tempest, which overlaps with research associated with 0ktapus, Scattered Spider, and UNC3944, was initially seen in early 2022, targeting mobile telecommunications and business process outsourcing organizations to initiate phone number ports (also known as SIM swaps). Octo Tempest monetized their intrusions in 2022 by selling SIM swaps to other criminals and performing account takeovers of high-net-worth individuals to steal their cryptocurrency.

Building on their initial success, Octo Tempest harnessed their experience and acquired data to progressively advance their motives, targeting, and techniques, adopting an increasingly aggressive approach. In late 2022 to early 2023, Octo Tempest expanded their targeting to include cable telecommunications, email, and technology organizations. During this period, Octo Tempest started monetizing intrusions by extorting victim organizations for data stolen during their intrusion operations and in some cases even resorting to physical threats.

In mid-2023, Octo Tempest became an affiliate of ALPHV/BlackCat, a human-operated ransomware as a service (RaaS) operation, and initial victims were extorted for data theft (with no ransomware deployment) using ALPHV Collections leak site. This is notable in that, historically, Eastern European ransomware groups refused to do business with native English-speaking criminals. By June 2023, Octo Tempest started deploying ALPHV/BlackCat ransomware payloads (both Windows and Linux versions) to victims and lately has focused their deployments primarily on VMWare ESXi servers. Octo Tempest progressively broadened the scope of industries targeted for extortion, including natural resources, gaming, hospitality, consumer products, retail, managed service providers, manufacturing, law, technology, and financial services.  

In recent campaigns, we observed Octo Tempest leverage a diverse array of TTPs to navigate complex hybrid environments, exfiltrate sensitive data, and encrypt data. Octo Tempest leverages tradecraft that many organizations don’t have in their typical threat models, such as SMS phishing, SIM swapping, and advanced social engineering techniques. This blog post aims to provide organizations with an insight into Octo Tempest’s tradecraft by detailing the fluidity of their operations and to offer organizations defensive mechanisms to thwart the highly motivated financial cybercriminal group.

Analysis 

The well-organized, prolific nature of Octo Tempest’s attacks is indicative of extensive technical depth and multiple hands-on-keyboard operators. The succeeding sections cover the wide range of TTPs we observed being used by Octo Tempest.

Initial access 

Social engineering with a twist

Octo Tempest commonly launches social engineering attacks targeting technical administrators, such as support and help desk personnel, who have permissions that could enable the threat actor to gain initial access to accounts. The threat actor performs research on the organization and identifies targets to effectively impersonate victims, mimicking idiolect on phone calls and understanding personal identifiable information to trick technical administrators into performing password resets and resetting multifactor authentication (MFA) methods. Octo Tempest has also been observed impersonating newly hired employees in these attempts to blend into normal on-hire processes.

Octo Tempest primarily gains initial access to an organization using one of several methods:

• Social engineering
  • Calling an employee and socially engineering the user to either:
    • Install a Remote Monitoring and Management (RMM) utility
    • Navigate to a site configured with a fake login portal using an adversary-in-the-middle toolkit
    • Remove their FIDO2 token
  • Calling an organization’s help desk and socially engineering the help desk to reset the user’s password and/or change/add a multi-factor authentication token/factor
• Purchasing an employee’s credentials and/or session token(s) on a criminal underground market
• SMS phishing employee phone numbers with a link to a site configured with a fake login portal using an adversary-in-the-middle toolkit
• Using the employee’s pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.

In rare instances, Octo Tempest resorts to fear-mongering tactics, targeting specific individuals through phone calls and texts. These actors use personal information, such as home addresses and family names, along with physical threats to coerce victims into sharing credentials for corporate access.

Reconnaissance and discovery 

Crossing borders for identity, architecture, and controls enumeration

In the early stage of their attacks, Octo Tempest performs various enumeration and information gathering actions to pursue advanced access in targeted environments and abuses legitimate channels for follow-on actions later in the attack sequence. Initial bulk-export of users, groups, and device information is closely followed by enumerating data and resources readily available to the user’s profile within virtual desktop infrastructure or enterprise-hosted resources. 

Frequently, Octo Tempest uses their access to carry out broad searches across knowledge repositories to identify documents related to network architecture, employee onboarding, remote access methods, password policies, and credential vaults.

Octo Tempest then performs exploration through multi-cloud environments enumerating access and resources across cloud environments, code repositories, server and backup management infrastructure, and others. In this stage, the threat actor validates access, enumerates databases and storage containers, and plans footholds to aid further phases of the attack.

Additional tradecraft and techniques:

• PingCastle and ADRecon to perform reconnaissance of Active Directory 
• Advanced IP Scanner to probe victim networks
• Govmomi Go library to enumerate vCenter APIs 
• PureStorage FlashArray PowerShell module to enumerate storage arrays 
• AAD bulk downloads of user, groups, and devices

Privilege escalation and credential access

Octo Tempest commonly elevates their privileges within an organization through the following techniques:

• Using their pre-existing access to mobile telecommunications and business process outsourcing organizations to initiate a SIM swap or to set up call number forwarding on an employee’s phone number. Octo Tempest will initiate a self-service password reset of the user’s account once they have gained control of the employee’s phone number.
• Social engineering – calling an organization’s help desk and socially engineering the help desk to reset an administrator’s password and/or change/add a multi-factor authentication token/factor

Further masquerading and collection for escalation

Octo Tempest employs an advanced social engineering strategy for privilege escalation, harnessing stolen password policy procedures, bulk downloads of user, group, and role exports, and their familiarity with the target organizations procedures. The actor’s privilege escalation tactics often rely on building trust through various means, such as leveraging possession of compromised accounts and demonstrating an understanding of the organization’s procedures. In some cases, they go as far as bypassing password reset procedures by using a compromised manager’s account to approve their requests.

Octo Tempest continually seeks to collect additional credentials across all planes of access. Using open-source tooling like Jercretz and TruffleHog, the threat actor automates the identification of plaintext keys, secrets, and credentials across code repositories for further use.

Additional tradecraft and techniques:

• Modifying access policies or using MicroBurst to gain access to credential stores
• Using open-source tooling: Mimikatz, Hekatomb, Lazagne, gosecretsdump, smbpasswd.py, LinPEAS, ADFSDump
• Using VMAccess Extension to reset passwords or modify configurations of Azure VMs
• Creating snapshots virtual domain controller disks to download and extract NTDS.dit
• Assignment of User Access Administrator role to grant Tenant Root Group management scope

Defense evasion

Security product arsenal sabotage

Octo Tempest compromises security personnel accounts within victim organizations to turn off security products and features and attempt to evade detection throughout their compromise. Using compromised accounts, the threat actor leverages EDR and device management technologies to allow malicious tooling, deploy RMM software, remove or impair security products, data theft of sensitive files (e.g. files with credentials, signal messaging databases, etc.), and deploy malicious payloads.

To prevent identification of security product manipulation and suppress alerts or notifications of changes, Octo Tempest modifies the security staff mailbox rules to automatically delete emails from vendors that may raise the target’s suspicion of their activities.

Additional tradecraft and techniques:

• Using open-source tooling like privacy.sexy framework to disable security products
• Enrolling actor-controlled devices into device management software to bypass controls
• Configuring trusted locations in Conditional Access Policies to expand access capabilities
• Replaying harvested tokens with satisfied MFA claims to bypass MFA

Persistence 

Sustained intrusion with identities and open-source tools

Octo Tempest leverages publicly available security tools to establish persistence within victim organizations, largely using account manipulation techniques and implants on hosts. For identity-based persistence, Octo Tempest targets federated identity providers using tools like AADInternals to federate existing domains, or spoof legitimate domains by adding and then federating new domains. The threat actor then abuses this federation to generate forged valid security assertion markup language (SAML) tokens for any user of the target tenant with claims that have MFA satisfied, a technique known as Golden SAML. Similar techniques have also been observed using Okta as their source of truth identity provider, leveraging Okta Org2Org functionality to impersonate any desired user account.

To maintain access to endpoints, Octo Tempest installs a wide array of legitimate RMM tools and makes required network modifications to enable access. The usage of reverse shells is seen across Octo Tempest intrusions on both Windows and Linux endpoints. These reverse shells commonly initiate connections to the same attacker infrastructure that deployed the RMM tools.

A unique technique Octo Tempest uses is compromising VMware ESXi infrastructure, installing the open-source Linux backdoor Bedevil, and then launching VMware Python scripts to run arbitrary commands against housed virtual machines.

Additional tradecraft and techniques:

• Usage of open-source tooling: ScreenConnect, FleetDeck, AnyDesk, RustDesk, Splashtop, Pulseway, TightVNC, LummaC2, Level.io, Mesh, TacticalRMM, Tailscale, Ngrok, WsTunnel, Rsocx, and Socat
• Deployment of Azure virtual machines to enable remote access via RMM installation or modification to existing resources via Azure serial console
• Addition of MFA methods to existing users
• Usage of the third-party tunneling tool Twingate, which leverages Azure Container instances as a private connector (without public network exposure)

Actions on objectives

Common trifecta: Data theft, extortion, and ransomware

The goal of Octo Tempest remains financially motivated, but the monetization techniques observed across industries vary between cryptocurrency theft and data exfiltration for extortion and ransomware deployment.

Like in most cyberattacks, data theft largely depends on the data readily available to the threat actor. Octo Tempest accesses data from code repositories, large document management and storage systems, including SharePoint, SQL databases, cloud storage blobs/buckets, and email, using legitimate management clients such as DBeaver, MongoDB Compass, Azure SQL Query Editor, and Cerebrata for the purpose of connection and collection. After data harvesting, the threat actor employs anonymous file-hosting services, including GoFile.io, shz.al, StorjShare, Temp.sh, MegaSync, Paste.ee, Backblaze, and AWS S3 buckets for data exfiltration.

Octo Tempest employs a unique technique using the data movement platform Azure Data Factory and automated pipelines to extract data to external actor hosted Secure File Transfer Protocol (SFTP) servers, aiming to blend in with typical big data operations. Additionally, the threat actor commonly registers legitimate Microsoft 365 backup solutions such as Veeam, AFI Backup, and CommVault to export the contents of SharePoint document libraries and expedite data exfiltration.

Ransomware deployment closely follows data theft objectives. This activity targets both Windows and Unix/Linux endpoints and VMware hypervisors using a variant of ALPHV/BlackCat. Encryption at the hypervisor level has shown significant impact to organizations, making recovery efforts difficult post-encryption.

Octo Tempest frequently communicates with target organizations and their personnel directly after encryption to negotiate or extort the ransom—providing “proof of life” through samples of exfiltrated data. Many of these communications have been leaked publicly, causing significant reputational damage to affected organizations.

Additional tradecraft and techniques:

• Use of the third-party services like FiveTran to extract copies of high-value service databases, such as SalesForce and ZenDesk, using API connectors
• Exfiltration of mailbox PST files and mail forwarding to external mailboxes

Recommendations

Hunting methodology

Octo Tempest’s utilization of social engineering, living-off-the land techniques, and diverse toolsets could make hunting slightly unorthodox. Following these general guidelines alongside robust deconfliction with legitimate users will surface their activity:

Identity

• Understand authentication flows in the environment.
• Centralize visibility of administrative changes in the environment into a single pane of glass.
• Scrutinize all user and sign-in risk detections for any administrator within the timeframe. Common alerts that are surfaced during an Octo Tempest intrusion include (but not limited to): Impossible Travel, Unfamiliar Sign-in Properties, and Anomalous Token
• Review the coverage of Conditional Access policies; scrutinize the use of trusted locations and exclusions.
• Review all existing and new custom domains in the tenant, and their federation settings.
• Scrutinize administrator groups, roles, and privileges for recent modification.
• Review recently created Microsoft Entra ID users and registered device identities.
• Look for any anomalous pivots into organizational apps that may hold sensitive data, such as Microsoft SharePoint and OneDrive.

Azure

• Leverage and continuously monitor Defender for Cloud for Azure Workloads, providing a wealth of information around unauthorized resource access.
• Review Azure role-based access control (RBAC) definitions across the management group, subscription, resource group and resource structure.
• Review the public network exposure of resources and revoke any unauthorized modifications.
• Review both data plane and management plane access control for all critical workloads such as those that hold credentials and organizational data, like Key Vaults, storage accounts, and database resources.
• Tightly control access to identity workloads that issue access organizational resources such as Active Directory Domain Controllers.
• Review the Azure Activity log for anomalous modification of resources.

Endpoints

• Look for recent additions to the indicators or exclusions of the EDR solution in place at the organization.
• Review any generation of offboarding scripts.
• Review access control within security products and EDR software suites.
• Scrutinize any tools used to manage endpoints (SCCM, Intune, etc.) and look for recent rule additions, packages, or deployments.
• Scrutinize use of remote administration tools across the environment, paying particular attention to recent installations regardless of whether they are used legitimately within the network already.
• Ensure monitoring at the network boundary is in place, that alerting is in place for connections with common anonymizing services and scrutinize the use of these services.

Defending against Octo Tempest activity

Align privilege in Microsoft Entra ID and Azure

Privileges spanning Microsoft Entra ID and Azure need to be holistically aligned, with purposeful design decisions to prevent unauthorized access to critical workloads. Reducing the number of users with permanently assigned critical roles is paramount to achieving this. Segregation of privilege between on-premises and cloud is also necessary to sever the ability to pivot within the environment.

It is highly recommended to implement Microsoft Entra Privileged Identity Management (PIM) as a central location for the management of both Microsoft Entra ID roles and Azure RBAC. For all critical roles, at minimum:

• Implement role assignments as eligible rather than permanent.
• Review and understand the role definition Actions and NotActions – ensure to select only the roles with actions that the user requires to do their role (least privileged access).
• Configure these roles to be time-bound, deactivating after a specific timeframe.
• Require users to perform MFA to elevate to the role.
• Optionally require users to provide justification or a ticket number upon elevation.
• Enable notifications for privileged role elevation to a subset of administrators.
• Utilize PIM Access Reviews to reduce standing access in the organization on a periodic basis.

Every organization is different and, therefore, roles will be classified differently in terms of their criticality. Consider the scope of impact those roles may have on downstream resources, services, or identities in the event of compromise. For help desk administrators specifically, ensure to scope privilege to exclude administrative operations over Global Administrators. Consider implementing segregation strategies such as Microsoft Entra ID Administrative Units to segment administrative access over the tenant. For identities that leverage cross-service roles such as those that service the Microsoft Security Stack, consider implementing additional service-based granular access control to restrict the use of sensitive functionality, like Live Response and modification of IOC allow lists.

Segment Azure landing zones

For organizations yet to begin or are early in their modernization journey, end-to-end guidance for cloud adoption is available through the Microsoft Azure Cloud Adoption Framework. Recommended practice and security are central pillars—Azure workloads are segregated into separate, tightly restricted areas known as landing zones. When deploying Active Directory in the cloud, it is advised to create a platform landing zone for identity—a dedicated subscription to hold all Identity-related resources such as Domain Controller VM resources. Employ least privilege across this landing zone with the aforementioned privilege and PIM guidance for Azure RBAC.

Implement Conditional Access policies and authentication methods

TTPs outlined in this blog leverage strategies to evade multifactor authentication defenses. However, it is still strongly recommended to practice basic security hygiene by implementing a baseline set of Conditional Access policies:

• Require multifactor authentication for all privileged roles with the use of authentication strengths to enforce phish-resistant MFA methods such as FIDO2 security keys
• Require phishing-resistant multifactor authentication for administrators
• Enforce MFA registration from trusted locations from a device that also meets organizational requirements with Intune device compliance policies
• User and sign-in risk policies for signals associated to Microsoft Entra ID Protection

Organizations are recommended to keep their policies as simple as possible. Implementing complex policies might inhibit the ability to respond to threats at a rapid pace or allow threat actors to leverage misconfigurations within the environment.

Develop and maintain a user education strategy

An organization’s ability to protect itself against cyberattacks is only as strong as its people—it is imperative to put in place an end-to-end cybersecurity strategy highlighting the importance of ongoing user education and awareness. Targeted education and periodic security awareness campaigns around common cyber threats and attack vectors such as phishing and social engineering not only for users that hold administrative privilege in the organization, but the wider user base is crucial. A well-maintained incident response plan should be developed and refined to enable organizations to respond to unexpected cybersecurity events and rapidly regain positive control.

Use out-of-band communication channels

Octo Tempest has been observed joining, recording, and transcribing calls using tools such as OtterAI, and sending messages via Slack, Zoom, and Microsoft Teams, taunting and threatening targets, organizations, defenders, and gaining insights into incident response operations/planning. Using out-of-band communication channels is strongly encouraged when dealing with this threat actor.

Detections

Microsoft 365 Defender

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

NOTE: Several tools mentioned throughout this blog are remote administrator tools that have been utilized by Octo Tempest to maintain persistence. While these tools are abused by threat actors, they can have legitimate use cases by normal users, and are updated on a frequent basis. Microsoft recommends monitoring their use within the environment, and when they are identified, defenders take the necessary steps for deconfliction to verify their use.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• HackTool:Win32/Mimikatz
• HackTool:Win64/Mimikatz
• Behavior:Win32/BlackCatExec
• Ransom:Win32/Blackcat
• Ransom:Linux/BlackCat
• Behavior:Win32/BlackCat
• Ransom:Win64/BlackCat

Turning on tamper protection, which is part of built-in protection, prevents attackers from stopping security services.

Microsoft Defender for Endpoint

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

• Octo Tempest activity group

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

• Suspicious usage of remote management software
• Mimikatz credential theft tool
• BlackCat ransomware
• Activity linked to BlackCat ransomware
• Tampering activity typical to ransomware attacks
• Possible hands-on-keyboard pre-ransom activity

Microsoft Defender for Cloud Apps

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

• Backdoor creation using AADInternals tool
• Suspicious domain added to Microsoft Entra ID
• Suspicious domain trust modification following risky sign-in
• User compromised via a known AitM phishing kit
• User compromised in AiTM phishing attack
• Suspicious email deletion activity

Similarly, the connector for Okta raises the following alerts:

• Suspicious Okta account enumeration
• Possible AiTM phishing attempt in Okta

Microsoft Defender for Identity

Microsoft Defender for Identity raises the following alerts for TTPs used by Octo Tempest such as NTDS stealing and Active Directory reconnaissance:

• Account enumeration reconnaissance
• Network-mapping reconnaissance (DNS)
• User and IP address reconnaissance (SMB)
• User and Group membership reconnaissance (SAMR)
• Suspected DCSync attack (replication of directory services)
• Suspected AD FS DKM key read
• Data exfiltration over SMB

Microsoft Defender for Cloud

The following Microsoft Defender for Cloud alerts relate to TTPs used by Octo Tempest. Note, however, that these alerts can also be triggered by unrelated threat activity.

• MicroBurst exploitation toolkit used to enumerate resources in your subscriptions
• MicroBurst exploitation toolkit used to execute code on your virtual machine
• MicroBurst exploitation toolkit used to extract keys from your Azure key vaults
• MicroBurst exploitation toolkit used to extract keys to your storage accounts
• Suspicious Azure role assignment detected
• Suspicious elevate access operation (Preview)
• Suspicious invocation of a high-risk ‘Initial Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Credential Access’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Impact’ operation detected (Preview)
• Suspicious invocation of a high-risk ‘Lateral Movement’ operation detected (Preview)
• Unusual user password reset in your virtual machine
• Suspicious usage of VMAccess extension was detected on your virtual machines (Preview)
• Suspicious usage of multiple monitoring or data collection extensions was detected on your virtual machines (Preview)
• Run Command with a suspicious script was detected on your virtual machine (Preview)
• Suspicious Run Command usage was detected on your virtual machine (Preview)
• Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview)

Microsoft Sentinel

Microsoft Sentinel customers can use the following Microsoft Sentinel Analytics template to identify potential AitM phishing attempts:

• Possible AitM Phishing Attempt Against Azure AD

This detection uses signals from Microsoft Entra ID Identity Protection and looks for successful sign-ins that have been flagged as high risk. It combines this with data from web proxy services, such as ZScaler, to identify where users might have connected to the source of those sign-ins immediately prior. This can indicate a user interacting with an AitM phishing site and having their session hijacked. This detection uses the Advanced Security Information Model (ASIM) Web Session schema. Refer to this article for more details on the schema and its requirements. 

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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 info, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Octo Tempest
• Octo Tempest uses social engineering and AADInternals to compromise cloud identities

Microsoft 365 Defender Threat analytics  

• Actor profile: Octo Tempest
• Threat insights: Octo Tempest uses social engineering and AADInternals to compromise cloud identities

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.

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

• Suspicious sign-in followed by MFA modification
• Account MFA modifications
• Okta SSO phishing detection
• Okta rare MFA operations
• Okta login from different locations
• Okta user password reset
• SharePointFileOperation via clientIP with previously unseen user agents
• SharePointFileOperation via devices with previously unseen user agents
• SharePointFileOperation via previously unseen IPs of risky ASN’s
• SharePointFileOperation via previously unseen IPs
• Anomalous AAD account manipulation
• New external user granted admin
• Anomolous sign-ins based on time
• New account added to admin group
• Authentication methods changed for privileged account
• Rare run command PowerShell script
• Azure NSG administrative operations
• Rare operations of create and update of snapshots
• AdFind usage
• Anomalous listing of storage keys
• Storage account key enumeration
• Potential Microsoft Security services tampering
• Potential Microsoft Defender tampering
• Office mail forwarding
• Multiple users Office mail forwarding

Further reading

Listen to Microsoft experts discuss Octo Tempest TTPs and activities on The Microsoft Threat Intelligence Podcast.

Visit this page for more blogs from Microsoft Incident Response.

For more 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.

November 1, 2023 update: Updated the Actions of objectives section to fix the list of anonymous file-hosting services used by Octo Tempest for data exfiltration, which incorrectly listed Sh.Azl. It has been corrected to shz.al.

The post Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction appeared first on Microsoft Security Blog.

Our investigation found that within those five days, the threat actor employed a range of tools and techniques, culminating in the deployment of BlackByte 2.0 ransomware, to achieve their objectives. These techniques included:

• Exploitation of unpatched internet-exposed Microsoft Exchange Servers
• Web shell deployment facilitating remote access
• Use of living-off-the-land tools for persistence and reconnaissance
• Deployment of Cobalt Strike beacons for command and control (C2)
• Process hollowing and the use of vulnerable drivers for defense evasion
• Deployment of custom-developed backdoors to facilitate persistence
• Deployment of a custom-developed data collection and exfiltration tool

In this blog, we share details of our investigation into the end-to-end attack chain, exposing security weaknesses that the threat actor exploited to advance their attack. As we learned from Microsoft’s tracking of ransomware attacks and the cybercriminal economy that enables them, disrupting common attack patterns could stop many of the attacker activities that precede ransomware deployment. This case highlights that common security hygiene practices go a long way in preventing, identifying, and responding to malicious activity as early as possible to mitigate the impact of ransomware attacks. We encourage organizations to follow the outlined mitigation steps, including ensuring that internet-facing assets are up to date and configured securely. We also share indicators of compromise, detection details, and hunting guidance to help organizations identify and respond to these attacks in their environments.  

Forensic analysis

Initial access and privilege escalation

To obtain initial access into the victim’s environment, the threat actor was observed exploiting the ProxyShell vulnerabilities CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207 on unpatched Microsoft Exchange Servers. The exploitation of these vulnerabilities allowed the threat actor to:

• Attain system-level privileges on the compromised Exchange host
• Enumerate LegacyDN of users by sending Autodiscover requests, including SIDs of users
• Construct a valid authentication token and use it against the Exchange PowerShell backend
• Impersonate domain admin users and create a web shell by using the New-MailboxExportRequest cmdlet
• Create web shells to obtain remote control on affected servers

The threat actor was observed operating from the following IP to exploit ProxyShell and access the web shell:

• 185.225.73[.]244

Persistence

Backdoor

After gaining access to a device, the threat actor created the following registry run keys to run a payload each time a user signs in:

The file api-msvc.dll (SHA-256: 4a066569113a569a6feb8f44257ac8764ee8f2011765009fdfd82fe3f4b92d3e) was determined to be a backdoor capable of collecting system information, such as the installed antivirus products, device name, and IP address. This information is then sent via HTTP POST request to the following C2 channel:

• hxxps://myvisit[.]alteksecurity[.]org/t

The organization was not using Microsoft Defender Antivirus, which detects this malware as Trojan:Win32/Kovter!MSR, as the primary antivirus solution, and the backdoor was allowed to run.

An additional file, api-system.png, was identified to have similarities to api-msvc.dll. This file behaved like a DLL, had the same default export function, and also leveraged run keys for persistence.

Cobalt Strike Beacon

The threat actor leveraged Cobalt Strike to achieve persistence. The file sys.exe (SHA-256: 5f37b85687780c089607670040dbb3da2749b91b8adc0aa411fd6280b5fa7103), detected by Microsoft Defender Antivirus as Trojan:Win64/CobaltStrike!MSR, was determined to be a Cobalt Strike Beacon and was downloaded directly from the file sharing service temp[.]sh:

• hxxps://temp[.]sh/szAyn/sys.exe

This beacon was configured to communicate with the following C2 channel:

• 109.206.243[.]59:443

AnyDesk

Threat actors leverage legitimate remote access tools during intrusions to blend into a victim network. In this case, the threat actor utilized the remote administration tool AnyDesk, to maintain persistence and move laterally within the network. AnyDesk was installed as a service and was run from the following paths:

• C:\systemtest\anydesk\AnyDesk.exe
• C:\Program Files (x86)\AnyDesk\AnyDesk.exe
• C:\Scripts\AnyDesk.exe

Successful connections were observed in the AnyDesk log file ad_svc.trace involving anonymizer service IP addresses linked to TOR and MULLVAD VPN, a common technique that threat actors employ to obscure their source IP ranges.

Reconnaissance

We found the presence and execution of the network discovery tool NetScan being used by the threat actor to perform network enumeration using the following file names:

• netscan.exe (SHA-256:1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e)
• netapp.exe (SHA-256:1b9badb1c646a19cdf101ac4f6fdd23bc61eaab8c9f925eb41848cea9fd0738e)

Additionally, execution of AdFind (SHA-256: f157090fd3ccd4220298c06ce8734361b724d80459592b10ac632acc624f455e), an Active Directory reconnaissance tool, was observed in the environment.

Credential access

Evidence of likely usage of the credential theft tool Mimikatzwas also uncovered through the presence of a related log file mimikatz.log. Microsoft IR assesses that Mimikatz was likely used to attain credentials for privileged accounts.

Lateral movement

Using compromised domain admin credentials, the threat actor used Remote Desktop Protocol (RDP) and PowerShell remoting to obtain access to other servers in the environment, including domain controllers.

Data staging and exfiltration

In one server where Microsoft Defender Antivirus was installed, a suspicious file named explorer.exe was identified, detected as Trojan:Win64/WinGoObfusc.LK!MT, and quarantined. However, because tamper protection wasn’t enabled on this server, the threat actor was able to disable the Microsoft Defender Antivirus service, enabling the threat actor to run the file using the following command:

explorer.exe P@$$w0rd

After reverse engineering explorer.exe, we determined it to be ExByte, a GoLang-based tool developed and commonly used in BlackByte ransomware attacks for collection and exfiltration of files from victim networks. This tool is capable of enumerating files of interest across the network and, upon execution, creates a log file containing a list of files and associated metadata. Multiple log files were uncovered during the investigation in the path:

• C:\Exchange\MSExchLog.log

Analysis of the binary revealed a list of file extensions that are targeted for enumeration.

Forensic analysis identified a file named data.txt that was created and later deleted after ExByte execution. This file contained obfuscated credentials that ExByte leveraged to authenticate to the popular file sharing platform Mega NZ using the platform’s API at:

• hxxps://g.api.mega.co[.]nz

We also determined that this version of Exbyte was crafted specifically for the victim, as it contained a hardcoded device name belonging to the victim and an internal IP address.

ExByte execution flow

Upon execution, ExByte decodes several strings and checks if the process is running with privileged access by reading \\.\PHYSICALDRIVE0:

• If this check fails, ShellExecuteW is invoked with the IpOperation parameter RunAs, which runs explorer.exe with elevated privileges.

After this access check, explorer.exe attempts to read the data.txt file in the current location:

• If the text file doesn’t exist, it invokes a command for self-deletion and exits from memory:

C:\Windows\system32\cmd.exe /c ping 1.1.1.1 -n 10 > nul & Del <PATH>\explorer.exe /F /Q

• If data.txt exists, explorer.exe reads the file, passes the buffer to Base64 decode function, and then decrypts the data using the key provided in the command line. The decrypted data is then parsed as JSON below and fed for login function:

{
	“a”:”us0”,
	“user”:”<CONTENT FROM data.txt>”
}

Finally, it forms a URL for sign-in to the API of the service MEGA NZ:

• hxxps://g.api.mega.co[.]nz/cs?id=1674017543

Data encryption and destruction

On devices where files were successfully encrypted, we identified suspicious executables, detected by Microsoft Defender Antivirus as Trojan:Win64/BlackByte!MSR, with the following names:

• wEFT.exe
• schillerized.exe

The files were analyzed and determined to be BlackByte 2.0 binaries responsible for encryption across the environment. The binaries require an 8-digit key number to encrypt files.

Two modes of execution were identified:

• When the -s parameter is provided, the ransomware self-deletes and encrypts the machine it was executed on.
• When the -a parameter is provided, the ransomware conducts enumeration and uses an Ultimate Packer Executable (UPX) packed version of PsExec to deploy across the network. Several domain admin credentials were hardcoded in the binary, facilitating the deployment of the binary across the network.

Depending on the switch (-s or -a), execution may create the following files:

• C:\SystemData\M8yl89s7.exe (UPX-packed PsExec with a random name; SHA-256: ba3ec3f445683d0d0407157fda0c26fd669c0b8cc03f21770285a20b3133098f)
• C:\SystemData\wEFT.exe (Additional BlackByte binary)
• C:\SystemData\MsExchangeLog1.log (Log file)
• C:\SystemData\rENEgOtiAtES (A vulnerable (CVE-2019-16098) driver RtCore64.sys used to evade detection by installed antivirus software; SHA-256: 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd)
• C:\SystemData\iHu6c4.ico (Random name – BlackBytes icon)
• C:\SystemData\BB_Readme_file.txt (BlackByte ReadMe file)
• C:\SystemData\skip_bypass.txt (Unknown)

BlackByte 2.0 ransomware capabilities

Some capabilities identified for the BlackByte 2.0 ransomware were:

• Antivirus bypass
  • The file rENEgOtiAtES created matches RTCore64.sys, a vulnerable driver (CVE-2049-16098) that allows any authenticated user to read or write to arbitrary memory
  • The BlackByte binary then creates and starts a service named RABAsSaa calling rENEgOtiAtES, and exploits this service to evade detection by installed antivirus software
• Process hollowing
  • Invokes svchost.exe, injects to it to complete device encryption, and self-deletes by executing the following command:
    • cmd.exe /c ping 1.1.1.1 -n 10 > Nul & Del “PATH_TO_BLACKBYTE” /F /Q
• Modification / disabling of Windows Firewall
  • The following commands are executed to either modify existing Windows Firewall rules, or to disable Windows Firewall entirely:
    • cmd /c netsh advfirewall set allprofiles state off
  • • cmd /c netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes
    • cmd /c netsh advfirewall firewall set rule group=”Network Discovery” new enable=Yes
• Modification of volume shadow copies
  • The following commands are executed to destroy volume shadow copies on the machine:
    • cmd /c vssadmin Resize ShadowStorge /For=B:\ /On=B:\ /MaxSize=401MB
    • cmd /c vssadmin Resize ShadowStorage /For=B:\ /On=B:\ /MaxSize=UNBOUNDED
• Modification of registry keys/values
  • The following commands are executed to modify the registry, facilitating elevated execution on the device:
    • cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
  • • cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLinkedConnections /t REG_DWORD /d 1 /f
    • cmd /c reg add HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
• Additional functionality
  • Ability to terminate running services and processes
  • Ability to enumerate and mount volumes and network shares for encryption
  • Perform anti-forensics technique timestomping (sets the file time of encrypted and ReadMe file to 2000-01-01 00:00:00)
  • Ability to perform anti-debugging techniques

Recommendations

To guard against BlackByte ransomware attacks, Microsoft recommends the following:

• Ensure that you have a patch management process in place and that patching for internet-exposed devices is prioritized; Understand and assess your cyber exposure with advanced vulnerability and configuration assessment tools like Microsoft Defender Vulnerability Management
• Implement an endpoint detection and response (EDR) solution like Microsoft Defender for Endpoint to gain visibility into malicious activity in real time across your network
• Ensure antivirus protections are updated regularly by turning on cloud-based protection and that your antivirus solution is configured to block threats
• Enable tamper protection to prevent components of Microsoft Defender Antivirus from being disabled
• Block inbound traffic from IPs specified in the indicators of compromise section of this report
• Block inbound traffic from TOR exit nodes
• Block inbound access from unauthorized public VPN services
• Restrict administrative privileges to prevent authorized system changes

Conclusion

BlackByte ransomware attacks target organizations that have infrastructure with unpatched vulnerabilities.  As outlined in the Microsoft Digital Defense Report, common security hygiene practices, including keeping systems up to date, could protect against 98% of attacks.

As new tools are being developed by threat actors, a modern threat protection solution like Microsoft 365 Defender is necessary to prevent and detect the multiple techniques used in the attack chain, especially where the threat actor attempts to evade or disable specific defense mechanisms. Hunting for malicious behavior should be performed regularly in order to detect potential attacks that could evade detections, as a complementary activity for continuous monitoring from security tools alerts and incidents.

To understand how Microsoft can help you secure your network and respond to network compromise, visit https://aka.ms/MicrosoftIR.

Microsoft 365 Defender detections

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Win32/Kovter!MSR
• Trojan:Win64/WinGoObfusc.LK!MT
• Trojan:Win64/BlackByte!MSR
• HackTool:Win32/AdFind!MSR
• Trojan:Win64/CobaltStrike!MSR

Microsoft Defender for Endpoint

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

• ‘CVE-2021-31207’ exploit malware was detected
• An active ‘NetShDisableFireWall’ malware in a command line was prevented from executing.
• Suspicious registry modification.
• ‘Rtcore64’ hacktool was detected
• Possible ongoing hands-on-keyboard activity (Cobalt Strike)
• A file or network connection related to a ransomware-linked emerging threat activity group detected
• Suspicious sequence of exploration activities
• A process was injected with potentially malicious code
• Suspicious behavior by cmd.exe was observed
• ‘Blackbyte’ ransomware was detected

Microsoft Defender Vulnerability Management

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

• CVE-2021-34473
• CVE-2021-34523
• CVE-2021-31207
• CVE-2019-16098

Hunting queries

Microsoft 365 Defender

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

ProxyShell web shell creation events

DeviceProcessEvents
| where ProcessCommandLine has_any ("ExcludeDumpster","New-ExchangeCertificate") and ProcessCommandLine has_any ("-RequestFile","-FilePath")

Suspicious vssadmin events

DeviceProcessEvents
| where ProcessCommandLine has_any ("vssadmin","vssadmin.exe") and ProcessCommandLine has "Resize ShadowStorage" and ProcessCommandLine has_any ("MaxSize=401MB"," MaxSize=UNBOUNDED")

Detection for persistence creation using Registry Run keys

DeviceRegistryEvents 
| where ActionType == "RegistryValueSet" 
| where (RegistryKey has @"Microsoft\Windows\CurrentVersion\RunOnce" and RegistryValueName == "MsEdgeMsE")  
    or (RegistryKey has @"Microsoft\Windows\CurrentVersion\RunOnceEx" and RegistryValueName == "MsEdgeMsE")
    or (RegistryKey has @"Microsoft\Windows\CurrentVersion\Run" and RegistryValueName == "MsEdgeMsE")
| where RegistryValueData startswith @"rundll32"
| where RegistryValueData endswith @".dll,Default"
| project Timestamp,DeviceId,DeviceName,ActionType,RegistryKey,RegistryValueName,RegistryValueData

Microsoft Sentinel

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

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

• ProxyShell
• Web shell activity
• Suspicious file downloads on Exchange Servers
• Firewall rule changes
• Shadow copy deletion
• Anamolous RDP activity

Indicators of compromise

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

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

Appendix

File extensions targeted by BlackByte binary for encryption:

Shared folders targeted for encryption (Example: \\[IP address]\Downloads):

File extensions ignored:

Folders ignored:

Files ignored:

Processes terminated:

Services terminated:

Drivers that Blackbyte can bypass:

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 The five-day job: A BlackByte ransomware intrusion case study appeared first on Microsoft Security Blog.