Study guide
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis
TryHackMe Security Analyst Level 1 SAL1
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy
2 SOC Simulator Exam Skills
2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes
3 Network Essentials
3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission
4 Operating System Basics
4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity
5 Cryptography, Cloud, Web and Scripting Basics
5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs
6 Cybersecurity Fundamentals and MITRE ATT&CK
6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques
7 Kill Chain, NIST CSF, and Attack Indicators
7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain
8 Social Engineering and Network Attacks
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns
9 Web Exploitation and Endpoint Attacks
9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd
10 Command and Control, Malware, and LOLBAS
10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS
11 EDR, Firewalls, and WAF
11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation
12 SIEM and SOAR
12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration
13 Threat Intelligence and Vulnerability Scanning
13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning
14 SOC Team, Activities, and Alert Triage
14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts
15 SOC Metrics, Escalation, and Communication
15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis
Key Takeaways Explain This Topic AI
Header From is a display claim; Return-Path is the SMTP envelope bounce address that SPF evaluates before DMARC alignment is applied.
Typosquatting uses an attacker-owned lookalike domain that can SPF/DKIM/DMARC-pass; sender spoofing forges a domain the attacker does not control.
Authentication-Results is added by the receiving system; a copy that merely arrived from the public internet is not a signed verdict.
Windows chooses a file handler from the rightmost extension, so Invoice.pdf.exe is an executable lure, not a PDF.
Punycode hosts (xn--) and URL redirector query parameters must be decoded before you judge whether a link belongs to the brand.
Last updated: September 2026
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 ExamFinch 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.
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.
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.
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.
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.
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.
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.
Loading diagram... Email-threat lifecycle for analyst tickets
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.
Header Question it answers Analyst trap
From Whom does the client display as author? Display name is not a mailbox. Header From can be copied independently of the envelope.
Reply-To Where does a user reply go? A "CEO" message with Reply-To at a free-mail provider is a classic business email compromise (BEC) pattern even when From looks internal.
Return-Path Where should bounces go? Receivers write this from SMTP MAIL FROM. Envelope domain may differ from From. SPF is evaluated against the envelope domain and connecting IP, not against the pretty From, until DMARC alignment is applied.
Received Which servers touched the message? Added top-down, so the top hop is the last hop (your side). Attackers cannot rewrite the Received line your own mail exchanger (MX) added. Extra Received lines lower in the stack can be forged. Start from your MX and walk outward.
Message-ID What unique token did a sending system assign? Format often leaks the platform. A claimed on-premises Exchange sender with a consumer-webmail Message-ID is inconsistent. Message-ID can be forged; use it as a consistency check, not as proof.
Authentication-Results What did this receiving system conclude about SPF, DKIM, and DMARC? Your filter or secure-email gateway adds this header. Do not treat an Authentication-Results header that arrived from the public internet as a signed verdict.
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:
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.
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.
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.
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.
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.