Account Takeover Investigation: A Response Playbook

Last verified on Nov 8, 2026.

An account takeover investigation answers four questions: how the attacker got in, how long they had access, what they did with it, and whether they still have it. Detection is covered in the authentication anomalies guide. This page starts after someone has said "I think this account was taken over" and walks the response in order: scope, timeline, containment, impact, notification.

A takeover is MITRE ATT&CK T1078, Valid Accounts: adversaries obtain and abuse credentials of existing accounts for initial access, persistence, privilege escalation, or defense evasion. That framing matters because valid credentials do not trigger exploit alerts. Your evidence is in authentication and audit logs, so you will be reading those first.

Preserve Evidence First

Before you change anything, copy the logs for the account. A password reset, session purge, or key deletion changes what the logs show next, and some systems delete state when you do. Export the account's authentication events, session records, and audit trail for a window that starts well before the first suspicious event, and note the time you started so later entries are not confused with the attacker's.

OWASP's session guidance recommends logging the full lifecycle of sessions: creation, renewal, and destruction of session IDs, privilege changes within the session, timeout expiration, and invalid session activity, plus the timestamp, source address, requested resource, event type, result, and user ID. If your logs do not have these, note the gap now and fix it later. Raw session IDs should not be in logs. OWASP recommends logging a salted hash so entries can be correlated without exposing the ID.

Scope: Sessions, IPs, and Devices

Start with every authentication event for the account in the window:

SELECT ts, event_type, outcome, src_ip, user_agent, session_hash, mfa_method
FROM auth_events
WHERE user_id = 'user_4412'
  AND ts BETWEEN TIMESTAMP '2026-10-25 00:00' AND now()
ORDER BY ts

Then separate the owner's normal footprint from everything else. List the distinct source addresses and user agents with first and last seen and the outcome counts:

SELECT src_ip, user_agent, min(ts) AS first_seen, max(ts) AS last_seen,
       count(*) FILTER (WHERE outcome = 'success') AS ok,
       count(*) FILTER (WHERE outcome = 'failure') AS failed
FROM auth_events
WHERE user_id = 'user_4412' AND ts > now() - INTERVAL '30 days'
GROUP BY 1, 2
ORDER BY first_seen

Look for the first successful login from an address or device the owner has never used, preceded or not by failures. Many failures then a success from one address suggests guessing. A single success with no failures suggests the attacker already had the password, from phishing, malware, or a breach elsewhere.

Next, pivot outward. Credential stuffing tests username and password pairs taken from other breaches, and OWASP notes that the tooling commonly uses proxy networks that spread requests across many addresses, so one address per account is not a safe assumption. Search by the attacker's address and user agent across all users to find sibling accounts:

SELECT user_id, count(*) AS attempts,
       count(*) FILTER (WHERE outcome = 'success') AS successes
FROM auth_events
WHERE (src_ip IN ('203.0.113.50', '203.0.113.51') OR user_agent = 'python-requests/2.31.0')
  AND ts > now() - INTERVAL '30 days'
GROUP BY user_id
ORDER BY successes DESC

If it is more than one account, you are probably in a credential stuffing campaign, and the investigation becomes a population problem: find every account with a success from the same infrastructure, and treat each as compromised. OWASP also recommends storing an account's IP address authentication history, which is exactly what makes this query possible.

Timeline: What the Attacker Changed

An attacker with a session usually does three things: secure access, look around, and take something. Build the timeline from the first suspicious login forward, with these event types in one query:

SELECT ts, event_type, src_ip, detail
FROM audit_events
WHERE user_id = 'user_4412'
  AND ts >= TIMESTAMP '2026-10-30 14:00'
  AND event_type IN (
    'password.reset_requested', 'password.changed',
    'email.change_requested', 'email.changed',
    'mfa.enrolled', 'mfa.removed', 'recovery.updated',
    'api_key.created', 'oauth.grant', 'session.created', 'session.revoked',
    'login.success', 'login.failure')
ORDER BY ts

What each means:

