Email Threat Investigation and Analysis

Investigate suspicious emails like a SOC analyst using header forensics.

Introduction

30 Second Summary

Every day, dangerous emails slip past automated filters and land in inboxes looking perfectly legitimate. The difference between a security breach and a stopped attack often comes down to one person knowing how to read the hidden clues buried in an email's metadata.

In this project, you will investigate multiple email samples the way a working SOC analyst does. You'll trace each email's origin through its raw headers, validate whether the sender is legitimate or spoofed, extract indicators of compromise, enrich them against threat intelligence platforms, and produce a unified professional investigation report with risk verdicts for each email.

What You'll Build

You'll finish with a completed investigation case file that you could hand to a manager or incident response team. Open it, and they'll see exactly which emails are dangerous, why, and what to do about them.

By the end of this project, you'll have:

  • A multi-email threat investigation report with an Executive Summary, per-email analysis with risk verdicts (SAFE, SUSPICIOUS, or MEDIUM RISK), a consolidated IOC table, and actionable recommendations that a team can execute immediately.
  • Documented authentication validation for every email showing whether SPF, DKIM, and DMARC confirm or contradict the claimed sender, with evidence you gathered by hand and verified with MXToolbox.
  • A threat intelligence enrichment workflow where you can take any IP, URL, or domain from a suspicious email, run it through VirusTotal and AbuseIPDB, and confirm whether the infrastructure behind it is known-malicious.
  • Secret Mission: Investigate an email that passes all authentication checks but is still a threat, proving that behavioral analysis catches what automated checks miss.

Are there any prerequisites?

You'll need a basic understanding of IP addresses, DNS, and network protocols. You'll also need registered accounts on VirusTotal and AbuseIPDB before starting. Both are free to sign up.

You'll also need your own email samples to investigate. These can be .eml files exported from your email client or raw header text copied from suspicious messages.

Before We Start

Before you dive into raw email headers and threat intelligence lookups, take a moment to lock in what you are about to build and why it matters. This step is your commitment to the investigation ahead.

Prepare Your Investigation Workspace

Every SOC investigation lives or dies by its documentation. If you cannot trace where a piece of evidence came from, when you collected it, and what you concluded from it, the investigation holds no weight.

In this step, you will build a case folder that mirrors how real Security Operations Center analysts organize phishing investigations. You will also confirm your email samples are ready for forensic analysis.

In this step, get ready to:
  • Create a structured case folder with evidence, IOC, and report subfolders.
  • Place your email samples in the evidence folder with clear names.
  • Confirm raw email headers are visible when opened in Notepad.
Create your case folder structure

A case folder groups all evidence, extracted indicators, and your final report under a single timestamped identifier. This means you can always trace every finding back to its source file.

  • Right-click on your Windows Desktop and select New, then Folder.
  • Name the folder with today's date and a case identifier, for example 2026-07-20_CASE-001.
  • Double-click the new folder to open it in File Explorer.
  • Inside the case folder, create three new subfolders by right-clicking in the empty space and selecting New > Folder three times.
  • Name them evidence, iocs, and report.

You should now see three subfolders inside your case folder.

Why this folder structure?

The evidence folder holds raw email files exactly as you received them. The iocs folder stores extracted indicators of compromise (IPs, URLs, domains) after enrichment. The report folder holds your final professional investigation report.

Separating raw evidence from analysis outputs ensures nothing gets accidentally modified. This is the same principle behind chain-of-custody documentation in forensic investigations.

Don't see three subfolders?

Make sure you created the folders inside the case folder, not on the Desktop itself. Double-click your case folder first, then create the subfolders in the empty space inside it.

Check for typos in the folder names. They should be lowercase: evidence, iocs, report.

Help me set up my case folder structure for this investigation.

Place your email samples in the evidence folder

Your email samples are the raw evidence for this investigation. Placing them in the evidence folder with clear names means you can always reference which email a finding came from.

  • Locate your email sample files. These are either .eml files exported from your email client, or raw header text you have copied.
  • Copy or move your .eml files into the evidence subfolder inside your case folder.
  • Rename each file clearly, for example email-1.eml, email-2.eml, or descriptively like paypal-alert.eml.

Raw headers instead of .eml files

If you have raw headers copied from an email client (like Gmail's "Show original" or Outlook's "View source") instead of .eml files, paste each email's headers into a separate text file in the evidence folder. Name them email-1-headers.txt, email-2-headers.txt, etc.

  • Open the evidence folder in File Explorer and confirm your email files are listed.

You should see your email sample files listed inside the evidence folder with clear, identifiable names.

Files not appearing in the evidence folder?

Make sure you moved the files into the evidence subfolder, not the parent case folder or another subfolder.

If your files have an unfamiliar extension, check that File Explorer is set to show file extensions. Click View in the File Explorer toolbar and enable File name extensions.

Help me get my email samples into the evidence folder.

Open and verify raw email headers in Notepad

