heyosjabout
labs

Casefile: 'System Shutdown' Phish — Safe Redirect Triage + IOC Extraction

A repeatable email-triage workflow: preserve evidence, review headers, extract/defang links, safely resolve redirects (headers-only), and document IOCs + defensive actions.

Invalid Date5 min read

IOCs:

  • IP (redirector): 130.250.191.154
  • Domain (landing): shoecatphone[.]com
  • Domain (sender/infra): nandakan[.]com
  • URL pattern: /qs=<token>

OHHH NOOO NOT MY CLOUD

…anyway, let’s parse the headers. hunting-redirect-logic

What This Is

I got a suspicious email in my personal inbox. Instead of just deleting it, I treated it like a real incident and documented the full triage workflow. This casefile walks through safe analysis without ever clicking the link or executing anything.

Context: Random phishing attempt I received. Analyzed it in an isolated VM for practice and to document a repeatable investigation process.

Safety Constraints:

  • No browser interaction with landing pages
  • No JavaScript execution
  • No credential entry or form submits
  • Headers-only inspection via curl -I + passive recon

Evidence note: The exported .eml included multiple parts; I isolated the relevant message into msg1.eml before analysis.

Environment

Setup:

  • Host: macOS
  • Analysis VM: Kali Linux (VirtualBox)
  • Evidence: msg1.eml (standalone artifact)
  • Chain of custody: SHA-256 hash captured

msg1-eml

Evidence handling: The exported .eml included extra MIME content I didn’t need for this casefile. Since the header + relevant body were contained in the first ~290 lines, I carved that section into a standalone artifact (msg1.eml). Then I generated a SHA-256 so I can verify the file stays unchanged during analysis.

# carve + preserve
sed -n '1,290p' *.eml > msg1.eml
sha256sum msg1.eml | tee msg1.sha256

1. Header Triage

First step: understand what the email claims to be vs. what it actually is.

full-header-block-message-1

Quick signal: Before digging into the body, I pulled the high-signal header fields to understand what the message claims (Subject/From/Return-Path) and what the mail system observed (auth results + Received chain). I capped the output to keep it readable.

# quick signal
grep -nE '^(Subject|From|Return-Path):' msg1.eml
grep -nE '^(Authentication-Results|DKIM-Signature|Received):' msg1.eml | head -n 80

Looking for: auth failures, suspicious sender paths, unusual routing.

2. Extract The HTML Body

Raw .eml files are messy (MIME boundaries, encoding, embedded content). Extracted the HTML part to make link hunting clean and deterministic.

decoded-html-output

Body language: classic urgency tactics ("prevent data loss" / "update payment immediately").

3. Extract + Defang URLs

Pull every URL, defang them to prevent accidental clicks.

extracted-urls-from-msg1

URL extraction: I pulled every URL-like string from the decoded HTML into a file, then defanged the results so nothing is accidentally clickable when I paste it into notes/tickets.

# extract unique URLs
grep -Eo '(https?://[^"<> ]+)' msg1_body.html | sort -u > urls_raw.txt

# defang for safe handling
sed -E 's#https?://#hxxps://#g; s/\./[.]/g' urls_raw.txt > urls_defanged.txt

4. The qs= Tokens

Links used tokenized routing markers instead of clean paths:

  • /qs=op-…
  • /qs=r-…
  • /qs=ua-…

qs

What This Means: These tokens track individual recipients and campaign variants. More sophisticated than basic phishing—suggests operational tracking infrastructure.

Detection Value: High signal. Most legitimate emails don't use /qs= path tokens.

5. Normalize The IPv6 Artifact

Embedded links used IPv6-mapped format (::ffff:...). Converted to IPv4 for use in blocklists and detection rules.

ip_ioc

python3 << 'PY'
import ipaddress
ip6 = ipaddress.ip_address("::ffff:82fa:bf9a")
print("ipv4:", ip6.ipv4_mapped)
PY

Result: 130.250.191.154

6. Resolve Redirects (Headers Only)

