Learning Objectives

By the end of this module, you will be able to:

1. Name and describe how each of the 28 threat categories in this taxonomy actually works, in enough technical detail to explain it to a customer accurately.
2. For any given threat category, identify the concrete indicators and the specific evidence to collect — not a generic "investigate further."
3. Apply safe investigation practices (Module 11) to every category without exception, including categories that seem low-risk.
4. Distinguish categories that are primarily a nuisance/hygiene issue (spam, graymail) from categories that are potential security incidents (BEC, account takeover, ransomware) and apply the correct escalation threshold to each.
5. Correctly separate a false positive from a false negative and know the distinct handling path for each.
6. Never claim a security control provides complete protection, for any category.

Key Terminology

Indicator of compromise (IOC)

A specific, observable artifact — IP, domain, hash, URL, header pattern — associated with malicious activity.

Social engineering

Manipulating a human, not a technical system, into taking an action: clicking, replying, transferring funds, disclosing credentials.

Payload

The actual malicious component of an attack — a link, an attachment, or embedded content — as distinct from the delivery/lure mechanism around it.

Time-of-click

Evaluating a URL's safety at the moment a recipient clicks it, rather than only at the moment the message was originally scanned, because a benign-at-delivery URL can be weaponized afterward.

False positive (FP)

A legitimate message incorrectly flagged, blocked, or quarantined as a threat.

False negative (FN)

A malicious message incorrectly allowed through as safe.

Lesson

This module is the working vocabulary of security investigation. Every threat entry below follows a fixed, repeating structure — how the attack works, common indicators, evidence to collect, typical detection methods, product controls that may apply, safe investigation practices, containment and remediation, customer communication, and escalation thresholds — so that once the pattern is familiar, you can pattern-match a new category quickly instead of relearning a format each time. Entries that build directly on Module 4's authentication mechanics (display-name spoofing, domain spoofing, lookalike domains) are intentionally concise here and cross-reference back rather than repeating that mechanics content in full.

Before the individual entries, two reference tools: a map of how the 28 categories cluster together, and a quick-reference table of escalation triggers across all of them. Use the map to build a mental model of the whole taxonomy before you start memorizing individual categories — most engineers find it easier to place a new category into a familiar cluster than to hold 28 unrelated items in memory.

One thread runs through a large share of this taxonomy and is worth naming before you read the individual entries: passing authentication (SPF/DKIM/DMARC) does not mean a message is safe. Module 4 introduced this as a mechanics lesson; here it becomes a recurring investigative trap. At least seven categories below — BEC (9.4), Account Takeover (9.5), Conversation Hijacking (9.17), Display-Name Spoofing (9.19), Domain Spoofing (9.20), Executive/Employee Impersonation (9.22), and Supply-Chain Compromise (9.23) — can present entirely clean authentication results while still being actively malicious, because in each of them the sending identity truly is legitimate (a genuinely compromised account, a genuinely unrelated but authenticated domain, a genuinely trusted vendor whose own systems were breached). Watch for this pattern as you read; it is the single highest-value error to catch in your own investigative habits, and in Module 17 it is the most common root cause behind tickets that were under-escalated.

9.1 Spam and Bulk Mail

Spam is unsolicited bulk commercial mail sent to many recipients without a pre-existing relationship, or without meeting applicable opt-in requirements. It is the least severe category in this taxonomy — a hygiene and customer-satisfaction issue rather than a security incident — but it is also the category customers report most often, so getting your handling of it right matters for ticket volume even though the individual risk is low.

Common indicators include high similarity in recipient counts across many unrelated customers, generic or templated content, recognizable bulk-sending infrastructure signatures, and an absence of any real personalization beyond a mail-merge field.

Evidence to collect: the message headers, the sending IP and domain, and the volume pattern if it's available to you.

Detection here typically relies on sender-reputation scoring, volume and pattern heuristics, and content signatures (Module 10) rather than deep content analysis — spam filtering is fundamentally a probabilistic classification problem, not a binary determination, which is exactly why an occasional legitimate sender will get mis-scored.

This is a low-risk category: standard header review is normally sufficient, and no special handling beyond Module 11's baseline protocol is required. When you talk to a customer about it, explain plainly that filtering is probabilistic, not absolute, and offer to review any specific sender they believe was misclassified. Escalate only if the volume pattern itself suggests a filtering-system malfunction (Module 15) rather than an individual sender's classification — a spike affecting many unrelated customers at once is a different problem from one customer's one mis-scored sender.

9.2 Phishing

Phishing impersonates a trusted entity — a bank, a well-known brand, an internal system — to induce the recipient to disclose information, click a malicious link, or take some other harmful action, typically at broad, untargeted scale. It's the category most people mean when they say "phishing" generically, which is exactly why this module insists on more precise terminology: spear phishing (9.3), BEC (9.4), and callback phishing (9.15) are all meaningfully different attacks that a customer will often also just call "phishing," and part of your job is naming which one you're actually looking at.

Common indicators: a generic greeting, urgency or fear-based language, a sending domain that's mismatched or suspicious relative to the impersonated brand, links to credential-harvesting pages, and branding that replicates the real thing imperfectly.

