Legitimate hosting services, such as SharePoint, OneDrive, and Dropbox, are widely used by organizations for storing, sharing, and collaborating on files. However, the widespread use of such services also makes them attractive targets for threat actors, who exploit the trust and familiarity associated with these services to deliver malicious files and links, often avoiding detection by traditional security measures.

Importantly, Microsoft takes action against malicious users violating the Microsoft Services Agreement in how they use apps like SharePoint and OneDrive. To help protect enterprise accounts from compromise, by default both Microsoft 365 and Office 365 support multi-factor authentication (MFA) and passwordless sign-in. Consumers can also go passwordless with their Microsoft account. Because security is a team sport, Microsoft also works with third parties like Dropbox to share threat intelligence and protect mutual customers and the wider community.

In this blog, we discuss the typical attack chain used in campaigns misusing file hosting services and detail the recently observed tactics, techniques, and procedures (TTPs), including the increasing use of certain defense evasion tactics. To help defenders protect their identities and data, we also share mitigation guidance to help reduce the impact of this threat, and detection details and hunting queries to locate potential misuse of file hosting services and related threat actor activities. By understanding these evolving threats and implementing the recommended mitigations, organizations can better protect themselves against these sophisticated campaigns and safeguard digital assets.

Attack overview

Phishing campaigns exploiting legitimate file hosting services have been trending throughout the last few years, especially due to the relative ease of the technique. The files are delivered through different approaches, including email and email attachments like PDFs, OneNote, and Word files, with the intent of compromising identities or devices. These campaigns are different from traditional phishing attacks because of the sophisticated defense evasion techniques used.

Since mid-April 2024, we observed threat actors increasingly use these tactics aimed at circumventing defense mechanisms:

• Files with restricted access: The files sent through the phishing emails are configured to be accessible solely to the designated recipient. This requires the recipient to be signed in to the file-sharing service—be it Dropbox, OneDrive, or SharePoint—or to re-authenticate by entering their email address along with a one-time password (OTP) received through a notification service.
• Files with view-only restrictions: To bypass analysis by email detonation systems, the files shared in these phishing attacks are set to ‘view-only’ mode, disabling the ability to download and consequently, the detection of embedded URLs within the file.

An example attack chain is provided below, depicting the updated defense evasion techniques being used across stages 4, 5, and 6:

Initial access

The attack typically begins with the compromise of a user within a trusted vendor. After compromising the trusted vendor, the threat actor hosts a file on the vendor’s file hosting service, which is then shared with a target organization. This misuse of legitimate file hosting services is particularly effective because recipients are more likely to trust emails from known vendors, allowing threat actors to bypass security measures and compromise identities. Often, users from trusted vendors are added to allow lists through policies set by the organization on Exchange Online products, enabling phishing emails to be successfully delivered.

While file names observed in these campaigns also included the recipients, the hosted files typically follow these patterns:

• Familiar topics based on existing conversations
  • For example, if the two organizations have prior interactions related to an audit, the shared files could be named “Audit Report 2024”.
• Familiar topics based on current context
  • If the attack has not originated from a trusted vendor, the threat actor often impersonates administrators or help desk or IT support personnel in the sender display name and uses a file name such as “IT Filing Support 2024”, “Forms related to Tax submission”, or “Troubleshooting guidelines”.
• Topics based on urgency
  • Another common technique observed by the threat actors creating these files is that they create a sense of urgency with the file names like “Urgent:Attention Required” and “Compromised Password Reset”.

Defense evasion techniques

Once the threat actor shares the files on the file hosting service with the intended users, the file hosting service sends the target user an automated email notification with a link to access the file securely. This email is not a phishing email but a notification for the user about the sharing action. In scenarios involving SharePoint or OneDrive, the file is shared from the user’s context, with the compromised user’s email address as the sender. However, in the Dropbox scenario, the file is shared from no-reply@dropbox[.]com. The files are shared through automated notification emails with the subject: “<User> shared <document> with you”. To evade detections, the threat actor deploys the following additional techniques:

• Only the intended recipient can access the file
  • The intended recipient needs to re-authenticate before accessing the file
  • The file is accessible only for a limited time window
• The PDF shared in the file cannot be downloaded

These techniques make detonation and analysis of the sample with the malicious link almost impossible since they are restricted.

Identity compromise

When the targeted user accesses the shared file, the user is prompted to verify their identity by providing their email address:

Next, an OTP is sent from no-reply@notify.microsoft[.]com. Once the OTP is submitted, the user is successfully authorized and can view a document, often masquerading as a preview, with a malicious link, which is another lure to make the targeted user click the “View my message” access link.

This link redirects the user to an adversary-in-the-middle (AiTM) phishing page, where the user is prompted to provide the password and complete multifactor authentication (MFA). The compromised token can then be leveraged by the threat actor to perform the second stage BEC attack and continue the campaign.

Recommended actions

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

• Enable Conditional Access policies in Microsoft Entra, especially risk-based access policies. Conditional access policies evaluate sign-in requests using additional identity-driven signals like user or group membership, IP address location information, and device status, among others, are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices, Azure trusted IP address requirements, or risk-based policies with proper access control. If you are still evaluating Conditional Access, use security defaults as an initial baseline set of policies to improve identity security posture.
• Implement continuous access evaluation.
• Implement Microsoft Entra passwordless sign-in with FIDO2 security keys.
• Turn on network protection in Microsoft Defender for Endpoint to block connections to malicious domains and IP addresses.
• Implement Microsoft Defender for Endpoint – Mobile Threat Defense on mobile devices used to access enterprise assets.
• Leverage Microsoft Edge to automatically identify and block malicious websites, including those used in this phishing campaign, and Microsoft Defender for Office 365 to detect and block malicious emails, links, and files. Monitor suspicious or anomalous activities in Microsoft Entra ID Protection. Investigate sign-in attempts with suspicious characteristics (such as the location, ISP, user agent, and use of anonymizer services). Educate users about the risks of secure file sharing and emails from trusted vendors.

Appendix

Microsoft Defender XDR detections

Microsoft Defender XDR raises the following alerts by combining Microsoft Defender for Office 365 URL click and Microsoft Entra ID Protection risky sign-ins signal.

• Risky sign-in after clicking a possible AiTM phishing URL
• User compromised through session cookie hijack
• User compromised in a known AiTM phishing kit

Hunting queries

Microsoft Defender XDR 

The file sharing events related to the activity in this blog post can be audited through the CloudAppEvents telemetry. Microsoft Defender XDR customers can run the following query to find related activity in their networks: 

Automated email notifications and suspicious sign-in activity

By correlating the email from the Microsoft notification service or Dropbox automated notification service with a suspicious sign-in activity, we can identify compromises, especially from securely shared SharePoint or Dropbox files.

let usersWithSuspiciousEmails = EmailEvents
    | where SenderFromAddress in ("no-reply@notify.microsoft.com", "no-reply@dropbox.com") or InternetMessageId startswith "<OneTimePasscode"
    | where isnotempty(RecipientObjectId)
    | distinct RecipientObjectId;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

Files share contents and suspicious sign-in activity