Used HEAD requests to follow redirect chains without rendering the page.

curl -sS -I --max-time 10 "http://130.250.191.154/<qs_path>" | sed -n '1,30p'

shoecatphone-headers

Redirect chain:
130.250.191.154 → 302 → www.shoecatphone[.]com/<path>

This is the operational outcome: multi-stage redirect infrastructure leading to a separate landing domain.

7. Passive Infrastructure Recon

Collected DNS records and response headers from the destination domain.

dig +short A www.shoecatphone.com
dig +short AAAA www.shoecatphone.com
curl -sS -I --max-time 10 "https://www.shoecatphone.com/<path>" | sed -n '1,40p'

infra-info

Signals: CDN/proxy characteristics (Cloudflare), common for phishing operations to mask origin infrastructure.

Findings

Confirmed:

  • Multi-stage redirect infrastructure (130.250.191.154 → shoecatphone[.]com)
  • Tokenized tracking via /qs= path markers
  • IPv6-mapped addressing (uncommon, suspicious)
  • CDN proxying on destination domain
  • Urgency-driven social engineering language

MITRE ATT&CK:

  • T1566.002: Phishing (Spearphishing Link)
  • T1071.001: Web Protocols (redirect chain)
  • T1583.001: Acquire Infrastructure (Domains)

If This Hit Production

Block:

  • Domain: shoecatphone[.]com (DNS/proxy filter)
  • IP: 130.250.191.154 (firewall/proxy where applicable)

Hunt:

  • Email gateway logs: search sender patterns + subject line
  • Proxy logs: flag requests with /qs= paths
  • Email content: scan for IPv6-mapped addresses in URLs

Detect:

  • Alert on /qs= token patterns in email URLs (low FP rate)
  • Flag IPv6-mapped addresses (::ffff:) in email content
  • Monitor 302 redirect chains from email-sourced clicks

Escalate:

  • Check if any users clicked (email gateway click tracking)
  • Review credentials entered on landing page (if any)
  • Feed IOCs to threat intel platform

What I'd Do Differently

Gaps:

  • Should have pulled full Received: header chain for complete mail flow
  • Could have checked VirusTotal for historical context on IP/domain
  • Automate extraction + defang + IOC summary in one script.

Learned:

  • /qs= tokens are high-signal detection markers
  • IPv6-mapped addresses in emails are worth flagging
  • Headers-only analysis is fast and safe for initial triage

Next Time:

  • Build a small Python script for auto-defanging + IOC extraction
  • Create a Sentinel analytics rule for /qs= patterns
  • Document full SMTP routing chain (not just top headers)

Key Takeaways

  • IPv6-mapped addresses in email URLs = uncommon, worth investigating
  • Tokenized path routing (/qs=) suggests sophisticated tracking infrastructure
  • Headers-only inspection is safe and effective for redirect analysis
  • Multi-stage redirects complicate attribution but are traceable
  • Always defang IOCs before sharing (prevents accidental execution)

Commands

# preserve + hash
sha256sum msg1.eml | tee msg1.sha256

# header triage
grep -nE '^(Subject|From|Return-Path):' msg1.eml
grep -nE '^(Authentication-Results|DKIM-Signature|Received):' msg1.eml | head -n 80

# extract + defang URLs
grep -Eo '(https?://[^"<> ]+)' msg1_body.html | sort -u > urls_raw.txt
sed -E 's#https?://#hxxps://#g; s/\./[.]/g' urls_raw.txt > urls_defanged.txt

# pull qs= tokens
grep -RhoE '/qs=[^" ]+' msg1_body.html | sort -u

# headers-only redirect
curl -sS -I --max-time 10 "http://130.250.191.154/<qs_path>" | sed -n '1,30p'

# normalize IPv6 → IPv4
python3 -c "import ipaddress; print(ipaddress.ip_address('::ffff:82fa:bf9a').ipv4_mapped)"

Seen similar patterns? me@heyosj.com • @heyosj