Open with a real, recent-flavor scenario: a student receives a text from '(628) 555-0134' saying 'Chase security alert: unusual sign-in at 2:14 AM. Confirm identity: https://chase.com.secure-login-verify.co/auth'. Ask cold-call: would you tap it? Take 2-3 fast answers, then reveal the trick — the real registrable domain is secure-login-verify.co, NOT chase.com. Everything to the LEFT of the last dot-word.dot-tld pair is just a label the attacker chose. Tell students: today they learn to read a URL the way an analyst reads it, to interpret what HTTPS and the padlock actually promise (spoiler: less than they think), and to build a repeatable verification workflow. Frame the stakes — the 2020 Twitter breach and countless payroll-diversion frauds started with a login page that looked correct.

1. 6m

   Anatomy of a URL — where ownership actually lives

   Content

   A URL has a fixed structure, and only ONE part identifies who owns the site: the registrable domain, which is the label immediately to the left of the top-level domain (TLD). Read a URL from right to left to find it. In https://accounts.google.com/signin?hl=en, the TLD is .com, the registrable domain is google.com, accounts is a subdomain Google chose, /signin is the path, and ?hl=en is a query string. The attacker's URL from the hook, https://chase.com.secure-login-verify.co/auth, has TLD .co, registrable domain secure-login-verify.co, and chase.com is merely a subdomain the attacker created — it proves nothing. Same logic exposes login-microsoft.com-security.ru (owner: com-security.ru) and appleid.apple.com.evil.tk (owner: evil.tk). The rule: find the TLD, take the label just before it, and that plus the TLD is who you are trusting. Everything else is decoration.

   Delivery

   Walk students through reading right-to-left three times with three different URLs — build the reflex. Ask 'who owns paypal-support.account-check.net?' and cold-call. The misconception to kill NOW: 'chase.com appears in the URL, so it's Chase.' Push back — a subdomain is a label the site owner picked and can be literally anything. Emphasize that the deck's URL anatomy diagram shows protocol, subdomain, registrable domain, TLD, and path as distinct zones — only the domain+TLD zone establishes identity.