Evidence to collect: the full original message source, every URL in the message (left unclicked), the authentication results, and what can be determined about the sender's infrastructure.

Detection methods typically combine URL reputation, content and heuristic analysis, and brand-impersonation detection (Module 10).

Containment typically means quarantining or blocking the sender and the URL, and — if the message appears to have been widely distributed — considering an organization-wide search for the same indicators (Modules 15/17). When you communicate with the customer, confirm the classification and advise against interacting with the message, but resist the temptation to speculate about the attacker's identity or motive; you're reporting what the evidence shows, not building a narrative.

Escalation threshold: escalate if any recipient reports having clicked the link or entered credentials — see 9.6 and the account-compromise handling in 9.5.

9.3 Spear Phishing

Spear phishing is targeted phishing, crafted using specific knowledge about the recipient or organization — a name, a role, a live project, a known vendor relationship — to raise credibility, and sent to one individual or a small, deliberately chosen group rather than broadcast widely. Because it's built around real context, it reads as far more convincing than generic phishing, and it disproportionately targets people whose role makes them valuable: finance, HR, IT administrators, and executives.

Evidence to collect is the same as 9.2, plus something extra worth doing deliberately here: review what specific information the attacker appears to have used, and consider whether it's the kind of thing available from public sources (a LinkedIn profile, a press release, a public org chart) versus the kind of thing that would suggest the attacker already has some prior access to internal information. That distinction matters directly to your escalation decision.

Detection methods lean more heavily on behavioral and impersonation analysis and natural-language intent analysis (Module 10) than on signature-based detection, which tends to be weaker here precisely because each spear-phishing message is low-volume and unique — there's no large batch of near-identical messages for a signature to catch.

Investigation practices mirror 9.2. When you communicate with the customer, note the targeted nature of the attack honestly, but don't overstate certainty about exactly how the attacker obtained their context — you can describe what's plausible without asserting it as fact.

Escalation threshold: escalate to Security if the targeting pattern suggests insider knowledge or a prior compromise, rather than research from public sources alone — this is a materially more serious situation than an attacker who simply did good open-source research.

9.4 Business Email Compromise (BEC)

BEC is financially motivated social engineering — typically impersonating an executive, a vendor, or another trusted party — used to induce a wire transfer, a payment redirection, a gift-card purchase, or disclosure of sensitive data. What makes it distinct, and what makes it dangerous from a detection standpoint, is that it usually carries minimal or no malicious payload at all: no link, no attachment, just persuasive text. That's precisely why payload-focused scanning evades it — there's often nothing for a scanner built to inspect links and files to actually catch.

Common indicators: urgency, confidentiality requests ("don't discuss this with anyone else"), a request to change payment or banking details, and executive impersonation — frequently via display-name spoofing (9.19, Module 4.6) riding on otherwise entirely clean authentication. That last point is worth sitting with: a BEC message can pass SPF, DKIM, and DMARC cleanly, because the attacker is sending from their own domain, not forging the victim's — the display name is doing all the deceptive work, not the authenticated identity.

Evidence to collect: full headers, authentication results, any prior correspondence thread the message references, and any financial details mentioned — handled per Module 11's guidance on sensitive content, since payment and banking details deserve minimum-necessary exposure even during a legitimate investigation.

Detection methods here are necessarily natural-language and intent analysis, impersonation detection, and financial-keyword heuristics (Module 10) — not link or attachment scanning, since there's frequently no payload for that layer to see.

If there is any indication a payment action may already have occurred, containment shifts to urgency: notify the customer immediately, and urge them to contact the receiving bank and their own finance and legal leadership right away — time is critical for any chance of fund recovery, and that recovery process itself is outside Support's remit. Do not attempt to advise on financial-recovery mechanics yourself; direct, don't diagnose, on that specific point.

Escalation threshold — always: escalate to Security immediately if there's any indication a payment was made or attempted. Treat this as a security incident under Module 17, not a routine ticket. This is one of the three highest-stakes categories in the whole taxonomy — see the note earlier in this section.

9.5 Account Takeover (ATO)

Account takeover is what happens when an attacker gains actual control of a legitimate account — through credential theft, MFA fatigue, session-token theft, or another method — and then sends mail, internally and/or externally, from that genuine, authenticated account. This is the clearest illustration in the entire taxonomy of why "authentication passed" cannot be your safety signal on its own: the account really is who it claims to be, technically speaking, because the attacker is genuinely inside it.

Common indicators: sending-pattern anomalies (unusual time of day, unusual volume, unusual recipients), login-location anomalies from the identity provider (outside the email product's own scope, but important context if your customer's IT team can share it), and — often the first signal you'll actually see — a purported sender denying they sent a message that clearly came from their account.

Evidence to collect: full headers (which will show entirely legitimate authentication, since the account itself is genuine — don't expect a red flag here), sign-in and audit logs from the identity provider (coordinate with the customer's IT/identity team, since this lives outside the email product), and any outbound messages sent during the suspected compromise window.

Because content and authentication both look legitimate, the product generally cannot detect ATO from message content alone — detection has to rely on behavioral and anomaly analysis of sending patterns instead.

