Why the Order Matters More Than the Steps
When someone else has access to your account, doing the right things in the wrong order can make the situation worse.
- Change the password first, and you may hand the new one straight to malware still running on your own laptop.
- Change it but skip the session list, and the intruder stays signed in, because a password change does not always invalidate a login that already happened.
- Delete the evidence before you have read it, and you lose the dates that a bank dispute or a platform report will ask for.
What follows is an incident-response sequence written for one person with one or two devices, not for a company with a security team. Work through it in order, and stop where it stops applying to you.
Step 1: Get to a Device You Trust Before You Change Anything
Many takeovers begin with an infostealer - malware that copies saved browser passwords, session cookies, cryptocurrency wallet files and autofill data, then uploads them. If that is what happened, every password you type on the infected machine is captured as well, and you will be locked out again within hours. Resetting credentials from a compromised computer is how people end up doing this twice.
So before touching the account, move to a device you have reason to trust:
- A second phone, using mobile data rather than the home Wi-Fi.
- A household computer that has not been used for pirated software, game cheats, cracked installers or unusual downloads.
- A freshly reset device, if you have one.
Do not use a shared or public computer. You will be typing your most sensitive password and reading one-time codes on it.
If you have no second device, accept the trade-off explicitly: run a full malware scan first (Step 6), do the recovery from the machine, then repeat the password changes from a clean device afterwards.
Do not delete the suspicious messages yet. Sign-in alerts, the password-reset email you did not request, and messages sent in your name are the timeline of what the attacker reached and when. Bank disputes, platform abuse reports and police reports all ask for those dates.
Step 2: Use the Provider's Own Recovery Flow, Reached by Typing the Address
Type the provider's domain into the address bar, or open its installed app. Never reach a recovery page from a link in an email, and never from a sponsored search result - fake recovery pages are a standard follow-up scam aimed specifically at people who are panicking and searching for help.
Recovery is not the same thing as a password reset. It is an evidence-weighing process. The provider asks for things only the real owner is likely to know, then scores the answers: a code sent to your recovery phone or email, an older password you once used, the month the account was created, devices it already recognises, sometimes a government ID for high-value accounts. Answer from memory. Approximations are often accepted; a pile of confident wrong guesses hurts your case.
Two limits worth understanding before you start
- Deliberate waiting periods. If the attacker already changed your recovery phone and email, some providers impose a cooling-off period before honouring further changes, precisely so the real owner has a chance to object. This is frustrating and it is also protecting you.
- Refiling does not help. Submitting the same form repeatedly rarely accelerates anything and can look like an automated attack. Get one submission as complete as you can make it.
Google's public guidance for a hacked account is a good model of what these flows ask, and it is worth reading before you need it, so you know which recovery details you have registered and whether they are still current.
Step 3: Set a New Unique Password, Then Sign Out Every Other Session
Choose something long and used nowhere else: a passphrase of unrelated words, or a manager-generated random string. Current NIST guidance moved away from forced character-composition rules and from mandatory periodic rotation, because both pushed people toward predictable patterns and small increments of the old password. A new password that is a variation of the old one is not a new password.
Now the step most people skip. When you sign in, the service gives your browser a session cookie - a token meaning this browser already proved who it is. The attacker's browser holds one too. On many services a password change does not retract it, and almost none retract tokens held by other client types: mail apps connected over IMAP, linked mobile apps and app-specific passwords can all survive a reset.
So clear the list. Look under Security for Your devices, Where you're signed in or Active sessions, and choose the option to sign out everywhere else. Do this after changing the password, or the intruder can simply sign back in with the old one.
If a stolen cookie was the route in, the sign-out is the actual fix. The password change matters for the future; revoking sessions is what removes the access the attacker is using right now.
Step 4: Hunt for the Persistence They Left Behind
A competent intruder does not depend on keeping your password. They plant a second way in, plus a way to stop you noticing. Check every row below, even if the first few look untouched - the point of persistence is that it is quiet.
| What to check | Why attackers use it |
|---|---|
| Mail forwarding address, and every filter or rule | A silent copy of every message. Rules that delete anything containing "password", "invoice" or a bank's name hide the alerts from you. |
| Recovery email and recovery phone number | Whoever controls these can reset the password again at will, long after you have changed it. |
| App passwords (app-specific passwords) | Generated strings that bypass multi-factor authentication for one app, and that outlive a password change until revoked individually. |
| Connected apps and third-party access (OAuth grants) | Anything authorised with "Sign in with..." holds its own token and needs no password at all. |
| Security questions and answers | Rewritten to something only the attacker knows, which turns the recovery flow against you. |
| Registered MFA methods | An extra authenticator entry or phone number added beside yours, so the attacker also clears the second factor. |
| Aliases, delegated access, auto-reply, signature, account language | Quiet extra doors. A changed auto-reply spreads the scam to everyone who writes to you; a switched interface language slows the real owner down. |
| Linked payment methods, saved cards, delivery addresses | The commercial version of persistence: a stored card or address they can use long after you regain the login. |
Where to look, concretely: a Google Account keeps most of this under Security and under Data & privacy at myaccount.google.com; Microsoft, Apple and Meta keep theirs under Security, Privacy or Connected apps. Note any forwarding destination before deleting the rule - it belongs in your report.
Step 5: Rebuild Multi-Factor Authentication From Scratch
Do not simply delete the one method you do not recognise. Remove all of them and enrol again, because you often cannot tell which entry is yours: an authenticator app entry shows only a label, and the label was chosen by whoever enrolled it.
- Regenerate backup codes. The old set may have been downloaded during the intrusion, and old codes usually stay valid until a new set is issued.
- Store the new codes offline - on paper, or in a password manager, but never inside the account they unlock.
- Prefer a passkey or hardware security key where offered. SMS beats no second factor but loses to both SIM swap and proxy phishing. If SMS is the only option, ask the operator for a port-out PIN as well.
- Enrol a backup factor on a second device in the same sitting, so the next lost phone is an inconvenience rather than a crisis.
How each method works, and where each one fails, is set out on multi-factor authentication and passkeys.
Step 6: Widen the Search - One Account Is Rarely the Only Loss
A single compromised account is usually a symptom rather than the whole event. Work outwards.
- Check breach exposure. Enter the address at Have I Been Pwned, which indexes public breach data and names the services involved. It cannot see unpublished breaches, so a clean result is reassurance rather than proof.
- Change the old password everywhere it was reused. Reuse is the normal case, not a shameful exception. Order: primary email first, then anything holding payment or identity data, then the rest. Your browser's saved-password list is a serviceable inventory of what to work through.
- Scan for infostealer malware. On Windows: Windows Security, then Virus and threat protection, then Scan options, then Full scan - followed by a second, reputable on-demand scanner, because no single engine catches everything. If a stealer is confirmed, treat every credential ever saved in that browser as compromised and seriously consider reinstalling the operating system rather than cleaning it.
- Warn the people it messaged, through a different channel, and say what the scam message asked for - not just "I was hacked". A specific warning is one people act on.
- Watch the money. If payment details were stored or visible, read recent statements line by line, switch on transaction alerts, and ask the issuer to reissue the card rather than merely block one charge. The card number itself is compromised and will be tried again.
- Consider a credit freeze or your country's equivalent if identity documents were exposed. In the United States, IdentityTheft.gov builds a recovery plan for your specific case.
Step 7: Report It, and Know What Reporting Achieves
Three channels are worth the time, for three different reasons.
- The platform. Its compromised-account or abuse form is what gets messages sent in your name taken down, and it creates a record if a payment dispute later turns on whether you notified anyone.
- Your bank or card issuer, the same day, if payment data was involved. Chargeback rights and fraud-liability rules are frequently tied to how fast you reported, and that window can be measured in days.
- Your national cybercrime or consumer-protection body. Most countries run an official portal through the police, a telecoms regulator or a cyber-security agency. Find yours on your government's own domain, never through a search advertisement.
Be realistic: a single report rarely identifies the attacker or recovers money by itself. Its value is a dated paper trail, eligibility for a chargeback or insurance claim, takedown of content sent in your name, and the aggregate data that eventually gets criminal infrastructure blocked. Refuse one offer outright: anyone who contacts you offering paid account recovery, or a hacker for hire, is running a second scam aimed at people who were just robbed.
If You Cannot Get the Account Back
Sometimes recovery fails, particularly when the attacker changed the recovery details and the provider's cooling-off period favours whoever holds them. Shift from recovery to containment.
- Open a new account on a different address and secure it with a passkey or hardware key from day one.
- Find every service that used the lost address as its login or its recovery contact, and change it there. This is the real damage: whoever holds the mailbox can reset those accounts whenever they choose.
- Detach it from the other side. Wherever you used "Sign in with..." with that address, open that service's own security settings and remove the link, or set a direct password.
- Tell your contacts that the old address is no longer yours and that anything arriving from it should be ignored.
- Keep the timeline. If the address is later used to impersonate you, a dated record of when you lost control is the most useful document you will have.
Questions readers ask about this page
Should I change my password first or sign out other sessions first?
Change the password first, then immediately sign out all other sessions. The order matters: if you sign out first and change the password afterwards, an attacker who still has the old password can simply sign back in. Doing both, in that order, removes both the credential and the live session they are using.
The attacker deleted my messages. Does that matter?
It matters mostly as a limitation. Deleting security alerts and the reset emails you did not request is a common move, and it removes your timeline. Look instead at whatever survives: sign-in notification emails on linked addresses, the platform's own security log of recent activity, and bank statements. Keep every screenshot and note the date.
I changed my password but I am still locked out, or the attacker is still inside. Why?
Three common reasons. An app-specific password or an OAuth token was never revoked and still works. A connected mail client kept a session over IMAP. Or a mail forwarding rule is still feeding them your messages, letting them reset again. Working through the persistence checklist in Step 4 covers all three.
How do I know whether my computer is infected?
You often cannot, which is why the first step is to recover from a different device. Signs that justify treating a device as compromised include unexpected browser extensions, a changed homepage or search engine, antivirus disabling itself, and credentials failing shortly after you reset them. A full scan is worth running; a clean scan is not proof, and a confirmed infostealer usually justifies reinstalling the operating system.
Someone offered to recover my account for a fee. Should I use them?
No. Paid account-recovery offers that arrive by message, direct message or search advertisement are a well-documented follow-up scam that targets people who have just lost an account. They cannot do anything you cannot do through the provider's own recovery flow, and they frequently take payment and then ask for your remaining credentials. Use the official recovery route, and visit the official DEWA89 website for more on account protection.
Sources checked for this page
- Google - Secure a hacked or compromised Google Account
- UK NCSC - Recovering a hacked account
- NIST - SP 800-63B: Digital Identity Guidelines
- Have I Been Pwned - check an email address against known breach data
- US FTC - IdentityTheft.gov recovery plans
- CISA - Secure Our World guidance for individuals
- UK Action Fraud - national reporting for fraud and cybercrime
About DEWA89
DEWA89 is an independent educational project written by one person. It is not a company, an agency or a managed editorial team, and it does not pretend to be one. Rehan Aldiansyah writes these pages, checks them against the primary sources cited on each one, and answers corrections sent to the address on the support page.
DEWA89 is the name the site publishes under; the name above is the person accountable for what it says. Nothing here is generated and published unread: a claim either traces to a source you can open yourself, or it is marked as the author's own judgement.
How this site is funded
It is not. There is no advertising, no sponsorship, no affiliate link, no paid placement and no product for sale anywhere on this site. No company pays to be mentioned, and no page carries a commission-bearing link. Hosting is paid for out of the author's own pocket, which is the whole of the commercial relationship. If that ever changes, the change will be disclosed on this page before it appears anywhere else.
How to read this site
- Primary sources only. Where a claim can be checked, it links to the standards body, regulator or vendor documentation that supports it — not to another summary of it.
- Limits are stated. Where a control fails, or a setting only partly helps, the page says so in the same breath as the advice.
- Country-specific answers are labelled. Reporting routes, consumer protections and privacy law differ by country, so a passage that applies in only one is marked as such.
- No fear as a sales tool. Scaring a reader into a purchase is the behaviour this site exists to argue against.
Editorial standards we hold ourselves to
- We do not quote a statistic without naming the report and its year.
- We do not name a step-by-step settings path unless the vendor's own documentation still shows it.
- We do not present a product as the answer. Where a category of tool helps, we describe the category and what to look for in it.
- We do not write in the voice of expertise we do not have. When a question needs a lawyer, a doctor or a regulator, the page says so and stops.
- We do not silently rewrite a substantive claim. Material corrections are recorded with a dated note on the page, as described on the support page.
Dates, and what they mean
The date below is the last time these pages were re-checked against the sources they cite. It is a record of what happened, not a schedule: no page here states a calendar interval for review, because a static site cannot enforce one. Pages are re-checked when something they describe actually changes — a vendor renames a setting, a standard is revised, a regulation is amended, a link breaks — and at least once a year regardless, so that nothing is left unexamined through neglect.
The date moves only when a person has re-opened the cited sources and confirmed the text still matches them. It is not the date a file was last saved. Where a passage has been left standing but is no longer certain, it is marked as uncertain rather than quietly carried forward.
If the date below looks old, that is information, not a fault. It means the pages are due for their next pass. Everything on them links its primary source precisely so you can check the current position yourself rather than relying on our copy of it.
Who is accountable for this page
| Published by | DEWA89, an independent educational project written and paid for by Rehan Aldiansyah |
|---|---|
| Written by | Rehan Aldiansyah — an independent writer, publishing under the DEWA89 name. No employer, qualification or years of experience is claimed here, because this site asserts only what can be checked. |
| Reviewed by | Rehan Aldiansyah. This site has no separate reviewer, and we do not name one to look better. Every page is self-reviewed against the sources it cites, and that is exactly what the review record below means. |
| Corrections | Send a correction — specific reports are checked against a primary source and fixed or answered |
| First published | 2026-10-08 |
| Last reviewed | 2026-10-08 — every page on this site carries the same review date, and each one links the sources it was checked against |
Contact
Corrections, factual disputes, reports of a link that now leads somewhere harmful, and notices that a described setting has moved are all welcome at the address below. Rehan Aldiansyah reads them.
We will never ask you for a password, a one-time code, a recovery code or remote access to your device, and we will never ask you to confirm account details by replying to a message. Any message claiming to come from this site and asking for any of that is not from us.
Scope and limitations
Read this before acting on anything here.
- This is general education, not advice for your situation. It explains how account takeover and phishing generally work and what a reader can do about them. It is not legal advice, it creates no advisory relationship, and it should not be quoted in a dispute, a claim or a police report. If an account, your money or your identity is already affected, the people who can act are the provider's own recovery process, your bank, and the police or reporting body where you live.
- We cannot see your accounts or your devices. We cannot tell you whether a particular message you received is genuine, whether an account has been compromised, or what an organisation holds about you.
- We cannot act on your behalf. We cannot contact a platform, bank, regulator or data protection authority for you, and we cannot investigate anyone. Requests like that have to go to the provider directly.
- Menus move. Settings are renamed, moved and reset by updates. A click path that was accurate on the review date may look different in your version. Treat every step here as a description of what to look for rather than a guarantee of what you will see.
- We can be wrong. Errors get through. If you find one, the support page explains what happens next.