In the majority of the campaigns, the file name involves a sense of urgency or content related to finance or credential updates. By correlating the file share emails with suspicious sign-ins, compromises can be detected. (For example: Alex shared “Password Reset Mandatory.pdf” with you). Since these are observed as campaigns, validating that the same file has been shared with multiple users in the organization can support the detection.

let usersWithSuspiciousEmails = EmailEvents
    | where Subject has_all ("shared", "with you")
    | where Subject has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password")
    | where isnotempty(RecipientObjectId)
    | summarize RecipientCount = dcount(RecipientObjectId), RecipientList = make_set(RecipientObjectId) by Subject
    | where RecipientCount >= 10
    | mv-expand RecipientList to typeof(string)
    | distinct RecipientList;
AADSignInEventsBeta
| where AccountObjectId in (usersWithSuspiciousEmails)
| where RiskLevelDuringSignIn == 100

BEC: File sharing tactics based on the file hosting service used

To initiate the file sharing activity, these campaigns commonly use certain action types depending on the file hosting service being leveraged. Below are the action types from the audit logs recorded for the file sharing events. These action types can be used to hunt for activities related to these campaigns by replacing the action type for its respective application in the queries below this table.

OneDrive or SharePoint: The following query highlights that a specific file has been shared by a user with multiple participants. Correlating this activity with suspicious sign-in attempts preceding this can help identify lateral movements and BEC attacks.

let securelinkCreated = CloudAppEvents
    | where ActionType == "SecureLinkCreated"
    | project FileCreatedTime = Timestamp, AccountObjectId, ObjectName;
let filesCreated = securelinkCreated
    | where isnotempty(ObjectName)
    | distinct tostring(ObjectName);
CloudAppEvents
| where ActionType == "AddedToSecureLink"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive for Business")
| extend FileShared = tostring(RawEventData.ObjectId)
| where FileShared in (filesCreated)
| extend UserSharedWith = tostring(RawEventData.TargetUserOrGroupName)
| extend TypeofUserSharedWith = RawEventData.TargetUserOrGroupType
| where TypeofUserSharedWith == "Guest"
| where isnotempty(FileShared) and isnotempty(UserSharedWith)
| join kind=inner securelinkCreated on $left.FileShared==$right.ObjectName
// Secure file created recently (in the last 1day)
| where (Timestamp - FileCreatedTime) between (1d .. 0h)
| summarize NumofUsersSharedWith = dcount(UserSharedWith) by FileShared
| where NumofUsersSharedWith >= 20

Dropbox: The following query highlights that a file hosted on Dropbox has been shared with multiple participants.

CloudAppEvents
| where ActionType in ("Added users and/or groups to shared file/folder", "Invited user to Dropbox and added them to shared file/folder")
| where Application == "Dropbox"
| where ObjectType == "File"
| extend FileShared = tostring(ObjectName)
| where isnotempty(FileShared)
| mv-expand ActivityObjects
| where ActivityObjects.Type == "Account" and ActivityObjects.Role == "To"
| extend SharedBy = AccountId
| extend UserSharedWith = tostring(ActivityObjects.Name)
| summarize dcount(UserSharedWith) by FileShared, AccountObjectId
| where dcount_UserSharedWith >= 20

Microsoft Sentinel

Microsoft Sentinel customers can use the resources below to find related activities similar to those described in this post:

The following query identifies files with specific keywords that attackers might use in this campaign that have been shared through OneDrive or SharePoint using a Secure Link and accessed by over 10 unique users. It captures crucial details like target users, client IP addresses, timestamps, and file URLs to aid in detecting potential attacks:

let OperationName = dynamic(['SecureLinkCreated', 'AddedToSecureLink']);
OfficeActivity
| where Operation in (OperationName)
| where OfficeWorkload in ('OneDrive', 'SharePoint')
| where SourceFileName has_any ("payment", "invoice", "urgent", "mandatory", "Payoff", "Wire", "Confirmation", "password", "paycheck", "bank statement", "bank details", "closing", "funds", "bank account", "account details", "remittance", "deposit", "Reset")
| summarize CountOfShares = dcount(TargetUserOrGroupName), 
            make_list(TargetUserOrGroupName), 
            make_list(ClientIP), 
            make_list(TimeGenerated), 
            make_list(SourceRelativeUrl) by SourceFileName, OfficeWorkload
| where CountOfShares > 10

Considering that the attacker compromises users through AiTM,  possible AiTM phishing attempts can be detected through the below rule:

• Possible AiTM Phishing Attempt

In addition, customers can also use the following identity-focused queries to detect and investigate anomalous sign-in events that may be indicative of a compromised user identity being accessed by a threat actor:

• Signins From VPS Providers
• Signins from Nord VPN Providers
• Successful Signin From Non-Compliant Device

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 File hosting services misused for identity phishing appeared first on Microsoft Security Blog.

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

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

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

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

Analysis of the recent Storm-0501 campaign

On-premises compromise

Initial access and reconnaissance

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

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

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

Credential access and lateral movement

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

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

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

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

Data collection and exfiltration

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

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

Defense evasion

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

On-premises to cloud pivot

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

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

Microsoft Entra Connect Sync account compromise

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

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

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

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

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

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

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

Cloud session hijacking of on-premises user account

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

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

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

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

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

Impact

Cloud compromise leading to backdoor

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

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

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

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

On-premises compromise leading to ransomware

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

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

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

Mitigation and protection guidance

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

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

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

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

Detection details

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

Microsoft Defender XDR detections

Microsoft Defender Antivirus 

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

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

Additional Cobalt Strike components are detected as the following:

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

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

• Backdoor:Win32/SuspAadInternalsUsage

Embargo Ransomware threat components are detected as the following:

• Ransom:Win32/Embargo

Microsoft Defender for Endpoint 

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

• Ransomware-linked Storm-0501 threat actor detected

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

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

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

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

Microsoft Defender for Identity

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

• Data exfiltration over SMB
• Suspected DCSync attack

Microsoft Defender for Cloud Apps

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

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

Microsoft Defender Vulnerability Management

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

• CVE-2022-47966

Threat intelligence reports 

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

• Storm-0501

Advanced hunting 

Microsoft Defender XDR

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

Microsoft Entra Connect Sync account exploration

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

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

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

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

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

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

Check which IP addresses Microsoft Entra Connect Sync account uses

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

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

Federation and authentication domain changes

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

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

Microsoft Sentinel

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

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

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

Search for file IOC

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

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

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

Indicators of compromise (IOCs)

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

References

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

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

Microsoft Threat Intelligence Community

Learn more

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

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

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

The post Storm-0501: Ransomware attacks expanding to hybrid cloud environments appeared first on Microsoft Security Blog.

We identified several vulnerable applications in the Google Play Store that represented over four billion installations. We anticipate that the vulnerability pattern could be found in other applications. We’re sharing this research so developers and publishers can check their apps for similar issues, fix as appropriate, and prevent introducing such vulnerabilities into new apps or releases.  As threats across all platforms continue to evolve, industry collaboration among security researchers, security vendors, and the broader security community is essential in improving security for all. Microsoft remains committed to working with the security community to share vulnerability discoveries and threat intelligence to protect users across platforms.

