8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis

8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis

Phishing is social engineering delivered as a message that looks like it belongs in a business mailbox. For Security Analyst Level 1 (SAL1) study, treat phishing as an investigation problem rather than a gut feeling: who appears to have sent the message, who actually handed it to the mail system, where a click would go, and what would happen if a recipient opened the attachment. This chapter is independent OpenExamPrep study material covering SAL1 Social Engineering and Network Attacks topics. It is not an official TryHackMe publication and does not claim partnership, review, or approval.

Why email is still a reliable delivery path

Simple Mail Transfer Protocol (SMTP) was designed to move text between cooperative servers. Identity was an honor system. Later controls — Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) — add Domain Name System (DNS) and cryptographic checks, but they authenticate domains the sending infrastructure is allowed to use, not the human story in the body. Users still see a display name, a logo in HyperText Markup Language (HTML), and a sense of urgency. Attackers live in that gap.

Email remains attractive because it crosses organizational boundaries without a virtual private network (VPN), because finance and information technology already send unexpected messages, and because a single successful click can yield a password, a session cookie, or a foothold that later looks like ordinary HTTPS. TryHackMe's SAL1 training content groups this work under Social Engineering: attack lifecycle, email vulnerabilities, and detection — including impersonation, typo-squatting, and sender spoofing — before SPF, DKIM, DMARC, and header analysis. This section teaches the lifecycle and the header craft; section 8.2 teaches what the authentication protocols actually prove.

The email-threat attack lifecycle

Analysts describe phishing as a short lifecycle that sits inside ordinary mail flow. Mapping a ticket onto the lifecycle tells you what evidence should exist and what to tell responders.

1. Reconnaissance. The attacker collects names, job titles, vendors, ticket formats, and public mail patterns. Company websites, social networks, and previous breach dumps supply the pretext. You will not always see this stage in logs. You infer it when the lure uses an internal project name the public should not know — or, conversely, when the lure is generic because recon was shallow.
2. Pretext and lure. The message needs a reason to act now: an overdue invoice, a password expiry, a shipment exception, a benefits window, or a shared document. Urgency plus a familiar process beats crude spelling errors.
3. Delivery. The lure arrives as email (the SAL1 header-analysis path), SMS (smishing), voice (vishing), or a paste in chat. SMTP leaves headers. Chat often does not.
4. User action. The victim clicks a link, opens an attachment, replies with data, or approves a payment change. This is the step that turns a delivered message into an incident.
5. Collection or execution. Credentials post to a lookalike portal, a payload runs, or a finance conversation is hijacked. From here the case may become account takeover, mailbox-rule persistence, or ransomware staging.
6. Follow-through. Attackers often send a second wave from the stolen mailbox because internal mail is trusted. Record that expansion path in the ticket.

The lifecycle matters because a security operations center (SOC) queue is not "this is phishing, close it." You record where the chain broke and which artifacts — sender domain, URL, attachment hash, Reply-To — become indicators of compromise (IoCs).

Impersonation versus typosquatting versus sender spoofing

These tactics are related. They fail different checks.

Display-name impersonation abuses the human-readable name beside the address. A client can show IT Help Desk while the mailbox is no-reply@randommail.example. Many mobile previews show only the display name. The SMTP address may be a throwaway domain or a free webmail account registered in minutes.

Typosquatting (SAL1 training content uses the spelling typo-squatting) registers a lookalike domain: rnicrosoft.example (the letters r and n), northwind-support.example, n0rthwind.example, or a hyphenated cousin of a brand. The SMTP conversation can be technically honest: the attacker owns that domain, can publish SPF, can sign DKIM, and can set a DMARC policy. Authentication may pass. The deception is visual similarity, not a forged envelope for the real brand.

Sender spoofing forges the visible From — and sometimes the envelope sender — so the message claims to come from a domain the attacker does not control. Spoofing is still practical when the real domain has no SPF, DKIM, or DMARC, when a downstream system displays From without honoring Authentication-Results, or when a lookalike Unicode character fools a person even though the ASCII domain is different. Spoofing is a claim about identity. Typosquatting is a claim about domain ownership. Impersonation can ride on either.

Triage rule: if Authentication-Results shows pass for a domain that is one character off the real brand, treat it as a lookalike, not as proof that the brand sent the mail. If the From domain is the real brand but DMARC fails and Return-Path points elsewhere, treat it as spoofing — or as a forwarding break that you must explain before you declare malice.

Header fields that decide identity

Email clients hide evidence. Analysts open full headers. Each field answers a different question. RFC 5321 describes the SMTP envelope (MAIL FROM, RCPT TO). RFC 5322 describes header fields the client shows. They are not required to match.

Worked example: invented invoice lure

The sample below is fictional. It is not a real person's mail. Addresses, IPs, and identifiers are teaching placeholders in documentation ranges.

