Key terms

You will see these terms in tickets, tools, and every later page of this guide. Each entry gives a plain-language definition first, then explains why the term matters during triage.

What counts as phishing?

NIST defines phishing in several ways across its publications. The most common is a fraudulent message, usually email, in which an attacker pretends to be a trusted business or person in order to obtain sensitive data (NIST, n.d.).

MITRE ATT&CK, the industry's catalog of attacker techniques, adds two points. First, all phishing is social engineering delivered electronically. Second, attackers use it to gain initial access, their first foothold inside an organization (MITRE, 2026).

Glossary

Spear phishing

Phishing aimed at a specific person, company, or industry, often using personal details to look believable.

Why it matters: Targeted emails look more legitimate and need closer inspection.

Business email compromise (BEC)

A scam in which the attacker poses as an executive, vendor, or coworker to request money or data. It often contains no link or attachment at all.

Why it matters: Your link and attachment scanners may find nothing, so you have to judge the request itself.

Credential harvesting

Sending the reader to a fake login page to steal their username and password.

Why it matters: This is the most common phishing goal. Always check whether anyone entered credentials.

Callback phishing

An email that urges the reader to call a phone number, where the attacker talks them into installing software or visiting a site.

Why it matters: There may be no malicious link at all. The phone number is the indicator.

Thread hijacking

The attacker replies inside a real, existing email conversation, usually from a compromised account.

Why it matters: The sender may be a real partner whose account has been taken over.

Email header

The hidden routing information attached to every email: which servers handled it, the true sending address, and authentication results.

Why it matters: Headers reveal what the display name hides.

Display name vs. sender address

The display name (for example, “IT Support”) is free text that anyone can set. The sender address is the actual mailbox.

Why it matters: Always compare the two.

SPF (Sender Policy Framework)

A DNS record that lists which mail servers may send email for a domain (defined in RFC 7208).

Why it matters: A “fail” means the sending server was not authorized by that domain.

DKIM (DomainKeys Identified Mail)

A digital signature that shows which domain signed the message and that it was not altered in transit (RFC 6376).

Why it matters: A valid signature tells you which domain really sent the message.

DMARC

A domain policy that ties SPF and DKIM results to the visible From address and tells receivers what to do when checks fail (RFC 7489).

Why it matters: A DMARC fail on a well-known brand's domain is a strong sign of spoofing.

Indicator of compromise (IOC)

Any observable artifact tied to an attack: a URL, domain, IP address, file hash, or sender address.

Why it matters: You collect IOCs to block the threat and to search for other victims.

Defanging

Rewriting an IOC so it cannot be clicked, for example hxxps://evil[.]com.

Why it matters: Prevents accidental clicks in tickets and chat.

Sandbox

An isolated environment for safely opening a suspicious file or URL and watching what it does.

Why it matters: Lets you test without risking your own computer.

True positive / false positive

A true positive is a report that is really malicious. A false positive is a report that turns out to be harmless.

Why it matters: Your main job in triage is to sort reports into these buckets.

Escalation

Handing a case to a more senior analyst or to the incident response team.

Why it matters: Know your trigger points before you start; they are listed in step 9 of the procedure.

Incident response (IR)

The organized process of detecting, containing, and recovering from a security incident. NIST SP 800-61 Rev. 3 is the main U.S. guideline.

Why it matters: Phishing triage is often the first step of incident response.

Reading an email header

The four header lines you will check most often, in a trimmed example:

From: "IT Help Desk" <helpdesk@northwind-it-support[.]com>
Return-Path: <bounce@northwind-it-support[.]com>
Received: from mail.northwind-it-support[.]com (203.0.113.45)
Authentication-Results: spf=pass; dkim=pass; dmarc=pass
        header.from=northwind-it-support[.]com

Notice that every check passes, but for the attacker's domain, not the company's real one. The Worked Example walks through this email in full.