The quickest way to learn cybersecurity basics is to follow one attack from start to finish, and account takeover is the best one to pick: an attacker gets hold of someone’s login, gets past whatever protects it, and uses the account as if it were theirs. Almost every core security idea (authentication, MFA, phishing, logging, detection, incident response) shows up along the way.
This guide walks through how account takeovers work technically, what defenders and SOC analysts see in the logs, how they respond, and what you can practise as a beginner. There is also a short section on protecting your own phone, WhatsApp and bank accounts, because the same mechanics apply.
Legal note: every example here uses our own lab or a fictional company, Acme Fintech (acme-fintech.test). Only test systems you own or have written permission to test.
What is an account takeover?
An account takeover (ATO) is when someone other than the owner gains control of an account and uses it. The account might be an email inbox, a WhatsApp number, a bank app, a social media profile or a company’s cloud login. In MITRE’s ATT&CK knowledge base, using a stolen login is catalogued as Valid Accounts (T1078), and it is attractive to attackers for a simple reason: once they are logged in, their activity looks like a normal user’s.
Most takeovers follow three stages. Learn these and you understand the attack, the defences and the job of the analyst who catches it.
- Get the credential. The password, the one-time code, or the session itself.
- Get past the second check. MFA, device checks, or the account’s recovery process.
- Use the account and hold on to it. Fraud, data theft, messaging your contacts, and changing settings so the owner cannot get back in.
Stage 1: how attackers get the credential
Phishing
The attacker sends a message (email, SMS, WhatsApp, social media DM) that leads to a fake login page. You type your password into what looks like the real site, and it goes to the attacker. This is Phishing (T1566) in ATT&CK. We take real-looking examples apart in phishing email examples: what a SOC analyst looks for.
Credential stuffing and password spraying
When a website is breached, its usernames and passwords often end up in circulation. In credential stuffing, attackers take those pairs and try them on other sites, betting that people reuse passwords. In password spraying, they try one or two very common passwords against many accounts, staying under lockout limits. Both are sub-techniques of Brute Force (T1110).
Tricking people into reading out codes
Many services send a one-time code by SMS to confirm a login or register a device. Attackers impersonate a friend, a bank or a delivery company and persuade the victim to read the code back. This is the trick behind the common messaging-app hijack: the attacker starts registering the victim’s number on their own phone, the real owner receives the code, and the attacker talks them into sharing it. We explain how the WhatsApp version works and how to stop it in WhatsApp account takeover explained.
SIM swap
If the attacker can persuade or bribe someone at a mobile network to move the victim’s number to a new SIM, every SMS code goes to the attacker. ATT&CK’s mobile matrix lists this as SIM Card Swap (T1451). The victim’s first clue is usually that their phone suddenly has no signal.
Malware that steals saved logins and cookies
“Infostealer” malware, often hidden in cracked software or fake installers, copies saved browser passwords and session cookies from an infected computer.
Stage 2: how attackers get past MFA
MFA defeats an attacker who only has your password, which is exactly why attackers have developed ways around the weaker forms of it.
| Bypass | How it works | ATT&CK reference |
|---|---|---|
| MFA fatigue | Trigger push notifications again and again until the user taps “Approve” to make them stop | T1621 |
| Adversary-in-the-middle phishing | A proxy phishing page passes your password and your MFA code to the real site in real time, then keeps the session | T1557 |
| Session cookie theft | Steal the cookie that says “already logged in”, so no password or MFA is needed at all | T1539 |
| Recovery abuse | Use a weak “forgot password” flow, an old recovery email, or a SIM swap to reset the account | (varies) |
This is why defenders increasingly prefer phishing-resistant authentication, such as passkeys and security keys. These bind the login to the real website’s domain, so a fake site cannot capture something reusable. NIST’s digital identity guidelines, SP 800-63B, describe phishing resistance as a property of the authenticator and are a good primary source for how modern authentication should work. We compare the options in passwords, passkeys and MFA explained.
Stage 3: what attackers do once they are in
- Fraud: move money, request payment from contacts, change bank details on invoices.
- Spread: message the victim’s contacts with the same scam, which is far more convincing from a trusted name.
- Persist: add their own MFA device, change the recovery email or phone, create email forwarding rules, register a new device.
- Hide: delete the security alert emails, or set rules that move them to an obscure folder.
For a defender, persistence changes are gold. Real users rarely add a new MFA device, change their recovery email and create a forwarding rule within ten minutes of a login from a new country.
How do defenders detect account takeover?
SOC analysts rely on logs: records of sign-ins, MFA events, configuration changes and messages. Here are the patterns they look for, and the log source that shows each one.
| Signal | What it might mean | Where an analyst sees it |
|---|---|---|
| Many failed logins across many accounts from one source | Password spraying | Identity provider sign-in logs |
| Many failed logins for one account | Brute force or a forgetful user | Sign-in logs, account lockout events |
| A success after a run of failures from the same source | A sprayed password worked | Sign-in logs |
| Many MFA push requests, then an approval | MFA fatigue | MFA / identity logs |
| Same session used from two distant locations | Stolen session cookie | Sign-in and session logs |
| New MFA method, recovery change or forwarding rule soon after an unusual login | Attacker persistence | Audit logs, mailbox audit logs |
| User reports “my phone has no signal” plus password reset emails | Possible SIM swap | Help desk tickets, account change logs |
A worked example from our lab
Here is a small extract from a lab export of sign-in events for Acme Fintech, as CSV: time, account, source IP, result. (The IPs use documentation and private ranges; the accounts are fictional.)
$ head -4 signins.csv
2026-10-09T02:14:00Z,finance01@acme-fintech.test,203.0.113.45,failure
2026-10-09T02:14:04Z,finance02@acme-fintech.test,203.0.113.45,failure
2026-10-09T02:14:08Z,ops01@acme-fintech.test,203.0.113.45,failure
2026-10-09T02:14:12Z,ops02@acme-fintech.test,203.0.113.45,failure
Count failures by source IP:
$ grep “,failure$” signins.csv | cut -d, -f3 | sort | uniq -c | sort -rn
12 203.0.113.45
1 192.168.10.31
How many different accounts did that IP try?
$ grep “203.0.113.45,failure” signins.csv | cut -d, -f2 | sort -u | wc -l
12
Twelve failures across twelve different accounts, four seconds apart, at 2am: one attempt per account. That is the fingerprint of password spraying, not a user who forgot their password (that is the single failure from 192.168.10.31, an internal address, followed by a success). Now the critical question: did any attempt succeed?
$ grep “203.0.113.45.*success” signins.csv
2026-10-09T02:15:02Z,treasury02@acme-fintech.test,203.0.113.45,success
One did. That account is now the incident. In a real SOC the same logic would run as a SIEM query or detection rule rather than grep, but the reasoning is identical, and practising it with command-line tools is how many analysts first learn it.
How do defenders respond to a takeover?
Incident response follows a familiar sequence. For the compromised treasury02 account in the example:
- Contain: disable the account or force a sign-out of all sessions, revoke tokens, and reset the password. Ending the attacker’s session matters as much as changing the password.
- Scope: what did the attacker do after 02:15? Check audit logs for new MFA devices, recovery changes, mailbox rules, file downloads and payments. Check whether 203.0.113.45 succeeded anywhere else.
- Eradicate: remove anything the attacker added, such as MFA methods, forwarding rules and app consents.
- Recover: restore access for the real user with strong, ideally phishing-resistant, MFA.
- Improve: block the source, tune the detection so a spraying pattern alerts in real time, and ask why a guessable password was possible. That might lead to a banned-password list or a move to passkeys.
The NCSC’s guidance on recovering a hacked account covers the same steps from the individual’s side, and it is worth comparing the two views.
Protecting your own phone, WhatsApp and bank accounts
The defences that stop attackers at work also protect you personally. The short list:
- Use a password manager and unique passwords everywhere. That alone defeats credential stuffing.
- Turn on two-step verification in WhatsApp (Settings > Account > Two-step verification) and set the PIN or password it asks for; follow what your app shows, and add a recovery email if offered. An attacker who tricks you into sharing an SMS code still needs that PIN or password. See WhatsApp’s help page for the current steps.
- Never share one-time codes or PINs, with anyone, for any reason. Legitimate banks and services do not ask for them.
- Prefer passkeys or an authenticator app over SMS codes where the service offers them.
- Lock your phone with a strong PIN or biometrics, keep it updated, and install apps only from official stores.
- Ask your mobile network what protections it offers against SIM swaps, and act fast if your phone loses signal unexpectedly.
- Check your accounts' security pages for unknown devices, sessions and recovery details every few months.
If you want to check a suspicious link before trusting it, our beginner’s workflow on how to analyse a phishing link safely shows how analysts do it without clicking.
What can a beginner practise?
You can build real, job-relevant skill from this one topic:
- Recreate the log analysis. Build a CSV of fake sign-in events (normal logins, a spraying run, one success) and find the attack with
grep,cut,sortanduniq, as above. Then do the same in a spreadsheet, and later in a free SIEM in your home lab. - Map an attack to ATT&CK. Take a public, well-documented account takeover write-up and list each step with its technique ID.
- Write a mini incident report for the Acme Fintech example: timeline, impact, containment steps, recommendations. Clear writing is half the SOC job.
- Review the sign-in and security activity history in your own accounts and see what events your email provider records.
- Read the NCSC and NIST guidance linked above and note where they agree.
Each of those is a portfolio piece. If the career side interests you, our roadmap on how to get into cybersecurity with no experience shows where this fits, and if you are wondering whether you can cope with the technical side, read is cybersecurity hard to learn?