Phishing Incident Analysis

SOC Triage Lab — Email Header Forensics & Threat Intelligence

---

Objective

Methodically triage a real-world phishing email sampled from an open-source phishing repository. The goal was to reverse-engineer its origin using raw email headers, validate sender authenticity through SPF/DKIM/DMARC inspection, identify the social engineering tactics employed, perform threat intelligence lookups on the sending infrastructure, and produce actionable Indicators of Compromise (IOCs) for immediate organizational mitigation.

---

Table of Contents

• Scenario
• Skills Demonstrated
• Tools Used
• MITRE ATT&CK Mapping
• Analysis Walkthrough
  • Step 1 — Email Content Review
  • Step 2a — Raw Header Inspection
  • Step 2b — SPF Record Search
  • Step 3 — Header Analyzer Output
  • Step 4 — Sender IP Intelligence
  • Step 5 — Mitigation & Containment
• Email Authentication Summary
• IOC Summary
• Final Reflections
• Report

---

Scenario

A suspicious email was flagged and escalated to the SOC for analysis. The email claimed to be a Microsoft security alert notifying the recipient of unusual sign-in activity and prompting them to click a button to "report the user." The sample was sourced from a public phishing repository for safe, controlled analysis.

Attack type: Brand impersonation + email spoofing Target: End-user Microsoft account credentials Lure: Urgency / fear — unusual sign-in activity

---

Skills Demonstrated

Domain	Skill
Email Header Analysis	Tracing email origin via Received headers; identifying the true sending IP
Email Authentication	Interpreting SPF, DKIM, and DMARC results to detect spoofing
Threat Intelligence	AbuseIPDB lookups; hosting infrastructure analysis; abuse history scoring
Social Engineering Recognition	Identifying urgency, fear, and false branding as manipulation vectors
IOC Production	Extracting and documenting indicators of compromise for defensive action
Incident Response Documentation	Structured triage report mapping findings to mitigations

---

Tools Used

Tool	Purpose
MXToolbox	Email header parsing and authentication check visualization
AbuseIPDB	Sender IP reputation, abuse reports, and hosting provider lookup
URLScan.io / VirusTotal	Safe detonation and analysis of malicious URLs and domains
Text Editor (raw source)	Manual SPF/DKIM/DMARC search within raw email headers
Phishing Pot (GitHub)	Open-source repository of real phishing samples used as the test subject

---

MITRE ATT&CK Mapping

Technique ID	Name	Observed Behavior
T1566	Phishing	Malicious email delivered to end-user inbox
T1566.002	Phishing: Spearphishing Link	CTA button directing user to attacker-controlled URL
T1598.003	Gather Victim Identity Info: Phishing for Info	Microsoft account credential harvesting attempt
T1036	Masquerading	Sender impersonating Microsoft Account Team via spoofed display name
T1078	Valid Accounts	Objective: capture credentials to gain valid account access

---

Analysis Walkthrough

Step 1 — Email Content Review

Ref 1 — Email Body

The email presents as a Microsoft security alert warning of unusual sign-in activity on the recipient's account. Three social engineering signals are immediately present:

• Brand impersonation: Microsoft logos and formatting to establish false legitimacy
• Urgency / fear: "Unusual sign-in activity" creates a time-pressured emotional response
• Deceptive CTA: A "Report the user" button designed to harvest credentials via a phishing page

This matches the classic pretexting + urgency pattern documented in security awareness training.

---

Step 2a — Raw Header Inspection

Ref 2a — Raw Email Source (Header Analyzer)

The raw email source was submitted to MXToolbox's header analyzer, which parsed and simplified the Received header chain to reveal the true sending path. Two immediate inconsistencies were identified:

Field	Value
Display Name	Microsoft Account Team
From Address	no-reply@access-accsecurity.com
Return-Path	bounce@thcultarfdes.co.uk

The mismatch between the display name (Microsoft Account Team), the sending domain (access-accsecurity.com — not microsoft.com), and the bounce address (thcultarfdes.co.uk) is a textbook spoofing indicator. Legitimate Microsoft emails originate from microsoft.com or accountprotection.microsoft.com.

---

Step 2b — SPF Record Search

Ref 2b — SPF Search in Raw Source

