Phishing Alert ID: 257 · Writeup

// Lab Objectives

Email analysis inspecting headers, sender, subject, and body for indicators of phishing
Understanding attack patterns recognising social-engineering hooks like fake giveaways
Email attachment analysis handling password-protected ZIP payloads safely
Confidence and validating alerts making a verdict with limited evidence

Background

The reason I wanted to solve this lab is that even when our security team and tools are working excellently, attackers can still get into an organisation by manipulating users. We need to educate employees, and at the same time we need to catch phishing emails before users click anything.

When I started this lab, I assumed I'd get all the necessary details handed to me. That's not how it works. There's a difference between real-world email alerts and the evidence we receive in labs labs often give limited evidence. The trick is this: if you can validate correctly with limited details, then in the real world (with more evidence) validation becomes easier. Sometimes more evidence even creates more confusion if you don't have a method.

Tools Used

This lab didn't require any external tools everything I needed (including a threat-intel platform) was provided inside the LetsDefend environment. The only external reference was the MITRE ATT&CK framework for mapping techniques.

Email Entity Threat Intel MITRE ATT&CK Endpoint Logs Terminal History

Walkthrough

The lab broke into 5 main phases. Here's how I approached each:

Initial Reconnaissance

I opened the alert page first. From there I pulled the basic facts: who the sender was, who the recipient was, and what the email subject said. Those three fields alone usually tell you whether something deserves a closer look.

I immediately searched the sender IP in the threat-intel platform provided by LetsDefend. While that was running, I re-read the subject line and it was already a red flag. The wording was clearly engineered to push the user into clicking a URL or opening an attachment.

Email Entity Investigation

Using the recipient's email ID, I went to the Email Security tab and searched for the user, which surfaced the phishing email itself.

Quick tip

Looking at the Email Entity confirmed the phishing verdict. The email contained a .zip attachment, the body offered a 'free coffee' promotion, classic social engineering bait, and there was a "Redeem" URL button that redirected the user to download a password-protected malicious ZIP.

Even when something looks suspicious, people still click out of curiosity or temptation. Instead of clicking blindly, 3–5 minutes of basic investigation is usually enough to determine whether a URL or attachment is malicious.

Exploitation

Using the username, I searched the endpoint inventory and found the user's device. (In the real world I'd pivot on device ID or UPN, but in this lab the username was what I had.) Once on the device, I checked the browser history and confirmed the user had downloaded the attachment, the likely entry point for the compromise.

Where I got stuck

Initially I couldn't figure out how to confirm whether the user actually opened the attachment. I went through every process I could see and got nowhere. I almost started checking each artefact one by one but in security, patience is the actual skill. I took a 2-minute break, looked at the UI as a whole, and that's when I noticed the Browser History tab. The download was right there.

Post-Exploitation

After the attachment was opened, the attacker started discovery like system info, disk info, network info, running processes. Terminal history showed enumeration commands being executed back-to-back with only 5–6 seconds between them, which strongly suggests automated or scripted activity rather than manual user behaviour.

Terminal History observed commands

systeminfo
whoami /all
net user
ipconfig /all
tasklist
netstat -ano
wmic logicaldisk get name,size,freespace

Response Actions

Once the chain was confirmed, the response actions were:

Isolate the device to prevent lateral movement.
Reset the user's credentials and revoke all active sessions.
Run a full antivirus / EDR scan on the host.
Add the malicious file hash and sender IP as IOCs.
After investigation is fully complete, wipe and rebuild the device.

// Defender Takeaways

If I saw this in a real SOC, I'd handle it like this:

Even though this was a lab, every step here leaves traces in real telemetry. Here's the playbook I'd apply on a live alert:

Validate, then respond fast once the alert is confirmed as a true positive, immediately check whether the user clicked the link or downloaded the attachment. Response actions come right after; deeper investigation and the report come last.

Detect password-protected archives in mail flow Alert on inbound emails containing .zip / .rar attachments where the password is embedded in the email body. This bypasses most AV scanning and is a well-known phishing pattern.

Detect rapid host-discovery sequences chained execution of systeminfo, whoami, ipconfig, tasklist, and netstat within a short window from a single process tree is high-fidelity evidence of post-exploitation enumeration.

→ See the full set of related detection rules on the Detections page.

Key Learnings

Beyond the lab itself, here's what I'm taking back to the SOC desk:

Limited evidence is still evidence

You won't always get the full picture. Build a verdict from what's in front of you and clearly state your confidence level.

Patience beats panic

When you're stuck, stop scrolling. Step back, look at the whole UI, and the missing artefact is usually one tab away.

Click vs. download is the key question

Confirming whether the user actually executed the payload changes the entire severity and response path of the incident.

Map to MITRE early

Tagging techniques (T1566.001, T1059, T1082, T1033, T1049, T1057, T1083) while investigating gives the report structure for free.

What's Next?

This lab fits into my broader path of building strong fundamentals in email-borne threats and Tier-1 SOC triage. Next, I want to go deeper into email header analysis (SPF / DKIM / DMARC) and full attachment sandboxing moving from "is this phishing?" to "what exactly does this payload do?"

After that, I'll be working through more LetsDefend SOC alerts to formalise the methodology.

References

LetsDefend Monitoring Event ID 257
MITRE ATT&CK techniques: T1566.001 (Spearphishing Attachment), T1059 (Command & Scripting Interpreter), T1082 (System Information Discovery), T1033 (System Owner/User Discovery), T1049 (System Network Connections Discovery), T1057 (Process Discovery), T1083 (File and Directory Discovery)