After discovering this issue, we identified several vulnerable applications. As part of our responsible disclosure policy, we notified application developers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) and worked with them to address the issue. We would like to thank the Xiaomi, Inc. and WPS Office security teams for investigating and fixing the issue. As of February 2024, fixes have been deployed for the aforementioned apps, and users are advised to keep their device and installed applications up to date.

Recognizing that more applications could be affected, we acted to increase developer awareness of the issue by collaborating with Google to publish an article on the Android Developers website, providing guidance in a high-visibility location to help developers avoid introducing this vulnerability pattern into their applications. We also wish to thank Google’s Android Application Security Research team for their partnership in resolving this issue.

In this blog post, we continue to raise developer and user awareness by giving a general overview of the vulnerability pattern, and then focusing on Android share targets, as they are the most prone to these types of attacks. We go through an actual code execution case study where we demonstrate impact that extends beyond the mobile device’s scope and could even affect a local network. Finally, we provide guidance to users and application developers and illustrate the importance of collaboration to improve security for all.

Overview: Data and file sharing on Android

The Android operating system enforces isolation by assigning each application its own dedicated data and memory space. To facilitate data and file sharing, Android provides a component called a content provider, which acts as an interface for managing and exposing data to the rest of the installed applications in a secure manner. When used correctly, a content provider provides a reliable solution. However, improper implementation can introduce vulnerabilities that could enable bypassing of read/write restrictions within an application’s home directory.

The Android software development kit (SDK) includes the FileProvider class, a subclass of ContentProvider that enables file sharing between installed applications. An application that needs to share its files with other applications can declare a FileProvider in its app manifest and declare the specific paths to share.

Every file provider has a property called authority, which identifies it system-wide, and can be used by the consumer (the app that wants to access the shared files) as a form of address. This content-based model bears a strong resemblance to the web model, but instead of the http scheme, consumers utilize the content scheme along with the authority, followed by a pseudo-path to the file that they want to access.

For example, assuming that the application com.example.server shares some files under the file:///data/data/com.example.server/fileshttps://www.microsoft.com/images directory that it has previously declared as shared using the name shared_images, a consumer can use the content://[authority]/shared_images/[sub-path]/[filename] URI to index these files.

Access is given by the data sharing application most commonly using the grantUriPermissions attribute of the Android manifest, in combination with special flags that are used to define a read or write mode of operation. The data sharing application creates and sends an intent to the consumer that provides temporary fine-grained access to a file.  Finally, when a provider receives a file access request, it resolves the actual file path that corresponds to the incoming URI and returns a file descriptor to it.  

Implementation pitfalls

This content provider-based model provides a well-defined file-sharing mechanism, enabling a serving application to share its files with other applications in a secure manner with fine-grained control. However, we have frequently encountered cases where the consuming application doesn’t validate the content of the file that it receives and, most concerning, it uses the filename provided by the serving application to cache the received file within the consuming application’s internal data directory. If the serving application implements its own malicious version of FileProvider, it may be able to cause the consuming application to overwrite critical files.

Share targets

In simple terms, a share target is an Android app that declares itself to handle data and files sent by other apps. Common application categories that can be share targets include mail clients, social networking apps, messaging apps, file editors, browsers, and so on. In a common scenario, when a user clicks on a file, the Android operating system triggers the share-sheet dialog asking the user to select the component that the file should be sent to:

While this type of guided file-sharing interaction itself may not trigger a successful attack against a share target, a malicious Android application can create a custom, explicit intent and send a file directly to a share target with a malicious filename and without the user’s knowledge or approval. Essentially, the malicious application is substituting its own malicious FileProvider implementation and provides a filename that is improperly trusted by the consuming application.

In Figure 2, the malicious app, on the left, creates an explicit intent that targets the file processing component of the share target, on the right, and attaches a content URI as an intent’s extra. It then sends this intent to the share target using the startActivity API call.

After this point, most of the share targets that we have reviewed seem to follow a specific code pattern that includes the following steps:

1. Request the actual filename from the remote file provider
2. Use this filename to initialize a file that is subsequently used to initialize a file output stream
3. Create an input stream using the incoming content URI
4. Copy the input stream to the output stream

Since the rogue app controls the name as well as the content of the file, by blindly trusting this input, a share target may overwrite critical files in its private data space, which may lead to serious consequences.

Impact

We identified this vulnerability pattern in the then-current versions of several Android applications published on the Google Play Store, including at least four with more than 500 million installations each. In each case, we responsibly disclosed to the vendor. Two example vulnerable applications that we identified are Xiaomi Inc.’s File Manager (1B+ installs) and WPS Office (500M+ installs).

In Xiaomi Inc.’s File Manager, we were able to obtain arbitrary code execution in version V1-210567. After our disclosure, Xiaomi published version V1-210593, and we verified that the vulnerability has been addressed. In WPS Office, we were able to obtain arbitrary code execution in version 16.8.1. After our disclosure, WPS published and informed us that the vulnerability has been addressed as of version 17.0.0.

The potential impact varies depending on implementation specifics. For example, it’s very common for Android applications to read their server settings from the shared_prefs directory. In such cases, the malicious app can overwrite these settings, causing the vulnerable app to communicate with an attacker-controlled server and send the user’s authentication tokens or other sensitive information.

In a worst-case (and not so uncommon) scenario, the vulnerable application might load native libraries from its data directory (as opposed to the more secure /data/app-lib directory, where the libraries are protected from modification). In this case, the malicious application can overwrite a native library with malicious code that gets executed when the library is loaded. In the following section, we use Xiaomi Inc.’s File Manager to illustrate this case. We demonstrated the ability for a malicious application to overwrite the application’s shared preferences, write a native library to the application’s internal storage, and cause the application to load the library. These actions provided arbitrary code execution with the file manager’s user ID and permissions.

In the following sections, we focus on this case and delve into the technical details of this vulnerability pattern.

Case study: Xiaomi Inc.’s File Manager

Xiaomi Inc.’s File Manager is the default file manager application for Xiaomi devices and is published under the package name com.mi.android.globalFileexplorer on the Google Play Store, where it has been installed over one billion times.

Besides having full access to the device’s external storage, the application requests many permissions, including the ability to install other applications:

Further, it offers a junk files cleaner plugin as well as the ability to connect to remote FTP and SMB shares:

Vulnerability assessment findings

During our investigation, we identified that the application exports the CopyFileActivity, an activity alias of the com.android.fileexplorer.activity.FileActivity, which is used to handle copy-from-to file operations:

Since this activity is exported, it can be triggered by any application installed on the same device by using an explicit intent of action SEND or SEND_MULTIPLE and attaching a content URI corresponding to a file stream.

Upon receiving such an intent, the browser performs a validity check, which we found to be insufficient:

As depicted above, the initCopyOrMoveIntent method calls the checkValid method passing as an argument a content URI (steps 1 and 2). However, the checkValid method is designed to handle a file path, not a content URI. It always returns true for a content URI. Instead, a safer practice is to parse the string as a URI, including ensuring the scheme is the expected value (in this case, file, not content).The checkValid method verifies that the copy or move operation doesn’t affect the private directory of the app, by initializing a file object using the incoming string as an argument to the File class constructor and comparing its canonical path with the path that corresponds to the home directory of the application (steps 3 and 4). Given a content URI as a path, the File constructor normalizes it (following a Unix file system normalization), thus the getCanonicalPath method returns a string starting with “/content:/“, which will always pass the validity check. More specifically, the app performs a query to the remote content provider for the _size, _display_name and _data columns (see line 48 below). Then it uses the values returned by these rows to initialize the fields of an object of the com.android.fileexplorer.mode.c class:

Given the case that the _display_name and _data values, returned from the external file provider, are relative paths to the destination directory, after exiting from the method above, these class fields will contain values like the ones depicted below:

As shown above, the paths (variables d and e) of this file-model point to files within the home directory of the application, thus the file streams attached to the incoming intent are going to be written under the specific locations.

Getting code execution

As previously mentioned, the application uses a plugin to clean the device’s junk files:

When the application loads this plugin, it makes use of two native libraries: libixiaomifileu.so, which fetches from the /data/app directory, and libixiaomifileuext.so from the home directory:

As apps don’t have write access to the /data/app folder, the libixiaomifileu.so file stored there cannot be replaced. The easiest way to get code execution is to replace the libixiaomifileuext.so with a malicious one. However, an attempt to do so would fail since in this particular case, the vulnerability that we described can only be used to write new files within the home directory, not overwrite existing files. Our next inquiry was to determine how the application loads the libixiaomifileu.so.

Our assessment showed that before the application loads this library, it follows the following steps:

1. Calculate the hash of the file libixiaomifileu.so, located in the /data/app directory

2. Compare this hash with the value assigned to the “libixiaomifileu.so_hm5” string, fetched from the com.mi.android.globalFileexprorer_preferences.xml file

3. If the values don’t match, search for the libixiaomifileu.so file in the /files/lib path in the home directory

4. If the file is found there, calculate its hash and compare it again with the value from the shared_preferences folder

5. If the hashes match, load the file under the /files/lib using the System.load method

Given this behavior, in order to get code execution with the file manager’s user ID, an attacker must take the following steps:

1. Use the path traversal vulnerability to save a malicious library as /files/lib/libixiaomifileu.so (the file does not already exist in that directory, so overwriting is not an issue)

2. Calculate the hash of this library to replace the value of the libixiaomifileu.so_hm5 string

3. Trigger the junk cleaner plugin with an explicit intent, since the activity that loads the native libraries is exported

An acute reader might have noticed that the second step requires the attacker to force the browser to overwrite the com.mi.android.globalFileexprorer_preferences.xml, which, as we already mentioned, was not possible.

To overcome this restriction, we referred to the actual implementation of the SharedPreferences class, where we found that when an Android application uses the getSharedPreferences API method to retrieve an instance of the SharedPreferences class, giving the name of the shared preferences file as an argument, then the constructor of the SharedPreferencesImpl class performs the following steps:

1. Create a new file object using the name provided to the getSharedPreferences method, followed by the .xml extension, followed by the .bak extension

2. Check if this file exists, and in case it does, delete the original xml file and replace it with the one created in the first step

Through this behavior, we were able to save the com.mi.android.globalFileexprorer_preferences.xml.bak under the shared preferences folder (as during the application’s runtime it is unlikely to exist), so when the app tried to verify the hash, the original xml file was already replaced by our own copy. After this point, by using a single intent to start the junk cleaner plugin, we were able to trick the application to load the malicious library instead of the one under the /data/app folder and get code execution with the browser’s user ID.

Impact

One reason we chose to use this app as a showcase is because the impact extends beyond the user’s mobile device. The application gives the option to connect to remote file shares using the FTP and SMB protocols and the user credentials are saved in clear text in the /data/data/com.mi.android.globalFileexplorer/files/rmt_i.properties file:

If a third party app was able to exploit this vulnerability and obtain code execution, an attacker could retrieve these credentials. The impact would then extend even further, since by the time that a user requests to open a remote share, the browser creates the directory /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ where it saves the files that the user retrieves:

This means that a remote attacker would be able to read or write files to SMB shares of a local network, assuming that the device was connected to it. The same stands for FTP shares as they are handled exactly in the same way:

In summary, the exploitation flow is depicted in the figure below:

In step 1, the user opens a malicious app that may pose as a file editor, messaging app, mail client, or any app in general and request the user to save a file. By the time that the user attempts to save such a file, no matter what destination path they choose to save it, the malicious app forces the file browser app to write it under its internal /files/lib folder. Then, the malicious app can start the junk cleaner using an explicit intent (no user interaction is required) and this will lead to code execution with the browser’s ID (step 2).

In step 3, the attacker uses the arbitrary code execution capability to retrieve the SMB and FTP credentials from the rmt_i.properties file. Subsequently, the attacker can now jump to step 5 and access the shares directly using the stolen credentials. Alternatively, after retrieving the share credentials, the mobile device can connect to a local network (step 4) and access an SMB or FTP share, allowing the attacker to access the shared files through the /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ folder (step 5).

Recommendations

Recognizing that this vulnerability pattern may be widespread, we shared our findings with Google’s Android Application Security Research team. We collaborated with Google to author guidance for Android application developers to help them recognize and avoid this pattern. We recommend developers and security analysts familiarize themselves with the excellent Android application security guidance provided by Google as well as make use of the Android Lint tool included with the Android SDK and integrated with Android Studio (supplemented with Google’s additional security-focused checks) to identify and avoid potential vulnerabilities. GitHub’s CodeQL also provides capabilities to identify vulnerabilities.

To prevent these issues, when handling file streams sent by other applications, the safest solution is to completely ignore the name returned by the remote file provider when caching the received content. Some of the most robust approaches we encountered use randomly generated names, so even in the case that the content of an incoming stream is malformed, it won’t tamper with the application.

In cases where such an approach is not feasible, developers need to take extra steps to ascertain that the cached file is written to a dedicated directory. As an incoming file stream is usually identified by a content URI, the first step is to reliably identify and sanitize the corresponding filename. Besides filtering characters that may lead to a path traversal and before performing any write operation, developers must verify that the cached file is within the dedicated directory by performing a call to the File.getCanonicalPath and validating the prefix of the returned value.

Another area to safeguard is in the way developers try to extract a filename from a content URI. Developers often use Uri.getLastPathSegment(), which returns the (URL) decoded value of the last path URI segment. An attacker can craft a URI with URL encoded characters within this segment, including characters used for path traversal. Using the returned value to cache a file can again render the application vulnerable to this type of attack.

For end users, we recommend keeping mobile applications up to date through the Google Play Store (or other appropriate trusted source) to ensure that updates addressing known vulnerabilities are installed. Users should only install applications from trusted sources to avoid potentially malicious applications. We recommend users who accessed SMB or FTP shares through the Xiaomi app before updates to reset credentials and to investigate for any anomalous behavior. Microsoft Defender for Endpoint on Android can alert users and enterprises to malicious applications, and Microsoft Defender Vulnerability Management can identify installed applications with known vulnerabilities.

Dimitrios Valsamaras

Microsoft Threat Intelligence

References

