Account takeover (ATO) is the most common security threat SaaS companies face. Whether it is automated credential stuffing or a targeted attack on a specific account, the pattern is the same: an attacker gains access and acts as the legitimate user. Your audit logs are the primary tool for detecting these attacks and understanding their impact.
Authentication events
Every authentication event should be logged with enough detail to reconstruct the sequence:
auth.login.success— actor, IP address, user agent, authentication method (password, SSO, magic link), session IDauth.login.failure— attempted identifier, IP address, failure reason (invalid password, account locked, MFA failed)auth.logout— actor, session ID, whether user-initiated or session-expiredauth.mfa.enrolled/auth.mfa.removed— critical for detecting attackers adding their own MFA deviceauth.password.changed/auth.password.reset— distinguish between user-initiated changes and reset flows
Session and access events
Beyond login, track what happens during a session:
session.created/session.revoked— especially concurrent sessions from different locationsapi_key.created/api_key.revoked— attackers often create API keys for persistent accessuser.email.changed— a classic takeover move: change the email, then reset the passworduser.role.changed— privilege escalation is a strong takeover signal
Detecting mass account takeover (MATO)
MATO attacks are automated and high-volume. The signals are in the aggregate:
- High volume of
auth.login.failureevents across many accounts in a short window - Login attempts from IP ranges known for bot traffic
- Unusual user agent strings or missing browser fingerprints
- Successful logins immediately followed by email or password changes
Without structured audit logs, detecting these patterns requires digging through application server logs and stitching together data from multiple sources. With structured events, a single query surfaces the pattern.
Detecting targeted account takeover (TATO)
TATO attacks are harder to detect because they are low-volume and targeted. The signals are more subtle:
- Login from a new geographic location for an established user
- Session activity at unusual hours relative to the user’s history
- Rapid sequence: login, MFA removal, password change, email change
- Data export or bulk download shortly after a credential change
These signals only become visible when you have historical context — which means you need to be logging these events before the attack happens, not after.
Making logs actionable
Logging the right events is necessary but not sufficient. To make logs actionable:
- Standardize event names — use consistent, dot-namespaced actions so you can query across event types
- Include context — IP address, user agent, geographic location, and session ID turn individual events into a story
- Retain history — detection requires comparing current behavior to baselines, which requires retention beyond the immediate window
- Enable customer access — your customers’ security teams are often the first to notice suspicious activity on their own accounts, give them the tools to investigate