Email headers are metadata lines at the top of every email that record its entire journey from sender to recipient. Normal email clients hide these headers. Opening the raw file in Notepad reveals the full header block that you will analyze throughout this investigation.

Before you open your first file, think about what you expect to see. Do you think it will look like a normal email with a subject and body, or something different?

  • In the evidence folder, right-click your first email file (e.g. email-1.eml).
  • Select Open with, then choose Notepad.
  • Look at the top of the file. The headers are everything above the first blank line.

You should see lines starting with fields like Received:, From:, Authentication-Results:, Return-Path:, and Reply-To:. This is the raw metadata that email clients normally hide from you. Below the first blank line is the email body (often HTML markup).

  • Repeat this process for each of your other email samples. Right-click each file, select Open with > Notepad, and confirm you can see header fields at the top.

What are email headers?

Every email carries a block of headers that record which servers handled the message, when each hop occurred, and whether authentication checks passed or failed. Think of them as a shipping label with a chain of custody stamp from every post office the package passed through.

The key fields you will use in this investigation are Received: (delivery path), From: (claimed sender), Return-Path: (envelope sender), Reply-To: (where replies go), and Authentication-Results: (SPF/DKIM/DMARC verdicts).

Don't see header text?

If you see HTML tags like <html> or <body> immediately at the top with no Received: lines above them, your file contains only the email body, not the full message with headers. You need to re-export the email using your email client's "Show original" or "View message source" option.

If the file appears completely blank or shows garbled characters, it may be encoded in a format Notepad cannot read. Try opening it with a different text editor, or re-save the original source as a plain .txt file.

Help me get raw email headers visible in my file.

Your investigation workspace is organized and your evidence is confirmed readable. Next up, you will read each email's raw headers line by line to uncover where it actually came from and spot the first red flags.

Analyze Email Headers Manually

Your case folder is set up and your email samples are ready to examine. Now it's time to read the raw headers and uncover where each email actually came from.

Every email carries a hidden story in its headers. The visible "From" field can say anything the sender wants, but the delivery path recorded in the headers reveals the true origin. Reading headers manually builds your intuition for spotting red flags before any automated tool does it for you.

In this step, get ready to:
  • Trace the Received chain to identify the originating IP for each email.
  • Compare sender identity headers to detect spoofing indicators.
  • Record raw authentication values for later validation.
Trace the Received chain from bottom to top

Every server that handles an email stamps its own Received: header onto the message. These headers stack up like layers of a postmark trail. The bottom-most Received: header is closest to the originating server, and each one above it is a relay that passed the message along to your inbox.

  • Switch back to your first email file (e.g., email-1.eml) in Notepad.
  • Scroll through the headers and find all lines that start with Received:.
  • Start reading from the bottom-most Received: line and work your way up.
  • For each hop, note the server name, the IP address (usually in square brackets), and the timestamp.
  • Identify the originating IP. This is the IP address in the bottom-most Received: line (the first server to handle the email).

What does a Received header look like?

A typical Received: line includes "from" (the sending server), "by" (the receiving server), and a timestamp. For example: Received: from mail-server.example.com (192.0.2.1) by recipient-server.com; Mon, 20 Jul 2026 10:30:00 -0400.

The IP in parentheses is the actual source. Server names can be forged, but the IP recorded by the receiving server is harder to fake.

  • Open a new Notepad window by pressing Ctrl+N.
  • Write down the full Received chain for your first email: each hop's server name, IP, and timestamp.
  • At the top of the file, clearly note the originating IP.
  • Save this file as header-analysis-email-1.txt in your evidence folder.
  • Repeat the same process for each additional email sample, saving each as header-analysis-email-2.txt, etc.

Open your evidence folder in File Explorer. You should see your new notes file(s) alongside your original email samples.

Not sure which IP is the originating one?

If your email has many Received: lines, look for the very last one at the bottom of the header block. Internal relay hops (between servers within the same organization like Google or Microsoft) can appear above it. The key IP is the one in the first external handoff.

If you see IP addresses like 10.x.x.x or 127.0.0.1, those are internal/private and not the originating IP you want. Look for the first public IP address in the chain.

Help me identify the originating IP in my email headers.

Compare sender identity headers

Three different headers each claim to represent the "sender" of an email. If they all match, the sender is probably who they say they are. If they don't match, that mismatch is one of the strongest spoofing indicators you can find.

  • In your email file in Notepad, locate the From: header. This is the visible sender that the recipient sees in their inbox.
  • Find the Reply-To: header. This is where replies will actually be sent. If it differs from the From: address, flag it.
  • Find the Return-Path: header. This is the envelope sender used for bounce messages. Compare it to both From: and Reply-To:.
  • Check the Message-ID: header. The domain after the @ symbol should match the claimed sender's domain. If it does not, flag it as a mismatch.
  • Add your comparison findings to your header-analysis-email-1.txt notes file. Document the exact values of all three headers and note any mismatches.
  • Repeat for each email sample, adding findings to the corresponding notes file.

