What to do after an account takeover
Resetting the password is only the first step. Learn how to contain a compromised account, remove attacker persistence, investigate what happened, and safely restore access.
You confirm that a work account has been compromised. Reset the password first, but do not stop there.
This guide is for IT and security administrators responding to a compromised work account. If you use the account but do not administer it, report the incident through a known, trusted channel from another device. Do not use the compromised account to seek help or receive recovery details.
An attacker can create other ways to return after gaining access. Google Workspace and Microsoft 365 both identify sessions, connected apps, forwarding rules, and recovery details as recovery checks.
An account takeover is an identity incident, not just a password problem. Your response should focus on three things:
- Stop the attacker.
- Remove any way they can return.
- Understand what they did while they had access.
Contain the account first
Contain the account before starting a long investigation. Block or suspend the account if your environment allows it, then reset the password with a new, unique credential.
Revoke refresh tokens and identity-provider sessions, then remove the account's access from connected applications where needed. A password reset or token revocation does not always end an application's own browser session immediately. Microsoft's emergency access guidance explains that each application controls its own session tokens.
A good first response is simple:
- Block or suspend the account.
- Reset the password.
- Revoke refresh tokens and identity-provider sessions.
- Preserve relevant logs and evidence without delaying containment.
- Keep the account restricted while you check for persistence.
NIST's incident-response guidance recommends integrating preparation, response, and recovery into your incident-management process. Preserve the evidence you need, but prioritize stopping ongoing access.
- Confirmed account takeover
- Contain account
- Revoke sessions
- Remove persistence
- Investigate activity
- Restore access
Remove the attacker's ways back in
After containment, check what the attacker changed. A password reset removes one access path, but an attacker may have created several others.
Start with authentication methods. Review every sign-in method attached to the account, including MFA devices, passkeys, security keys, recovery email addresses, phone numbers, and trusted devices. Remove anything the user does not recognize. Google and Microsoft both include this review in their recovery guidance.
Then review connected applications and their OAuth permissions. OAuth lets a user grant an application access without sharing a password. If an attacker approved a malicious application, it can retain access until you revoke its permission.
The exact controls differ by platform. This article uses Microsoft 365 and Google Workspace as examples; follow the equivalent recovery steps in your identity provider and connected SaaS applications.
You should also inspect the account for changes such as:
- New MFA methods or recovery details.
- Unknown trusted devices.
- New OAuth applications or consent grants.
- New forwarding addresses.
- Inbox or mailbox rules.
- Changes to delegated access.
- New API keys or application passwords.
- Unexpected role or permission changes.
For email accounts, pay close attention to forwarding and mailbox rules. Attackers can move security alerts, hide replies, forward messages externally, or delete messages before the user notices them. Microsoft lists suspicious Inbox rules and new external forwarding as signs of mailbox compromise. Google recommends checking forwarding settings and filters.
Record suspicious changes before removing them. A forwarding address, application ID, device name, rule, or recovery email can help you understand how the attacker operated.
Build a timeline of the attack
After you remove the obvious persistence, work out what happened. Start before the first suspicious event.
If a user reports an unusual email at 11:00, the compromise may have started hours or days earlier. Look for the event that gave the attacker access in the first place.
Review authentication and audit logs for these events. NIST's current incident-response guidance recommends using cybersecurity data to prepare for, respond to, and recover from incidents:
- Successful and failed sign-ins.
- New devices.
- New MFA registrations.
- Password or recovery changes.
- OAuth consent.
- Permission changes.
- Unusual applications.
- New geographic locations.
- New IP addresses.
- Activity outside the user's normal working pattern.
Do not treat one signal as proof. A new IP address may come from a VPN, a different country may reflect a mobile network or proxy, and a new device may be legitimate. Look at how the signals fit together.
For example, a successful login from an unfamiliar device, followed by a new MFA method and an external forwarding rule ten minutes later, tells a much stronger story than any of those events alone.
Your timeline should answer a few basic questions:
- When did the attacker first gain access?
- How did they authenticate?
- What changes did they make?
- What data or services did they access?
- Did they send messages or create new access paths?
- When did you remove their access?
You do not need perfect attribution. You need to understand the attack well enough to remove the access paths the attacker used.
Check what the attacker could reach
Investigate more than the account that was initially compromised. Work accounts often connect to email, cloud storage, collaboration platforms, CRM systems, internal dashboards, code repositories, HR tools, finance platforms, and other SaaS applications.
Google and Microsoft both recommend looking beyond the mailbox. Follow the identity: check which systems the account could access and what activity occurred during the compromise window.
For example, look for:
- Files opened or downloaded.
- Shared folders the account accessed.
- New sharing links.
- Messages the account sent.
- Contacts exported.
- API keys the account created.
- Permissions the account changed.
- New users invited.
- Sensitive records the account viewed.
- Applications the account connected to.
Match the investigation to the user's role. A compromised administrator can expose much more than a standard user. A developer account may provide access to source code and infrastructure. An HR account may expose employee data, while an executive account may give an attacker a trusted identity for internal social engineering.
Find out who the attacker contacted
People already trust a compromised account, so messages from it can spread the incident. Microsoft and Google both recommend reviewing messages and account activity after a compromise. Check what the attacker sent during the compromise period.
Look for messages containing:
- Login requests.
- Shared-document links.
- QR codes.
- MFA requests.
- Unusual attachments.
- Requests for sensitive information.
- Changes to normal business processes.
- Requests to move a conversation to another channel.
Then identify who received those messages. If another user clicked a link, entered credentials, approved an MFA request, authorized an application, or shared sensitive information, investigate that user as a possible second compromise.
Account takeover often spreads through trust. One compromised identity gives an attacker a legitimate-looking starting point for the next attack.
Restore access after you understand the incident
Restore access only after you can answer these questions:
- How did the attacker get in?
- What did they change or access?
- What have you done to stop the same path from working again?
You may not know every detail, but you should understand the access path well enough to reduce the chance of an immediate repeat compromise. Then take these steps:
- Remove unknown authentication methods.
- Revoke suspicious application permissions.
- Remove malicious forwarding or mailbox rules.
- Reset recovery details if needed.
- Rotate exposed application passwords or API keys.
- Review privileged access.
- Require fresh authentication.
- Re-register MFA if necessary.
Where possible, move the user to phishing-resistant authentication such as passkeys or FIDO2 security keys. CISA recommends phishing-resistant MFA and identifies FIDO/WebAuthn as a widely available approach. Start with high-impact accounts, then expand the deployment.
After restoring the account, monitor it closely. Watch for new authentication methods, unfamiliar sessions, repeated MFA prompts, new OAuth grants, forwarding rules, unusual messages, or other unexpected changes. Confirm that the account returns to its normal pattern.
Avoid these recovery mistakes
Avoid these common mistakes, which can leave the attacker with access:
- Stopping after a password reset. Check for active sessions, tokens, connected applications, and alternative authentication methods.
- Deleting suspicious changes before recording them. Rules, devices, recovery addresses, and OAuth applications can help you reconstruct the attack.
- Using the compromised account as the recovery channel. Communicate with the user through another trusted method until you confirm that the account is clean.
- Restoring access before checking persistence. One missed access path can let the attacker return immediately.
- Limiting the investigation to email. Check every important service the identity could reach.
- Assuming only one person was affected. A trusted account can be used to attack colleagues, customers, suppliers, or external contacts.
A password reset is the beginning, not the end
Treat account takeover as an identity incident. The attacker may have an active session, a malicious OAuth grant, a new authentication method, hidden mailbox rules, access to cloud files, or a trusted identity they can use to target someone else.
Contain the account first. Remove every persistence mechanism you can find, build a timeline, and check the systems and people the attacker reached. Restore access only when you understand why the attacker should no longer be able to return. That is the difference between resetting an account and recovering it.
