Module 17 — Phishing, social engineering, and insider risk¶

Why it matters to a software engineer¶

Every technical control in this course — MFA, object authorization, egress allowlists, detection rules — assumes an attacker starts from outside with no valid credential. In most real breaches that assumption is false on day one: the attacker starts with Alice's password because Alice typed it into a fake page, or the "attacker" is a legitimately authenticated employee misusing access they were actually granted. It changes how you read every detection in this course, so it belongs here rather than being skipped.

Like Modules 14–15, this is a paper lab on alerts you already have, not a new container — there is no email-phishing simulator in this repo (a scope choice, not a claim that a local fake login page is impossible).

Visual overview¶

sequenceDiagram
  participant Alice
  participant Fake as Fake login page
  participant Attacker
  participant API as Notes API
  Alice->>Fake: real password + real MFA approval
  Fake-->>Attacker: relayed credential + session
  Attacker->>API: request using Alice's session
  Note over API: authenticates as Alice — correctly

Intuition

Every arrow after "Fake-->>Attacker" is indistinguishable, at the API, from Alice using her own account. This is why Module 3's "a valid token is input to authorization, not proof of permission" line matters so much here: authentication succeeding is not evidence the request reflects what Alice intended.

Scenario	Access was	Detected by	Fixed by
Phishing	Illegitimate grant; the resulting session is valid	Unusual source/pattern for a known identity	Credential rotation, phishing-resistant MFA
Insider misuse	Legitimately authorized	Access with no business justification	Least privilege (technical blast-radius cap) plus audit review (operational)

Hint

The same alert can be either row of that table. Keep both hypotheses open (Module 11) until evidence — not the alert — tells you which one you're in; picking the wrong response (rotating a credential that was never stolen, or missing an insider because "the login looked normal") wastes the response window.

Learning objectives¶

Distinguish phishing (credential/access theft via deception) from insider risk (misuse of access someone was legitimately granted).
Explain why technical controls change where the attack starts, not whether the human/organizational layer can be attacked.
Read DET-001 and DET-004 as evidence of two different human-factor scenarios, not just two different technique IDs.
Name the controls that work when the attacker already holds a valid credential.

Key concepts¶

Phishing changes the starting point, not the rest of the kill chain. Once Alice's password is phished, everything downstream — login, token issuance, object access — proceeds exactly as it would for Alice herself (see the intuition note above on why that's Module 3's authn/authz split in practice).

Insider risk is not a technical vulnerability. DET-004 (broken function-level authorization: a non-admin calling an admin endpoint) is a missing-control story. A true insider incident looks different: a legitimately admin-privileged account doing something within its technical permissions but outside its business justification — reading every customer's notes with no ticket, no case, no reason. No authorization check catches that, because the access was authorized. Only audit review, least privilege, and anomaly detection on legitimate access patterns catch it.

The two responses diverge sharply. For the same unusual burst of note reads: phishing calls for rotating the credential and reviewing scope of compromise; insider misuse calls for HR/legal process, not a token rotation. The SOC (Module 10) picks the wrong one if it responds to the alert instead of to the hypothesis the evidence actually supports.

MFA and phishing-resistance are not the same property. Any MFA raises the cost of a phished password alone. Phishing-resistant MFA (passkeys, hardware security keys using WebAuthn) specifically defeats real-time credential-relay phishing, where the attacker proxies the login in real time including the MFA prompt. A one-time code can still be relayed; a hardware-bound key cannot.

Least privilege is the only control that limits insider blast radius. You cannot detect your way out of a legitimately authorized action. The only thing that bounds the damage of a trusted actor going wrong is how much that actor was trusted with in the first place — which is Module 1's "residual risk" idea applied to your own team, not just to attackers.

Architecture connection¶

Add "the human holding a valid credential" as an explicit actor in your Module 1 trust-boundary diagram, distinct from "the untrusted internet." Every box that trusts a token implicitly trusts whoever is currently holding it. Design reviews that only ask "is this endpoint authenticated" and never ask "what if the authenticated caller's intent is wrong" are missing this actor entirely.

Hands-on lab — read two identical-looking alerts, two different ways¶

No new containers; this reuses alerts you can already generate.

Prerequisites¶

make lab-up; alerts exist from Module 9/11 (simulate + ingest, or python3 labs/attack-sim/simulate.py --scenario all).

Before you run this¶

Predict: (1) which evidence appears (2) which does not (3) why.

Then run the steps. Compare with the prediction. If the result differs, which assumption was wrong?

Steps¶