Why do mismatches matter?

Legitimate senders almost always have matching From:, Reply-To:, and Return-Path: domains. When an attacker spoofs the From: to look like your bank but sets Reply-To: to their own domain, they want your reply (with credentials or information) to reach them instead of the real bank.

The Message-ID: domain is generated by the sending server. If someone claims to be support@paypal.com but the Message-ID domain is random-server.xyz, the email did not originate from PayPal's infrastructure.

Save your notes files. You should now have documented the exact values of From:, Reply-To:, Return-Path:, and Message-ID: for each email alongside any mismatches you found.

Record raw authentication values

The Authentication-Results: header contains the verdict from the receiving mail server's checks on SPF, DKIM, and DMARC. For now, you are only recording the raw values. You will interpret what they mean for sender legitimacy in the next step.

  • In your email file in Notepad, search for the Authentication-Results: header. Use Ctrl+F and search for Authentication-Results.
  • Note the SPF result (e.g., spf=pass, spf=fail, or spf=none).
  • Note the DKIM result (e.g., dkim=pass, dkim=fail, or dkim=none).
  • Note the DMARC result (e.g., dmarc=pass, dmarc=fail, or dmarc=none).
  • Add these raw values to your notes file for each email. Record exactly what the header says without interpreting pass or fail yet.

What if there is no Authentication-Results header?

If you cannot find an Authentication-Results: header, note that as a finding in your analysis file. This may indicate the email was not processed by a modern mail gateway that performs SPF/DKIM/DMARC checks. The absence itself is a data point worth recording.

  • Save your updated notes files (header-analysis-email-1.txt, header-analysis-email-2.txt, etc.).

What are SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) checks whether the sending server's IP is authorized to send on behalf of the claimed domain. DKIM (DomainKeys Identified Mail) verifies a cryptographic signature proving the email was not tampered with in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together by requiring that the authenticated domain aligns with the visible From: domain.

An SPF pass alone does not guarantee the email is legitimate. SPF validates the envelope sender (Return-Path), which can differ from the visible From: address. DMARC alignment is what connects them. You will analyze this in the next step with MXToolbox.

Before you check your work, think about what you have gathered so far. For each email, do you think the headers point toward a legitimate message or a suspicious one?

Open your evidence folder in File Explorer. You should see a header-analysis-email-1.txt (and one for each additional email) alongside your original sample files. Open any notes file and confirm it contains at least three documented observations: the originating IP, the From:/Reply-To:/Return-Path: comparison, and the raw authentication values.

Missing notes or incomplete findings?

If your notes file is missing one of the three observation types, go back to the relevant substep above and check the email headers again. Some emails may not have a Reply-To: header at all. That is normal. Note its absence rather than skipping the comparison entirely.

If your email file appears as a single long line in Notepad, try enabling word wrap: click Format in the menu bar, then click Word Wrap.

Help me find the key headers in my email file.

You now have a manual baseline for each email: where it came from, whether the sender identities align, and what the authentication checks reported. Next, you will feed these headers into MXToolbox to get a structured, automated view and see whether your manual findings hold up under deeper authentication analysis.

Validate Authentication with MXToolbox

Your header analysis notes from the last step document the raw SPF, DKIM, and DMARC values for each email. You know what the headers say. But can you confidently determine whether each sender is legitimate based on those raw values alone?

An SPF pass means the sending server was authorized by some domain. It does not guarantee that domain matches the visible From address. MXToolbox parses this alignment and highlights where authentication claims break down.

In this step, get ready to:
  • Analyze each email's headers in MXToolbox Email Header Analyzer.
  • Compare parsed authentication results against your manual findings.
  • Document per-email authentication verdicts in auth-validation.txt.
Paste your email headers into MXToolbox

Before you paste anything, think about what you expect to see. You already recorded the raw SPF/DKIM/DMARC values manually. Do you think MXToolbox will confirm everything you found, or reveal something your manual reading missed?

  • Open your browser and navigate to https://mxtoolbox.com/EmailHeaders.aspx.
  • Switch to Notepad where you have your first email's header file open (email-1.eml or your raw headers text file).
  • Select all the header text (everything above the first blank line in the file) and copy it.
  • Return to MXToolbox and paste the copied text into the Paste Header text box.
  • Click the Analyze Header button.
  • Repeat this process for each additional email sample (email-2.eml, etc.). Click Analyze New Header at the top of the results page to start a fresh analysis.

You should see a parsed output page for each email. The page displays the email subject at the top, followed by a hop-by-hop delivery timeline showing timestamps and delays between each server.

What does MXToolbox show you?

The parsed output is divided into sections. The top section shows the delivery route as a visual timeline of server hops, highlighting any delays. Below that, SPF and DKIM information appears with pass/fail indicators.

