IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Cheat sheet & pop quiz
This track showed how identity gets attacked, and the defense that wins each time. Here is the whole track as a cheat sheet and a lookup. Then five scenarios show it stuck.
If you remember nothing else…
| # | The attack, and the defense that beats it |
|---|---|
| 1 | Credential stuffing and password spraying: bots try leaked pairs, or one common password on many accounts. A lockout sees almost nothing. Use layers: MFA or a passkey, breached-password check, bot detection, limits by address, account and device, alerts across accounts. |
| 2 | Adversary-in-the-middle: a fake page passes on your login and your one-time code, live. Use phishing-resistant passkeys (WebAuthn). They are tied to the real origin and will not sign for a fake site. |
| 3 | MFA fatigue (push bombing): a flood of approval prompts until you tap "approve". Use number matching and a lockout after repeated denials. |
| 4 | Device-code phishing: you are talked into entering their code. Rule: never approve a code you did not start. Add short code lifetimes and device details on the approval screen. |
| 5 | Consent phishing: a rogue OAuth app asks for broad, lasting access. Use an admin-consent policy and least-privilege scopes. Revoke old grants. |
| 6 | Session hijacking: a stolen session cookie. Use HttpOnly, Secure and SameSite cookies and device binding (DBSC), so a stolen cookie is useless elsewhere. |
| 7 | Recovery attacks (SIM swap, fake help-desk calls): a taken-over phone number, a weak "forgot password" path, or a caller who talks the help desk into a reset. Drop SMS for recovery. Use phishing-resistant recovery (a second passkey, verified identity). Verify callers on a channel you choose. |
| 8 | Whatever still gets through: detect it. Look for impossible travel, bursts of MFA denials, consent to new apps, and a cookie on a new IP. Connect high-confidence detections to automatic revoke and step-up. |
| 9 | The incident itself: Detect, Triage, Contain, Eradicate, Recover, Learn. Contain before you clean. Always hunt the persistence left behind: an added passkey, recovery email or OAuth grant. |
Attack → the defense that wins
| The attacker used… | …and the defense that wins is |
|---|---|
| Credential stuffing or password spraying by bots | MFA or a passkey, a breached-password check, bot detection and alerts across accounts, because a lockout per account sees only one try (credential stuffing, password spraying and bots) |
| AiTM phishing to pass on your code | Phishing-resistant passkeys: origin-bound WebAuthn credentials that will not sign for the proxy (adversary-in-the-middle) |
| MFA fatigue: a storm of push prompts | Number matching and lockout: you must type the on-screen number, and repeated denials lock the prompt (MFA fatigue) |
| Device-code phishing: "enter this code" | Never approve a code you did not start, short code lifetimes, device context (device-code phishing) |
| Consent phishing: a rogue app grant | Admin-consent policy and least-privilege scopes, and revoke lasting grants (consent phishing) |
| Session hijacking: a stolen cookie | HttpOnly, Secure, SameSite and device binding, so the copy is useless (session hijacking) |
| SIM swap, a fake help-desk call or a weak recovery back door | Drop SMS; phishing-resistant recovery: a second passkey, verified re-enrollment; help-desk checks on a channel you choose, never knowledge questions (recovery attacks) |
| An unknown threat already in your logs | Detection and automatic revoke: score the signals, end the session, spread it with CAEP (detection engineering) |
Pop quiz: five questions
Q1 · Maya has MFA on, yet an attacker still got in. She typed her password and her one-time code on what looked like the real login page. What happened, and what one change stops it for good?
An adversary-in-the-middle phishing proxy passed both her password and her live code to the real site. A one-time code can be phished, because it is just a value you can hand over. The fix is a phishing-resistant passkey (WebAuthn). The credential is tied to the real origin, so it refuses to sign for the attacker's look-alike domain. There is nothing to pass on (adversary-in-the-middle).
Q2 · At 3 a.m. Priya's phone shows prompt after prompt to approve a sign-in. She is sleepy and wants to tap "approve" to make it stop. What is this, and which two controls defeat it?
It is MFA fatigue (push bombing). The attacker already has her password and sends prompts, hoping she gives in. Defeat it with number matching. She must type a number shown on the real sign-in screen, and she cannot see it because she never started a login. Add a lockout after repeated denials, so the flood stops itself. Priya should deny and report it (MFA fatigue).
Q3 · Sam gets a call: "This is IT. To finish your new device setup, type the code I am about to text you into your login page." He did not start any setup. What attack is this, and what rule stops it?
Device-code phishing. The attacker started a device-authorization flow and needs Sam to approve their code. So they talk him into entering it. The rule: never enter or approve a code you did not start yourself. No real flow needs you to read out a code to someone who called you. Short code lifetimes and a screen that names the requesting device help too (device-code phishing).
Q4 · Maya reset her password after a scare. Weeks later the attacker is reading her mail again, with no new phishing. Zara's tripwires saw no fresh sign-in. How did the attacker keep access, and what should the response have done?
The attacker planted persistence. Most likely it was a broad OAuth consent grant, or an added passkey or recovery email. These survive a password change, because a lasting token is not tied to the password. The response should have hunted for persistence in the Eradicate phase. That means revoking all OAuth grants and removing unknown recovery methods and passkeys, not only resetting the password. Prevent it earlier with an admin-consent policy and least-privilege scopes (consent phishing; the incident playbook).
Q5 · An attacker got a mobile carrier to move Priya's number to their SIM. Then they used "text me a recovery code" to take her account. What is the attack, and how do you close this door? Once it is clearly an incident, what is Zara's first move?
It is a SIM swap that abuses an SMS recovery back door. Recovery is only as strong as its weakest path, and SMS can be hijacked. Close the door by dropping SMS for recovery and using phishing-resistant recovery: a second enrolled passkey or verified re-enrollment. Once triage confirms it is real, Zara's first move is Contain. She revokes every session and refresh token and forces a new sign-in before she touches the password. Then she eradicates, which removes the recovery methods the attacker added. She also spreads the logout with CAEP. The same hole opens if a caller talks the help desk into moving the MFA. There the fix is to verify on a channel you choose, such as a push to the enrolled device (recovery attacks; the incident playbook).
That is the whole Attacks & Defenses track. You can now spot the main identity attacks and name the defense that beats each. You can catch the ones that slip through in the logs, and run an incident calmly at 2 a.m. Always use it to defend, never to attack. Put it to work in When things go wrong and Identity telemetry & SIEM. Next up is Customer Identity (CIAM): defending the accounts your customers own. Start at identity for your customers, not your staff.
Put it to the test. Browse our free security micro-tools at the tools shelf, or explore our services. Talk to our team when you are ready to design the real thing.