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.

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.

This blog shines a light on techniques that are prominently used in many recent email-based attacks. We’ve chosen to highlight these techniques based on their observed impact to organizations, their relevance to active email campaigns, and because they are intentionally designed to be difficult to detect. They hide text from users, masquerade as the logos of trusted companies, and evade detection by using common web practices that are usually benign:

• Brand impersonation with procedurally-generated graphics
• Text padding with invisible characters
• Zero-point font obfuscation
• Victim-specific URI

We’ve observed attackers employ these tricks to gain initial access to networks. Although the examples we present were primarily seen in credential theft attacks, any of these techniques can be easily adapted to deliver malware.

By spotting trends in the threat landscape, we can swiftly respond to potentially malicious behavior. We use the knowledge we gain from our investigations to improve customer security and build comprehensive protections. Through security solutions such as Microsoft Defender for Office 365 and the broader Microsoft 365 Defender, we deliver durable and comprehensive protection against the latest attacker trends.

Brand impersonation with procedurally-generated graphics

We have observed attackers using HTML tables to imitate the logos and branding of trusted organizations. In one recent case, an attacker created a graphic resembling the Microsoft logo by using a 2×2 HTML table and CSS styling to closely match the official branding.

Spoofed logos created with HTML tables allow attackers to bypass brand impersonation protections. Malicious content arrives in users’ inboxes, appearing to recipients as if it were a legitimate message from the company. While Microsoft Defender for Office 365 data shows a decline in the usage of this technique over the last few months, we continue to monitor for new ways that attackers will use procedurally-generated graphics in attacks.

Figure 1. Tracking data for small 2×2 HTML tables

How it works

A graphic resembling a trusted organization’s official logo is procedurally generated from HTML and CSS markup. It’s a fileless way of impersonating a logo, because there are no image files for security solutions to detect. Instead, the graphic is constructed out a specially styled HTML table that is embedded directly in the email.

Of course, inserting an HTML table into an email is not malicious on its own. The malicious pattern emerges when we view this technique in context with the attacker’s goals.

Two campaigns that we have been tracking since April 2021 sent targets emails that recreated the Microsoft logo. They impersonated messages from Office 365 and SharePoint. We observed the following email subjects:

• Action Required: Expiration Notice On <Email Address>
• Action Required: 3 Pending Messages sent <date>
• New 1 page incoming eFax© message for “<Email Alias>”

Figure 2. Sample emails that use HTML code to embed a table designed to mimic the Microsoft logo

Upon extracting the HTML used in these emails, Microsoft analysts determined that the operators used the HTML table tag to create a 2×2 table resembling the Microsoft logo. The background color of each of the four cells corresponded to the colors of the quadrants of the official logo.

Figure 3. Page source of the isolated HTML mimicking the Microsoft logo