The Headers Found section displays every header field in a table format (Return-Path, From, Authentication-Results, DKIM-Signature, etc.). If any item is highlighted in red, it requires your attention.

Gmail headers and DKIM failures

If your email was exported from Gmail and DKIM shows a failure, this may be caused by Gmail altering headers during the copy process. For accurate results, use the Show Original option in Gmail, then click Download Original to get an unmodified .eml file.

Not seeing any results after clicking Analyze Header?

Make sure you copied the full header block, not just the email body. The headers are everything above the first blank line in your .eml file. If you pasted body content (HTML or plain text), MXToolbox cannot parse it.

help me troubleshoot why MXToolbox is not showing parsed results for my email headers

Compare parsed results against your manual findings

Now that you have the structured MXToolbox output, compare it against what you recorded manually in Step 2. This is where discrepancies surface.

  • For each email, compare the originating IP shown in MXToolbox's hop timeline against the originating IP you recorded in your header-analysis notes. They should match.
  • Check the SPF result in MXToolbox's parsed output. Note which domain SPF validated for (this is the Return-Path/envelope sender domain, not necessarily the From domain).
  • Check the DKIM result and identify the signing domain (the d= value in the DKIM-Signature header). This tells you which domain cryptographically signed the message.
  • Check the DMARC result. DMARC passes only when SPF or DKIM aligns with the visible From header domain.
  • Note any red-highlighted warnings or errors in the MXToolbox output. These indicate authentication failures or missing signatures.

Why does SPF pass not mean the email is legitimate?

SPF validates the envelope sender (Return-Path domain), not the visible From address. An attacker can send from a server authorized by their own domain's SPF record while displaying a completely different From address to the recipient.

DMARC closes this gap by requiring alignment: the domain authenticated by SPF or DKIM must match the domain in the visible From header. An SPF pass without DMARC alignment means the email is not authenticated for the claimed sender. This is a critical distinction.

Pay special attention to any email where SPF shows "pass" but the validated domain differs from the From address. This is the most common pattern in spoofed emails that slip past basic checks.

Document your authentication findings

You have the parsed results from MXToolbox and the comparison against your manual findings. Now consolidate everything into a single structured reference file.

  • Open Notepad (press the Windows key, type Notepad, press Enter).
  • Create a new file and save it as auth-validation.txt inside your evidence folder.
  • For each email, record the following on separate lines: the email identifier (filename or subject), SPF result and the domain it validated for, DKIM result and the signing domain (the d= value), DMARC result and the policy (none/quarantine/reject), and your preliminary assessment of whether the email is legitimately sent by the claimed sender or is spoofed/unauthorized.
  • For the preliminary assessment, state your reasoning in 1-2 sentences. Reference specific evidence: "SPF passed for domain X but From header claims domain Y, indicating misalignment."
  • Save auth-validation.txt.

What does a good auth-validation entry look like?

Each email entry should follow a consistent structure. For example: Email identifier, then SPF result (pass/fail/neutral) with the domain it validated, then DKIM result with the d= signing domain, then DMARC result with the policy, then your verdict.

Your verdict is not the final risk classification. It is a preliminary statement about sender legitimacy based on authentication evidence alone. The full classification comes later when you combine this with IOC enrichment data.

Confirm your auth-validation.txt file is saved in the evidence folder with entries for every email sample you analyzed.

Not sure what to write for the preliminary assessment?

Focus on alignment. If SPF passed for domain A and the From header also shows domain A, and DKIM signed by domain A, write that authentication confirms the sender. If any of these domains differ from the visible From address, note the mismatch and flag it as potentially spoofed or unauthorized.

help me write my preliminary authentication assessment for this email

You now have structured authentication evidence for every email in your case. You know which emails have legitimate senders and which have authentication gaps. Next up, you'll extract every indicator of compromise from these emails and check them against threat intelligence databases to build the full evidence picture for your risk classifications.

Extract IOCs and Enrich with Threat Intelligence

You now know where each email came from and whether it passed authentication checks. But knowing an email looks suspicious is not the same as proving it is malicious.

To render a confident risk classification, you need to confirm whether the infrastructure behind each email (IPs, domains, URLs) is known-malicious. In this step, you will extract every indicator of compromise from your emails, check them against threat intelligence platforms, and build a consolidated evidence sheet that transforms gut feelings into documented proof.

In this step, get ready to:
  • Extract and defang all indicators of compromise from your email samples.
  • Enrich originating IPs on AbuseIPDB and suspicious URLs or domains on VirusTotal.
  • Record enrichment results in a consolidated IOC list with per-indicator assessments.
Extract indicators from each email

An indicator of compromise (IOC) is any observable artifact that signals malicious activity. For email investigations, these include IP addresses, URLs, domains, file hashes, and sender addresses.

  • Open your header analysis notes (header-analysis-email-1.txt, header-analysis-email-2.txt, etc.) from your evidence folder.
  • For each email, collect the following indicators and write them down:
  • Create a new file called ioc-list.txt in your iocs subfolder. Open it in Notepad.
  • Defang every indicator as you write it into the file. Defanging prevents accidental clicks or connections:

Use the following format in your ioc-list.txt file to keep each indicator structured:

IOC LIST - CASE 2026-07-20_CASE-001
================================================

EMAIL 1: [subject or filename]
------------------------------------------------
Type: IP
Value: 203[.]0[.]113[.]45
Source: Originating IP (bottom Received header)
Enrichment: [to be completed]

Type: URL
Value: hxxps://example[.]com/login
Source: Email body link
Enrichment: [to be completed]

Type: Domain
Value: example[.]com
Source: From header
Enrichment: [to be completed]

What does this format accomplish?

Each entry records the indicator type, the defanged value, and which email it came from. The Enrichment field is a placeholder you will fill in the next substep after checking each indicator against threat intelligence platforms.

Listing everything in one file gives you a single reference sheet for the final report, making it easy to spot patterns across multiple emails (like the same IP appearing in two different phishing attempts).

  • Save ioc-list.txt after entering all indicators from every email.
  • Confirm your file has at least one originating IP per email and any URLs or domains you found in the body.

Not sure what counts as an IOC?

If the email body contains no clickable links and has no attachments, you may only have the originating IP and the sender domain. That is fine. Not every email has many indicators.

If you cannot find the originating IP, revisit your header-analysis-email-X.txt file from Step 2 and look at the bottom-most Received: header entry.

Help me identify which parts of my email header are indicators of compromise.

Enrich indicators with AbuseIPDB and VirusTotal

Extracting IOCs tells you what infrastructure is involved. Enrichment tells you whether that infrastructure is already known to be malicious.

  • In your browser, navigate to https://www.abuseipdb.com.
  • Paste the first originating IP address (the real, non-defanged version) into the search box labeled Check an IP Address, Domain Name, Subnet, or ASN.
  • Click Check.

What does AbuseIPDB show you?

AbuseIPDB displays a report for the IP including an abuse confidence score rated 0-100, where 100 means the site is confident the IP is entirely malicious. You will also see the country of origin, ISP name, usage type (e.g., Data Center, Fixed Line ISP), total number of abuse reports, and the date of the most recent report.

The web version of AbuseIPDB has no usage limitations for manual lookups, so you can check as many IPs as you need.

  • For each originating IP in your IOC list, note down: the abuse confidence score, country, ISP, usage type, total reports, and most recent report date.
  • Repeat the lookup for any other IPs from your list that appeared in suspicious contexts.
  • Next, navigate to https://www.virustotal.com in your browser.
  • Paste a suspicious URL or domain from your IOC list into the search bar.
  • Review the VirusTotal results. For URLs, you will see the detection ratio showing how many security vendors flagged it as malicious out of the total number of vendors that reviewed it. For domains, you will see related activity including WHOIS data, passive DNS, and community comments.
  • Check the WHOIS tab if available. Note the domain registration date. Domains registered days or weeks before a phishing campaign are a strong indicator of malicious intent.
  • Repeat for each suspicious URL or domain in your list.

Zero detections does not mean safe

Fresh phishing infrastructure often shows zero detections on VirusTotal because it has not been reported yet. A domain registered two days ago with zero detections is more suspicious than a 10-year-old domain with zero detections. Combine the detection ratio with the domain age to form your assessment.

VirusTotal shows no results for your URL?

If a URL returns no results, it means VirusTotal has never scanned it before. This does not confirm the URL is safe. Try searching just the domain portion instead for broader context.

Help me interpret my VirusTotal and AbuseIPDB results for threat analysis.

Record enrichment results in your IOC list

You now have raw enrichment data from both platforms. The final task is recording these findings directly into your ioc-list.txt so every indicator has its evidence attached.

  • Switch back to ioc-list.txt in Notepad.
  • For each indicator, fill in the Enrichment field with: the tool used, the result (malicious, clean, or suspicious), and the key data point.

Here is an example of what a completed entry looks like:

Type: IP
Value: 203[.]0[.]113[.]45
Source: Originating IP (bottom Received header)
Enrichment: AbuseIPDB | Malicious | 87/100 confidence,
  42 reports in last 30 days, Hostwinds LLC, US

Type: URL
Value: hxxps://secure-paypa1[.]com/verify
Source: Email body link
Enrichment: VirusTotal | Malicious | 12/94 vendors
  flag as phishing, domain registered 3 days ago

Type: Domain
Value: secure-paypa1[.]com
Source: From header domain
Enrichment: VirusTotal | Suspicious | 0/94 vendors,
  but domain registered 2026-07-17 (3 days old)

Why record zero-detection results too?

Low or zero detections on fresh infrastructure is common and does not mean the indicator is safe. Recording this finding is still valuable because it documents that you checked. Combined with other evidence (like a newly registered domain or a mismatched Reply-To), zero detections on a fresh domain strengthens a SUSPICIOUS classification rather than weakening it.

  • Save ioc-list.txt after completing all enrichment entries.

