I Built a Phishing Attack, Then Caught Myself: A Red Team vs. Blue Team Walkthrough

What running both sides of a phishing simulation taught me about how attacks actually happen — and why the "click rate" isn't the number that matters

Most people learn about phishing the same way: a slide with a screenshot of a suspicious email, a few red flags circled in red, and a "spot the difference" quiz. That's useful, but it's passive. You're told what to look for instead of understanding why the attack is built that way in the first place.

So this week, I decided to build one myself — end to end — in a fully isolated lab. Not to trick anyone, but to understand phishing from both directions: as the attacker crafting it, and as the SOC analyst who has to catch it.

Here's how it went, and what it actually taught me.

Setting Up the Lab

Before touching anything resembling an attack, I needed an environment where nothing could accidentally leave the lab. The setup:

• VMware — isolated virtual machine, no route to the real internet for sending mail
• Kali Linux — the OS running everything
• GoPhish — an open-source phishing simulation framework that real red teams use for authorized security awareness campaigns
• MailHog — a local SMTP server that catches every outgoing email instead of actually delivering it anywhere

That last piece is the most important one. By pointing GoPhish's sending profile at 127.0.0.1:1025 (MailHog's local listener) instead of a real mail server, there was no possible way for anything to reach a real inbox — even by accident. If you're building something similar, this is the non-negotiable first step.

Part 1: Wearing the Attacker's Hat

Picking the pretext

Every phishing email starts with a story, not a technical trick. Attackers don't succeed because of clever code — they succeed because the pretext makes the target want to act without thinking.

I went with something almost boringly common: a password expiry notice, appearing to come from an internal IT/security team. It's unglamorous, which is exactly why it works — it doesn't ask the target to believe anything unusual, just to do a routine task right now.

Building the attack in GoPhish

Sending Profile — I created a profile named "Sscope Attack" with the display name "Security Testing," sending through MailHog. The display name is deliberately mismatched from anything a target would recognize as external — a small detail, but one that matters a lot on the detection side later.

Target Group — Three test accounts I control, under a fictional domain (sscope.com). This is the ethical line with a tool like GoPhish: it makes importing a real employee list trivially easy, and doing that without written authorization crosses from "lab exercise" into something illegal. My group only ever contained accounts I own.

Email Template — Subject line: "Urgent: Your Portal Access Requires Immediate Attention." The body used three techniques stacked together:

• Urgency — a same-day deadline
• Authority impersonation — framed as an internal security team
• A single, unambiguous call to action — one button, no distractions

Landing Page — This is where I made a choice that surprised me once I thought it through: instead of a simple fake login page, I built a password reset form asking for the current password and a new one. At first this seemed like more work for the same result. It's actually more dangerous — a login page can capture a mistyped or half-remembered password, but a reset form that asks for the current password captures something a victim is far more likely to type correctly and confidently, because it feels like a routine task rather than a suspicious login attempt.

Launching it

Three emails went out. Two were opened. One recipient clicked the link, landed on the fake reset page, and submitted both password fields — captured, timestamped, and logged by GoPhish in real time.

Part 2: Watching It Land

Seeing the email arrive in MailHog's inbox view was oddly anticlimactic — it just looked like an email. Clean layout, plausible subject line, nothing screaming "attack" at a glance. That's sort of the point.

What the "victim" experience looked like: One recipient opened it, clicked without hovering over the link first, and filled out the form. From their perspective, they just reset a password like they've done a hundred times before.

What a better outcome would have looked like: A recipient who hovers over the button before clicking would see the actual destination URL doesn't match anything associated with their real company domain — a mismatch that's invisible in the rendered email but obvious the moment you check.

Part 3: Switching to the Blue Team

This is the part that actually matters for SOC work — because catching phishing isn't about being suspicious of everything, it's about checking specific things, in order, every time.

1. Check the headers, not just what's visible

The visible sender name said "Security Testing," but that's just a display name — trivially set to anything. In a real investigation, you'd go further: check the Return-Path, and verify SPF, DKIM, and DMARC results. If those authentication checks fail or are missing, that's a strong signal the sending domain isn't actually authorized to send on behalf of the identity it's claiming.

2. Check the link — hover, never click

The email displayed "Review Account Security" as the link text. The actual destination was a completely different URL. This display-text-vs-real-destination mismatch is one of the fastest, most reliable phishing tells there is, and it costs nothing to check — hover, read the status bar, done.

3. Read the content like an analyst, not a recipient

Three things stood out once I looked for them deliberately:

• A generic greeting ("Hello Team Member") instead of an actual name — mass phishing rarely personalizes
• Urgency language stacked deliberately to short-circuit careful reading
• An unusual request pattern — real password resets almost never ask for your old password on the same page as a new one. Legitimate systems use a one-time emailed token instead. This was, in hindsight, the clearest technical tell in the entire simulation.

4. Map it to something structured

This attack maps cleanly to MITRE ATT&CK T1566 (Phishing), specifically T1566.002 — Spearphishing Link. Mapping incidents to a framework like this isn't just paperwork — it's what lets a SOC team spot patterns across many incidents instead of treating each one as a one-off.

5. What happens next

In a real SOC, the response from here would be: block the sender domain, block the malicious URL at the proxy, search mail logs for anyone else who received the same email, and — critically — force an immediate password reset for anyone who submitted credentials, then check their account for any suspicious login activity that followed.

The Number That Actually Matters

Here's the full result set from the campaign:

3 sent → 2 opened → 1 clicked → 1 submitted credentials → 0 reported

Most people's eyes go straight to "1 clicked" as the headline number. It isn't. The number that should worry a SOC team is the last one: zero reported.

One person interacted with a phishing email and didn't flag it to anyone. That gap — between recognizing something was off and actually reporting it — is exactly what security awareness training is trying to close. A workforce that never clicks anything is unrealistic. A workforce that reports what it clicks is achievable, and it's the difference between an incident that gets caught in minutes versus one that sits undetected for days.

What I'd Do Differently Next Time

• Add a second, more sophisticated pretext (spear phishing with more personalized detail) to compare detection difficulty against this generic version
• Simulate a delayed "second-stage" — what happens after a credential is captured — to practice the incident response side more fully
• Deliberately build a landing page with better authentication signals (a real-looking padlock, closer domain match) to stress-test whether surface-level trust cues alone would have been enough to fool a less careful recipient

Why This Exercise Was Worth It

Reading about phishing indicators is fine. Building the attack yourself and then hunting for your own mistakes is a completely different kind of learning — you stop memorizing a checklist and start understanding why each item on it exists.

If you're working toward a SOC or security analyst role, I'd genuinely recommend doing this exact exercise in your own isolated lab. It's free (GoPhish and MailHog are both open source), it takes an afternoon, and it turns "I know what phishing indicators are" into "I've actually caught one."

Full technical write-up, screenshots, and IOC documentation are on my GitHub — link below.

https://github.com/ScriptedByArun47/phishing-simulation-redteam-blueteam.git

Currently building hands-on SOC and penetration testing experience toward an entry-level cybersecurity analyst role. If you're on a similar path or want to compare notes on lab setups, feel free to connect.