Hunting Malicious Inbox Rules: KQL Detections for BEC Persistence

Initial access gets all the glory, but persistence is where the real damage is done. Once an attacker lands in a Microsoft 365 tenant, their immediate priority is ensuring they do not lose that foothold when the initial compromised credential is rotated or the session token expires. For sophisticated adversaries and commodity business email compromise operators alike, the Exchange mailbox rule remains the ultimate stealth persistence mechanism. It is an infrastructure-free, highly native method for routing sensitive data, hiding administrative alerts, and intercepting communication without triggering endpoint detection systems.

We saw this explicitly in Microsofts disclosures regarding Midnight Blizzard. After compromising a legacy non-production OAuth application and chaining permissions to access corporate mailboxes, the Russian state-sponsored actor did not just read emails. They actively manipulated mailbox rules to obfuscate their tracks and quietly siphon correspondence related to their own operations. They understood that SOC analysts rarely audit user-level Outlook configurations unless a specific alert prompts them to do so.

Hunting for these mechanisms requires moving past basic static indicators and diving into the behavioral telemetry of the Unified Audit Log. You cannot just look for rules that forward mail to external webmail providers anymore. You have to hunt for the subtle, internal routing manipulations that attackers use to blind the victim to their own inbox.

The Anatomy of an APT-Grade Evasion Rule

The classic business email compromise playbook involves setting up a rule to forward emails containing keywords like invoice, payment, or wire to a threat-controlled external address. Microsoft and most security vendors caught onto this years ago. Default tenant configurations now heavily restrict automatic external forwarding, forcing attackers to adapt their tradecraft to operate entirely within the boundaries of the compromised mailbox.

Midnight Blizzard and similar advanced persistent threats rely on internal obfuscation. Instead of exfiltrating data via SMTP forwarding, they create rules that sweep incoming alerts, security notifications, or specific replies into obscure folders that the user never checks. The RSS Subscriptions folder, the Archive folder, or even the Deleted Items folder become temporary staging grounds.

Exploiting the RSS Subscriptions Folder

The RSS Subscriptions folder is a particularly favored destination because it exists in every default Exchange mailbox and is universally ignored by actual human users. When an attacker initiates a password reset for a downstream application, they configure a rule to immediately move the incoming password reset email to this folder and mark it as read.

Operation: New-InboxRule. Parameters: Name: ., MoveToFolder: RSS Subscriptions, MarkAsRead: True, StopProcessingRules: True.

The victim logs in, checks their primary inbox, and sees absolutely nothing out of the ordinary. The attacker, accessing the mailbox via a stolen session token or persistent OAuth grant, retrieves the reset link from the RSS folder and continues their attack chain.

Extracting the Signal from the Unified Audit Log

To catch this activity, defenders must rely on the Unified Audit Log. The specific operations of interest are New-InboxRule, Set-InboxRule, and occasionally Enable-InboxRule, all of which fall under the ExchangeAdmin workload. But querying the Unified Audit Log directly for these operations is only the first step. The actual meat of the operation is buried inside a nested JSON array called Parameters.

Expanding the Parameters Array

When a user or an attacker creates a rule, Exchange logs the specific configuration of that rule as a series of key-value pairs within this array. Because the Unified Audit Log schema is notoriously flat in some areas and deeply nested in others, extracting the actionable data requires expanding this array dynamically.

In Kusto Query Language, you cannot simply filter on a rule name because the name is trapped inside the JSON blob. You have to use the mv-expand operator to unroll the Parameters array, followed by conditional logic to extract the specific keys you care about. You need to map out the Name of the rule, the MoveToFolder destination, the ForwardTo address, and the specific match criteria such as SubjectContainsWords.

By projecting these specific values into their own columns, you transform a dense, unreadable JSON string into a structured table that you can actually analyze. This structural transformation is non-negotiable for effective hunting. Without it, you are just string-matching against raw logs, which is incredibly fragile and prone to missing variations in the JSON structure.

Writing Detections for Names, Destinations, and Triggers

With the data correctly parsed, you can begin applying behavioral logic. Effective malicious inbox rule detection requires looking past the event name and analyzing the string entropy and configuration logic of the rule itself. Threat actors often use automated scripts to deploy these rules, resulting in naming conventions that stand out if you know what to look for.