Before you review your completed IOC list, think about this: based on what you have recorded so far, which email do you predict carries the highest risk? What evidence would confirm that prediction?

  • Review your completed ioc-list.txt file. Confirm that every originating IP has an AbuseIPDB result noted, and at least one URL or domain from each suspicious email has a VirusTotal result.

Your IOC list now contains documented, evidence-backed findings for every indicator you extracted. Each entry records what you found, where you found it, and what the threat intelligence platforms reported about it.

Some indicators still have empty Enrichment fields?

If an indicator is a private/internal IP address (like 10.x.x.x or 192.168.x.x), it will not appear on AbuseIPDB because it is not publicly routable. Note "Private IP - not externally routable" in the Enrichment field instead.

Help me complete my IOC enrichment results.

You have moved from raw suspicion to documented proof. In the next step, you will synthesize all of this evidence into a professional investigation report with clear risk verdicts for each email.

Write the Professional Investigation Report

Your IOC enrichment has given you the evidence to back up your verdicts. Now it's time to turn all that raw analysis into the deliverable that actually gets acted on.

A SOC investigation without a structured report is just notes on a desk. The report is what gives management and incident response a single document to make containment decisions from.

In this step, get ready to:
  • Write a metadata header and Executive Summary that gives readers the big picture in under a minute.
  • Document per-email risk classifications with evidence-based reasoning, a consolidated IOC table, and MITRE ATT&CK mapping.
  • Write Recommended Actions organized by urgency and proportional to your risk classifications.
Create the report file and write the Executive Summary

The Executive Summary is the first thing a manager or incident responder reads. It tells them immediately how many threats you found, how severe they are, and whether immediate action is needed.

  • Create a new file called INVESTIGATION-REPORT.md inside your report folder. Right-click inside the report folder, select New, then Text Document.
  • Rename the file to INVESTIGATION-REPORT.md (make sure to replace the .txt extension with .md). If you prefer plain text, name it INVESTIGATION-REPORT.txt instead.
  • Right-click the new file, select Open with, and choose Notepad.
  • Start the report by writing a metadata header using this structure as your guide:
# Email Threat Investigation Report

## Metadata
- **Case ID:** [[CASEID="your case folder name, e.g. 2026-07-20_CASE-001"]]
- **Date:** [[REPORT_DATE="today's date"]]
- **Analyst:** [[ANALYST_NAME="your name"]]
- **Emails Analyzed:** [[EMAIL_COUNT="number of emails you investigated"]]

What does this metadata do?

The metadata header makes the report traceable. If this report gets escalated to a senior analyst or forwarded to management six months later, anyone can immediately identify who wrote it, when, and what scope it covers.

  • Below the metadata, write your Executive Summary. This is 4-6 sentences covering five things: what triggered the investigation, how many emails were analyzed, how they were classified (e.g., "Of 3 emails analyzed, 1 was classified SAFE, 1 SUSPICIOUS, and 1 MEDIUM RISK"), the most significant finding, and the overall risk to the organization.
  • Use this structure as a guide for the Executive Summary:
## Executive Summary

This investigation was initiated in response to [what triggered it, e.g. flagged
emails reported by users or detected by gateway]. A total of [number] emails
were analyzed. Of these, [breakdown of classifications, e.g. 1 SAFE, 1
SUSPICIOUS, 1 MEDIUM RISK]. The most significant finding was [your most
critical discovery, e.g. a phishing email with a confirmed malicious domain
targeting credential theft]. The overall risk to the organization is [your
assessment based on the severity and scope of findings].

Write from your actual findings

Replace the bracketed placeholders with your real investigation data. Pull the classification breakdown from the verdicts you reached in Steps 2-4. The most significant finding is whichever email had the strongest evidence of malicious intent.

  • Save the file.
  • Confirm your report now has a metadata header with all four fields filled in, followed by an Executive Summary of 4-6 sentences.

Not sure what risk classification to use?

Use SAFE when authentication passed, IOCs came back clean, and headers showed no red flags. Use SUSPICIOUS when you found some indicators (mismatched Reply-To, low-score IOCs, unusual routing) but nothing confirmed malicious. Use MEDIUM RISK when you have confirmed malicious infrastructure, failed authentication, or multiple strong indicators.

Help me decide risk classifications for my emails.

Write the Email-by-Email Analysis and MITRE ATT&CK mapping

This is the core of your report. Each email gets its own analysis block with a verdict backed by specific evidence from your header analysis, authentication validation, and IOC enrichment.

  • Below the Executive Summary, add the Email-by-Email Analysis section. Write one analysis block per email using this structure:
## Email-by-Email Analysis