Return-Path: <billing@paymnts-contoso.example>
Received: from mx.northwind.example ([192.0.2.10]) by mail.northwind.example with ESMTPS id x7k; Fri, 18 Sep 2026 09:14:02 -0700
Received: from outgoing.mailhost-77.example ([203.0.113.77]) by mx.northwind.example with ESMTPS id q2p; Fri, 18 Sep 2026 09:13:58 -0700
Authentication-Results: mx.northwind.example;
    spf=pass smtp.mailfrom=paymnts-contoso.example;
    dkim=pass header.d=paymnts-contoso.example;
    dmarc=pass header.from=paymnts-contoso.example
From: "Contoso Accounts Payable" <ap@paymnts-contoso.example>
Reply-To: payments@paymnts-contoso.example
Message-ID: <20260918.7712.notexchange@smtp.mailhost-77.example>
Subject: Invoice 88421 overdue — remit today

Walk the fields in investigation order:

1. Header From versus ownership. The display name claims Contoso Accounts Payable, but the raw From, DKIM signer, and envelope all use paymnts-contoso.example — a hyphenated lookalike, not Contoso's domain. Some clients emphasize the friendly name and visually de-emphasize the address.
2. Pass is not safe. Authentication-Results says pass for paymnts-contoso.example. That only proves the sending hosts were authorized for the lookalike the attacker registered. It does not prove Contoso sent the message. Section 8.2 expands this trap.
3. Reply-To diversion. A finance user who clicks Reply writes to payments@paymnts-contoso.example, not Contoso. In BEC, the conversation is the payload; malware is optional.
4. Received chain. The top Received hop is the organisation's own MX (mx.northwind.example at 192.0.2.10, a documentation address). The previous hop is an unrelated outbound cluster. No Contoso mail gateway appears in the path.
5. Message-ID. The right-hand side names the attacker mail host and does not resemble a typical Exchange identifier. That is inconsistent with a claimed Contoso enterprise notification.

Verdict: an authenticated typosquatted domain plus display-name impersonation, not a spoofed header From for Contoso's real domain. A junior analyst who stops at "DMARC pass equals deliver" will miss the case.

If this same lure had header.from=contoso.com with dmarc=fail and spf=fail, the story would flip toward spoofing of the real brand — or toward a legitimate forwarder that broke authentication. You confirm the second possibility by checking whether Contoso publishes a strict DMARC policy and whether the path includes a known forwarding service.

A ticket note for this worked sample should quote raw fields, not the preview pane: From: ap@paymnts-contoso.example; envelope/header.d: paymnts-contoso.example; Reply-To: payments@paymnts-contoso.example; last hop mx.northwind.example. Recommend: do not click, do not reply, hold the invoice, and hunt the lookalike domain in the rest of the mail queue.

Double-extension attachments

Microsoft Windows can hide known extensions when folder options conceal them. A file named Invoice_88421.pdf.exe then appears as Invoice_88421.pdf. That is a double-extension lure. Related names include Invoice.pdf.lnk, Invoice.pdf.iso, Invoice.pdf.js, and Invoice.pdf.scr. The operating system chooses a handler from the rightmost extension.

Analyst checks:

• Read the filename from the mail gateway, sandbox, or ticket artifact — not from a cropped screenshot of File Explorer.
• Compare the MIME Content-Type declared in the message with the true file type after sandbox inspection (magic bytes). A claimed PDF whose type is a Windows executable is a mismatch.
• Treat nested archives (invoice.zip containing invoice.pdf.exe) as the same problem one layer down.
• Macro-enabled Office files (invoice.docm, invoice.xlsm) are not double extensions, but they are the same decision point: the lure asks the user to enable content.

Do not open suspicious attachments on an analyst workstation. Record the original name, hash the object in a controlled pipeline, and let a sandbox report behavior. The detection technique is mismatch-finding: name versus type versus what the user was told they received.

URL parsing at analyst level

Phishing links are parsed, not clicked on a production browser. Split a Uniform Resource Locator (URL) into scheme, host, path, query, and fragment. The registrable host is the identity. Pretty path words such as /paypal/login are decoration.

Homograph and Punycode. Browsers encode internationalized domain names as Punycode with an xn-- prefix. A host such as xn--pypal-4ve.example is not paypal.com. Copy the URL from headers, a secure-email rewrite log, or a sandbox, decode it, and compare the registrable domain to the brand. Do not trust a favicon.

Redirectors. Marketing wrappers and open redirects hide the destination: https://links.vendor.example/click?u=https%3A%2F%2Fportal-contoso.example%2Fowa. URL-decode the query, then evaluate the final host, not the first trusted brand in the path. Multi-hop chains (enterprise link wrapper, then open redirect, then credential kit) are common. Sandbox click-through reports list hops. Some SIEM URL logs store only the first hop, which is why "it went to a Microsoft rewriter" is an incomplete finding.

Credential-kit tells. Paths that imitate /owa/auth, /sso/saml, or a vendor login on a domain that is not the identity provider, plus a domain registered this week, are portal clones.

IP literals and odd ports. http://203.0.113.50:8080/login is rarely a bank. Record the port; it becomes a firewall hunt.

Detection is a stack: header identity, domain age, decoded URL, attachment type mismatch, and the reporter's story. No single field closes a phishing case. The next section explains what SPF, DKIM, and DMARC actually prove — and why they still miss lookalikes.