Two-Phase Lab Exercise
■ Phase 1 — Red Team
Attack simulation: GoPhish campaign setup, spoofed sender domain, Gmail SMTP relay, cloned M365 login page, SPF/DKIM/DMARC bypass analysis, credential capture.
■ Phase 2 — Blue Team / DFIR
Forensic investigation: email header analysis, SHA-256 evidence hashing, browser artefact recovery, network capture analysis, MITRE ATT&CK mapping, defensive recommendations.
The two-phase structure was deliberate: running the attack first gave a precise attacker's-eye view of every artefact left behind, making the forensic investigation significantly more thorough than starting from the defender side alone.
Lab isolation: all activities were performed in an isolated Kali Linux virtual machine with no connection to any real Microsoft infrastructure. The "victim" browser session was a separate local VM. No real user credentials were captured at any point.
Step 1 — GoPhish Campaign Setup on Kali Linux
GoPhish was installed and configured on Kali Linux as the phishing campaign management platform. The campaign tracked email opens, link clicks, and form submissions (credential capture) via GoPhish's built-in listener.
# Download and configure GoPhish on Kali Linux wget https://github.com/gophish/gophish/releases/download/v0.12.1/\ gophish-v0.12.1-linux-64bit.zip unzip gophish-v0.12.1-linux-64bit.zip -d /opt/gophish chmod +x /opt/gophish/gophish # Start GoPhish — admin interface on :3333, listener on :80 cd /opt/gophish && sudo ./gophish time="2024-03-15T09:00:01Z" level=info msg="Starting admin server at 0.0.0.0:3333" time="2024-03-15T09:00:01Z" level=info msg="Starting phishing server at 0.0.0.0:80" time="2024-03-15T09:00:01Z" level=info msg="Admin server started, username: admin" time="2024-03-15T09:00:01Z" level=info msg="Please login with the password provided in the output."
Step 2 — Spoofed Sender Domain
A typosquatted sender domain was created to mimic Microsoft: m1crosoft-notify.com (digit-1 substitution for the letter "l"). The display name was set to Microsoft 365 Account Team <noreply@m1crosoft-notify.com>. This is a common attacker technique — the display name appears legitimate to users who don't inspect the raw email address.
Step 3 — Gmail SMTP Relay & SPF/DKIM/DMARC Bypass
Gmail SMTP (smtp.gmail.com:587 with STARTTLS) was configured in GoPhish using an app password. This relay technique exploits a gap in email authentication:
- The email passes SPF because it's sent from a legitimate Gmail server — SPF validates the sending server's IP, not the From display name.
- DKIM is signed by Gmail's key for the
gmail.comdomain — but users see the spoofed display name, not the signing domain. - DMARC only fails if the organisation has set
p=reject— many still usep=none(monitoring only), allowing the email through.
# GoPhish SMTP config — Gmail relay with app password Sending Profile: Interface Name : gmail-relay SMTP From : noreply@m1crosoft-notify.com (spoofed display) SMTP Host : smtp.gmail.com:587 Username : attacker.lab@gmail.com Password : [app password - 16 chars] Ignore Cert Errors: false # SPF lookup on recipient MTA for relay IP nslookup -type=TXT gmail.com v=spf1 ... include:_spf.google.com ... ~all → Google's sending IP passes SPF — attacker email delivered as "SPF pass" # DMARC check on target domain (example — p=none passes through) nslookup -type=TXT _dmarc.example.com v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com → p=none = report only, no enforcement — email delivered without quarantine
Step 4 — Phishing Email Content
The email pretext: "Your Microsoft 365 password expires in 24 hours. Click below to reset your password and maintain access to your account." A time-pressure social engineering trigger combined with an impersonated trusted brand — two of the most effective phishing levers.
Step 5 — Cloned M365 Login Page
GoPhish's site importer was used to clone the Microsoft 365 login page structure locally. The landing page was served on the Kali Linux host at http://192.168.56.10/ (host-only network). All form submissions (username + password) were captured by GoPhish's listener and logged to the campaign results dashboard.
# GoPhish campaign results after simulated victim interaction Campaign: "M365 Password Expiry - Lab Test" Status : Completed Results: Emails Sent : 1 Emails Opened : 1 (100%) [tracking pixel loaded] Links Clicked : 1 (100%) [victim clicked reset link] Creds Submitted : 1 (100%) [username + password captured] Submitted Data: victim@lab.local Password: [captured — redacted in report] Source IP: 192.168.56.20 (victim VM) User-Agent: Mozilla/5.0 ... Chrome/120.0.0.0
Step 1 — Email Header Analysis
The raw email (.eml) was extracted from the victim VM's mail client and analysed header by header to reconstruct delivery path, identify spoofing, and trace the originating infrastructure.
# Raw email headers (abbreviated) — key forensic fields Return-Path: <attacker.lab@gmail.com> ← real return address ≠ From display Received: from mail-ot1-f68.google.com (209.85.210.68) by mx.victim-lab.local; Thu, 15 Mar 2024 09:05:33 +1100 Received-SPF: pass (google.com: 209.85.210.68 is permitted sender) ← SPF passes because Google is the actual sending server DKIM-Signature: d=gmail.com; s=20230601; h=from:to:subject... ← DKIM signed by gmail.com, not m1crosoft-notify.com From: "Microsoft 365 Account Team" <noreply@m1crosoft-notify.com> ← spoofed display name — typosquatted domain X-Gophish-Signature: [campaign tracking header — GoPhish artefact] Authentication-Results: spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com; dmarc=pass (policy=none) ← p=none means no enforcement action # Key finding: Return-Path ≠ From header → clear indicator of spoofed display name
Step 2 — SHA-256 Evidence Preservation
Before any analysis, all evidence files were hashed to establish chain of custody. This ensures artefacts have not been modified during the investigation — a standard DFIR practice.
# Hash all evidence files before analysis sha256sum phishing_email.eml landing_page.html chrome_history.db \ network_capture.pcap > evidence_hashes.txt Evidence Hash Record — 2024-03-15 09:30 UTC -------------------------------------------------- a3f2e8c91d4b...7f0e phishing_email.eml b7a1d3f05c8e...2a91 landing_page.html cc2941e0f17b...5d3c chrome_history.db e84f1a2970cd...8b4e network_capture.pcap # Verify hashes match after analysis (chain of custody check) sha256sum -c evidence_hashes.txt phishing_email.eml: OK landing_page.html: OK chrome_history.db: OK network_capture.pcap: OK
Step 3 — Browser Artefact Recovery
Chrome's SQLite history database and cache were examined for evidence of the victim's interaction with the phishing landing page — URL visited, form submission timestamp, and cached page resources.
# Extract Chrome browsing history from victim VM (SQLite) sqlite3 ~/.config/google-chrome/Default/History \ "SELECT datetime(last_visit_time/1000000-11644473600,'unixepoch'), url, title FROM urls WHERE url LIKE '%192.168.56.10%' ORDER BY last_visit_time DESC LIMIT 10;" datetime url title ------------------------------------------------------------------ 2024-03-15 09:05:44 http://192.168.56.10/ Sign in to your account 2024-03-15 09:05:41 http://192.168.56.10/?rid=abc (tracking redirect) # Extract Chrome login data (form autofill entries) sqlite3 ~/.config/google-chrome/Default/Login\ Data \ "SELECT origin_url, username_value, date_created FROM logins WHERE origin_url LIKE '%192.168.56%';" http://192.168.56.10/ | victim@lab.local | 2024-03-15 09:05:44 → Confirms credential submission to phishing page captured in Chrome autofill
Step 4 — Network Capture Analysis (HTTP POST)
Wireshark was used to analyse the network capture from the victim VM. The HTTP POST request containing the submitted credentials was visible in plaintext — demonstrating why HTTPS is required even on internal phishing infrastructure (and how defenders can detect credential submission events in proxy/IDS logs).
# Wireshark display filter — HTTP POST to phishing listener http.request.method == "POST" && http.host == "192.168.56.10" Frame 847: POST / HTTP/1.1 Host: 192.168.56.10 Content-Type: application/x-www-form-urlencoded Form data: username=victim%40lab.local password=[redacted in report] submit=Sign+in → Credentials transmitted in plaintext HTTP POST — visible to any network tap → In real attack via HTTPS, payload encrypted but DNS + TLS SNI remain visible # Extract GoPhish-specific tracking cookie from HTTP headers Cookie: gophish_rec=abc123xyz → GoPhish tracking identifier — unique per campaign recipient → Defensive use: proxy/IDS signature on "gophish_rec" cookie can detect GoPhish campaigns
Return-Path: attacker.lab@gmail.com vs From: noreply@m1crosoft-notify.com. The discrepancy between Return-Path and the From display domain is the primary indicator of spoofing. SPF/DKIM passed because Gmail was the legitimate sending server.
p=none — monitoring only. If the policy were p=reject, this email would have been blocked at the MTA. DMARC alignment failed (signing domain gmail.com ≠ From domain m1crosoft-notify.com) but no action was taken.
X-Gophish-Signature header present in raw email — a GoPhish artefact that can be used as a detection signature in email security gateways or SIEM. Real attacker-controlled tooling would strip or randomise this.
http://192.168.56.10/ and Chrome autofill logged a credential entry for that origin. Timestamps correlated with email delivery time, establishing a clear causal chain.
Attack Techniques Mapped
| Technique ID | Name | Tactic | Evidence |
|---|---|---|---|
| T1566.002 | Spearphishing Link | Initial Access | GoPhish campaign — targeted email with link to cloned M365 login page |
| T1598 | Phishing for Information | Reconnaissance | Credential harvesting form on cloned M365 login page |
| T1056.003 | Web Portal Capture | Credential Access | GoPhish listener captured username + password submitted to cloned portal |
| T1071.001 | Web Protocols (C2) | Command & Control | HTTP POST to GoPhish listener on port 80 — credential exfil over web protocol |
How to Detect & Prevent This Attack
p=reject DMARC policy would have blocked this email at the recipient MTA. Migration path: start with p=none to collect reports, move to p=quarantine, then p=reject once all legitimate sending sources are in SPF and signed with DKIM. This is the single highest-impact control for spoofing prevention.
X-Gophish-Signature headers. DNS monitoring should alert on newly registered lookalike domains (typosquatting). Proxy logs should flag HTTP POST submissions to external IPs not matching known login domains. Combine with threat intel feeds for phishing infrastructure detection.
Key Learning from This Lab Exercise
Practising both sides of this attack in the same lab exercise created a level of understanding that reading about phishing alone cannot achieve. Running the attack first produced a precise inventory of every artefact left behind — making the forensic phase much more targeted and thorough.
The most significant takeaway: SPF, DKIM, and DMARC are not independently sufficient. Each protocol solves a specific, narrow problem. SPF validates the sending server's IP — not the display name. DKIM validates message integrity and signing domain — not the From header domain. DMARC ties them together, but only enforces when p=quarantine or p=reject is set. Many organisations leave DMARC at p=none for years, providing monitoring but no actual protection.
Understanding attacker tradecraft at this level directly informs how I approach defensive detection engineering — knowing exactly what artefacts are left behind means writing better SIEM correlation rules and email security policies.