DEWA89 home DEWA89 official siteOfficial site (opens in a new tab)
Guide 4 of 4 - Incident response

What to Do When an Account Is Compromised: A DEWA89 Guide

When someone else gets into your account, the order you do things in matters more than the individual steps. Change the password first and you may hand the new one straight to malware still running on your laptop. Change it but skip the session list, and the intruder stays signed in.

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.

Last reviewed 8 October 2026Free to read, no sign-upPart of the DEWA89 guides

Visit the official DEWA89 website (opens in a new tab)Opens the official DEWA89 website in a new tab.

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.

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:

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

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 checkWhy attackers use it
Mail forwarding address, and every filter or ruleA 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 numberWhoever 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 answersRewritten to something only the attacker knows, which turns the recovery flow against you.
Registered MFA methodsAn extra authenticator entry or phone number added beside yours, so the attacker also clears the second factor.
Aliases, delegated access, auto-reply, signature, account languageQuiet 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 addressesThe 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.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

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.

  1. Open a new account on a different address and secure it with a passkey or hardware key from day one.
  2. 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.
  3. 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.
  4. Tell your contacts that the old address is no longer yours and that anything arriving from it should be ignored.
  5. 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.

Back to top ↑

Sources checked for this page

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

Editorial standards we hold ourselves to

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 byDEWA89, an independent educational project written and paid for by Rehan Aldiansyah
Written byRehan 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 byRehan 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.
CorrectionsSend a correction — specific reports are checked against a primary source and fixed or answered
First published2026-10-08
Last reviewed2026-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.

dewa89official@gmail.com

One person, checking messages between other work. Reports that name the passage and the source they disagree with are answered fastest — the support page sets out exactly what to include, and what we cannot help with.

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.

Back to top ↑