Enemy at the Gate, and Beyond: Detecting and Stopping Account Takeover

The talk treats account takeover as two stages: obtaining access, through stolen credentials, phishing or an insider handing over logins, and then using that access, where a successfully authenticated identity can still belong to an attacker. It follows one intrusion chain that moves from a compromised mailbox to a phished user, a hijacked identity-provider session and finally a persistent cloud access key.

For each step the speaker presents a detection approach. Impossible-travel alerts produced millions of notifications at one large customer, so the team cut the noise by discounting shared corporate IP ranges that many endpoints use, trusting addresses seen routinely, excluding service accounts and building baselines of normal travel routes. For MFA bypass, a legacy basic-authentication client identifier in sign-in logs gives a reliable signal, which is then checked against endpoint data, past login history and mailbox activity such as forwarding rules. Okta session hijacking is spotted by grouping events per session ID and flagging changes in IP address, operating system or browser, using edit distance to ignore minor browser version updates. Newly created AWS access keys used from unfamiliar addresses are compared against a time-series baseline of normal IP usage.

The takeaways are that MFA alone does not stop account takeover, that correlating identity, endpoint and cloud sources reduces noise and adds context, and that detection has to feed a clear response workflow. Teams should also consider blocking legacy authentication through conditional access policies.