Spotting Obfuscated Rule Names

A common evasion technique is naming the rule with a single character, such as a period, a comma, or a single space. This minimizes the visual footprint of the rule if the user happens to open their Outlook settings. In your KQL query, you should calculate the string length of the extracted rule name. Any New-InboxRule event where the rule name length is less than two characters should immediately trigger a high-severity alert.

You can also look for randomized alphanumeric strings. While users sometimes give rules arbitrary names, a rule named with a perfectly random sixteen-character string is highly indicative of automated deployment via a malicious PowerShell script or an attacker-controlled Graph API application.

Broad Match Criteria and Internal Staging

Beyond the name, analyze the match criteria and the action. Attackers frequently use extremely broad match conditions, such as rules that trigger on every single incoming email, combined with a MoveToFolder action directing the mail to Archive or Deleted Items. This is often used during the final stages of a BEC campaign to completely blind the user while the attacker interacts with the target company financial department.

Your KQL logic should flag any rule that combines a DeleteMessage or MoveToFolder action with a lack of specific filtering criteria. If a rule is moving everything to the RSS Feeds folder, it is malicious. There is no legitimate business use case for routing all inbound corporate communication to an obsolete syndication folder.

Contextualizing Rule Creation with Identity Telemetry

The challenge with hunting mailbox rules is that users do exceptionally weird things with their email. A perfectly legitimate user might create a rule to delete all emails from a specific internal application, or they might name a rule with a single letter because they were in a hurry. If you alert purely on the rule creation, you will fatigue your SOC with false positives.

Session Token Correlation

To build a high-fidelity detection, you must correlate the ExchangeAdmin event with identity telemetry. When Midnight Blizzard accessed mailboxes, they often did so using stolen session tokens, bypassing primary authentication and conditional access policies. This leaves a distinct fingerprint in the Azure Active Directory SigninLogs.

You need to take the SessionId or the ClientIPAddress from the Unified Audit Log event and join it against the sign-in logs. Look for rule creation events that occur within a session flagged by Azure Identity Protection for anomalous token use, unfamiliar sign-in properties, or a radically different autonomous system number compared to the users historical baseline.

If an inbox rule with a single-character name is created during a session originating from a commercial VPN node, and that user typically authenticates from a corporate IP space, you no longer have a suspicious event. You have a confirmed compromise. Correlation is what upgrades a weak indicator of compromise into a definitive behavioral signature.

Automating the Response Pipeline

Detection is only half the battle. Because inbox rules operate continuously in the background, every minute a malicious rule remains active is a minute the attacker is successfully hiding their tracks or exfiltrating data. Manual triage is too slow. You need an automated runbook to neutralize the threat the moment the KQL detection fires.

Suspending the Mailbox and Revoking Sessions

When your SIEM triggers on a high-fidelity correlation between an anomalous rule creation and a suspicious session, it should initiate an automated response playbook. Using Azure Logic Apps or a dedicated SOAR platform, the first step is to suspend the mailbox. This involves executing the Disable-InboxRule cmdlet against the specific rule ID extracted from your KQL query, immediately stopping the mail manipulation.

Following the rule suspension, the runbook must revoke all active sessions for the compromised user via the Revoke-AzureADUserAllRefreshToken cmdlet. This severs the attackers access, whether they are using a stolen token or a persistent OAuth grant. Finally, the runbook should force a password reset and isolate the users primary endpoint to prevent lateral movement.

The takeaway

Relying on endpoint detection alone leaves a massive blind spot in your cloud infrastructure. Mailbox rules are native, legitimate administrative functions, which means they will never be blocked by antivirus or flagged by basic malware heuristics. Hunting them requires a deep understanding of how attackers abuse standard features to maintain their operational tempo.

By parsing the nested parameters of the Unified Audit Log and joining that data with identity context, defenders can strip away the obfuscation that groups like Midnight Blizzard rely on. It takes effort to build and tune these KQL queries, but the visibility gained is invaluable. When you are ready to automate this level of forensic depth across your entire tenant without writing custom parsers from scratch, the analytics engine inside MailSleuth.AI provides the exact correlation needed to stop BEC persistence in its tracks.