Support cannot remediate ATO directly — password reset, session revocation, and MFA re-enrollment are identity-platform actions, not email-product actions. Direct the customer immediately to their identity/IT team for those steps, and focus your own effort on identifying and containing whatever mail the attacker sent while in control of the account. When you communicate this to the customer, be explicit that account remediation has to happen on the identity platform, not through the email security product — a customer who doesn't hear that clearly may wait on you to "fix" something you have no ability to fix.

Escalation threshold — always: escalate to Security. This is a security incident by definition, not a standard ticket (Module 17). Along with 9.4 and 9.14, this is one of the three categories that deserve the deepest, most confident recall in this entire module.

9.6 Credential Theft

Credential theft is the mechanism most phishing (9.2) and spear phishing (9.3) attacks are actually built to accomplish: the message directs the recipient to a fake login page — often a highly convincing replica of a real portal — designed specifically to capture whatever credentials get entered.

Common indicators: login-themed lure content, a destination URL on a domain not owned by the brand being impersonated, and urgency framed around account suspension or "verification required."

Evidence to collect: the URL or URLs involved (left unclicked), the brand being impersonated, and — only via an approved sandboxed method — the actual page content if it needs to be analyzed.

Detection typically combines URL reputation, brand-impersonation and visual-similarity detection, and time-of-click re-evaluation (Module 10).

If a recipient reports having actually entered credentials, treat that as presumptive account compromise — jump straight to the 9.5 handling path and direct them to an immediate password and session reset on the affected platform, not just email-side remediation.

Escalation threshold: escalate to Security whenever credential entry is confirmed or even suspected — this is one of the "confirmed malicious message with recipient interaction" always-escalate triggers.

9.7 Malicious Links

A malicious link is a URL embedded in a message that leads to malware download, credential harvesting, or some other harmful destination. Attackers commonly disguise the true destination through display text that doesn't match the actual href, through URL shorteners, or through multi-hop redirect chains — all techniques aimed at defeating a quick visual check.

Common indicators: a mismatch between the displayed text and the actual href, a suspicious or newly registered destination domain, and multiple redirect hops before the final landing page.

Evidence to collect: the literal href — never the display text alone — the full redirect chain if it can be traced with approved tools, and the destination domain's age and reputation.

Detection here relies on URL reputation, redirect-chain analysis, and time-of-click re-evaluation (Module 10), since a URL that was benign at the moment of delivery can be weaponized later.

Extract and analyze URLs only through approved private tools (Module 14) — never navigate to a suspected malicious URL directly from a production workstation. Containment means blocking at both the domain and the specific-URL level, as the product supports. When you explain a finding to a customer, describe the specific mismatch or redirect pattern you found in plain language, rather than a generic "this link is bad" — a customer who understands the mechanism is better equipped to recognize the next one themselves.

Escalation threshold: escalate if the link was actually clicked and led to credential entry or file execution.

9.8 URL Redirection and URL Shorteners

This is a close relative of 9.7, worth treating as its own entry because the evasion mechanism is distinct: a shortener service or an open-redirect feature masks the true destination, specifically to defeat simple domain-reputation checks and a quick visual review of the displayed link.

Common indicators: known shortener domains, redirect chains that terminate somewhere different from what was initially presented, and abuse of a legitimate service's own open-redirect feature as the evasion technique — meaning the abused service itself is often entirely reputable.

Evidence to collect: the full redirect chain, resolved through approved tooling — never by following the link in a browser directly, since that's the exact action the technique is designed to induce.

Detection depends on resolving the redirect chain before scoring reputation, combined with time-of-click re-evaluation (Module 10).

Containment should target the final resolved destination, not just the shortener link itself — the shortener is frequently a legitimate service being abused rather than the actual malicious infrastructure, so blocking only the shortener wildcard could either be too broad (blocking legitimate uses of that service) or miss the point (the abuser can generate a new short link pointing to the same destination). When you communicate this to a customer, be clear that the shortener service itself isn't necessarily malicious — the abuse is in how it was used.

Escalation threshold: same as 9.7.

9.9 QR-Code Phishing ("Quishing")