• https://www.blackhat.com/asia-23/briefings/schedule/index.html#dirty-stream-attack-turning-android-share-targets-into-attack-vectors-30234
• https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename
• https://developer.android.com/reference/androidx/core/content/FileProvider
• https://developer.android.com/guide/topics/manifest/provider-element#gprmsn
• https://play.google.com/store/apps/details?id=com.mi.android.globalFileexplorer
• https://play.google.com/store/apps/details?id=cn.wps.moffice_eng
• https://googlesamples.github.io/android-custom-lint-rules/checks/UnsafeDynamicallyLoadedCode.md.html
• https://androidrank.org/application/file_manager/com.mi.android.globalFileexplorer
• https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/SharedPreferencesImpl.java;l=150
• https://developer.android.com/privacy-and-security/risks
• https://developer.android.com/studio/write/lint#gradle
• https://github.com/google/android-security-lints/
• https://codeql.github.com/codeql-query-help/java/

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 “Dirty stream” attack: Discovering and mitigating a common vulnerability pattern in Android apps 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.

October 2024 update – Microsoft’s Digital Crimes Unit (DCU) is disrupting the technical infrastructure used by Star Blizzard. We have updated this blog with the latest observed Star Blizzard tactics, techniques, and procedures (TTPs).

Microsoft Threat Intelligence continues to track and disrupt malicious activity attributed to a Russian nation-state actor we call Star Blizzard. Star Blizzard has continuously improved their detection evasion capabilities while remaining focused on email credential theft against the same targets. Star Blizzard, whose activities we assess to have historically supported both espionage and cyber influence objectives, continues to prolifically target individuals and organizations involved in international affairs, defense, and logistics support to Ukraine, as well as academia, information security companies, and other entities aligning with Russian state interests. Microsoft continues to refine and deploy protections against Star Blizzard’s evolving spear-phishing tactics.

Microsoft is grateful for the collaboration on investigating Star Blizzard compromises with the international cybersecurity community, including our partners at the UK National Cyber Security Centre, the US National Security Agency Cybersecurity Collaboration Center, and the US Federal Bureau of Investigation.

This blog provides updated technical information about Star Blizzard tactics, techniques, and procedures (TTPs), building on our 2022 blog as the threat actor continues to refine their tradecraft to evade detection. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the necessary information to secure their accounts.

Star Blizzard TTPs observed in 2024

Star Blizzard persistently introduces new techniques to avoid detection. These TTPs are employed for brief periods and are either modified or abandoned once they become publicly known.

Microsoft has identified the following evasive techniques used by Star Blizzard in campaigns in 2024:

• Use of multiple registrars to register domain infrastructure
• Use of multiple link-shortening services and legitimate websites with open redirects, to hide actor-registered domains
• Use of altered legitimate email templates as spear-phishing lures

Using multiple registrars to register domain infrastructure

In December 2023, we highlighted that Star Blizzard was using the registrar NameCheap to register their domain infrastructure. As CitizenLab reported (August 2024), the threat actor has also used Hostinger to register domains used in the infrastructure for email credential theft.

Microsoft can confirm that in 2024 Star Blizzard transitioned from their long-standing practice of primarily using a single domain name registrar. Among the registrars seen used by Star Blizzard in 2024 are the following:

• Hostinger
• RealTime Register
• GMO Internet

A list of recent domain names registered by Star Blizzard can be found at the end of this report.

Use of multiple link-shortening services and legitimate websites to hide actor-registered domains

Since August 2024, Star Blizzard has made substantial changes in the methods they employ to redirect targets to their virtual private server (VPS) infrastructure, on which Evilginx is installed and then used to facilitate credential theft.

In December 2023, we detailed the threat actor’s use of email marketing platforms to prevent the need to embed the actor-registered domains in their spear-phishing emails. This technique was abandoned in early 2024, with the threat actor transitioning first to hosting the initial redirector website on shared infrastructure. Since August 2024, Star Blizzard has added multiple layers of redirection to their VPS infrastructure, utilizing various link-shortening services and legitimate websites that can be used as open redirectors.

For example, in a recent spear-phishing email that was sent from an actor-controlled Outlook account, we found that the threat actor had embedded an initial link, which was created using the Microsoft 365 Safe Links into the attached PDF lure. The Safe Links URL could only be generated by sending an email between actor-controlled accounts with the link in the body. The actor then copied that generated Safe Links URL to use in their attack.   

This link redirected to a shortened URL created using the Bitly link-shortening service, which resolved to another shortened URL created using the Cuttly link-shortening service. The second shortened URL redirected to a legitimate website, used as an open redirector, which ultimately redirected to the first actor-controlled domain.

The website mechengsys[.]net was hosted on shared infrastructure at Hostinger and performed various filtering actions until ultimately redirecting to an actor-controlled VPS installed with Evilginx, resolving the domain vidmemax[.]com.

Use of altered legitimate email templates as spear-phishing lures

For a brief period between July and August 2024, the threat actor utilized spear-phishing lures that did not contain or redirect to PDF lures embedded with links that redirected to actor-controlled infrastructure. Instead, Star Blizzard sent targets an altered OneDrive file share notification that included a clickable link to a malicious URL. When clicked, the link would initiate redirection to actor-controlled infrastructure. We observed Star Blizzard using this approach in spear-phishing attacks against its traditional espionage targets, including individuals associated with politics and diplomacy, NGOs, and think tanks.

In this approach, the threat actor began by creating a new email account, usually a Proton account, intended to impersonate a trusted sender so the recipient would be more likely to open the phishing email. The actor then stored a benign PDF or Word file in a cloud file-hosting service (for example, when targeting Microsoft customers, OneDrive) and shared the file with the newly created email account. The threat actor edited the HTML of the email, changing the displayed sender name and the URL behind the “Open” button that would otherwise lead back to the OneDrive-hosted file so that it directed to the Evilginx redirector domain instead.  

Star Blizzard then sent the spear-phishing email to the target. When the “Open” button was clicked, it directed the user to the redirector domain, which, after performing filtering based on browser fingerprinting and additional methods, directed the target to an actor-controlled Virtual Private Server (VPS) with the Evilginx installation. The Evilginx server allowed Star Blizzard to perform an adversary-in-the-middle (AiTM) attack on an authentication session to an email provider, enabling the actor to receive the necessary information to perform subsequent sign-ins to the target’s email account, including the username, password, and MFA token, if MFA is used by the target.

TTPs used in past Star Blizzard campaigns

Microsoft observed Star Blizzard using the following TTPs in campaigns before 2024, highlighting continuously evolving techniques used by the threat actor to evade detection:

• Use of server-side scripts to prevent automated scanning of actor-controlled infrastructure
• Use of email marketing platform services to hide true email sender addresses and obviate the need for including actor-controlled domain infrastructure in email messages
• Use of a DNS provider to obscure the IP addresses of actor-controlled virtual private server (VPS) infrastructure. Once notified, the DNS provider took action to mitigate actor-controlled domains abusing their service.
• Password-protected PDF lures or links to cloud-based file-sharing platforms where PDF lures are hosted
• Shift to a more randomized domain generation algorithm (DGA) for actor-registered domains

Use of server-side scripts to prevent automated scanning

