Look for new MFA device registration, unexpected inbox forwarding rules, unusual cloud storage access, and session activity that changes user agents or locations after successful sign-in. Those behaviours often appear after the attacker has the valid cookie and is trying to establish persistence. Detection should focus on post-login behaviour, not only failed logins.
How AiTM account takeover shows up after the initial sign-in
The clearest clue is that the account behaves as if someone else is already inside it. After the attacker captures a valid session, the evidence shifts from login failure to post-login manipulation: new MFA factors, mailbox rule changes, storage access, delegated access, and session activity that does not fit the user’s normal device or location pattern. That makes session-aware monitoring more valuable than password-focused alerting.
One useful way to read the signals is to separate compromise of the login path from compromise of the session. An AiTM attack often preserves the original authentication success, so defenders should expect a believable sign-in followed by abnormal changes that only the real user, or a threat actor with the cookie, could perform. The behavioural gap is the warning sign, not the sign-in event itself.
A second indicator is persistence-building behaviour. If the attacker can keep re-entering the account, they will often register a new authenticator, alter recovery options, or create forwarding and delegation rules so access survives password resets. Those actions are especially suspicious when they appear soon after a successful authentication from an unusual device, browser, network, or geography, or when they occur in bursts that do not match the user’s normal working pattern.
What defenders should watch in mailbox, cloud, and session telemetry
The most practical detection focus is on three surfaces: identity changes, content-routing changes, and cloud activity. New MFA device enrollment, unexpected inbox forwarding, and unfamiliar access to documents or object stores are all strong post-login indicators because they show the session is being used to entrench access or exfiltrate data. In many environments, the first high-confidence alert is not a blocked login, but a rule change or a cloud file read that the user did not initiate.
Session telemetry matters just as much. A valid cookie can let an attacker continue from a different browser profile, operating system, or network path, so look for sessions that keep running after impossible travel, abrupt user-agent changes, or sign-in patterns that do not match the user’s established device set. A single unusual sign-in can be noise; a successful sign-in followed by mailbox tampering and storage access is much more actionable.
For a deeper reference on the kinds of identity behaviours that matter here, the Workforce Identity Security Guide is a strong internal starting point because it ties together phishing-resistant authentication, account recovery, and session theft patterns. For control design, NIST guidance on authentication and session management also helps frame why post-login monitoring is essential in addition to credential protection.
Why AiTM compromise often looks normal until the attacker starts acting
AiTM succeeds because the attacker does not need to break the password after the fact. Once the session token is obtained, the account may continue to look legitimately authenticated, which is why these incidents are easy to miss if detection is limited to failed logins or MFA prompts. The compromise often becomes visible only when the attacker tries to make the access durable, broaden it, or use it to reach data.
That creates a specific investigative pattern: successful sign-in first, then account-change activity, then data-access or forwarding activity. If the sequence is reversed or absent, the case is less likely to be an AiTM-style takeover. In practice, the highest-value artefacts are the changes that extend access, such as new recovery methods, delegated mailbox access, and unusual cloud storage reads immediately after the session begins.
Threat modelling resources such as the MITRE ATLAS adversarial AI threat matrix are not the main lens here, but the broader adversary-technique mindset is useful: defenders should trace what an attacker does after access is obtained, not just how access was obtained. That same logic applies to AiTM account takeover.
Risk and Threat Considerations
AiTM is risky because it can leave an account apparently healthy while the attacker already has usable access. The main exposure is delayed detection: by the time password resets begin, the threat actor may already have created persistence, exfiltrated messages or files, or used the session to pivot into adjacent services.
Failure mechanism: The attacker captures a live session cookie or token during proxy-based authentication interception, then uses the authenticated session to change account settings, establish persistence, and access data without needing repeated MFA challenges.
Impact: Teams can miss the compromise if they watch only for failed logins, and the attacker may retain access long enough to steal mail, move laterally, or lock in recovery methods that outlast a simple password reset.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AiTM takeover often depends on stolen session and authenticator material. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-login changes and session anomalies are the key indicators in AiTM incidents. | |
| IA-2 — Identification and Authentication (Organizational Users) | AiTM abuses authenticated user sessions, so strong user authentication remains central. | |
| Recommendation — Rotate, expire, and revoke authenticators and session credentials quickly after suspicious sign-in activity. Review sign-in and post-authentication activity together to catch persistence-building actions. Require phishing-resistant user authentication to reduce session-capture success. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect cybersecurity events | AiTM detection depends on monitoring sign-in and post-login behaviour. |
| PR.AA-03 — Users, services, and hardware are authenticated commensurate with risk | Phishing-resistant authentication reduces the attacker’s ability to reuse stolen sessions. | |
| Recommendation — Correlate sign-in telemetry with mailbox and session activity to identify takeover. Apply stronger authentication for accounts exposed to credential and session theft. | ||
Practitioner Guidance
What to verify: Treat any successful login followed by new MFA enrollment, forwarding-rule creation, recovery-option changes, or unusual file access as a possible takeover until the session is validated against the user’s normal device and location baseline. Verify the sequence of events, not just the existence of the login.
What to prioritise: Alert on post-authentication changes that increase persistence or broaden access, especially mailbox rules, delegated access, recovery settings, and first-time access from a new device or network. These are often more reliable than raw sign-in anomalies for AiTM.
Practitioner takeaway: For AiTM, the question is not “did the login succeed?”, but “what did the session do after it succeeded?”
Related resources from NHI Mgmt Group
- Who is accountable when a crypto exchange account is taken over through recovery abuse?
- Who is accountable when a SaaS account is taken over through valid credentials?
- What are the signs that a returning customer account has been taken over?
- What are the signs that a social media account may have been taken over and used for crypto theft?