### Email 1: [subject line or filename]
- **Sender:** [sender address from the From header]
- **Date Received:** [date from the Date header]
- **Risk Classification:** [SAFE / SUSPICIOUS / MEDIUM RISK]
- **Evidence-Based Reasoning:**
  [3-5 sentences explaining WHY you assigned this classification.
  Reference specific findings: originating IP reputation, authentication
  results, header mismatches, IOC enrichment scores, domain age, etc.]

What makes good evidence-based reasoning?

Reference concrete data points from your earlier analysis files. Instead of "this email looked suspicious," write something like "SPF passed for a domain that does not match the visible From address, the originating IP (defanged) has an AbuseIPDB confidence score of 72/100 with 15 reports in the last 30 days, and the Reply-To domain was registered 4 days before the email was sent."

  • Repeat the analysis block for each email you investigated. Pull your findings from header-analysis-email-1.txt, header-analysis-email-2.txt, auth-validation.txt, and ioc-list.txt.
  • After all individual email analyses, add a consolidated IOC table. This pulls every indicator from your ioc-list.txt into one view:
## Consolidated IOC Table

| Type | Value (Defanged) | Associated Email | Enrichment Result | Assessment |
|------|-----------------|------------------|-------------------|------------|
| IP | 192[.]168[.]1[.]1 | Email 1 | AbuseIPDB: 87/100 | Malicious |
| URL | hxxps://example[.]com/login | Email 2 | VT: 12/94 vendors | Malicious |
| Domain | example[.]com | Email 2 | VT: 5/94, 3 days old | Suspicious |

What goes in each column?

Type is IP, URL, Domain, Hash, or Email Address. Value is always defanged (dots replaced with [.], http replaced with hxxp). Enrichment Result is the key data point from AbuseIPDB or VirusTotal. Assessment is your verdict on that specific indicator: Malicious, Suspicious, or Clean.

  • Replace the example rows with your actual IOCs from ioc-list.txt. Include every indicator you extracted and enriched.
  • Below the IOC table, add the MITRE ATT&CK mapping section. This maps your findings to the industry-standard threat classification framework:
## MITRE ATT&CK Mapping

| Technique ID | Technique Name | Tactic | Applicable Email(s) | Rationale |
|-------------|---------------|--------|---------------------|----------|
| T1566.001 | Spearphishing Attachment | Initial Access (TA0001) | [emails with malicious attachments] | [why this applies] |
| T1566.002 | Spearphishing Link | Initial Access (TA0001) | [emails with malicious URLs] | [why this applies] |
| T1204.001 | Malicious Link | Execution (TA0002) | [emails requiring user click] | [why this applies] |
| T1204.002 | Malicious File | Execution (TA0002) | [emails requiring user to open file] | [why this applies] |

How do I pick the right technique?

For phishing emails, the primary technique is T1566 (Phishing) under the Initial Access tactic (TA0001). Use T1566.001 (Spearphishing Attachment) if the email uses a malicious attachment. Use T1566.002 (Spearphishing Link) if it uses a malicious URL.

If the attack requires the user to click or open something, also map T1204 (User Execution) under the Execution tactic (TA0002). Use T1204.001 (Malicious Link) or T1204.002 (Malicious File) depending on the payload type. Only include rows that actually apply to your emails.

  • Fill in the MITRE ATT&CK table with only the techniques relevant to your specific emails. Remove any rows that do not apply.
  • Save the file.
  • Scroll through your report. You should now see four distinct sections: Metadata, Executive Summary, Email-by-Email Analysis (with per-email verdicts), and the consolidated IOC table followed by MITRE ATT&CK mapping.

Not sure which emails are SAFE vs. SUSPICIOUS?

Go back to your auth-validation.txt and ioc-list.txt files. An email is SAFE when all three authentication checks pass with alignment AND all IOCs come back clean. The moment you have one failed check or one flagged indicator, the email moves to SUSPICIOUS at minimum.

Help me classify my emails based on my findings.

Write the Recommended Actions section

The Recommended Actions section turns your findings into decisions someone else can act on. The key principle is proportionality. SAFE emails need no action. SUSPICIOUS emails may warrant monitoring. MEDIUM RISK emails require immediate containment.

  • Below your MITRE ATT&CK mapping, add the Recommended Actions section. Organize it into three categories using this structure:
## Recommended Actions

### Immediate
- [Actions to stop threats NOW. Only for MEDIUM RISK emails.]
- Example: Block sender domain at email gateway
- Example: Quarantine messages from all recipient mailboxes
- Example: Block originating IPs at the firewall

### Investigative
- [Actions to understand scope.]
- Example: Search mail logs for other recipients of the same campaign
- Example: Check proxy logs for users who visited phishing URLs
- Example: Correlate originating IPs against other recent alerts

### User-Facing
- [Actions to protect affected users.]
- Example: Notify recipients of MEDIUM RISK emails
- Example: Advise password reset if credentials may have been entered
- Example: Send awareness alert if campaign is widespread

Why three categories?