Between April 2023 and December 2023, we observed Star Blizzard gradually moving away from using hCaptcha servers as the sole initial filter to prevent automatic scanning of their Evilginx server infrastructure. Redirection was still performed by an actor-controlled server, first executing JavaScript code (titled “Collect and Send User Data”) before redirecting the browsing session to the Evilginx server.

Shortly after, in May 2023, the threat actor was observed refining the JavaScript code, resulting in an updated version (titled “Docs”), which is still in use today.

This capability collects various information from the browser performing the browsing session to the redirector server. The code contains three main functions:

• pluginsEmpty(): This function checks if the browser has any plugins installed.

• isAutomationTool(): This function checks for various indicators that the page is being accessed by an automation tool (such as Selenium, PhantomJS, or Nightmare) and returns an object with information about the detected tools.

• sendToBackend(data): This function sends the data collected by isAutomationTool() to the server using a POST request. If the server returns a response, the message in the response is executed using eval().

Following the POST request, the redirector server assessed the data collected from the browser and decided whether to allow continued browser redirection.

When a good verdict is reached, the browser received a response from the redirection server, redirecting to the next stage of the chain, which is either an hCaptcha for the user to solve, or direct to the Evilginx server.

A bad verdict resulted in the receipt of an HTTP error response and no further redirection.

Use of email marketing platform services

We previously observed Star Blizzard using two different services, HubSpot and MailerLite. The actor used these services to create an email campaign, which provided them with a dedicated subdomain on the service that is then used to create URLs. These URLs acted as the entry point to a redirection chain ending at actor-controlled Evilginx server infrastructure. The services also provided the user with a dedicated email address per configured email campaign, which the threat actor has been seen to use as the “From” address in their campaigns.

Most Star Blizzard HubSpot email campaigns have targeted multiple academic institutions, think tanks, and other research organizations using a common theme, aimed at obtaining their credentials for a US grants management portal. We assess that this use-case of the HubSpot mailing platform was to allow the threat actor to track large numbers of identical messages sent to multiple recipients. Note should be taken to the “Reply-to” address in these emails, which is required by the HubSpot platform to be an actual in-use account. All the sender accounts in the following examples were dedicated threat actor-controlled accounts.

Other HubSpot campaigns have been observed using the campaign URL embedded in an attached PDF lure or directly in the email body to perform redirection to actor-controlled Evilginx server infrastructure configured for email account credential theft. We assess that in these cases, the HubSpot platform was used to remove the need for including actor-controlled domain infrastructure in the spear-phishing emails and better evade detection based on indicators of compromise (IOC).

Star Blizzard’s use of the MailerLite platform is similar to the second HubSpot tactic described above, with the observed campaign URL redirecting to actor-controlled infrastructure purposed for email credential theft.

Use of a DNS provider to resolve actor-controlled domain infrastructure

In December 2022, we began to observe Star Blizzard using a domain name service (DNS) provider that also acts as a reverse proxy server to resolve actor-registered domain infrastructure. As of May 2023, most Star Blizzard registered domains associated with their redirector servers use a DNS provider to obscure the resolving IP addresses allocated to their dedicated VPS infrastructure.

We have yet to observe Star Blizzard utilizing a DNS provider to resolve domains used on Evilginx servers.

Password-protected PDF lures or links to cloud-based file-sharing platforms

Star Blizzard has been observed sending password-protected PDF lures in an attempt to evade email security processes implemented by defenders. The threat actor usually sends the password to open the file to the targeted user in the same or a subsequent email message.

In addition to password-protecting the PDF lures themselves, the actor has been observed hosting PDF lures at a cloud storage service and sharing a password-protected link to the file in a message sent to the intended victim. While Star Blizzard frequently uses cloud storage services from all major providers (including Microsoft OneDrive), Proton Drive is predominantly chosen for this purpose.

Microsoft suspends Star Blizzard operational accounts discovered using our platform for their spear-phishing activities.

Randomizing DGA for actor registered domains

Following the detailed public reporting by Recorded Future (August 2023) on detection opportunities for Star Blizzard domain registrations, we have observed the threat actor making significant changes in their chosen domain naming syntax.

Prior to the public reporting, Star Blizzard utilized a limited wordlist for their DGA. Subsequently, Microsoft has observed that the threat actor has upgraded their domain-generating mechanism to include a more randomized list of words.

Despite the increased randomization, Microsoft has identified detection opportunities based on the following constant patterns in Star Blizzard domain registration behavior:

• Namecheap remains the registrar of choice
• Domains are usually registered in groups, many times with similar naming conventions
• X.509 TLS certificates are provided by Let’s Encrypt, created in the same timeframe of domain registration

A list of recent domain names registered by Star Blizzard can be found at the end of this report.

Consistent TTPs since 2022

Star Blizzard activities remain focused on email credential theft, predominantly targeting cloud-based email providers that host organizational and/or personal email accounts.

Star Blizzard continues to utilize the publicly available Evilginx framework to achieve their objective, with the initial access vector remaining to be spear-phishing via email. Target redirection to the threat actor’s Evilginx server infrastructure is still usually achieved using custom-built PDF lures that open a browser session. This session follows a redirection chain ending at actor-controlled Evilginx infrastructure that is configured with a “phishlet” for the intended targets’ email provider.

Star Blizzard remains constant in their use of pairs of dedicated VPSs to host actor-controlled infrastructure (redirector + Evilginx servers) used for spear-phishing activities, where each server usually hosts a separate actor registered domain.

Protecting yourself against Star Blizzard

As with all threat actors that focus on phishing or spear-phishing to gain initial access to victim mailboxes, individual email users should be aware of who these attacks target and what they look like to improve their ability to identify and avoid further attacks.

The following are a list of answers to questions that enterprise and consumer email users should be asking about the threat from Star Blizzard:

Am I at risk of being a Star Blizzard target?

Users and organizations are more likely to be a potential Star Blizzard target if connected to the following areas:

1. Government or diplomacy (both incumbent and former position holders).
2. Research into defense policy or international relations when related to Russia.
3. Assistance to Ukraine related to the ongoing conflict with Russia.

Remember that Star Blizzard targets both consumer and enterprise accounts, so there is an equal threat to both organization and personal accounts.

What will a Star Blizzard spear-phishing email look like?

Star Blizzard emails appear to be from a known contact that users or organizations expect to receive email from. The sender address could be from any free email provider, but special attention should be paid to emails received from Proton account senders  (@proton[.]me, @protonmail[.]com) as they are frequently used by the threat actor.

An initial email is usually sent to the target, asking them to review a document, but without any attachment or link to the document.

The threat actor will wait for a response, and following that, will send an additional message with either an attached PDF file or an embedded link, as detailed above in “Star Blizzard TTPs observed in 2024.”

If the targeted user has not completed authentication by entering their password in the offered sign-in page and/or supplied all the required factors for multifactor authentication (MFA), the threat actor does not have the capability to successfully compromise the targeted account.

Our recommendation to all email users that belong to Star Blizzard targeted sectors is to always remain vigilant when dealing with email, especially emails containing links to external resources. When in doubt, contact the person you think is sending the email using a known and previously used email address, to verify that the email was indeed sent by them.

What happens if I interact with a Star Blizzard PDF lure?

