I got a phishing email in my personal inbox last week. Nothing new — but this one caught my attention.

I decided to break it down in my home lab. The goal was simple: find out where the stolen data was being sent.

1) Start with a copy, not the live thing

First rule: don't click links from your real machine. I saved the raw email (.eml) and opened it in an isolated lab VM.

From there, I pulled out:

  • Headers
  • Body content
  • Attachments (if any)
  • All URLs I could find

Keeping a copy means the email can't change later. Some phishers rotate links.

2) Check the headers first

Headers reveal a lot. I looked at:

  • From vs Return-Path mismatch
  • SPF/DKIM/DMARC results
  • Received chain to find the real sending IP

I noted the IP, ASN, and region. No assumptions yet — just collecting data.

3) Extract every indicator

I pulled every possible clue:

  • Links hidden behind buttons
  • Shortened URLs
  • Open redirects
  • Attachment hashes

I decoded anything suspicious:

  • Base64-encoded strings
  • URL-encoded params
  • Tokens like id=, email=, etc.

This gave me a shortlist of targets to investigate.

4) Open safely and capture traffic

I spun up a fresh VM, started packet capture, and opened the phishing link there.

Steps I followed:

  1. Start capture.
  2. Visit the link.
  3. Click only what a normal victim would click — login, next, submit.
  4. Stop capture.

No real credentials. I used fake test data.

5) Follow the redirects

The link didn't go straight to a fake login page. It bounced a few times:

  • First domain → open redirect → final brand-lookalike page

I mapped every hop. Redirect chains often hide the real exfil domain.

None

6) Read the page source

I checked the HTML and scripts for:

  • <form action="..."> endpoints
  • JavaScript fetch calls
  • Hardcoded API URLs
  • Telegram bots or email forwarders

This is usually where attackers leave clues. And they did.

7) Watch where the data goes

I submitted fake credentials and watched the network tab + packet capture.

Right after clicking "Sign in," a POST request fired to a domain I hadn't seen yet. That was the real C2 server — the place receiving stolen data.

I confirmed by trying once more with different fake data. Same endpoint.

8) Pivot on the infrastructure

Attackers reuse stuff. I checked:

  • Certificate transparency logs
  • Favicon hashes
  • Analytics IDs
  • Hosting IP history

That led me to two more domains in the same phishing campaign.

9) Summarize the findings

Here's what I noted for my own records:

  • Exfil domain and exact path
  • IP + ASN
  • TLS certificate details
  • Redirect chain
  • Related domains discovered via pivots

Keeping it short makes it easier to reuse later.

10) Lessons from this

  • Don't trust the first domain. Many are just redirectors.
  • Page source often exposes the real exfil URL.
  • Favicon hashes and analytics IDs are underrated pivots.
  • Never test with real credentials.
  • Always analyze in a controlled lab.

My simple toolkit

  • Email client that shows raw headers
  • Isolated VM
  • Browser + network capture (Wireshark/tshark)
  • URL/Base64 decoders
  • Certificate transparency tools
  • WHOIS/RDAP lookups

Final thoughts

I didn't need any exploits or hacking tricks to find the C2. Just careful observation and a repeatable process.

Phishing emails aren't always dangerous if you handle them safely. Sometimes they make for the best lab exercises.