Account Takeover: Getting Your Email or Bank Back
Recover the account that can reset the others first—usually email—then remove attacker persistence before changing every downstream password.
Account takeover recovery is an order-of-operations problem. If an attacker controls the email address that resets your bank, cloud, shopping, or social accounts, recovering those downstream accounts first can be temporary. Start with the highest-leverage recovery account, usually your primary email or Apple/Google/Microsoft identity. Regain access through the provider’s official recovery flow, change the password from a trusted device, remove unfamiliar recovery addresses and phone numbers, revoke unknown sessions and connected apps, and check forwarding rules. Then move outward to financial and other high-value accounts. The objective is not just to change a password; it is to remove the attacker’s ability to return.
Find the “root” account before you reset twenty passwords
List the accounts that can recover or authenticate other services: primary email, phone carrier, password manager, Apple or Google account, and perhaps a work identity provider. If one of these is compromised, fix it first. Use the provider’s known website or app, not a link from an alert email. If you still have one trusted signed-in device, keep it online until you understand the recovery options; logging out everywhere too early can remove your easiest proof of ownership.
Once access is restored, change the password to a unique value and enable stronger MFA. Review the account’s recovery email, phone, security keys, app passwords, trusted devices, and recent sign-ins. Attackers often add a recovery method so they can reset the new password later.
Persistence hides in forwarding rules, sessions, and connected apps
Mailbox forwarding and filtering rules are especially important. A thief can create a rule that forwards bank alerts or hides password-reset messages while the visible inbox looks normal. Review rules, delegates, POP/IMAP settings, app passwords, and OAuth-connected applications. Revoke anything you do not recognize. Then inspect recent login history for locations, devices, or timestamps that help establish when the account was compromised. The FBI’s September 2026 warning on OAuth consent phishing is a useful reminder that an attacker may hold an app authorization token even without retaining the password; revoke unfamiliar connected-app grants explicitly rather than assuming a password change invalidates every form of access.
Do the same conceptually for social and cloud accounts: remove unknown sessions, connected applications, recovery devices, and API tokens when the service exposes them. Password changes that leave active sessions or third-party tokens untouched can give the attacker another route back in.
Financial accounts need both access recovery and fraud review
After the root account is safe, contact banks and card issuers if there are unauthorized transfers, cards, beneficiaries, payees, or profile changes. Do not merely change the banking password and assume the money side is resolved. Review transaction history, linked external accounts, Zelle or other payment settings, mailing addresses, phone numbers, and paperless-statement settings. Ask the fraud team whether account numbers, cards, or credentials should be replaced.
If the attacker used the recovered email to open new credit, add credit freezes and review reports. Existing-account takeover and new-account identity theft can happen in the same incident but require different controls.
The carrier account is a recovery system too
If SMS is used for password resets or MFA, secure the mobile carrier account. Add a port-out PIN, number lock, or equivalent carrier protection. A sudden loss of service can signal SIM swap or port-out fraud; in that case, call the carrier from another phone, recover the number, and treat accounts that rely on SMS as exposed until you review them. Move critical accounts away from SMS-only MFA when authenticator apps, passkeys, or security keys are available.
- □ Recover the primary email or identity-provider account before working through low-value downstream services.
- □ Remove attacker persistence: recovery methods, sessions, forwarding rules, OAuth apps, app passwords, delegates, and trusted devices.
- □ Change reused passwords everywhere they were used, starting with financial and administrative accounts.
- □ Replace SMS-only MFA on the most valuable accounts with stronger factors when supported.
- □ Review bank, payment, cloud, and social account histories for profile changes as well as transactions.
- □ Save recovery confirmations and suspicious login details in case an institution asks for evidence later.
Malware changes the recovery strategy
If the takeover began after you downloaded and ran a file, installed remote-access software, or entered credentials on a suspicious device, changing passwords on that same device can give the attacker the new credentials. Use a clean device for the first recovery steps. Disconnect the suspect device from sensitive accounts and run the operating system’s supported security checks or get professional help when the compromise is serious. For a business device, preserve evidence and follow the organization’s incident-response process before wiping it.
A phishing page that only captured a password is different from malware with persistent device access. Your response should match what actually happened rather than automatically factory-resetting every device.
Password reuse turns one takeover into a graph of takeovers
Search your password manager or account list for every service that reused the compromised password. Change those passwords to unique values. Do not create variations such as adding “2026!” to the old password; credential-stuffing attacks are automated. A password manager makes the cleanup practical because each account can receive a random value and the manager can show where reuse still exists.
Passkeys can further reduce phishing exposure on services that support them. Keep backup recovery options, however, so losing a single phone does not lock you out of the whole identity stack.
Prove that the attacker is gone before declaring success
Over the next several days, check for new recovery-method changes, forwarded mail, login attempts, new payment recipients, or password-reset messages you did not initiate. Revoke sessions again if the provider shows a device you missed. Keep alerts enabled on financial accounts. If there is no new attacker-controlled recovery path and the account history stabilizes, move from incident mode to normal monitoring.
The endpoint is control of recovery, not just control of the password
A secure account is one where you own the password, MFA, recovery email, recovery phone, devices, and connected applications. That definition is stricter than “I can log in again,” and it is what prevents repeat takeover. Once the root accounts are clean, downstream passwords are unique, financial activity is reviewed, and recovery channels are under your control, the account-takeover portion of the incident can be considered contained.
Questions specific to Account Takeover: Getting Your Email or Bank Back
Which account should I recover first after a takeover?
Usually the account that can reset the others, often primary email or a major identity-provider account. Securing downstream accounts first can be temporary if the attacker still controls the recovery path.
Is changing the password enough?
No. Review recovery addresses, phone numbers, sessions, forwarding rules, app passwords, connected apps, and trusted devices. Attackers often leave persistence mechanisms behind.
What if I downloaded a suspicious file before the takeover?
Use a trusted clean device for sensitive password changes and consider device-security or professional incident-response help. A compromised device can capture the new credentials as you enter them.
Should I turn off SMS MFA immediately?
Replace SMS on high-value accounts when stronger factors are available, especially if phone-number takeover is suspected. Keep a safe recovery path so the change does not create an accidental lockout.