Immediate actions stop active threats. Investigative actions determine whether the problem is bigger than what you found. User-Facing actions protect people who may have already interacted with a malicious email. Separating them ensures each recommendation reaches the right team.

  • Replace the example bullets with your own recommendations based on your findings. Only include Immediate actions for emails you classified as MEDIUM RISK. For SAFE emails, you may write "No action required" in the Immediate section.
  • Save the file.

Be specific in your recommendations

Instead of generic advice like "block the sender," reference the actual defanged indicators from your IOC table. For example: "Block domain evil-example[.]com at the email gateway" is actionable. A responder can copy that directly into their blocklist.

Before you check your final report, take a moment to predict: does your report have all four required sections?

  • Scroll to the top of your INVESTIGATION-REPORT.md file and read through the entire document from start to finish.

You should see all four sections present: Executive Summary, Email-by-Email Analysis (with per-email verdicts and evidence-based reasoning), consolidated IOC table with MITRE ATT&CK mapping, and Recommended Actions divided into Immediate, Investigative, and User-Facing categories.

Report feels incomplete?

Check that every email has all five fields filled in (Sender, Date, Risk Classification, and Evidence-Based Reasoning). Check that your IOC table includes every indicator from ioc-list.txt. Check that your MITRE ATT&CK mapping only includes techniques that actually apply to your emails.

Help me check if my investigation report is complete.

✔️ Awesome, I've got everything!

Your professional investigation report is complete. Make sure the file is saved in your report folder.

ⓧ I'd like to double check the full structure

Your completed report should contain these sections in order. Scroll through and confirm each one is present:

  • Metadata header (Case ID, Date, Analyst, Emails Analyzed).
  • Executive Summary (4-6 sentences with classification breakdown).
  • Email-by-Email Analysis (one block per email with Sender, Date, Risk Classification, Evidence-Based Reasoning).
  • Consolidated IOC Table (Type, Value defanged, Associated Email, Enrichment Result, Assessment).
  • MITRE ATT&CK Mapping (only techniques that apply to your emails).
  • Recommended Actions (Immediate, Investigative, User-Facing).

Secret mission

The Authentication-Passing Threat

You have classified emails based on authentication failures, header mismatches, and malicious infrastructure. But what happens when an email passes every automated check and still poses a threat? In this mission, you investigate an email that SPF, DKIM, and DMARC all approve, and prove that behavioral analysis catches what technical validation misses.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally with browser-based tools, so there are no ongoing costs.

Resources you created:

  • Case investigation folder on your desktop (e.g., 2026-07-20_CASE-001) containing evidence, iocs, and report subfolders with all investigation artifacts.
  • Browser sessions and search history on MXToolbox, VirusTotal, and AbuseIPDB.

Keep everything running

No action needed. Choose this if you plan to revisit your investigation, add more email samples, or refine your report.

  • Your case folder remains on your desktop with all evidence, IOC lists, and your final report intact.
  • Your VirusTotal and AbuseIPDB accounts remain active for future investigations.
  • Consider copying your INVESTIGATION-REPORT.md to a portfolio or cloud drive so you have a backup.

Pause - I'll come back to this later

Move your case folder off the desktop to reduce clutter while keeping your work accessible.

  • Move your case folder (e.g., 2026-07-20_CASE-001) from your desktop into your Documents folder or another archive location.
  • Close any open MXToolbox, VirusTotal, or AbuseIPDB browser tabs.
  • Your investigation files and accounts are preserved for when you return.

Delete - I don't want to use this again

Remove all project files from your machine. Your VirusTotal and AbuseIPDB accounts are not project-specific, so they stay unless you choose to delete them separately through those services.

  • Delete your case folder from the desktop. Open PowerShell and run the command below, replacing the folder name with your actual case folder name:
Remove-Item -Recurse -Force "$HOME\Desktop\[[CASE_FOLDER="your case folder name, e.g. 2026-07-20_CASE-001"]]"
  • Confirm the folder is gone by checking your desktop. The case folder should no longer appear.
  • Clear your browser history for MXToolbox, VirusTotal, and AbuseIPDB if you do not want any record of the searches you performed.

Nice Work!

Nice Work!

You just completed a multi-email threat investigation from raw headers to professional report. You now have a case file that demonstrates the exact workflow a SOC analyst uses to triage phishing alerts and escalate findings.

You've learned how to:

  • Trace email delivery paths through raw Received headers and validate SPF, DKIM, and DMARC authentication to determine whether a sender is legitimate or spoofed.
  • Extract and defang indicators of compromise, then enrich them against VirusTotal and AbuseIPDB to confirm whether infrastructure is known-malicious.
  • Produce a unified professional report with an Executive Summary, per-email risk classifications, a consolidated IOC table, MITRE ATT&CK mapping, and actionable recommendations that a SOC team can act on immediately.
  • Secret Mission: Investigated an email that passes all authentication checks and proved that behavioral analysis catches what automated validation misses.

Ready to quiz yourself?