Pull DET-001 (password guessing) and DET-004 (broken function-level authorization) alerts from soc-lite.
For DET-001, write two competing incident narratives from the same evidence: (a) an external attacker guessing Alice's password, (b) Alice herself, having forgotten her password, retrying it — and note what additional evidence (source IP reputation, geographic distance between attempts, time-of-day pattern) would let you tell them apart.
For DET-004, write two competing narratives that can actually produce that event (broken_function_authz fires only when role != admin): (a) a bug lets Alice’s non-admin token reach /admin/users, (b) Alice’s non-admin token was stolen (phished session) and the attacker is probing admin routes. A phished admin would list users without this alert — that is a third story, for a different event. Note that the technical fix (function-level check) is the same for (a) and (b), but the incident response is not — (b) requires credential rotation and scope review; (a) does not.
State, for each narrative, one control that would have prevented it regardless of which story is true (hint: rate limiting from Module 16 helps DET-001 either way; least privilege helps DET-004's insider variant even when the authorization bug is also fixed).

Expected observations¶

Two short written narratives per alert, each naming the specific additional evidence that would resolve the ambiguity, and one "works regardless of which story is true" control per alert.

Security lessons¶

An alert is evidence, not a verdict. The same event stream is compatible with an external attacker, a confused legitimate user, and a misbehaving insider; good incident response keeps competing hypotheses open (Module 11) specifically because the human-factor layer cannot be ruled out by log data alone.

Common mistakes¶

Assuming every alert implies an external attacker, which biases the response toward "block an IP" and away from "review who actually holds this credential right now."
Treating "insider threat" as a monitoring product to buy instead of a least-privilege and process question.
Recommending security-awareness training as if it were a complete control. It reduces phishing susceptibility; it does not replace phishing-resistant MFA or least privilege, the same way "code review" does not replace parameterized queries.

Cleanup¶

make lab-down.

Knowledge check¶

Why does successful authentication tell you nothing about whether a request reflects the account holder's intent?
Why is a one-time code weaker than a hardware key against phishing, even though both are "MFA"?
What distinguishes a phishing incident from an insider incident when the technical evidence looks the same?
What is the only control that bounds the damage of a legitimately authorized actor?
Why should an alert like DET-004 keep two competing narratives open during triage?

Answers: (1) Authentication proves identity, not intent — the same "valid token is not proof of permission" idea from Module 3, applied to the human holding the token. (2) A one-time code can be relayed in real time by a proxying attacker; a hardware key's response is bound to the origin and cannot be relayed. (3) Whether the grant was legitimate — phishing produces a valid session from an illegitimate grant; insider misuse abuses access that was actually given. Telemetry of a successful login looks the same. (4) Least privilege — how much authority that actor holds if they go wrong. (5) Because the response differs (credential rotation and scope review vs. an authorization bug fix), and picking the wrong one wastes the response window without addressing the real cause.

Engineering assignment¶

Write a one-page policy answering: which of your team's accounts or service identities would cause the most damage if phished, and which would cause the most damage if legitimately misused by their holder? They are not always the same account. Name one control for each.

Self-check¶

Answer before expanding. These are the assessment moves on this module's Acme Notes lab, not trivia.

Explain: Why does a successful login_success not prove the account holder's intent?

Authentication proves identity of the credential, not who meant to use it. Same Module 3 split: valid token is not permission, and it is not intent either.

Predict: DET-001 vs a phished-then-used password — what looks the same, what does not?

Guessing is a login_failure burst. A phished password produces a boring login_success and then Alice-shaped traffic. MFA-OTP can still be relayed; a hardware key bound to origin cannot.

Diagnose: DET-004 (non-admin hit /admin/users). Why keep two narratives open?

Missing function AuthZ vs a legitimately privileged insider on an admin account. Responses diverge: fix the check / rotate a stolen session vs HR/legal and least privilege. Picking from the alert name wastes the window.

Design: Which control bounds a true insider who is allowed to read notes?

Least privilege and process (tickets, dual control), plus anomaly review of authorized access. No authorization check catches a permitted bulk read. Awareness training does not replace that.

Defend: Residual risk after phishing-resistant MFA on Alice.

Stolen session cookies, malware on the device, and insider misuse of access that was actually granted. Containment for phishing is rotate and review scope; for insider it is not a token rotation.

Before you leave¶

Predict — write two competing narratives before you open DET-001 and DET-004.
Diagnose — name whether the grant was legitimate, from evidence you actually have.
Build — complete the competing-narrative writeup (phishing vs insider) on those two alerts.
Defend — state containment and residual risk in one sentence each.
Exit criteria — the course pass bar: Explain → Predict → Diagnose → Design → Defend.