Why detecting what happens after account compromise is critical — and why most security tools focus on the wrong stage of the attack.

Most email security investments focus on preventing the initial compromise — blocking phishing emails, enforcing multi-factor authentication, and detecting credential stuffing attacks. These are necessary controls, but they address only the first phase of an attack. What happens after an account is compromised is where the actual damage occurs, and it is precisely where the majority of security tooling has the least visibility.

The attack timeline

A typical email account compromise follows a predictable three-phase pattern.

•Phase 1 — Compromise: The attacker obtains valid credentials through phishing, password spraying, token theft, or social engineering. This phase is where most security tools are concentrated — anti-phishing gateways, identity protection systems, and login anomaly detection.
•Phase 2 — Persistence: Within minutes of gaining access, the attacker establishes mechanisms to maintain access even if the credentials are changed. This includes creating forwarding rules, adding delegate access, registering OAuth applications, or creating hidden inbox rules. These configuration changes are the attacker's insurance policy.
•Phase 3 — Exfiltration and action: With persistence established, the attacker begins their objective — monitoring communications for intelligence, intercepting financial transactions, stealing intellectual property, or launching secondary attacks against the organization's partners and customers.

What happens after credentials are stolen

The critical window between initial compromise and incident detection is where organizations suffer the most damage. During this period, attackers typically execute a rapid sequence of configuration changes designed to maximize their access and minimize their visibility.

Within the first hour, an attacker will commonly create one or more forwarding rules to an external address, ensuring they continue to receive copies of all email even after losing direct access. They may create a hidden inbox rule that automatically deletes or archives security notifications, password reset confirmations, and suspicious activity alerts. They often add a secondary authentication method — a phone number or authenticator app — as a backup access path. And in sophisticated operations, they register an OAuth application with mail.read permissions, creating a persistent API-level access channel that survives credential resets.

Each of these actions takes seconds to execute but can take months to discover if the organization is not specifically monitoring for them.

Forwarding rules as a persistence mechanism

Email forwarding rules are the most effective persistence mechanism available to an attacker in a cloud email environment because they require no ongoing access to the compromised account. Once created, a forwarding rule operates autonomously. The attacker can close their session, delete their browser history, and abandon the stolen credentials entirely — the rule continues to deliver every incoming message to their controlled address indefinitely.

This persistence survives the standard incident response playbook. Password resets, session revocations, MFA enforcement, and conditional access policy changes do not affect existing inbox rules. The rule was created during a period of authorized access (from the mail server's perspective), and it executes as a legitimate mailbox configuration.

The SIEM gap

Security Information and Event Management (SIEM) platforms are designed to aggregate and correlate log data across an organization's infrastructure. In theory, SIEMs should detect post-compromise activity by monitoring Exchange Online audit logs and Azure AD sign-in logs. In practice, several factors create a significant detection gap.

•Volume: A mid-sized organization generates thousands of mailbox events per hour. Inbox rule creation events are a tiny fraction of this volume, easily lost in the noise without highly specific detection rules.
•Context: A SIEM alert for "inbox rule created" is meaningless without context. The rule's destination, conditions, and the circumstances of its creation must be evaluated together. Most SIEM deployments lack the enrichment logic to make this determination automatically.
•Visibility: MAPI-level rules and certain EWS-created rules may not generate standard audit log entries, creating blind spots in SIEM coverage.
•Expertise: Building and maintaining effective detection rules for email configuration changes requires specialized knowledge of Exchange Online internals that most SOC teams do not possess.