Pressing the button in a PDF lure causes the default browser to open a link embedded in the PDF file code—this is the beginning of the redirection chain. Targets will likely see a web page titled “Docs” in the initial page opened and may be presented with a CAPTCHA to solve before continuing the redirection. The browsing session will end showing a sign-in screen to the account where the spear-phishing email was received, with the targeted email already appearing in the username field.

The host domain in the web address is an actor-controlled domain (see appendix for full list), and not the expected domain of the email server or cloud service.

If multifactor authentication is configured for a targeted email account, entering a password in the displayed sign-in screen will trigger an authentication approval request. If passwordless access is configured for the targeted account, an authentication approval request is immediately received on the device chosen for receiving authentication approvals.

As long as the authentication process is not completed (a valid password is not entered and/or an authentication request is not approved), the threat actor has not compromised the account.

If the authentication process is completed, the credentials have been successfully compromised by Star Blizzard, and the threat actor has all the required details needed to immediately access the mailbox, even if multifactor authentication is enabled.

Recommendations

As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the necessary information to secure their accounts.

Microsoft emphasizes that the following two mitigations will strengthen customers’ environments against Star Blizzard attack activity:

• Using phishing resistant authentication methods.
• Lockdown account access using Conditional Access policies

Microsoft is sharing indicators of compromise related to this attack at the end of this report to encourage the security community to further investigate for potential signs of Star Blizzard activity using their security solution of choice. All these indicators have been incorporated into the threat intelligence feed that powers Microsoft Defender products to aid in protecting customers and mitigating this threat. If your organization is a Microsoft Defender for Office customer or a Microsoft Defender for Endpoint customer with network protection turned on, no further action is required to mitigate this threat presently. A thorough investigation should be performed to understand potential historical impact if Star Blizzard activity has been previously alerted on in the environment.

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

• Use advanced anti-phishing solutions like Microsoft Defender for Office 365 that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers that automatically identify and block malicious websites and provide solutions that detect and block malicious emails, links, and files.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
• Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Use  security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable conditional access policies.  Conditional access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the application’s consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware. In all web protection scenarios, SmartScreen and Network Protection can be used together to ensure protection across both Microsoft and non-Microsoft browsers and processes.
• Microsoft Defender 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.

Appendix

Microsoft Defender XDR detections

Microsoft Defender for Office 365

Microsoft Defender for Office 365 offers enhanced solutions for blocking and identifying malicious emails. Signals from Microsoft Defender for Office 365 inform Microsoft 365 Defender, which correlate cross-domain threat intelligence to deliver coordinated defense, when this threat has been detected. These alerts, however, can be triggered by unrelated threat activity. Example alerts:

• A potentially malicious URL click was detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft Defender SmartScreen

Microsoft Defender SmartScreen has implemented detections against the phishing domains represented in the IOC section below. By enabling Network protection, organizations can block attempts to connect to these malicious domains.

Microsoft Defender for Endpoint

Aside from the Microsoft Defender for Office 365 alerts above, customers can also monitor for the following Microsoft Defender for Endpoint alerts for this attack. Note that these alerts can also be triggered by unrelated threat activity. Example alerts:

• Star Blizzard activity group
• Suspicious URL clicked
• Suspicious URL opened in web browser
• User accessed link in ZAP-quarantined email
• Suspicious activity linked to a Russian state-sponsored threat actor has been detected
• Connection to adversary-in-the-middle (AiTM) phishing site
• User compromised in AiTM phishing attack
• Possible AiTM phishing attempt

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 information, and recommended actions to prevent, mitigate, and respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Star Blizzard
• Disrupting Star Blizzard’s ongoing phishing operations
• Star Blizzard adopting PDF-less approach to spearphishing
• Star Blizzard spearphishing campaign targets US think tanks

Microsoft Defender for Endpoint Threat analytics 

• Threat Insights: Disrupting Star Blizzard’s ongoing phishing operations

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.  

• Open Email Link 
• Suspicious Url Clicked 
• Doc attachment with link to download
• Possible Phishing with CSL & NetworkSession
• Potential DGA detected
• Possible DGA Contacts 
• Potential DGA Detected via Repetitive Failures AnomalyBased
• MultiVendor-Possible DGA Contacts
• Successful Signin From Non-CompliantDevice
• Risky User In 3P network activity

Indicators of compromise

Domain infrastructure observed in 2024

Past Star Blizzard domain infrastructure

Star Blizzard HubSpot campaign domains:

• djs53104[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djr6t104[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djrzf704[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djskzh04[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djslws04[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djs36c04[.]eu1[.]hubspotlinksfree[.]com – used in August 2023
• djt47x04[.]eu1[.]hubspotlinksfree[.]com – used in September 2023
• djvcl404[.]eu1[.]hubspotlinksfree[.]com – used in October 2023
• d5b74r04[.]na1[.]hubspotlinksfree[.]com – used in October 2023
• djvxqp04[.]eu1[.]hubspotlinksfree[.]com – used in October 2023

Star Blizzard MailerLite campaign domain:

• ydjjja[.]clicks[.]mlsend[.]com – used in September 2023

References

• https://citizenlab.ca/2024/08/sophisticated-phishing-targets-russias-perceived-enemies-around-the-globe/
• https://www.ncsc.gov.uk/news/spear-phishing-campaigns-targets-of-interest
• https://www.recordedfuture.com/bluecharlie-previously-tracked-as-tag-53-continues-to-deploy-new-infrastructure-in-2023

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.

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 Star Blizzard increases sophistication and evasion in ongoing 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 current investigation indicates this campaign has affected fewer than 40 unique global organizations. The organizations targeted in this activity likely indicate specific espionage objectives by Midnight Blizzard directed at government, non-government organizations (NGOs), IT services, technology, discrete manufacturing, and media sectors. Microsoft has mitigated the actor from using the domains and continues to investigate this activity and work to remediate the impact of the attack. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Midnight Blizzard (NOBELIUM) is a Russia-based threat actor attributed by the US and UK governments as the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-government organizations (NGOs), and IT service providers primarily in the US and Europe. Their focus is to collect intelligence through longstanding and dedicated espionage of foreign interests that can be traced to early 2018. Their operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection.

Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. They utilize diverse initial access methods ranging from stolen credentials to supply chain attacks, exploitation of on-premises environments to laterally move to the cloud, exploitation of service providers’ trust chain to gain access to downstream customers, as well as the Active Directory Federation Service (AD FS) malware known as FOGGYWEB and MAGICWEB. Midnight Blizzard (NOBELIUM) is tracked by partner security vendors as APT29, UNC2452, and Cozy Bear.

Midnight Blizzard’s latest credential phishing attack

Midnight Blizzard regularly utilizes token theft techniques for initial access into targeted environments, in addition to authentication spear-phishing, password spray, brute force, and other credential attacks. The attack pattern observed in malicious activity since at least late May 2023 has been identified as a subset of broader credential attack campaigns that we attribute to Midnight Blizzard.

Use of security-themed domain names in lures

To facilitate their attack, the actor uses Microsoft 365 tenants owned by small businesses they have compromised in previous attacks to host and launch their social engineering attack. The actor renames the compromised tenant, adds a new onmicrosoft.com subdomain, then adds a new user associated with that domain from which to send the outbound message to the target tenant. The actor uses security-themed or product name-themed keywords to create a new subdomain and new tenant name to lend legitimacy to the messages. These precursory attacks to compromise legitimate Azure tenants and the use of homoglyph domain names in social engineering lures are part of our ongoing investigation. Microsoft has mitigated the actor from using the domains.

Social engineering attack chain

In this activity, Midnight Blizzard either has obtained valid account credentials for the users they are targeting, or they are targeting users with passwordless authentication configured on their account – both of which require the user to enter a code that is displayed during the authentication flow into the prompt on the Microsoft Authenticator app on their mobile device.

After attempting to authenticate to an account where this form of MFA is required, the actor is presented with a code that the user would need to enter in their authenticator app. The user receives the prompt for code entry on their device. The actor then sends a message to the targeted user over Microsoft Teams eliciting the user to enter the code into the prompt on their device.

Step 1: Teams request to chat

The target user may receive a Microsoft Teams message request from an external user masquerading as a technical support or security team.

Step 2: Request authentication app action

If the target user accepts the message request, the user then receives a Microsoft Teams message from the attacker attempting to convince them to enter a code into the Microsoft Authenticator app on their mobile device.

Step 3: Successful MFA authentication

If the targeted user accepts the message request and enters the code into the Microsoft Authenticator app, the threat actor is granted a token to authenticate as the targeted user. The actor gains access to the user’s Microsoft 365 account, having completed the authentication flow.

The actor then proceeds to conduct post-compromise activity, which typically involves information theft from the compromised Microsoft 365 tenant. In some cases, the actor attempts to add a device to the organization as a managed device via Microsoft Entra ID (formerly Azure Active Directory), likely an attempt to circumvent conditional access policies configured to restrict access to specific resources to managed devices only.

Recommendations

Microsoft recommends the following mitigations to reduce the risk of this threat.

• Pilot and start deploying phishing-resistant authentication methods for users.
• Implement Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Apply security best practices for Microsoft Teams. Refer to the security guide for Microsoft Teams.
  • Understand and select the best access settings for external collaboration for your organization.
  • Specify trusted Microsoft 365 organizations to define which external domains are allowed or blocked to chat and meet.
• Keep Microsoft 365 auditing enabled so that audit records could be investigated if required.
• Allow only known devices that adhere to Microsoft’s recommended security baselines.
• Educate users about social engineering and credential phishing attacks, including refraining from entering MFA codes sent via any form of unsolicited messages.
  • Educate Microsoft Teams users to verify ‘External’ tagging on communication attempts from external entities, be cautious about what they share, and never share their account information or authorize sign-in requests over chat.
  • Educate Microsoft Teams users about accepting or blocking people outside the organization who send messages in Microsoft Teams.
• Educate users to review sign-in activity and mark suspicious sign-in attempts as “This wasn’t me”.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.

Indicators of compromise

Hunting guidance

Microsoft Purview

Customers hunting for related activity in their environment can identify users that were targeted with the phishing lure using content search in Microsoft Purview. A content search can be created for selected Exchange mailboxes (which include Teams messages) using the following keywords (remove the [] around the “.” before use): 

• mlcrosoftaccounts.onmicrosoft[.]com
• msftonlineservices.onmicrosoft[.]com
• msonlineteam.onmicrosoft[.]com
• msftservice.onmicrosoft[.]com
• noreplyteam.onmicrosoft[.]com
• accounteam.onmicrosoft[.]com
• teamsprotection.onmicrosoft[.]com
• identityverification.onmicrosoft[.]com
• msftprotection.onmicrosoft[.]com
• accountsverification.onmicrosoft[.]com
• azuresecuritycenter.onmicrosoft[.]com
• We detected a recent change to your preferred Multi-Factor Authentication (MFA)

The search results will include the messages that match the criteria. The first result will appear to be from <threadid>@unq.gbl.spaces addressed to the target user and the threat actor (i.e., the request to chat as described in Step 1), followed by the message sent by the threat actor, as shown in the Microsoft Purview image below:

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with “TI map”) to automatically match indicators associated with Midnight Blizzard in Microsoft Defender Threat Intelligence 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 Defender Threat Intelligence connector and analytics rule deployed in their Sentinel workspace. Learn more about the Content Hub.

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

• Azure portal sign-in from another Azure tenant
• Successful sign-in from non-compliant device
• User accounts – Sign-in failure due to CA spikes
• New onmicrosoft domain added to tenant

Further reading

Read about the threat actor Midnight Blizzard (formerly tracked as NOBELIUM).

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 Midnight Blizzard conducts targeted social engineering over Microsoft Teams 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.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. MERCURY is now tracked as Mango Sandstorm and DEV-1084 is now tracked as Storm-1084.

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

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

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

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

In this blog post, we detail our analysis of the observed actor activity and related tools. We also share information to the community and industry partners on ways to detect these attacks, including detection details of MERCURY and DEV-1084’s tools in Microsoft 365 Defender, Microsoft Defender for Identity, Microsoft Defender for Cloud Applications, Microsoft Defender Antivirus, and Microsoft Defender for Endpoint. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

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

Who is DEV-1084?

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

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

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

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

Early activities, related attacker tools and techniques

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

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

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

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

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

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

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

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

On-premises destructive impact

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

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

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

Moving from on-premises to cloud

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

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

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

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

Extracting credentials

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

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

Cloud destructive impact

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

Mass Azure resource deletion

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

Exchange Web Server API abuse

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

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

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

Email impersonation

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

Emails were then created and sent both internally and externally.

The timeline below summarizes the sequence of events:

Mitigations for destructive attacks

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

Recommendations to secure your on-prem environment

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

Recommendations to secure your Azure AD environment

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

Detections

Microsoft 365 Defender

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

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

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

• Unusual activities by Azure AD Connect sync account

Microsoft Defender for Cloud Apps

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

• Multiple storage deletion activities
• Multiple delete VM activities

Azure AD Identity Protection

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

• Unfamiliar sign-in properties

Find details of Azure AD Identity Protection alerts here.

Microsoft Defender for Identity

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

• Suspicious additions to sensitive groups

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

• Honeytoken activity

Microsoft Defender Antivirus

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

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

Microsoft Defender for Endpoint

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

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

Reducing the attack surface

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

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion.
• Implement controlled folder access and add folders to the protected folders list to help prevent files from being altered or encrypted by ransomware. Set controlled folder access to Enabled.

Detecting Log4j 2 exploitation

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

Detecting post-exploitation activity

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

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

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

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

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

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

• Suspicious scheduled task

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

• Suspicious SSH tunneling activity

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

• Suspicious Microsoft Defender Antivirus exclusion
• Microsoft Defender Antivirus tampering

Any alert title that mentions PowerShell, for example:

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

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

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

Any alert related to persistence:

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

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

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

Microsoft Defender Vulnerability Management

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

Advanced hunting queries

Microsoft 365 Defender

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

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

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

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

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

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

//Advanced Hunting Query for Azure resource deletion activity

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

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

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

Microsoft Sentinel

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

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

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

Indicators of compromise (IOCs)

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

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

Microsoft Defender Threat Intelligence

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

References

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

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