Quishing embeds a malicious URL as a QR code image — in the message body or an attachment — instead of as clickable text. The technique is deliberately designed to do two things at once: evade text-based URL scanning (there's no literal href for a scanner to inspect), and shift the actual click from a monitored, managed corporate device to an unmanaged personal mobile device, where the organization has essentially no visibility at all.

Common indicators: a QR code image with no accompanying business context explaining why it's there, unusual placement — disguised as a "secure document" link or an MFA re-enrollment prompt is common — and framing that specifically asks the recipient to scan rather than click.

Evidence to collect: the image itself. If the code needs to be decoded for investigation, that has to happen through an approved isolated method — never a personal or production mobile device, which would recreate the exact exposure the attack is designed to cause.

Detection typically requires image-based URL extraction or OCR, followed by standard URL reputation checks (Module 10) — a meaningfully different detection path from text-based link scanning, and one not every system applies equally consistently.

Containment is based on the decoded destination, same as any other malicious URL, once it's been safely extracted. When talking to a customer, it's worth explicitly explaining the mobile-device evasion angle — in practice, this is often the exact question a customer is trying to get answered ("why didn't this get caught"), and the honest answer is that a QR code is designed to route around exactly the layer that would have caught a normal link.

Escalation threshold: escalate if a user reports having scanned the code, especially on an unmanaged device outside the organization's visibility.

9.10 Malicious Attachments

A malicious attachment is a file that contains or delivers malware upon opening or execution — one of the most direct threat mechanisms in this taxonomy, and one every engineer should be able to recognize and handle without hesitation.

Common indicators: an unexpected attachment from an unfamiliar or spoofed sender, a file type mismatched to its claimed content, and executable content disguised behind a document-style icon or filename.

Evidence to collect: the file itself (handled per Module 11's evidence protocol), the declared versus actual file type or signature, and the file's hash.

Detection typically combines signature-based scanning, static and dynamic analysis (sandboxing), and file-hash reputation (Module 10).

Containment is straightforward quarantine. If the attachment was actually opened, though, the situation moves beyond email entirely: treat it as a potential endpoint compromise requiring coordination with the customer's own endpoint or security team. When you talk to the customer about that scenario, be direct that isolating the affected device and engaging their endpoint-security process is the next step — that's beyond what email remediation alone can address.

Escalation threshold: escalate immediately if any recipient opened or executed the attachment — this is a recipient-interaction always-escalate trigger.

9.11 HTML Smuggling

HTML smuggling is a more sophisticated evasion technique: malicious content — often an encoded payload that gets reconstructed into an executable file — is embedded within an HTML attachment or the message's HTML body using JavaScript, and assembled client-side, in the recipient's own browser, rather than transmitted as a file that could be directly scanned. It exists specifically to defeat attachment scanning that inspects a file as it was delivered, not as it's later reconstructed after the fact.

Common indicators: an HTML attachment where you'd expect a native file type instead, and obfuscated or encoded JavaScript in the HTML source — large Base64 blobs are a common tell.

Evidence to collect: the raw HTML source of the attachment or body — not just how it renders visually, which is exactly what the technique is designed to hide behind.

Detection requires static analysis of the HTML and script content for obfuscation and payload-assembly patterns, rather than traditional file-type scanning alone (Module 10).

Analyze the HTML source only through approved tooling in an isolated environment — never open the HTML file in a standard browser on a production device, since that's exactly the action that would complete the attack. Containment depends on identifying the reconstructed payload once it's been safely analyzed. This is worth explaining to a customer plainly: HTML smuggling is a technique specifically engineered to evade conventional attachment scanning, which helps set accurate expectations about what "the filter didn't catch it" actually means in this case — it's a known evasion category, not necessarily a product defect.

Escalation threshold: escalate if the technique is confirmed and reached a recipient, given the elevated sophistication involved relative to a simpler malicious attachment.

9.12 Weaponized Documents

A weaponized document — an Office file or a PDF — contains a malicious macro, an embedded object, or an exploit that executes when the file is opened, frequently paired with a lure encouraging the recipient to "enable content" or "enable editing."

Common indicators: a request to enable macros or editing, embedded OLE objects, and documents from unfamiliar senders using generic invoice, HR, or legal framing designed to feel routine enough not to raise suspicion.

Evidence to collect: the file itself (Module 11 protocol), and macro or object content if it can be safely extracted through approved tooling.

Detection typically combines static document analysis (inspecting macros and embedded objects) with dynamic sandboxing (Module 10).

As with 9.10, never open a suspected weaponized document directly — use an approved analysis environment only. If macros were actually enabled, treat that as a potential endpoint compromise, same as an executed malicious attachment. It's worth recommending, separately from any single incident, that the customer disable macros by default organization-wide as a standing hygiene practice — that's a durable mitigation that reduces exposure to this entire category going forward, not just a fix for one ticket.

Escalation threshold: escalate if macros or content were actually enabled by a recipient.

9.13 Archive Files and Password-Protected Attachments

Attackers place malicious content inside a compressed archive — ZIP, RAR, 7z — or a password-protected file specifically to prevent automated scanners from inspecting the contents. Very often the password itself is supplied right in the message body, which is worth pausing on: a password exists there for essentially one purpose, defeating automated content inspection, which makes its mere presence a disproportionately strong indicator of malicious intent on its own, independent of whatever the archive actually turns out to contain.

Common indicators: a password supplied in the message body for an attached archive or document — treat this single pattern as a strong indicator by itself, not a minor detail.

Evidence to collect: the archive file, the stated password, and — only through approved tooling — the extracted contents.

Detection typically involves flagging password-protected content as inherently suspicious as a heuristic, combined with extraction-and-scan in a sandboxed environment where the product supports it (Module 10).

Never manually extract and open password-protected suspicious content outside an approved malware-analysis environment. Given how low the legitimate-use rate is relative to the abuse rate for this pattern, it's worth strongly recommending that the customer adopt an organization-wide policy to block or quarantine password-protected archives and documents from external senders by default, rather than evaluating each one case by case. When you explain a block to a customer, frame it accurately: "the scanner couldn't check inside the password-protected file" is itself the reason for the block — that's not a detection failure, it's the control doing exactly what it's designed to do when it can't verify safety.

Escalation threshold: escalate if extracted content — via approved tooling — confirms malware, or if a recipient extracted and opened the content independently.

9.14 Malware, Ransomware, and Remote-Access Tools

Delivered through the mechanisms in 9.10 through 9.13, this category is the payload itself actually taking effect: commodity malware, ransomware (which encrypts data for extortion), or remote-access tools — legitimate remote-access software abused for unauthorized control, which is a distinct detection challenge since the tool itself is not inherently malicious, only its use is.

Common indicators: a confirmed malicious file hash or signature; for RATs specifically, watch for abuse of otherwise-legitimate remote-access software, since a reputation check on the tool itself won't flag it.

Evidence to collect: the file hash, any sandboxing results available, and any confirmed execution evidence.

Detection methods combine signature and hash reputation, sandboxing and dynamic analysis, and behavioral detection tuned to RAT-abuse patterns (Module 10).

This category carries the highest containment urgency in the entire taxonomy. It is beyond email-security remediation alone — immediate coordination with the customer's endpoint or security team is required, and ransomware specifically requires isolating affected systems immediately, before anything else. When you communicate with a customer in this situation, urge immediate isolation of any device where the payload executed, and direct them into their own incident-response process. Do not attempt to advise on ransomware negotiation, payment, or recovery under any circumstance — that decision belongs to the customer's legal and security leadership, and it is well outside Support's scope.

Escalation threshold — always, immediately: this is never handled as a routine ticket (Module 17). Along with 9.4 and 9.5, this is one of the three categories where confident, immediate recognition matters more than anything else in this module.

9.15 Callback Phishing

Callback phishing is a message — often disguised as an invoice, a subscription renewal, or an IT alert — that contains no malicious link or attachment at all. Instead, it provides a phone number and instructs the recipient to call to "resolve" or "dispute" the matter. The actual social engineering, and often the actual payload delivery (typically a remote-access tool, tying directly back to 9.14), happens live, during the phone call itself — entirely outside anything an email security product can observe.

Common indicators: no embedded link or attachment, a phone number as the sole call to action, and invoice, subscription, or renewal framing designed specifically to prompt a concerned callback.

Evidence to collect: the message content and the phone number — there is typically no technical payload in the email itself to analyze, which is exactly what makes this category distinctive.

Detection requires natural-language and intent analysis specifically tuned to phone-callback lure patterns (Module 10) — traditional link and attachment scanning provides no signal here at all, since the message may otherwise be entirely "clean."

Containment relies on blocking by sender or content pattern, since there's usually no URL or file to sandbox. When you talk to the customer, be explicit: instruct them not to call the number, and explain the phone-based social-engineering mechanism directly, since it's often unfamiliar to recipients who are trained to expect the "real" threat to be a link or an attachment rather than a phone call.

Escalation threshold: escalate if a recipient confirms having called the number, since this often leads directly into remote-access tool installation (9.14).

9.16 Vendor Impersonation

Vendor impersonation is an attacker impersonating a known, legitimate vendor or supplier — often after researching a real business relationship — to redirect payments, harvest credentials, or deliver malware. It frequently leverages a lookalike domain (9.21) or, in a genuine supply-chain scenario, a truly compromised vendor account (9.23).

Common indicators: a sudden request to change banking details, urgency tied to a real, ongoing business relationship, and a sending domain that's slightly different from the vendor's actual known domain.

Evidence to collect: a direct comparison of the sending domain against the vendor's previously known-good domain, and correspondence history if it's available.

Detection relies on vendor-relationship and impersonation heuristics combined with lookalike-domain detection (Module 10).

During investigation, do not confirm or deny specific vendor relationships to an unverified inbound caller or emailer — that itself can leak information useful to a social engineer. The strongest containment advice here is process-level, not technical: advise the customer to verify any payment-detail change through a separately established, independently verified channel — a phone number pulled from prior records, never one supplied in the suspicious message itself. Recommend that as a standing practice, not just a one-off response to this incident.

Escalation threshold: escalate as BEC (9.4) if any payment action is involved.

9.17 Conversation Hijacking

Conversation hijacking is what happens when an attacker who has gained access to a genuine email account or thread — via account takeover or a prior compromise — inserts malicious content directly into an ongoing, legitimate conversation. It works precisely because it leverages the built-in trust of a real, existing exchange rather than trying to manufacture credibility from nothing.

Common indicators: a malicious message that replies within an authentic existing thread, a sudden topic shift — a normal project thread abruptly requesting payment or credentials is a classic pattern — and the message coming from an account the recipient has genuinely corresponded with before.

Evidence to collect: the full thread history if it's available, and sign-in or audit context for the account if account takeover is suspected — coordinated with the customer's identity team, as in 9.5.

Because content and authentication may both appear fully legitimate here, detection depends on behavioral anomaly analysis within known conversation patterns (Module 10) rather than any single technical signal. This is another entry in the "authentication passing ≠ safe" pattern flagged earlier in this module — the account really did send the message, and the thread really is real.

Treat this as presumptive account compromise pending evidence — since a hijacked conversation implies the source account itself was compromised, direct the customer to the identity platform for account remediation, exactly as in 9.5. When you communicate with the customer, make clear that it's the account, not just this one message, that requires remediation — cleaning up the single message without addressing the underlying compromise leaves the door open for more.

Escalation threshold — always: escalate to Security — this implies an underlying account compromise, and belongs in the same always-escalate bucket as 9.5.

9.18 Thread Injection

Thread injection is a close relative of conversation hijacking, but with an important difference: here the attacker fabricates the appearance of a reply within an existing thread — manipulating the Subject line with "Re:" and referencing prior content — without ever actually having compromised the account. It relies on visual and contextual trust cues, not genuine thread access, which is exactly why it's worth distinguishing from 9.17 rather than lumping the two together.

Common indicators: a "Re:" or "Fwd:" prefixed subject where the content doesn't actually match any real prior thread, and In-Reply-To: / References: headers that are either absent or inconsistent with any genuine prior message.

Evidence to collect: the In-Reply-To: and References: headers, compared against whether a genuine prior thread with matching Message-IDs actually exists — recall from Module 1.8 that the Message-ID is the reliable anchor here, not the subject line's visual appearance.

Detection combines header-consistency validation — does the referenced thread genuinely exist — with standard phishing and impersonation detection (Module 10).

As with other header-based investigation throughout this program, verify claims against the actual header evidence rather than a visual impression of the subject line alone. Containment follows standard phishing handling (9.2), since this technique does not, by itself, imply account compromise the way conversation hijacking does. When you talk to a customer, make that distinction explicit — it's an important part of how they'll scope their own incident response, since "someone faked a reply" is a very different remediation path from "an account was compromised."

Escalation threshold: the standard phishing threshold (9.2) applies, unless the header evidence actually suggests genuine thread access — in which case treat it as 9.17 instead.

9.19 Display-Name Spoofing

Display-name spoofing is fully covered mechanically in Module 4.6, so this entry stays intentionally brief and cross-references rather than repeats: the visible display name impersonates a trusted identity while the underlying address is unrelated, and that underlying address typically passes authentication legitimately for itself, since the attacker controls it. This is another entry in this module's "authentication passing ≠ safe" pattern — the authentication check is validating the real, unspoofed sending domain, which was never the deceptive part of the message to begin with.

Common indicators and evidence to collect are covered in Module 4.6/4.7 Example B and the full header comparison table in Module 5.5.

Detection relies on display-name and impersonation heuristics that compare the shown name against known trusted contacts (Module 10) — not authentication-based detection, precisely because authentication passes cleanly by design in this category.

The core safe-investigation habit here is Module 4.6's central lesson: never conclude a message is safe from authentication results alone. Containment follows standard phishing or BEC handling depending on the payload and intent involved. When you explain this to a customer, say plainly that the sending address — not the display name — is the actual identity; this is a frequent point of customer confusion worth addressing head-on rather than assuming they already understand it.

Escalation threshold: as 9.2 or 9.4, depending on payload or financial intent.

9.20 Domain Spoofing

Domain spoofing is covered in Module 4.6/4.7 Example C: an attacker attempts to send as the real victim domain without actually controlling it — precisely the scenario SPF, DKIM, and DMARC were designed to catch. Unlike display-name spoofing, this category is the one most reliably caught by authentication infrastructure alone, when it's correctly configured — a meaningful contrast worth holding onto as you move through this module's identity-based categories.

Common indicators: authentication failure against the claimed Header From domain — see Module 4.7 Example C for the full evidence walkthrough.

Detection here is SPF/DKIM/DMARC evaluation (Modules 3–4).

Part of investigating this category well is confirming the victim domain's own DMARC policy (the p= tag) — a p=none policy explains why an identified spoofing attempt wasn't rejected outright even though it was correctly flagged in reporting; that's a configuration gap on the victim's side, not a detection failure on the security product's side. Recommend the customer strengthen their own DMARC policy toward p=reject if it's currently p=none or p=quarantine, following a monitored rollout plan (Module 3.7). When communicating with the customer, be careful to distinguish "someone attempted to spoof your domain" from "your domain or systems were compromised" — these two very different situations are frequently conflated when customers review their own DMARC reports.

Escalation threshold: as 9.2/9.4 depending on payload or intent; escalate to Security if the spoofing volume suggests a targeted campaign against the customer specifically, rather than incidental abuse.

9.21 Lookalike Domains

Lookalike domains are covered in Module 4.6: a visually similar domain — a character substitution, a homoglyph, an added hyphen or word — is registered and used to send mail that authenticates legitimately for itself, since it's an attacker-owned domain, not a forged one.

Common indicators: a domain that requires close visual comparison to distinguish from the real one — the canonical example being rnicrosoft.com using "rn" to visually mimic "m" in microsoft.com.

Evidence to collect: a side-by-side character comparison against the legitimate domain, and the domain's registration age if it's available via an approved lookup tool (Module 14) — a very recently registered domain is itself a meaningful signal.

Detection depends on lookalike/homoglyph detection algorithms and newly-registered-domain flagging (Module 10).

Compare character by character rather than relying on a visual skim — a visual skim is precisely what the technique is built to exploit. On the containment side, block the specific lookalike domain and consider an organization-wide search for other messages from the same domain. It's also worth recommending the customer consider defensive domain registration for close variants of their own brand — a proactive measure that goes beyond remediating this one incident. When explaining a finding to a customer, show the specific character difference explicitly; customers frequently cannot see it on their own without it being pointed out directly.

Escalation threshold: as 9.2/9.4, depending on payload or intent.

9.22 Executive and Employee Impersonation

This category is a specific application of display-name spoofing (9.19) or domain spoofing (9.20), aimed specifically at the trust placed in an executive's or colleague's identity. It's frequently paired with BEC-style financial requests (9.4) or urgent internal asks — gift cards, HR data, credential resets — that rely on organizational hierarchy to discourage the recipient from questioning the request.

Common indicators: impersonation of a specific named internal individual, typically paired with urgency and a request that falls outside that person's normal communication pattern.

Evidence to collect: the same as 9.19/9.20, plus a direct comparison against the impersonated individual's actual known-good sending address.

Detection typically combines named-executive or VIP impersonation-protection lists with display-name and domain detection (Module 10).

Safe investigation practices mirror 9.19/9.20. It's worth recommending the customer configure and maintain a protected-users list for high-risk individuals, if the product supports it — and when you communicate about this category, recommend internal awareness specifically for the individual being impersonated, since repeat targeting of the same person is common once an attacker has identified them as a useful impersonation target.

Escalation threshold: as 9.4, if any financial or sensitive-data request is involved.

9.23 Supply-Chain Compromise

Supply-chain compromise is what happens when a genuine vendor, partner, or service provider's own systems or accounts are compromised, and the attacker uses that legitimate relationship and infrastructure to reach the customer's organization. The mail can show fully legitimate authentication in this scenario, because it truly did originate from the trusted party — it's just that the trusted party is itself, unknowingly, a victim.

Common indicators: malicious content arriving from a genuinely known, previously trusted sender, often marked by a sudden deviation from that sender's normal communication pattern.

Evidence to collect: a comparison against the vendor's historical communication pattern, and confirmation — through an out-of-band contact, not a reply to the suspicious message — of whether the vendor is aware of a compromise on their end.

Because authentication and sender identity are both technically legitimate here, detection depends on behavioral and pattern-deviation analysis (Module 10) — this is yet another category where "authentication passed" tells you nothing about safety.

An important investigative discipline here: do not assume malicious intent on the part of the vendor organization itself — their own systems are very likely also a victim, and treating them as an adversary rather than a fellow-victim can damage a relationship unnecessarily and slow down the coordinated response that's actually needed. Containment should target the specific compromised indicators — sender, URL, attachment — without necessarily blocking the entire vendor relationship, pending vendor confirmation. Recommend the customer notify the vendor through an independently verified channel, since the vendor's own security team very likely needs to know and may not yet.

Escalation threshold: escalate to Security given the multi-organization scope and the potential for a broader campaign impact beyond just this one customer.

9.24 Data Exfiltration

Data exfiltration is sensitive data leaving the organization via email — either through a malicious or compromised-account action, or as a byproduct of another attack, such as an attacker quietly forwarding mail after an account takeover.

Common indicators: outbound messages matching sensitive-data patterns via DLP detection, an unusual outbound recipient — an external, unfamiliar domain — and auto-forwarding rules configured without the account owner's knowledge, which is a common artifact left behind by account takeover.

Evidence to collect: the outbound message or messages, the DLP policy match details, and any newly created forwarding or rule configuration found on the sending account.

Detection typically relies on DLP pattern matching and outbound anomaly detection (Module 10).

If exfiltration is tied to account compromise, direct the customer to identity remediation (9.5), and review and remove any unauthorized forwarding rules you find. When communicating with the customer about confirmed data exfiltration, advise them to involve their privacy, legal, or compliance function — this may carry notification obligations that are well beyond Support's scope to assess.

Escalation threshold — always: potential data exfiltration is treated as a security and privacy incident, not a routine ticket — this is one of the five always-escalate triggers named earlier in this module.

9.25 Accidental Data Loss

Accidental data loss is what happens when a legitimate user sends sensitive data to the wrong recipient, or without appropriate encryption or handling, through human error rather than malicious action — autocomplete selecting the wrong "John Smith," or a misconfigured distribution list, are classic examples.

Common indicators: a DLP policy match on an otherwise entirely normal, authenticated internal-to-external send, with no other threat indicators present anywhere else in the picture.

Evidence to collect: the message and its DLP match details, and confirmation from the sender about intent — was this genuinely a mistake.

The detection layer here is identical to 9.24's — DLP pattern matching — which is exactly why the distinguishing factor between the two categories is intent and context, not the technical signal itself.

Safe investigation practices mirror 9.24. Attempt message recall or retraction if it's supported and still possible; if it isn't, advise the sender's organization on next steps — such as requesting deletion from the unintended recipient — while being clear that this request is not enforceable through email tooling alone; it depends entirely on the recipient's cooperation. When you talk to the customer, distinguish this clearly in tone from 9.24: this is a hygiene and process issue, not a security incident, though it may still carry compliance implications worth the customer assessing on their own.

Escalation threshold: escalate to Legal/Privacy if the data category is regulated — health, financial, or other personal data subject to notification requirements. Support should not make that regulatory determination itself, but should flag the situation so someone qualified can.

9.26 Email Bombing

Email bombing is when an attacker — often through automated sign-up abuse of many legitimate mailing lists and services — floods a target's inbox with a high volume of messages. It's typically not the actual attack itself, but a distraction technique, meant to bury a legitimate alert (a fraud notification, for example) that the attacker specifically doesn't want the victim to notice amid the noise.

Common indicators: a sudden, extreme volume of legitimate-looking subscription or confirmation emails from many distinct, unrelated senders, all arriving within a short window.

Evidence to collect: the volume pattern, sender diversity, and timing correlation with any other suspicious activity on the account — that correlation is a strong signal that this is a distraction tactic rather than the primary attack.

Detection relies on volume and pattern-based heuristics (Module 10) — individual messages in the flood are often not malicious on their own, which makes this a pattern-level detection challenge rather than a message-level one.

The right instinct here is to treat the flood as a signal to check for concurrent, more serious activity on the account — financial activity, credential resets — rather than pouring investigative effort into the flood messages themselves as if they were the primary threat. Containment means temporary filtering of the bulk/subscription-pattern mail, alongside a strong recommendation that the customer check for concurrent account activity elsewhere. When you talk to the customer, explain the likely distraction-tactic purpose so they know to check the right things first — recent account and financial activity — rather than fixating on the flood itself.

Escalation threshold: escalate to Security given the strong association with a concurrent, more serious attack.

9.27 Graymail

Graymail is legitimate bulk mail the recipient opted into at some point — newsletters, marketing, notifications — but no longer wants. It is not malicious, and it's worth being precise about that: it's a classification and customer-satisfaction challenge, distinct from spam, not a security finding at all.

Common indicators: a legitimate, properly authenticated sender, and a preference that's recipient-specific rather than a universal verdict — one recipient wants a given newsletter while another doesn't, and both are "correct" from a security standpoint.

Evidence to collect: the sender's identity and any prior opt-in or subscription relationship.

Detection is typically graymail-specific classification, often applied per-recipient rather than as a single global verdict (Module 10).

There is no security investigation practice to apply here — this simply isn't a security investigation category. Containment, such as it is, means per-recipient filtering preference rather than an organization-wide block, since the sender is legitimate for at least some recipients. When you communicate with a customer about it, distinguish it clearly from spam or phishing — this is a preference issue, not a security finding, and treating it as one in your explanation would misrepresent the actual risk.

Escalation threshold: this is not a security escalation category at all; escalate only if there's an underlying classification-accuracy defect (Module 17, Product) — that is, the categorization mechanism itself is malfunctioning, not any individual graymail message.

9.28 False Positives and False Negatives

This last entry is different in kind from the other 27 — it's not an attack category at all, but a detection-accuracy category. A false positive blocks or flags legitimate mail; a false negative allows malicious mail through undetected. Both matter enormously to how a customer perceives the product's overall value, and both have a distinct handling path that's important not to conflate.

Common indicators (false positive): a known-legitimate sender or domain that got quarantined or blocked, often surfaced by a customer saying something like "this always used to arrive fine."

Common indicators (false negative): confirmed-malicious mail — matching a known threat pattern — that was delivered without any action taken on it.

Evidence to collect: for a false positive, the message, the specific policy or rule that matched, and why it matched. For a false negative, the message, confirmation of its maliciousness through approved analysis, and an assessment of what detection layer should have caught it but didn't.

There's no detection method to describe for this category itself — it's about auditing detection outcomes after the fact, not detecting a threat directly.

For a suspected false negative, follow the same safe-handling protocol as the underlying threat category would call for — never assume "it must be fine since it wasn't caught" just because the product let it through. For a false positive, release the message only via the authorized process (Module 11's release-authorization protocol), and consider a scoped allow-list entry rather than an overly broad one that could reopen a gap elsewhere. For a false negative, quarantine or remove the message if it's still retrievable, and separately feed the finding back through the defect/tuning process (Module 17, Product) — that second step is not optional busywork, it's how the detection gap actually gets closed for the next customer who encounters the same thing.

When communicating with a customer about a false positive, acknowledge the inconvenience honestly without overstating a guarantee that it won't recur, and explain specifically what triggered the match. For a false negative, do not speculate about why detection missed it beyond confirmed facts — commit only to what has actually been verified or escalated, not to a theory about the cause.

Escalation threshold: escalate a false-positive outbreak — multiple tenants or customers affected, not an isolated case — as a potential service-wide issue (Module 17). Escalate any false negative involving confirmed malware, ransomware, credential theft, or BEC as a detection-gap finding requiring Product/Engineering visibility, kept separate from remediating the individual message itself.

Hands-On Lab

Scenario-Based Exercise

Knowledge Check

Answer each question yourself before expanding it.