Searching the raw source for spf= returned none — the sending domain has no SPF record configured. This is a significant red flag:

Legitimate corporate email senders publish SPF records to explicitly authorize which mail servers may send on their behalf. The absence of any SPF record means there is no mechanism to validate the sender, and any mail server in the world can claim to send as this domain.

Combined with the display name spoofing, this confirms the email is not from the claimed sender.

---

Step 3 — Header Analyzer Output

Ref 3 — MXToolbox Authentication Results

MXToolbox's authentication summary produced the following results:

Check	Result	Interpretation
SPF	none	Sending domain has no SPF record — sender cannot be validated
DKIM	fail	Digital signature is absent or invalid — email integrity unverified
DMARC	not evaluated	No DMARC policy to enforce alignment or request reporting

All three email authentication mechanisms failed. A fully spoofed legitimate email would typically pass SPF and DKIM. The fact that all three returned none/fail means the attacker made no attempt to spoof authentication — a signal that the sending domain is entirely attacker-controlled infrastructure, not a compromised legitimate domain.

---

Step 4 — Sender IP Intelligence

Ref 4 — AbuseIPDB Lookup

Analysis of the originating IP address via AbuseIPDB revealed three compounding risk factors:

Hosting Provider Misalignment The IP is registered to GHOSTNET GmbH, a generic data center / web hosting provider. Legitimate corporate email infrastructure (e.g., Microsoft 365, Google Workspace) does not originate from commodity hosting providers — it uses dedicated, well-documented IP ranges published in their SPF records.

Significant Abuse History The IP had been reported 30 times by 10 independent sources on AbuseIPDB, establishing a documented track record of malicious or abusive activity. This elevates the IP to a high-confidence malicious indicator.

Analyst Vigilance Signal The ISP name "GHOSTNET" — while likely coincidental — shares a name with a historic state-sponsored APT campaign. Regardless of any relation, the name will immediately trigger elevated scrutiny from experienced analysts.

---

Step 5 — Mitigation & Containment

Ref 5 — Mitigation Actions

Based on the analysis findings, the following containment and mitigation actions were recommended:

• Block sending domain (access-accsecurity.com) and bounce domain (thcultarfdes.co.uk) at the email gateway
• Block originating IP in perimeter firewall / email security appliance
• Add IOCs to SIEM watchlist for retroactive alerting on historical matches
• Notify affected users who received the email — advise against clicking and prompt credential rotation if interaction occurred
• Raise awareness with a targeted phishing awareness reminder to the affected user population

---

Email Authentication Summary

Protocol	Result	Risk Signal
SPF	none	Sending domain publishes no authorized senders
DKIM	fail	No valid cryptographic signature on message headers
DMARC	none	No policy to enforce alignment or generate abuse reports

All three authentication checks failed — a triple failure that provides high-confidence confirmation of email spoofing.

---

IOC Summary

Type	Indicator	Confidence
Sender Domain	access-accsecurity.com	High
Bounce Domain	thcultarfdes.co.uk	High
Sending IP	GHOSTNET GmbH-hosted IP (see report)	High
Display Name Spoof	Microsoft Account Team	High
SPF Result	none	High
DKIM Result	fail	High
AbuseIPDB Reports	30 reports / 10 sources	High
Lure Type	Unusual sign-in activity (urgency/fear)	Confirmed
CTA	"Report the user" credential-harvesting button	Confirmed

---

Final Reflections

This lab demonstrates the structured SOC triage workflow applied to a real phishing sample. The analysis moved through three distinct layers:

1. Content layer — identified the social engineering lure (brand impersonation + urgency) and the deceptive CTA
2. Authentication layer — confirmed spoofing via SPF none / DKIM fail / DMARC none (triple failure)
3. Infrastructure layer — exposed the malicious origin via AbuseIPDB: commodity hosting provider with a documented abuse history of 30 reports across 10 sources

The combination of all three layers produced high-confidence IOCs that can be actioned immediately — domain blocks, IP blocks, SIEM rules, and user notification — without requiring sandbox detonation or malware analysis. This is the core value of structured email triage: rapid, evidence-based containment decisions.

---

Report

Download the Phishing Incident Analysis Report (PDF)

---

_{Built and documented by Brandon · SOC Triage · Email Forensics · Threat Intelligence}