• Password reset requested, then a login. Often the reset link was intercepted in a compromised mailbox, which makes the mailbox the real incident.
• Email change. OWASP's recommended flow sends a notification-only message to the current address and a confirmation to the new one. Check whether both were sent and whether the notification link was used. An attacker who changes the email address controls all future resets.
• MFA removed or a new method enrolled. NIST SP 800-63B-4 requires notifying the subscriber when a new authenticator is bound. A new authenticator added shortly after a login from a new address is a persistence mechanism.
• New API key or OAuth grant. These survive a password reset. They are the most commonly missed persistence step.
• Recovery information changed. OWASP specifically warns that an attacker may have changed recovery information.

Mark the earliest attacker event as time zero. Everything the account did after that is suspect, and everything before it is baseline.

Contain

The order matters, because the attacker is still acting while you work. OWASP and NIST give a consistent sequence:

1. Suspend or invalidate the compromised authenticators. NIST SP 800-63B-4 says the provider suspends, invalidates, or destroys compromised authenticators promptly after compromise detection, and that verifiers must force a password change on evidence of compromise.
2. End every session and token. Invalidate sessions server-side. OWASP says all session IDs belonging to one logical session must be revoked together, including those issued by rotation and those still accepted during a grace period. Revoke refresh tokens, personal access tokens, and API keys created for the account.
3. Remove what the attacker added. Delete new API keys, OAuth grants, MFA methods, forwarding rules, recovery addresses, and phone numbers that appear in your timeline. OWASP says not to automatically restore superseded recovery addresses or phone numbers, since they may have been replaced because they were lost or compromised.
4. Recover through independent evidence. Do not rely on recently added or changed recovery information. Use previously established evidence, such as saved recovery codes. Then have the verified owner set a new password and re-enroll MFA.
5. Invalidate again after recovery. OWASP says to invalidate existing sessions and outstanding reset and recovery links or codes after successful recovery, so nothing can bring back the attacker's access.

If the account has administrative rights, treat it as a privilege change incident too: check what roles or tokens it granted to other accounts.

Check What They Accessed

Containment stops the attacker. Impact analysis tells you whom you need to tell. Use the application's audit trail for the account between time zero and containment:

SELECT date_trunc('hour', ts) AS hour, action, resource_type, count(*) AS n,
       count(DISTINCT resource_id) AS distinct_resources
FROM audit_events
WHERE user_id = 'user_4412'
  AND ts BETWEEN TIMESTAMP '2026-10-30 14:00' AND TIMESTAMP '2026-10-31 09:30'
  AND action IN ('read', 'export', 'download', 'share', 'delete', 'update')
GROUP BY 1, 2, 3
ORDER BY hour

Look for bulk reads and exports, new shares, deletions, payment or payout changes, messages sent from the account, and changes to other users' permissions. Compare against the owner's usual rate of activity. Access anomalies and abuse and fraud cover the patterns. Also check what the account's credentials could reach beyond your application: connected cloud consoles, source control, a shared mailbox, or secrets stored in notes. If a secret was reachable, rotate it and read secrets in logs.

If your application does not log reads, say so in the report. Absence of evidence is not evidence the attacker did not look.

Notify

NIST SP 800-63B-4 requires that account recovery causes a notification to the subscriber, and that notifications provide clear instructions, including contact information, if the recipient does not recognize the event. OWASP adds that you should notify through all applicable registered notification addresses, including established channels that remain safe to use, and not only the address on file, which the attacker may control. Tell the owner what you saw, what you changed, and what to check. Any legal or contractual notification duty depends on your jurisdiction and customers, and belongs with whoever owns that decision, with the evidence from your timeline.

Close the Gap

Write down the answer to how they got in, then fix that. Common causes and the matching controls:

• Reused password from a breach. Require MFA, check new passwords against a blocklist of compromised values, and apply credential stuffing defenses. OWASP calls MFA the best defense against the majority of password attacks.
• Phished session or token. Shorten session lifetimes, bind sessions to client properties, and require reauthentication after risk events such as password changes and logins from a new device.
• Compromised mailbox. Notify on every email and recovery change, and delay or confirm resets for high-value accounts.
• Missing logs. Add whatever the timeline lacked. Security logging lists the events and fields.

Finally, see account takeover for the definition.

Running the Investigation in Sazabi

Sazabi, an AI-native observability and security platform, searches the logs you send it. Once authentication and audit events are flowing, you can ask in plain language, for example sazabi logs ask "all successful logins for user_4412 from new IP addresses in the last 14 days", then follow the pivots above with your own queries when you want exact control. Sending the application audit trail, not only the access logs, is what makes the impact step possible.