Midnight Blizzard Attack Detection in Trellix Helix

By Ian Shefferman · March 18, 2024

On January 25, 2024, Microsoft reported a breach of their systems by the Russian APT group Midnight Blizzard, also known as APT29 and Cozy Bear. The attackers performed a password spray, compromised a Microsoft 365 test tenant account that didn’t have multi-factor authentication (MFA) enabled, and leveraged the account’s access to a legacy OAuth app to escalate privileges and exfiltrate email messages from Microsoft’s corporate Exchange Online environment.

Later, on March 8, 2024, Microsoft published an update: “Midnight Blizzard has increased the volume of some aspects of the attack, such as password sprays, by as much as 10-fold in February, compared to the already large volume we saw in January 2024”. The attackers were also observed trying to leverage information from the initial exfiltration to breach customer environments, indicating a sustained, significant commitment to gather even more data.

This article provides an overview of how Trellix Helix provides detection for and supports the investigation of the techniques observed in the Midnight Blizzard attack. Helix achieves this with a combination of rules and analytics (baseline deviation monitoring) that can detect various stages of this type of attack.

Attack Techniques and Patterns

Figure 1: Diagram of the Midnight Blizzard attack against Microsoft’s Exchange Online environment

Phase 1 - Detection

Initial access via password spray

The attackers conducted a password spray that compromised a legacy test account. They used residential proxies to evade detections based on failed logins from a single IP address, and targeted a low number of accounts with a low number of attempts to mask the password spray pattern.

The Helix rule “OFFICE 365 ANALYTICS [Brute Force]” can detect password spray and other brute force attacks. We are also continuously evolving our brute force analytics to detect more sophisticated and evasive forms of attacks.

The Helix rule “OFFICE 365 ANALYTICS [Abnormal Logon]” can also detect abnormal login patterns. For example, if a user has logged in from a country they’ve never logged in from previously.

These analytics have provided a number of true positive alerts for our customers in the past quarter:

Analytic Rule

True Positive Alerts

Customers

OFFICE 365 ANALYTICS [Abnormal Logon]

573

190

OFFICE 365 ANALYTICS [Brute Force]

50

16

Creation of new apps and user accounts

After gaining initial access, the attackers created new OAuth apps and users, then had the user accounts grant consent to the apps.

The Helix rules “MICROSOFT AZURE [User Account Added]” and “MICROSOFT AZURE [User Account Updated]” detect the creation and updating of user accounts, respectively.

The Helix rules “MICROSOFT AZURE AD [User Added to Admin Role (Non-PIM)]”, “MICROSOFT AZURE AD [User Added to Admin Role (PIM)]”, and “OFFICE 365 [User Added to Admin Group]” detect the granting of admin privileges to a user account, and the Helix rule “OFFICE 365 [Consent To Application]” detects the granting of consent to an application.

Granting of privileged permissions to apps

After creating new OAuth apps, the attackers used the legacy test app to grant the new apps the “full_access_as_app” role, which allows an app full access to all mailboxes in the environment.

The Helix rule “OFFICE 365 [Full Access as App Role Granted]” detects the granting of this role to apps. The Helix rule “MICROSOFT AZURE [OAuth Application Privileged Access]” detects the granting of other privileged permissions to apps.

API volume spike

The malicious apps created by the attacker exhibited a spike in Exchange Web Services API calls.

The Helix rule “OFFICE 365 ANALYTICS [Exchange Online App API Volume Spike]” detects Exchange Online API volume spikes from non-Microsoft OAuth apps.

Anomalous mailbox access from app

The Helix rule “OFFICE 365 ANALYTICS [Abnormal Mail Item Access]” detects suspicious mailbox access from an app; for example, an app accessing a particular mailbox for the first time. This could indicate a malicious app exfiltrating email messages.

Bringing it all together

The Helix rule “OFFICE 365 ANALYTICS [Suspicious User Activity]” is based on an analytic that takes a number of suspicious user actions into account:

• Abnormal Microsoft 365 login activity (e.g., login from never-before-seen country or ISP)
• Microsoft 365 brute force/password spray
• Azure flagged the login as a “risky sign-in”
• User has given consent to an Azure app
• User has assigned “full_access_as_app” role to an Azure app
• User has assigned privileged access to an Azure app
• User has created a new Azure user
• User has updated an Azure user
• User has updated privileges for an Azure user
• User has modified an Azure admin group
• IP address from user’s login was flagged by a threat intelligence event

If multiple of these criteria are met, this “Suspicious User Activity” alert will fire and may indicate a compromised user account. The more criteria that are met, the higher the risk score of the alert.

Figure 2: An “OFFICE 365 ANALYTICS [Suspicious User Activity]” Helix alert

A note on Helix Analytics
The Helix Analytics Engine continuously analyzes Helix events and generates findings that you can query with “class=analytics”. Many of these findings also trigger alerts. Helix analytics use correlation, statistical modeling, and anomaly detection techniques to provide sophisticated detection capabilities.

Phase 2 - Investigation

If an “OFFICE 365 ANALYTICS [Suspicious User Activity]” alert fires, click the “explanation” field in the alert event to get a breakdown of what suspicious activity triggered the alert. The “name” and “description” sub-fields provide a summary of what each detection found.

Figure 3: The “explanation” field in an “OFFICE 365 ANALYTICS [Suspicious User Activity]” Helix alert showing each detection found

This “explanation” field will also be available for other Office 365 Analytics alerts.

The “Investigative Tips” tab in the alert panel provides a useful starting point for beginning an investigation. For example, if an “OFFICE 365 ANALYTICS [Abnormal Logon]” alert fires, the following investigative tips can show you other pertinent activity observed from the user and IP address:

Figure 4: Tables of query results from investigative tips for an “OFFICE 365 ANALYTICS [Abnormal
Logon]” Helix alert

An example of Azure actions revealed by the investigative tips for an “OFFICE 365 [Full Access as App Role Granted]” alert:

Figure 5: Table of query results from investigative tips for an “OFFICE 365 [Full Access as App Role Granted]” Helix alert

An example of Microsoft 365 activity performed by an AppID that triggered an “OFFICE 365 ANALYTICS [Exchange Online App API Volume Spike]” alert:

Figure 6: Tables of Helix query results from investigative tips for an “OFFICE 365 ANALYTICS [Exchange Online App API Volume Spike]” alert

Perform search queries for actions taken by all of the users, IP addresses, and apps involved in the alerted behavior. For example, to see the earliest instance of an app accessing mail from a particular mailbox, run an archive search with the following query:

class=ms_office365 action=mailitemsaccessed appid=APPID mailbox=MAILBOXOWNER | table [meta_ts,srcipv4,srcipv6,clientvars,Folders] | sort < meta_ts

Figure 7: Table of results from a Helix query for all mail accesses from an app

Mitigations to prevent these types of attacks

Implement MFA and increase password security

The initial compromise vector relies upon performing password spray attacks against Microsoft 365 accounts that don’t have MFA (multi-factor authentication) enabled. Enable cloud authentication MFA to create a much higher barrier of entry for anyone performing this style of attack. Also be sure to set strict password requirements to make password spray attacks less likely to succeed.

Check apps and user accounts for heightened privileges

Verify that Microsoft Graph apps, service principals, and users don’t have more permissions than they need. In particular, if you have any non-production tenants, be careful of what privileges non-production apps have been granted consent to in the production tenant. Examples of heightened privileges include “EWS.AccessAsUser.All”, “EWS.full_access_as_app”, “User.ReadWrite.All”, “Directory.ReadWrite.All”, “RoleManagement.ReadWrite.All”, and “ApplicationImpersonation”.

Follow the tips in Microsoft’s advisory

Microsoft’s Midnight Blizzard attack advisory contains additional suggestions.