2. 6m

   What HTTPS and the padlock actually prove (and don't)

   Content

   HTTPS means the connection to whatever server answered is encrypted and that server presented a valid TLS certificate for the domain in the address bar. A certificate authority (CA) — Let's Encrypt, DigiCert, Sectigo — issued that certificate after verifying the requester controls that domain, typically via a DNS or HTTP challenge. That is ALL a padlock guarantees. It does not vouch for the operator, the business, or the intent. Attackers routinely obtain valid Let's Encrypt certs for secure-login-verify.co, appleid-support.com, or any typo-domain within minutes and free of charge. As of 2023, over 80% of phishing sites tracked by the APWG served HTTPS. The correct mental model: HTTPS answers 'is my traffic private and going to the domain I typed?' — it never answers 'is that domain trustworthy?' To inspect: click the padlock → Connection is secure → Certificate is valid → view the Subject (domain the cert was issued for) and Issuer (which CA). Confirm the Subject exactly matches the registrable domain you expected. A cert issued to secure-login-verify.co is a perfectly valid cert — for the attacker.

   Delivery

   This is the single most persistent misconception in the unit, so name it explicitly: 'the padlock means safe' is wrong. Ask students to state, in one sentence, what HTTPS DOES promise vs. what it doesn't. Have them cite the ~80% phishing-HTTPS statistic — it makes the point stick. Targets Skill Category 1 Analyze Risk: students must reason about what a control actually mitigates vs. what it doesn't.

3. 5m

   Look-alike domain techniques attackers use

   Content

   Three families of deception dominate. Typosquatting swaps or adds characters that read past a hurried eye: paypa1.com (digit 1 for lowercase L), rnicrosoft.com (r+n for m), goog1e.com, amaz0n.com, netfliix.com. Combo-squatting appends legitimate-sounding words: apple-id-verify.com, microsoft-account-security.net, chase-secure-login.com — the brand appears, but the registrable domain is not the brand's. Homograph (IDN) attacks use non-Latin Unicode characters that render identically: аpple.com where the 'а' is Cyrillic U+0430, not Latin U+0061; modern browsers show Punycode (xn--pple-43d.com) for mixed-script domains, but pure-script fakes can still slip through. Deceptive subdomains stack the real brand as a label: paypal.com.verify-user.help — the brand sits harmlessly to the LEFT of the actual owner (verify-user.help). Detection heuristic: (1) find the registrable domain, (2) is it exactly the brand's known domain? (3) if not, it is not the brand — regardless of what else appears in the URL.

   Delivery

   Rapid-fire five URLs and have students shout the registrable domain. Point out that combo-squatting is now the most common form because typos are easy to spot but appended words feel plausible ('of course Chase would have a chase-secure-login page'). Head off the misconception that 'the brand name in the URL means the brand made it.'

4. 4m

   The verification workflow before you type a password

   Content

   Turn the concepts into a repeatable decision path. Step 1: did YOU navigate here, or did a link/email/QR bring you? If you were sent, treat the page as untrusted by default. Step 2: read the address bar right-to-left and confirm the registrable domain matches the service's known domain exactly. Step 3: click the padlock, open the certificate, confirm Subject equals the expected domain and Issuer is a known CA. Step 4: does your password manager autofill? Managers key on exact domain match, so a spoof at chase-secure.com will NOT trigger a fill saved for chase.com — treat non-autofill on a familiar site as a red flag. Step 5: check for visual tells: broken localization, low-resolution logo, missing footer links, no working 'forgot password,' odd form action URL in page source. Step 6: if any check fails, do NOT type credentials — close the tab and reach the site by typing the known URL or using a bookmark. This workflow is what an AP-level analyst does; it is also what you should do on your phone.

   Delivery

   Walk students through the 6-step flow once, then have them repeat steps 1-6 chorally. Emphasize step 4: many students think saved passwords will 'refuse' to fill on a fake — technically true for autofill, but they can still MANUALLY type the password on the spoofed page, which is exactly the attacker's plan. Targets Skill Category 2 Mitigate Risk (layered verification) and Skill Category 3 Detect Attacks (recognizing anomalies).

1. 28m

   Credential-Harvest Triage Lab: URL, Certificate, and VerdictLab

   Students work in pairs at a computer. They complete a three-part triage handout. Targets Skill Category 1 Analyze Risk (weighing evidence about a page's legitimacy), Skill Category 2 Mitigate Risk (applying the verification workflow as a control), and Skill Category 3 Detect Attacks (classifying pages as legitimate or spoofed from indicators). Circulate and check for common errors — especially students who mark a page 'legit' because the padlock is green. Time it as: Part 1 (8 min), Part 2 (10 min), Part 3 (10 min). Student handout: Part 1 — URL triage (8 min) For each URL below, identify the registrable domain and classify as LEGIT (belongs to the real brand) or SPOOF (does not). One-sentence justification citing the specific technique. - a) https://accounts.google.com/signin/v2/identifier?hl=en - b) https://accounts.google.com.security-check.co/signin - c) https://login.microsoftonline.com/common/oauth2/authorize - d) https://login-microsoft.com-security.ru/verify - e) https://www.paypa1.com/us/signin - f) https://appleid.apple.com/sign-in - g) https://appleid.apple.com.id-verify.help/ - h) https://chase-secure-login.net/auth - i) https://www.chase.com/personal/for-you/log-on - j) https://аpple.com/account (note: first character is Cyrillic а, U+0430) For each: Registrable domain: __________ · Verdict: LEGIT / SPOOF · Technique if spoof: ____________ Part 2 — Certificate inspection (10 min) Visit each URL in Chrome or Firefox. Click the padlock (or 'Not secure') → Connection is secure → Certificate is valid (Chrome) or More Information → View Certificate (Firefox). Record Subject (Common Name), Issuer Organization, and Valid-From/To dates. 1. https://www.google.com 2. https://badssl.com 3. https://expired.badssl.com — what warning appears? Why? 4. https://wrong.host.badssl.com — what warning appears? Why? 5. https://self-signed.badssl.com — what warning appears? Why? Then answer: A valid TLS certificate proves _________________________ but does NOT prove ___________________________.__ Part 3 — Scenario verdicts (10 min) For each scenario, apply the 6-step verification workflow. Give a verdict (SAFE TO SIGN IN / DO NOT SIGN IN) and cite the two strongest pieces of evidence. - Scenario A: You click a link in an email 'Your Netflix payment failed.' The page shows the Netflix logo, a padlock, and the URL netflix-billing-update.com/login. Certificate Subject: netflix-billing-update.com, Issuer: Let's Encrypt, issued 2 days ago. Your password manager does not autofill. - Scenario B: You type chase.com in the address bar. It redirects to https://secure.chase.com/web/auth/dashboard. Padlock present. Cert Subject: *.chase.com, Issuer: DigiCert. Password manager autofills your Chase credentials. - Scenario C: A QR code in a parking lot leads to https://pay.parking-city-sf.com. Padlock present. Cert Subject: pay.parking-city-sf.com, Issuer: Let's Encrypt, issued yesterday. City of SF's real domain is sfmta.com. Password manager has nothing saved. Example correct outputs (do not show students): - Part 1(b): Registrable domain security-check.co · SPOOF · deceptive subdomain stacking the real brand as a label. - Part 1(j): Registrable domain xn--pple-43d.com · SPOOF · homograph / IDN attack. - Part 3(A): DO NOT SIGN IN — registrable domain is netflix-billing-update.com, not netflix.com (combo-squatting); password manager did not autofill despite this being a 'known' service; valid HTTPS does not vouch for identity. - Part 3(C): DO NOT SIGN IN — real SF parking is sfmta.com, so parking-city-sf.com is a combo-squat; QR-initiated navigation means you did not choose the destination; padlock is meaningless here.

   Materials

   • Student workstation with Chrome or Firefox
   • Printed or digital handout (content below)
   • Access to https://badssl.com and the live sites listed below

   Example outputs

   • Part 1(d): Registrable domain com-security.ru — SPOOF — deceptive subdomain (login-microsoft is a subdomain, not the owner).
   • Part 2(3): expired.badssl.com — browser shows NET::ERR_CERT_DATE_INVALID because Valid-To is in the past; cert is untrusted even though it was legitimately issued.
   • Part 3(B): SAFE TO SIGN IN — registrable domain chase.com matches; wildcard cert *.chase.com issued by DigiCert covers secure.chase.com; password manager autofilled, confirming exact domain match.

1. A user receives an email and clicks a link that opens a page reading 'Sign in to your Microsoft account.' The address bar shows https://login.microsoftonline.com.session-auth.io/oauth2. The padlock is present; the certificate was issued to session-auth.io by Let's Encrypt yesterday. The layout is pixel-identical to Microsoft's real login page. Which statement best evaluates this page? (Targets Skill Category 3 Detect Attacks.) A) The page is legitimate because HTTPS and a valid certificate are present. B) The page is legitimate because the URL contains login.microsoftonline.com. C) The page is a spoof because the registrable domain is session-auth.io, not microsoft.com or microsoftonline.com; HTTPS only confirms encryption to that attacker-owned domain. D) The page is a spoof because Let's Encrypt certificates are not trusted by browsers.

   multiple choiceC. The registrable domain (label immediately left of the TLD) is session-auth.io — login.microsoftonline.com is only a subdomain the attacker chose. The valid Let's Encrypt cert proves control of session-auth.io, which is exactly what an attacker needs. A is the padlock misconception; B is the subdomain misconception; D is false — Let's Encrypt is a trusted CA.

2. In 2-3 sentences, explain why a saved password in a browser or password manager NOT autofilling on a familiar-looking login page is a strong indicator that the page may be spoofed, and describe one way an attacker still succeeds even though autofill did not trigger. (Targets Skill Category 1 Analyze Risk.)

   short answerPassword managers key their saved credentials to the exact registrable domain where the password was stored, so autofill will not fire on a look-alike domain like chase-secure-login.net even when the visual page looks identical to chase.com — the mismatch is a strong signal the domain is not the real one. However, the attacker still wins if the user manually types the username and password into the spoofed form, because the manager's silence is only a warning, not a block. A rigorous user treats missing autofill on a 'known' site as a stop signal and re-navigates via a bookmark or typed URL.

3. A junior analyst is asked to write a 6-step verification procedure that any employee must run BEFORE typing a password into any web login. Write the procedure as an ordered list, and for two of the steps, state which specific attack technique the step is designed to detect. (Targets Skill Category 2 Mitigate Risk.)

   short answer1. Confirm you navigated to the page yourself (typed URL or bookmark), not via an email, text, or QR code — detects phishing links and QR-based redirects. 2. Read the URL right-to-left and verify the registrable domain exactly matches the service's known domain — detects typosquatting, combo-squatting, and deceptive-subdomain attacks. 3. Click the padlock and confirm the certificate Subject matches the expected domain and Issuer is a recognized CA — detects wrong-host and self-signed certs. 4. Confirm your password manager autofills on this page; if it does not on a familiar site, treat it as a red flag — detects look-alike domains that fool the eye but not the manager's exact-match logic. 5. Scan for visual anomalies: logo resolution, broken links, unusual form action, missing localization — detects hastily cloned pages. 6. If any step fails, close the tab and reach the site by typed URL or bookmark; never sign in from the suspect page.

• ☐One computer per pair with Chrome or Firefox and internet access
• ☐Printed handout with Parts 1-3 (or digital copy in LMS)
• ☐Whiteboard for right-to-left URL parsing during instruction
• ☐Instructor answer key for the triage lab
• ☐Projector for the auto-generated slide deck