HTML and CSS allow for colors to be referenced in several different ways. Many colors can be referenced in code via English language color names, such as “red” or “green”. Colors can also be represented using six-digit hexadecimal values (i.e., #ffffff for white and #000000 for black), or by sets of three numbers, with each number signifying the amount of red, green, or blue (RGB) to combine. These methods allow for greater precision and variance, as the designer can tweak the numbers or values to customize the color’s appearance.

Figure 4. Color values used to replicate the Microsoft logo

As seen in the above screenshot, attackers often obscure the color references to the Microsoft brand by using color names, hexadecimal, and RGB to color in the table. By switching up the method they use to reference the color, or slightly changing the color values, the attacker can further evade detection by increasing variance between emails.

Text padding with invisible characters

In several observed campaigns, attackers inserted invisible Unicode characters to break up keywords in an email body or subject line in an attempt to bypass detection and automated security analysis. Certain characters in Unicode indicate extremely narrow areas of whitespace, or are not glyphs at all and are not intended to render on screen.

Some invisible Unicode characters that we have observed being used maliciously include:

• Soft hyphen (U+00AD)
• Word joiner (U+2060)

Both of these are control characters that affect how other characters are formatted. They are not glyphs and would not even be visible to readers, in most cases. As seen in the following graph, the use of the soft hyphen and word joiner characters has seen a steady increase over time. These invisible characters are not inherently malicious, but seeing an otherwise unexplained rise of their use in emails indicates a potential shift in attacker techniques.

Figure 5. Tracking data for the invisible character obfuscation technique

How it works

When a recipient views a malicious email containing invisible Unicode characters, the text content may appear indistinguishable from any other email. Although not visible to readers, the extra characters are still included in the body of the email and are “visible” to filters or other security mechanisms. If attackers insert extra, invisible characters into a word they don’t want security products to “see,” the word might be treated as qualitatively different from the same word without the extra characters. This allows the keyword to evade detection even if filters are set to catch the visible part of the text.

Invisible characters do have legitimate uses. They are, for the most part, intended for formatting purposes: for instance, to indicate where to split a word when the whole word can’t fit on a single line. However, an unintended consequence of these characters not displaying like ordinary text is that malicious email campaign operators can insert the characters to evade security.

The animated GIF below shows how the soft hyphen characters are typically used in a malicious email. The soft hyphen is placed between each letter in the red heading to break up several key words. It’s worth noting that the soft hyphens are completely invisible to the reader until the text window is narrowed and the heading is forced to break across multiple lines.

Figure 6. Animation showing the use of the invisible soft hyphen characters

In the following example, a phishing email has had invisible characters inserted into the email body: specifically, in the “Keep current Password” text that links the victim to a phishing page.

Figure 7. Microsoft Office 365 phishing email using invisible characters to obfuscate the URL text.

The email appears by all means “normal” to the recipient, however, attackers have slyly added invisible characters in between the text “Keep current Password.” Clicking the URL directs the user to a phishing page impersonating the Microsoft single sign-on (SSO) page.

In some campaigns, we have seen the invisible characters applied to every word, especially any word referencing Microsoft or Microsoft products and services.

Zero-point font obfuscation

This technique involves inserting hidden words with a font size of zero into the body of an email. It is intended to throw off machine learning detections, by adding irrelevant sections of text to the HTML source making up the email body. Attackers can successfully obfuscate keywords and evade detection because recipients can’t see the inserted text—but security solutions can.

Microsoft Defender for Office 365 has been blocking malicious emails with zero-point font obfuscation for many years now. However, we continue to observe its usage regularly.

Figure 8. Tracking data for emails containing zero-point fonts experienced surges in June and July 2021

How it works

Similar to how there are many ways to represent colors in HTML and CSS, there are also many ways to indicate font size. We have observed attackers using the following styling to insert hidden text via this technique:

• font-size: 0px
• font-size: 0.0000em
• font-size: 0vw
• font-size: 0%
• font: italic bold 0.0px Georgia, serif
• font: italic bold 0em Georgia, serif
• font: italic bold 0vw Georgia, serif
• font: italic bold 0% Georgia, serif

Being able to add zero-width text to a page is a quirk of HTML and CSS. It is sometimes used legitimately for adding meta data to an email or to adjust whitespace on a page. Attackers repurpose this quirk to break up words and phrases a defender might want to track, whether to raise an alert or block the content entirely. As with the invisible Unicode character technique, certain kinds of security solutions might treat text containing these extra characters as distinct from the same text without the zero-width characters. This allows the visible keyword text to slip past security.

In a July 2021 phishing campaign blocked by Microsoft Defender for Office 365, the attacker used a voicemail lure to entice recipients into opening an email attachment. Hidden, zero-width letters were added to break up keywords that might otherwise have been caught by a content filter. The following screenshot shows how the email appeared to targeted users.

Figure 9. Sample email that uses the zero-point font technique

Those with sharp eyes might be able to spot the awkward spaces where the attacker inserted letters that are fully visible only within the HTML source code. In this campaign, the obfuscation technique was also used in the malicious email attachment, to evade file-hash based detections.

Figure 10. The HTML code of the email body, exposing the use of the zero-point font technique

Victim-specific URI

Victim-specific URI is a way of transmitting information about the target and creating dynamic content based upon it. In this technique, a custom URI crafted by the attacker passes information about the target to an attacker-controlled website. This aides in spear-phishing by personalizing content seen by the intended victim. This is often used by the attacker to create legitimate-seeming pages that impersonate the Single Sign On (SSO) experience.

The following graph shows cyclic surges in email content, specifically links that have an email address included as part of the URI. Since custom URIs are such a common web design practice, their usage always returns to a steady baseline in between peaks. The surges appear to be related to malicious activity, since attackers will often send out large numbers of spam emails over the course of a campaign.

Figure 11. Tracking data for emails containing URLs with email address in the PHP parameter

In a campaign Microsoft analysts observed in early May 2021, operators generated tens of thousands of subdomains from Google’s Appspot, creating unique phishing sites and victim identifiable URIs for each recipient. The technique allowed the operators to host seemingly legitimate Microsoft-themed phishing sites on third-party infrastructure.

How it works

The attacker sends the target an email, and within the body of the email is a link that includes special parameters as part of the web address, or URI. The custom URI parameters contain information about the target. These parameters often utilize PHP, as PHP is a programming language frequently used to build websites with dynamic content—especially on large platforms such as Appspot.

Details such as the target’s email address, alias, or domain, are sent via the URI to an attacker-controlled web page when the user visits the link. The attacker’s web page pulls the details from the parameters and use that to present the target with personalized content. This can help the attacker make malicious websites more convincing, especially if they are trying to mimic a user logon page, as the target will be greeted by their own account name.

Custom URIs containing user-specific parameters are not always, or even often, malicious. They are commonly used by all kinds of web developers to transmit pertinent information about a request. A query to a typical search engine will contain numerous parameters concerning the nature of the search as well as information about the user, so that the search engine can provide users with tailored results.

However, in the victim identifiable URI technique, attackers repurpose a common web design practice to malicious ends. The tailored results seen by the target are intended to trick them into handing over sensitive information to an attacker.

In the Compact phishing campaign described by WMC Global and tracked by Microsoft, this technique allowed the operators to host Microsoft-themed phishing sites on any cloud infrastructure, including third-party platforms such as Google’s Appspot. Microsoft’s own research into the campaign in May noted that not only tens of thousands of individual sites were created, but that URIs were crafted for each recipient, and the recipient’s email address was included as a parameter in the URI.

Newer variants of the May campaign started to include links in the email, which routed users through a compromised website, to ultimately redirect them to the Appspot-hosted phishing page. Each hyperlink in the email template used in this version of the campaign was structured to be unique to the recipient.

The recipient-specific information passed along in the URI was used to render their email account name on a custom phishing page, attempting to mimic the Microsoft Single Sign On (SSO) experience. Once on the phishing page, the user was prompted to enter their Microsoft account credentials. Entering that information would send it to the attacker.

Microsoft Defender for Office 365 delivers protection powered by threat intelligence

As the phishing techniques we discussed in this blog show, attackers use common or standard aspects of emails to hide in plain sight and make attacks very difficult to detect or block. With our trend tracking in place, we can make sense of suspicious patterns, and notice repeated combinations of techniques that are highly likely to indicate an attack. This enables us to ensure we protect customers from the latest evasive email campaigns through Microsoft Defender for Office 365. We train machine learning models to keep an eye on activity from potentially malicious domains or IP addresses. Knowing what to look out for, we can rule out false positives and focus on the bad actors.

This has already paid off. Microsoft Defender for Office 365 detected and protected customers from sophisticated phishing campaigns, including the Compact campaign. We also employed our knowledge of prevalent trends to hunt for a ransomware campaign that might have otherwise escaped notice. We swiftly opened an investigation to protect customers from what seemed at first like a set of innocuous emails.

Trend tracking helps us to expand our understanding about prevalent attacker tactics and to improve existing protections. We’ve already set up rules to detect the techniques described in this blog. Our understanding of the threat landscape has led to better response times to critical threats. Meanwhile, deep within Microsoft Defender for Office 365, rules for raising alerts are weighted so that detecting a preponderance of suspicious techniques triggers a response, while legitimate emails are allowed to travel to their intended inboxes.

Threat intelligence also drives what new features are developed, and which rules are added. In this way, generalized trend tracking leads to concrete results. Microsoft is committed to using our knowledge of the threat landscape to continue to track trends, build better protections for our products, and share intelligence with the greater online community.

Learn how to protect all of Office 365 against advanced threats like business email compromise and credential phishing with Microsoft Defender for Office 365.

Microsoft 365 Defender Threat Intelligence Team

The post Trend-spotting email techniques: How modern phishing emails hide in plain sight appeared first on Microsoft Security Blog.

In this blog, we’ll share our technical analysis and journey of unraveling this BEC operation, from the phishing campaign and compromised mailboxes to the attacker infrastructure. This threat highlights the importance of building a comprehensive defense strategy, which should include strong pre-breach solutions that can prevent attackers from gaining access and creating persistence on systems in the first place, as well as advanced post-breach capabilities that detect malicious behavior, deliver rich threat data, and provide sophisticated hunting tools for investigating and resolving complex cyberattacks.

This investigation also demonstrates how cross-domain threat data, enriched with expert insights from analysts, drives protection against real-world threats, both in terms of detecting attacks through products like Microsoft Defender for Office 365, as well as taking down operations and infrastructures.

The use of attacker infrastructure hosted in multiple web services allowed the attackers to operate stealthily, characteristic of BEC campaigns. The attackers performed discrete activities for different IPs and timeframes, making it harder for researchers to correlate seemingly disparate activities as a single operation. However, even with the multiple ways that the attackers tried to stay under the radar, Microsoft 365 Defender’s cross-domain visibility uncovered the operation.

Figure 1. Signals from Microsoft 365 Defender services that researchers correlated to expose the BEC attack

This depth and breadth of this visibility is especially critical in detecting and stopping BEC because these attacks have minimal footprint, create very low signals that don’t rise to the top of a defender’s alert list, and tend to blend in with the usual noise of corporate network traffic. BEC attacks unfortunately can stay undetected until they cause real monetary loss because of limited or partial visibility provided by security solutions that don’t benefit from comprehensive visibility into email traffic, identities, endpoints, and cloud behaviors, and the ability to combine together isolated events and deliver a more sophisticated cross-domain detection approach.  Armed with intelligence on phishing emails, malicious behavior on endpoints, activities in the cloud, and compromised identities, Microsoft researchers connected the dots, gained a view of the end-to-end attack chain, and traced activities back to the infrastructure.

Disrupting BEC operations is one of the areas of focus of Microsoft’s Digital Crimes Unit (DCU), which works with law enforcement and industry partners to take down operational infrastructure used by cybercriminals. For the specific BEC operation discussed in this blog, industry partnership was critical to the disruption. As our research uncovered that attackers abused cloud service providers to perpetrate this campaign, we worked with Microsoft Threat Intelligence Center (MSTIC) to report our findings to multiple cloud security teams, who suspended the offending accounts, resulting in the takedown of the infrastructure.

Initial access via phishing

Using Microsoft 365 Defender threat data, we correlated the BEC campaign to a prior phishing attack. The credentials stolen at this stage were used by the attackers to access target mailboxes. It’s important to note that multi-factor authentication (MFA) blocks attackers from signing into mailboxes. Attacks like this can be prevented by enabling MFA.

Our analysis shows that shortly before the forwarding rules were created, the mailboxes received a phishing email with the typical voice message lure and an HTML attachment. The emails originated from an external cloud provider’s address space.

Figure 2. Sample phishing email used to steal credential to be used for BEC attack

The HTML attachment contained JavaScript that dynamically decoded an imitation of the Microsoft sign-in page, with the username already populated.

Figure 3. Phishing page with user name prepopulated

When the target user entered their password, they were presented with animations and, eventually, a “File not found message”.

Figure 4. Phishing page with animation before eventually serving a fake error

Meanwhile, in the background, the JavaScript transmitted the credentials to the attackers via a redirector also hosted by an external cloud provider.

Figure 5. JavaScript code used to send stolen credentials to attackers

Persistence and exfiltration

Having already gained access to mailboxes via the credential phishing attack, attackers gained persistent data exfiltration channel via email forwarding rules (MITRE T114.003). During the course of our investigation of this campaign, we saw hundreds of compromised mailboxes in multiple organizations with forwarding rules consistently fitting one of patterns below:

These forwarding rules allowed attackers to redirect financial-themed emails to the attacker-controlled email addresses ex@exdigy.net and in@jetclubs.biz. The attackers also added rules to delete the forwarded emails from the mailbox to stay stealthy.

Figure 6. Alert in Microsoft 365 security center showing detection of forwarding rule creation

BEC infrastructure in the cloud

Our analysis revealed that the attack was supported by a robust cloud-based infrastructure. The attackers used this infrastructure to automate their operations at scale, including adding the rules, watching and monitoring compromised mailboxes, finding the most valuable victims, and dealing with the forwarded emails.

The attackers took steps to make it harder for analysts to connect their activities to one operation, for example, running distinct activities for different IPs and timeframes. The attack, however, was conducted from certain IP address ranges. We saw these commonalities in the user agents:

• Credentials checks with user agent “BAV2ROPC”, which is likely a code base using legacy protocols like IMAP/POP3, against Exchange Online. This results in an ROPC OAuth flow, which returns an “invalid_grant” in case MFA is enabled, so no MFA notification is sent.
• Forwarding rule creations with Chrome 79.
• Email exfiltration with an POP3/IMAP client for selected targets.

We observed the above activities from IP address ranges belonging to an external cloud provider, and then saw fraudulent subscriptions that shared common patterns in other cloud providers, giving us a more complete picture of the attacker infrastructure.

The attackers used a well-defined worker structure in the VMs, where each VM executed only a specific operation, which explains why activities originated from different IP sources. The attackers also set up various DNS records that read very similar to existing company domains. These are likely used to blend into existing email conversations or used for more tailored phishing campaign against specific targets.

The attackers pulled various tools on the VMs. One of the tools was called “EmailRuler”, a C# application that uses ChromeDriver to automatically manipulate the compromised mailboxes. The stolen credentials and the state of the mailbox compromised are stored in a local MySQL database as well as the state of the mailbox compromise.

Figure 7. Decompilation of EmailRuler tool

In addition, we also observed that on selected compromised user accounts, the attackers attempted to pull emails from the mailbox. A tool called “Crown EasyEmail” in the attacker’s VMs was likely used for this activity, consistent with the observation of using a POP3/IMAP client.

Defending against BEC and cloud-based attacker infrastructure with Office 365

Business email compromise is a constant threat to enterprises. As this research shows, BEC attacks are very stealthy, with attackers hiding in plain sight by blending into legitimate traffic using IP ranges with high reputation and by conducting discrete activities at specific times and connections.

Microsoft empowers organizations to comprehensively defend multiplatform and multicloud environments against these types of attacks through a wide range of cross-domain solutions that include advanced pre-breach and post-breach protection capabilities. External email forwarding is now disabled by default in Office 365, significantly reducing the threat of BEC campaigns that use this technique, while giving organizations the flexibility to control external forwarding. Organizations can further reduce their attack surface by reducing or disabling the use of  legacy protocols like POP3/IMAP and enable multi-factor authentication for all users.

As BEC attacks continue to increase in scope and sophistication, organizations need advanced and comprehensive protection like that provided by Microsoft Defender for Office 365. Microsoft Defender for Office 365 protects against email threats using its multi-layered email filtering stack, which includes edge protection, sender intelligence, content filtering, and post-delivery protection. It uses AI and machine learning to detect anomalous account behavior, as well as emails that utilize user and domain impersonation. In addition to disabling external forwarding by default, Microsoft Defender for Office 365 raises alerts for detected suspicious forwarding activity, enabling security teams to investigate and remediate attacks. Features like Attack simulation training further helps organizations improve user awareness on phishing, BEC, and other threats.

Figure 8. Sample suspicious email forwarding activity alert in Microsoft Defender for Office 365

Signals from Microsoft Defender for Office 365 informs Microsoft 365 Defender, which correlates cross-domain threat intelligence to deliver coordinated defense. Expert insights from researchers who constantly monitor the threat landscape help enrich this intelligence with an understanding of attacker behaviors and motivations. AI and machine learning technologies in our security products use this intelligence to protect customers. These signals and insights also enable us to identify and take action on threats abusing cloud services.  The resulting takedown of this well-organized, cross-cloud BEC operation by multiple cloud security teams stresses the importance of industry collaboration in the fight against attacks and improving security for all.

Learn how Microsoft is combating business email compromise, one of the costliest security threats.

Stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Stefan Sellmer, Microsoft 365 Defender Research Team

Nick Carr, Microsoft Threat Intelligence Center (MSTIC)

Advanced hunting query

Run the following query to locate forwarding rules:

let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| where Timestamp between(startTime .. endTime)
| where ActionType == "New-InboxRule"
| where (RawEventData contains "ex@exdigy.net" or RawEventData contains "in@jetclubs.biz")
or
(RawEventData has_any("invoice","payment","statement") and RawEventData has "BodyContainsWords")
| project Timestamp, AccountDisplayName, AccountObjectId, IPAddress

The post Behind the scenes of business email compromise: Using cross-domain threat data to disrupt a large BEC campaign appeared first on Microsoft Security Blog.

In this blog, we want to share our investigation of a BEC campaign that used attacker-created email infrastructure to facilitate gift card theft. In this campaign, we found that attackers targeted organizations in the consumer goods, process manufacturing and agriculture, real estate, discrete manufacturing, and professional services sectors using typo-squatted domains to make the emails appear as if they were originating from valid senders.

BEC emails are intentionally designed to look like ordinary emails, appearing to come from someone the targeted recipient already knows, but these campaigns are more complex than they appear. They require behind-the-scenes operations, preparation, and staging. Advanced email solutions like Microsoft Defender for Office 365 detect and block these elusive threats. Defender for Office 365 safeguards organizations against the threat posed by emails and URLs associated with BEC campaigns.

In our blog titled Business email compromise: How Microsoft is combating this costly threat, we wrote about the process of orchestrating BEC attacks and discussed Microsoft strategies to combat these threats. Additionally, Microsoft released a three-part blog series on BEC scams titled Business Email: Uncompromised, which offers an in-depth look into the evolution of BEC attacks and how Microsoft Defender for Office 365 employs multiple native capabilities to help customers defend against them.

Understanding the BEC gift card scam

Imagine this work-from-home scenario for an executive assistant (EA):

It’s a typical day at work for you as a remote EA. You prepare your to-do list for the day and check your CEO’s calendar for their scheduled meetings, all while communicating with other EAs via email and chat. You categorize your emails and prioritize your tasks—nothing out of the ordinary.

In the middle of the workday, you get an email appearing to come from your boss, requesting that you purchase gift cards to give to the team as an incentive for their hard work during the pandemic.

The request seems a little strange, you think. Maybe it was a spur-of-the-moment initiative. But you’re a rock star assistant and decide to go ahead and purchase the gift cards using department funds.

You reply to your boss’s email with the gift card codes. After a while of not hearing back, you finally ping them on chat to make sure they received them. Your boss expresses their confusion in response to your chat message–they never requested gift cards for the team.

This is a classic business email compromise (BEC) scenario.

Defining BEC attacks

BEC is a type of phishing attack that targets organizations, with the goal of stealing money or critical information. Our blog post Business Email: Uncompromised – Part One provides examples of real-world BEC attacks and how to identify key visual cues for spotting attacks.

The emails used in BEC attacks appear simple, but there is a wide level of complexity behind them—from reconnaissance and targeting, social engineering, to the delivery infrastructure.

If you’re wondering why these complex threats are crafted for a seemingly insignificant payout, think again. BEC continuously poses a serious area of concern, with attacks totaling approximately $1.8 billion in victim losses in 2020, according to the FBI’s Internet Crime Compliant Center (IC3). While attacks similar to the BEC gift card scenario we described earlier can add up to a hefty sum, many BEC attackers are known to target significantly larger transactions, such as intercepting and redirecting wire transfers, ultimately making BEC scams a highly profitable cybercriminal operation.

Conducting reconnaissance, social engineering for BEC attacks

For BEC actors to know who to target and who to impersonate, they frequently conduct reconnaissance prior to launching attacks. Social media sites, “about us” pages on a company’s website, or news articles about a targeted company may all give actors the information they need to craft a specific, believable message intended for a chosen victim. In our blog post, Business Email: Uncompromised – Part Two, we discuss the multiple stages of a BEC attack, from identifying target organizations to the attackers setting up transaction details.

BEC gift card campaign seen targeting various organizations

In this campaign, attackers targeted a variety of companies in the consumer goods, process manufacturing and agriculture, real estate, discrete manufacturing, and professional services sectors.

Figure 1. Breakdown of email volume sent to the top targeted industries we observed in this BEC campaign

This specific campaign started with an extremely vague request, such as “I need you to do a task for me” or “Let me know if you’re available.” The message body contained a few details related to the target to make the email seem legitimate.

Figure 2. A sample BEC email impersonating an executive

In the Figure 2 screenshot, the attacker signed the email as “Steve,” which is the name of an executive at this targeted organization. Additionally, the email was addressed to someone who worked with the impersonated executive while the subject line contained the recipient’s first name.

If the recipient replied to the email, the attacker responded with a more specific demand for a gift card. In other cases, attackers skipped the generic email altogether and jumped directly to the gift card demand, using a method of generating fake replies to add legitimacy to the email. We discussed the anatomy of BEC attacks in this blog post and detailed telltale signs of common phishing techniques.

Figure 3. A sample BEC email targeting the education sector demanding a gift card purchase

In this case, the attacker pretended to be a teacher at a K-12 institution and claimed that they were unable to leave their house to buy a gift card. In addition, the email subject contained the name of the purported teacher followed by “SICK” in the subject line.

The email body included a message requesting the recipient to purchase a physical gift card for them. According to our past BEC research, attackers frequently used the stolen gift card codes for websites that allow them to redeem and convert gift cards to cryptocurrency or other foreign currencies. The funds generated from cashing out gift cards can then be transferred to attacker-owned accounts untraceably.

In this campaign, we noticed that the email also contained a fake reply, wherein the threat actor included what appeared to be an original message in the email body, with the subject line starting with “Re:”. The ‘From’ email address in the crafted original message used yahoo.com, but the ‘From address of the actual email was a typo-squatted domain spoofing yahoo.com, hinting that the email reply was indeed fake.

Figure 4. The attacker used a typo-squatted domain that spoofed a Yahoo account

Upon closer examination, the actors had taken the extra step of faking the In-Reply-To and References headers, which added an extra air of legitimacy to the email. An email’s In-Reply-To header contains the unique Message ID of the previous message in the reply thread, and the References header contains the unique Message IDs from all previous messages in the reply thread. In a typical email that is not a reply, these two header fields would be blank.

Figure 5. Spoofed fields for the In-Reply-To and References headers

As shown in Figure 5, both the In-Reply-To and References headers are populated with Message IDs associated with legitimate email providers, including yahoo.com, which this campaign spoofed. We can see that these headers were manually added by the attacker as made apparent by the ya00h0o.com sender. In addition, the email’s HTML contents show that the message was manually typed to appear as though it’s a reply.

Filling these headers in made the email appear legitimate and that the attacker was simply replying to the existing email thread between the Yahoo and Outlook user. This characteristic sets this campaign apart from most BEC campaigns, where attackers simply include a real or specially crafted fake email, adding the sender, recipient, and subject, in the new email body, making appear as though the new email was a reply to the previous email.

Delivery infrastructure

For this campaign, attackers registered typo-squatted domains for over 120 different organizations to impersonate actual businesses. We observed patterns in using the correct domain name but an incorrect TLD, or slightly spelling the company name wrong. These domains were registered just days before this email campaign began.

We noted that these domains did not have domain privacy enabled, nor were they under the EU’s GDPR protections. Each domain used a unique registrant name and email. The registrant names appeared to be autogenerated random first names and last names, and the registrant contact email used a free email service such as Gmail or mail.com with accounts that were often simply <first name>.<last name>@gmail.com or similar. Each name was used to register just one domain used in the campaign, which made pivoting to related domains more challenging.

Another observation about this campaign is that the registered domains did not always align with the organization being impersonated in the email. This could have been a mistake on the actor’s part, as BEC domains are typically designed to closely mimic the impersonated organization. For example, an actor may register microsoft.xyz or micrrosoft.com, both of which would normally be used to send emails pretending to originate from Microsoft. In this campaign, those types of homoglyphed and typo-squatted domains were used to send emails pretending to originate from a variety of organizations.

Our in-depth research into this campaign’s delivery infrastructure directly informed the protection Microsoft provides against this BEC threat.

How Microsoft security solutions combat BEC campaigns

Microsoft Defender for Office 365 defends organizations against malicious threats posed by this BEC campaign.

For a better understanding on how Defender for Office 365 protects against BEC attacks, you can refer to our blog post about detecting user and domain impersonation at scale in a fast-evolving attack landscape. Email authentication in Defender for Office 365 allows you to verify whether email messages from a sender are legitimate and come from expected sources for that email domain. Email standards like SPF, DKIM, and DMARC are evaluated by Office 365 to prevent domain spoofing. Our spoof intelligence technology uses advanced algorithms to observe the sending patterns of domains and flag anomalies.

You can strengthen your security posture further by empowering employees through user awareness tools in Defender for Office 365 that are integrated into products like Outlook and Office 365 apps. For instance, attack simulation training in Defender for Office 365 allows you to craft and run realistic BEC-like attack scenarios in your organization.

As these threats are always changing and evolving, Microsoft has dedicated research teams who constantly stay abreast of the changing threat landscape and combine that knowledge with our extensive customer telemetry data to stay current on BEC and other attacks.

Microsoft’s portfolio of security products processes trillions of signals every day. This signal base drives constant improvements to the artificial intelligence layers backing our protection and detection systems. Microsoft threat analysts leverage these signals to track actors, infrastructure, and techniques used in phishing and BEC attacks to ensure Defender for Office 365 stays ahead of current and future threats.

Defender for Office 365 equips security operations teams with automated threat investigation and response capabilities to understand, simulate, and prevent email-related threats. Defender for Office 365 enables you to define threat protection policies to set up the appropriate level of protection for your organization, while allowing you to view and monitor real-time reports. Learn more about Microsoft Defender for Office 365.

 Microsoft 365 Defender Threat Intelligence Team

The post Business email compromise campaign targets wide range of orgs with gift card scam appeared first on Microsoft Security Blog.

By tracing these campaigns, we uncovered a sprawling infrastructure that is robust enough to seem legitimate to many mail providers, while flexible enough to allow the dynamic generation of new domain names and remain evasive. Shared IP space, domain generation algorithm (DGA) patterns, subdomains, registrations metadata, and signals from the headers of malicious emails enabled us to validate our research through overlaps in campaigns where attackers utilized multiple segments of purchased, owned, or compromised infrastructure. Using the intelligence we gathered on this infrastructure, we were at times able to predict how a domain was going to be used even before campaigns began.

This email infrastructure and the malware campaigns that use it exemplify the increasing sophistication of cybercriminal operations, driven by attackers who are motivated to use malware infections for more damaging, potentially more lucrative attacks. In fact, more recent campaigns that utilized this infrastructure distributed malware families linked to follow-on human-operated attacks, including campaigns that deployed Dopplepaymer, Makop, Clop, and other ransomware families.

Our deep investigation into this infrastructure brings to light these important insights about persistent cybercriminal operations:

• Tracking an email infrastructure surfaces patterns in attacker activity, bubbling up common elements in seemingly disparate campaigns
• Among domains that attackers use for sending emails, distributing malware, or command-and-control, the email domains are the most likely to share basic registration similarities and more likely to use DGA
• Malware services rely on proxy providers to make tracking and attribution difficult, but the proxies themselves can provide insights into upcoming campaigns and improve our ability to proactively protect against them
• Gaining intelligence on email infrastructures enables us to build or improve proactive and comprehensive protections like those provided by Microsoft Defender for Office 365 to defend against some of the world’s most active malware campaigns

While there is existing in-depth research into some of these specific campaigns, in this blog we’ll share more findings and details on how email distribution infrastructures drive some of the most prevalent malware operations today. Our goal is to provide important intelligence that hosting providers, registrars, ISPs, and email protection services can use and build on to protect customers from the threats of today and the future. We’ll also share insights and context to empower security researchers and customers to take full advantage of solutions like Microsoft Defender for Office 365 to perform deep investigation and hunting in their environment and make their organizations resilient against attacks.

The role of for-sale infrastructure services in the threat ecosystem

We spotted the first segment of the infrastructure in March, when multiple domains were registered using distinct naming patterns, including the heavy use of the word “strange”, inspiring the name StrangeU. In April, a second segment of the infrastructure, one that used domain generation algorithm (DGA), began registration as well. We call this segment RandomU.

The emergence of this infrastructure in March dovetailed with the disruption of the Necurs botnet that resulted in the reduction of service. Before being disrupted, Necurs was one of the world’s largest botnets and was used by prolific malware campaign operators such as those behind Dridex. For-sale services like Necurs enable attackers to invest in malware production while leasing the delivery components of their activities to further obfuscate their behavior. The StrangeU and RandomU infrastructure appear to fill in the service gap that the Necurs disruption created, proving that attackers are highly motivated to quickly adapt to temporary interruptions to their operations.

Figure 1. Timeline of staging and utilization of the email infrastructure

At first, the new email infrastructure was used infrequently in campaigns that distributed highly commodity malware like Mondfoxia and Makop. Soon, however, it attracted the attention of Dridex and Trickbot operators, who began using the infrastructure for portions of their campaigns, sometimes entirely and sometimes mixed with other compromised infrastructure or email providers.

Analyzing these mail clusters provides insight into how human the tangled web of modular attacker infrastructure remains. From unifying key traits in registration and behavior to the simple and effective techniques that the wide variety of malware uses, attackers’ goals in this diversification point toward combatting automated analysis. However, these same shared characteristics and methods translate to insights that inform resilient protections that defend customers against these attacks.

Domain registration and email infrastructure staging

On March 7, 2020, attackers began registering a series of domains with Namecheap using sets of stolen email addresses, largely from free email services like mail.com, mail.ru, list.ru, and others. These domains all had similar characteristics that could be linked back to various similarities in registration. Almost all of the registered domains contained the word “strange” and were under the .us TLD, hence the name StrangeU. The use of .us TLD prevented domain or WHOIS privacy services—often used to obfuscate domain ownership and provenance—which are prohibited for this TLD.

To circumvent tracking and detection of these domains, attackers used false registration metadata. However, there was heavy crossover in the fake names and email addresses, allowing us to find additional domain names, some of which could be tied together using other keywords as shown in the list below, and fingerprint the domain generation mechanism.

The StrangeU domains were registered in early March 2020 and operated in continuous small bursts until April, when they were used for a large ransomware campaign. Following that, a new campaign occurred fairly regularly every few weeks. Registration of new domains continued throughout the year, and in September, the StrangeU infrastructure was used in conjunction with a similar infrastructure to deliver Dridex, after which these domains were used less frequently.

This second mailing segment, RandomU, employed a different DGA mechanism but still utilized Namecheap and showed a more consistent through line of registration metadata than its StrangeU counterpart. This infrastructure, which surfaced in April, was used infrequently through the Spring, with a surge in May and July. After the Dridex campaign in September in which it was used along with StrangeU, it has been used in two large Dridex campaigns every month.

Figure 2. Common patterns in domains belonging to the email infrastructure

The StrangeU and RandomU segments of domains paint a picture of supplementing modular mailing services that allowed attackers to launch region-specific and enterprise-targeting attacks at scale, delivering over six million emails. The two segments contained a standard barrage of mailing subdomains, with over 60 unique subdomains referencing email across clusters, consistent with each other, with each domain having four to five subdomains. The following is a sample of malware campaigns, some of which we discuss in detail in succeeding sections, that we observed this infrastructure was used for:

• Korean spear-phishing campaigns that delivered Makop ransomware in April and June
• Emergency alert notifications that distributed Mondfoxia in April
• Black Lives Matter lure that delivered Trickbot in June
• Dridex campaign delivered through StrangeU and other infra from June to July
• Dofoil (SmokeLoader) campaign in August
• Emotet and Dridex activities in September, October, and November

Figure 3. Timeline of campaigns that used StrangeU and RandomU domains

Korean spear-phishing delivers Makop ransomware (April and June 2020)

In early April, StrangeU was used to deliver the Makop ransomware. The emails were sent to organizations that had major business operations in Korea and used names of Korean companies as display names. Signals from Microsoft Defender for Office 365 indicated that these campaigns ran in short bursts.

The emails had .zip attachments containing executables with file names that resembled resumes from job seekers. Once a user opened the attachments, the executables delivered Makop, a ransomware-as-a-service (RaaS) payload that targeted devices and backups.

Upon infection, the malware quickly used the WMI command-line (WMIC) utility and deleted shadow copies. It then used the BCEdit tool and altered the boot configuration to ignore future failures and prevent restoration before encrypting all files and renaming them with .makop extensions.

The second time we observed the campaign almost two months later, in early June, the attackers used a Makop ransomware variant with many modified elements, including added persistence via scripts in the Startup folder before triggering a reboot.

Nearly identical attempts to deliver Makop using resume-based lures were covered by Korean security media during the entire year, using popular mail services through legitimate vendors like Naver and Hanmail. This could indicate that during short bursts the Makop operators were unable to launch their campaigns through legitimate services and had to move to alternate infrastructures like StrangeU instead.

Black Lives Matter lure delivers Trickbot (June 2020)

One campaign associated with the StrangeU infrastructure gained notoriety in mid-June for its lure as well as for delivering the notorious info-stealing malware Trickbot. This campaign circulated emails with malicious Word documents claiming to seek anonymous input on the Black Lives Matter movement.

An initial version of this campaign was observed on June 10 sending emails from a separate, unique attacker-owned mailing infrastructure using .monster domains. However, in the next iteration almost two weeks later, the campaign delivered emails from various domains specifically created with the Black Lives Matter signage, interspersed with StrangeU domains:

• b-lives-matter[.]site
• blivesm[.]space
• blivesmatter[.]site
• lives-matter-b[.]xyz
• whoslivesmatter[.]site
• lives-m-b[.]xyz
• ereceivedsstrangesecureworld[.]us
• b-l-m[.]site

Both campaigns carried the same Trickbot payload, operated for two days, and used identical post-execution commands and callouts to compromised WordPress sites.

Once a user opened the document attachment and enabled the malicious macro, Word launched cmd.exe with the command “/c pause” to evade security tools that monitored for successive launches of multiple processes. It then launched commands that deleted proxy settings in preparation for connecting to multiple C2 IP addresses.

Figure 4. Screenshot of the malicious document used to deliver Trickbot

The commands also launched rundll32.exe, a native binary commonly used as a living-off-the-land binary, to load a malicious file in memory. The commandeered rundll32.exe also proceeded to perform other tasks using other living-off-the-land binaries, including wermgr.exe and svchost.exe.

In turn, the hijacked wermgr.exe process dropped a file with a .dog extension that appeared to be the Trickbot payload. The same instance of wermgr.exe then appeared to inject code into svchost.exe and scanned for open SMB ports on other devices. The commandeered svchost.exe used WMI to open connections to additional devices on the network, while continuing to collect data from the initial infected device. It also opened multiple browsers on localhost connections to capture browser history and other information via esentutl.exe and grabber_temp.edb, both of which are often used by the Trickbot malware family.

This campaign overwhelmingly targeted corporate accounts in the United States and Canada and avoided individual accounts. Despite heavy media coverage, this campaign was relatively small, reflecting a common behavior among cybercrime groups, which often run multiple, dynamic low-volume campaigns designed to evade resilient detection.

Dridex campaigns big and small (June to July 2020 and beyond)

From late June through July, Dridex operators ran numerous campaigns that distributed Excel documents with malicious macros to infect devices. These operators first delivered emails through the StrangeU infrastructure only, but they quickly started to use compromised email accounts of legitimate organizations as well, preventing defenders from easily blocking deliveries. Despite this, emails from either StrangeU or the compromised accounts had overlapping attributes. For example, many of the emails used the same Reply To addresses that were sourced from compromised individual accounts and not consistent with the sender addresses.

During the bulk of this run, Excel files were attached directly in the email in order to eventually pull the Dridex payload from .xyz domains such as those below. The attackers changed the delivery domains every few days and connected to IP-based C2s on familiar ports like 4664, 3889, 691, and 8443:

• yumicha[.]xyz
• rocesi[.]xyz
• secretpath[.]xyz
• guruofbullet[.]xyz
• Greyzone[.]xyz

When opened, the Excel document installed one of a series of custom Dridex executables downloaded from the attacker C2 sites. Like most variants in this malware family, the custom Dridex executables incorporated code loops, time delays, and environment detection mechanisms that evaded numerous public and enterprise sandboxes.

Dridex is known for its capability to perform credential theft and establish connectivity to attacker infrastructure. In this instance, the same Dridex payload was circulated daily using varying lures, often repeatedly to the same organizations to ensure execution on target networks.

During the longer and more stable Excel Dridex campaigns in June and July, a Dridex variant was also distributed in much smaller quantities utilizing Word documents over a one-day period, perhaps testing new evasion techniques. These Word documents, while still delivering Dridex, improved existing obfuscation methods using a unique combination of VBA stomping and replacing macros and function calls with arbitrary text. In a few samples of these documents, we found text from Shakespearean prose.

</ms:script>   
var farewell_and_moon = ["m","a","e","r","t","s",".","b","d","o","d","a"].reverse().join("")   
a_painted_word(120888)   
function as_thy_face(takes_from_hamlet)   
{return new ActiveXObject(takes_from_hamlet)}   
</ms:script>

While Microsoft researchers didn’t observe this portion of the campaign moving into the human-operated phase—targets did not open the attachment—this campaign was likely to introduce tools like PowerShell Empire or Cobalt Strike to steal credentials, move laterally, and deploy ransomware.

Emotet, Dridex, and the RandomU infrastructure (September and beyond)

Despite an errant handful of deliveries distributing Dofoil (also known as SmokeLoader) and other malware, the vast majority of the remaining deliveries through StrangeU have been Dridex campaigns that reoccured every few weeks for a handful of days at a time. These campaigns started on September 7, when RandomU and StrangeU were notably used in a single campaign, after which StrangeU began to see less utilization.

These Dridex campaigns utilized an Emotet loader and initial infrastructure for hosting, allowing the attackers to conduct a highly modular email campaign that delivered multiple distinct links to compromised domains. These domains employed heavy sandbox evasion and are connected by a series of PHP patterns ending in a small subset of options: zxlbw.php, yymclv.php, zpsxxla.php, or app.php. As the campaigns continued, the PHP was dynamically generated, adding other variants, including vary.php, invoice.php, share.php, and many others. Some examples are below.

• hxxps://molinolafama[.]com[.]mx/app[.]php
• hxxps://meetingmins[.]com/app[.]php
• hxxps://contrastmktg[.]com/yymclv[.]php
• hxxps://idklearningcentre[.]com[.]ng/zxlbw[.]php
• hxxps://idklearningcentre[.]com[.]ng/zpsxxla[.]php
• hxxps://idklearningcentre[.]com[.]ng/yymclv[.]php
• hxxps://hsa[.]ht/yymclv[.]php
• hxxps://hsa[.]ht/zpsxxla[.]php
• hxxps://hsa[.]ht/zxlbw[.]php
• hxxps://contrastmktg[.]com/yymclv[.]php
• hxxps://track[.]topad[.]co[.]uk/zpsxxla[.]php
• hxxps://seoemail[.]com[.]au/zxlbw[.]php
• hxxps://bred[.]fr-authentification-source-no[.]inaslimitada[.]com/zpsxxla[.]php
• hxxp://www[.]gbrecords[.]london/zpsxxla[.]php
• hxxp://autoblogsite[.]com/zpsxxla[.]php
• hxxps://thecrossfithandbook[.]com/zpsxxla[.]php
• hxxps://mail[.]168vitheyrealestate[.]com/zpsxxla[.]php

In this campaign, sandboxes were frequently redirected to unrelated sites like chemical manufacturers or medical suppliers, while users received an Emotet downloader within a Word document, which once again used macros to facilitate malicious activities.

Figure 5. Screenshot of the malicious document used to deliver Dridex

The malicious macro utilized WMI to run a series of standard PowerShell commands. First, it downloaded the executable payload itself by contacting a series of C2 domains associated with Emotet campaigns since July. Afterward, additional encoded PowerShell commands were used in a similar fashion to download a .zip file that contained a Dridex DLL. Additional commands also reached out to a variety of Emotet infrastructure hosted on compromised WordPress administrative pages, even after the Dridex payload has already been downloaded. Dridex then modified RUN keys to automatically start the Dridex executable, which was renamed to riched20.exe on subsequent logons.

We also observed simultaneous connections to associated Dridex and Emotet infrastructure. These connections were largely unencrypted and occurred over a variety of ports and services, including ports 4664 and 9443. At this point the malware had firm presence on the machine, enabling attackers to perform human-operated activity at a later date.

In the past, reports have confirmed Dridex being delivered via leased Emotet infrastructure. There have also been many IP and payload-based associations. This research adds to that body of work and confirms additional associations via namespace, as well as correlation of email lure, metadata, and sender. This iteration of campaign repeated through October to December largely unchanged with nearly identical mails.

Defending organizations against malware campaigns

As attacks continue to grow in modularity, the tactics that attackers use to deliver phishing email, gain initial access on systems, and move laterally will continuously become more varied. This research shows that despite these disparities and the increased resiliency attackers have built, the core tactics and tools that they use are still limited in scope, relying repeatedly on familiar malicious macros, lures, and sending tactics.

Sweeping research into massive attacker infrastructures, as well as our real-time monitoring of malware campaigns and attacker activity, directly inform Microsoft security solutions, allowing us to build or improve protections that block malware campaigns and other email threats, both current and future, as well as provide enterprises with the tools for investigating and responding to email campaigns in real-time.

Microsoft delivers these capabilities through Microsoft Defender for Office 365. Features likes Safe attachments and Safe links ensure real-time, dynamic protection against email campaigns no matter the lure or evasion tactic. These features use a combination of detonation, automated analysis, and machine learning to detect new and unknown threats. Meanwhile, the Campaign view shows the complete picture of email campaigns as they happen, including timelines, sending patterns, impact to the organization, and details like IP addresses, senders, and URLs. These insights into email threats empower security operations teams to respond to attacks, perform additional hunting, and fix configuration issues.

Armed with an advanced solution like Microsoft Defender for Office 365 and the rest of technologies in the broader Microsoft 365 Defender solution, enterprises can further increase resilience against threats by following these recommendations:

• Educate end users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing email, and reporting of reconnaissance attempts and other suspicious activity.
• Configure Office 365 email filtering settings to ensure blocking of phishing & spoofed emails, spam, and emails with malware. Set Office 365 to recheck links on click and delete sent mail to benefit from newly acquired threat intelligence.
• Disallow macros or allow only macros from trusted locations. See the latest security baselines for Office and Office 365.
• Turn on AMSI for Office VBA.
• Check perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Turn on network protection to block connections to malicious domains and IP addresses. Such restrictions help inhibit malware downloads and command-and-control activity.

Turning on attack surface reduction rules, including rules that can block advanced macro activity, executable content, process creation, and process injection initiated by Office applications, also significantly improves defenses. The following rules are especially useful in blocking the techniques observed in campaigns using the StrangeU and RandomU infrastructure:

• Block executable content from email client and webmail
• Block all Office applications from creating child processes
• Block Office applications from creating executable content
• Block Office applications from injecting code into other processes
• Block Win32 API calls from Office macros
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block Javascript or VBScript from launching downloaded executable content
• Block execution of potentially obfuscated scripts

Microsoft 365 customers can also use the advanced hunting capabilities in Microsoft 365 Defender, which integrates signals from Microsoft Defender for Office 365 and other solutions, to locate activities and artifacts related to the infrastructure and campaigns discussed in this blog. These queries can be used with advanced hunting in Microsoft 365 security center, but the same regex pattern can be used on other security tools to identify or block emails.  

This query searches for emails sent from StrangeU email addresses. Run query

EmailEvents   
| where SenderMailFromDomain matches regex @"^(?:eraust|ereply|reply|ereceived|received|reaust|esend|inv|send|emailboost|eontaysstrange|eprop|frost|eont|servicply).*(strange|stange|emailboost).*\.us$"   
or SenderFromDomain matches regex @"^(?:eraust|ereply|reply|ereceived|received|reaust|esend|inv|send|emailboost|eontaysstrange|eprop|frost|eont|servicply).*(strange|stange|emailboost).*\.us$"

Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Additional resources

• Listen to Episode 19 of the Security Unlocked podcast, where threat analyst Elif Kaya speaks about this email infrastructure
• Watch this Microsoft 365 Defender webinar about this research:

Indicators of compromise

StrangeU domains

RandomU domains

The post What tracking an attacker email infrastructure tells us about persistent cybercriminal operations appeared first on Microsoft Security Blog.

Whether it’s sophisticated nation-state attacks, targeted phishing schemes, business email compromise or a ransomware attacks, such attacks are on the rise at an alarming rate and are also increasing in their sophistication. It is therefore imperative that every organization’s security strategy include a robust email security solution.

So, what should IT and security teams be looking for in a solution to protect all their users, from frontline workers to the C-suite? Here are 6 tips to ensure your organization has a strong email security posture:

You need a rich, adaptive protection solution.

As security solutions evolve, bad actors quickly adapt their methodologies to go undetected. Polymorphic attacks designed to evade common protection solutions are becoming increasingly common. Organizations therefore need solutions that focus on zero-day and targeted attacks in addition to known vectors. Purely standards based or known signature and reputation-based checks will not cut it.

Solutions that include rich detonation capabilities for files and URLs are necessary to catch payload-based attacks. Advanced machine learning models that look at the content and headers of emails as well as sending patterns and communication graphs are important to thwart a wide range of attack vectors including payload-less vectors such as business email compromise. Machine learning capabilities are greatly enhanced when the signal source feeding it is broad and rich; so, solutions that boast of a massive security signal base should be preferred. This also allows the solution to learn and adapt to changing attack strategies quickly which is especially important for a rapidly changing threat landscape.

Complexity breeds challenges. An easy-to-configure-and-maintain system reduces the chances of a breach.

Complicated email flows can introduce moving parts that are difficult to sustain. As an example, complex mail-routing flows to enable protections for internal email configurations can cause compliance and security challenges. Products that require unnecessary configuration bypasses to work can also cause security gaps. As an example, configurations that are put in place to guarantee delivery of certain type of emails (eg: simulation emails), are often poorly crafted and exploited by attackers.

Solutions that protect emails (external and internal emails) and offer value without needing complicated configurations or emails flows are a great benefit to organizations. In addition, look for solutions that offer easy ways to bridge the gap between the security teams and the messaging teams. Messaging teams, motivated by the desire to guarantee mail delivery, might create overly permissive bypass rules that impact security. The sooner these issues are caught the better for overall security. Solutions that offer insights to the security teams when this happens can greatly reduce the time taken to rectify such flaws thereby reducing the chances of a costly breach

A breach isn’t an “If”, it’s a “When.” Make sure you have post-delivery detection and remediation.

No solution is 100% effective on the prevention vector because attackers are always changing their techniques. Be skeptical of any claims that suggest otherwise. Taking an ‘assume breach’ mentality will ensure that the focus is not only on prevention, but on efficient detection and response as well. When an attack does go through the defenses it is important for security teams to quickly detect the breach, comprehensively identify any potential impact and effectively remediate the threat.

Solutions that offer playbooks to automatically investigate alerts, analyze the threat, assess the impact, and take (or recommend) actions for remediations are critical for effective and efficient response. In addition, security teams need a rich investigation and hunting experience to easily search the email corpus for specific indicators of compromise or other entities. Ensure that the solution allows security teams to hunt for threats and remove them easily.
Another critical component of effective response is ensuring that security teams have a good strong signal source into what end users are seeing coming through to their inbox. Having an effortless way for end users to report issues that automatically trigger security playbooks is key.

Your users are the target. You need a continuous model for improving user awareness and readiness.

An informed and aware workforce can dramatically reduce the number of occurrences of compromise from email-based attacks. Any protection strategy is incomplete without a focus on improving the level of awareness of end users.

A core component of this strategy is raising user awareness through Phish simulations, training them on things to look out for in suspicious emails to ensure they don’t fall prey to actual attacks. Another, often overlooked, but equally critical, component of this strategy, is ensuring that the everyday applications that end-users use are helping raise their awareness. Capabilities that offer users relevant cues, effortless ways to verify the validity of URLs and making it easy to report suspicious emails within the application — all without compromising productivity — are very important.

Solutions that offer Phish simulation capabilities are key. Look for deep email-client-application integrations that allow users to view the original URL behind any link regardless of any protection being applied. This helps users make informed decisions. In addition, having the ability to offer hints or tips to raise specific user awareness on a given email or site is also important. And, effortless ways to report suspicious emails that in turn trigger automated response workflows are critical as well.

Attackers meet users where they are. So must your security.

While email is the dominant attack vector, attackers and phishing attacks will go where users collaborate and communicate and keep their sensitive information. As forms of sharing, collaboration and communication other than email, have become popular, attacks that target these vectors are increasing as well. For this reason, it is important to ensure that an organization’s anti-Phish strategy not just focus on email.

Ensure that the solution offers targeted protection capabilities for collaboration services that your organization uses. Capabilities like detonation that scan suspicious documents and links when shared are critical to protect users from targeted attacks. The ability in client applications to verify links at time-of-click offers additional protection regardless of how the content is shared with them. Look for solutions that support this capability.

Attackers don’t think in silos. Neither can the defenses.

Attackers target the weakest link in an organization’s defenses. They look for an initial compromise to get in, and once inside will look for a variety of ways increase the scope and impact of the breach. They typically achieve this by trying to compromise other users, moving laterally within the organization, elevating privileges when possible, and the finally reaching a system or data repository of critical value. As they proliferate through the organization, they will touch different endpoints, identities, mailboxes and services.

Reducing the impact of such attacks requires quick detection and response. And that can only be achieved when the defenses across these systems do not act in silos. This is why it is critical to have an integrated view into security solutions. Look for an email security solution that integrates well across other security solutions such as endpoint protection, CASB, identity protection, etc. Look for richness in integration that goes beyond signal integration, but also in terms of detection and response flows.

The post Top 6 email security best practices to protect against phishing attacks and business email compromise appeared first on Microsoft Security Blog.

The Microsoft Security Intelligence Report (SIR) provides a regular snapshot of the current threat landscape, using data from more than 600 million computers worldwide.

The latest report (SIRv19) was released this week and includes a detailed analysis of the actor group STRONTIUM – a group that uses zero-day exploits to collect the sensitive information of high-value targets in government and political organizations.

Since 2007, the group has targeted:

• Government bodies
• Diplomatic institutions
• Military forces and installations
• Journalists
• Political advisors and organizations

Attack vectors: How they manage to get in

A STRONTIUM actor attack usually has two components:

1. A spear phishing attempt that targets specific individuals within an organization. This phishing attempt is used to gather information about potential high-value targets and steal their login credentials.
2. A second phase that attempts to download malware using software vulnerabilities to further infect the target computers and spread through networks.

Spear phishing

We estimate the STRONTIUM actor targeted several thousand people with spear phishing attacks during the first half of 2015. The goal of the spam email attack is to get a list of high-value individuals with access to sensitive information.

The phishing email usually attempts to trick the target into believing there has been an unauthorized user accessing their account.

The email includes a link to a website under the attacker’s control that prompts the victim to change their password. If the attack is successful, the stolen credentials can be used to access the victim’s email account.

Visiting the malicious website can also send sensitive information to the attacker, even when no credentials are entered. The sensitive information can include details of the victim’s PC -including its IP address, browser and operating system versions, and any browser add-ons installed. This information can be used to target the individual with software exploits.

Malware downloads

The second phase of a STRONTIUM actor attack is to install malware on the compromised machine in an attempt to gain access to other machines on the network.

Usually, the malware is installed through a malicious link in an email. However, we have also seen social networks used to spread malicious links. The highly-targeted emails use current events, such as an upcoming conference, to entice the victim to click a link for “additional information”. The email is sent from well-known email providers and sender names that are designed to look credible.

When the link is clicked, a drive-by-download attack is launched using software vulnerabilities. The attacks often use zero-day exploits that target vulnerabilities for which the affected software vendor has not yet released a security update.

If the attack is successful the attacker tries to compromise other machines within the targeted organization to gather more sensitive information.

See the Microsoft Security Intelligence Report (SIRv19) for more technical details on the methods used by STRONTIUM.

Preventing attacks

You can reduce the likelihood of a successful compromise in a number of ways. Use an up-to-date real-time security product, such as Windows Defender for Windows 10.

In an enterprise environment you should also:

• Keep all your software up-to-date and deploy security updates as soon as possible
• Enforce segregation of privileges on user accounts and apply all possible safety measures to protect administrator accounts from compromise
• Conduct enterprise software security awareness training, and build awareness about malware infection prevention
• Institute multi-factor authentication

TheMicrosoft Security Intelligence Report (SIRv19) has more advice and detailed analysis of STRONTIUM, as well as other information about malware and unwanted software.

The Microsoft Malware Protection Center’s November Threat Intelligence Report also includes detailed information, resources, and advice to mitigate the risk of advanced persistent threats (APTs).

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity.

The post Microsoft Security Intelligence Report: Strontium appeared first on Microsoft Security Blog.