In this article, we take on the role of a SOC (Security Operations Center) analyst, analyzing a phishing alert related to a deceptive email with a malicious attachment sent to a user named Felix.
Letsdefend SOC282 Case Analysis
The alert flags a phishing email with the subject line “Free Coffee Voucher” sent to someone named Felix. It’s got all the red flags—an attachment and a sketchy-looking link. The analyst begins by combing through the basics: who sent it, who received it, what the subject says, and how the message traveled through the email system (that’s the SMTP path). The troubling part? The system didn’t block it. The device action logged it as “allowed,” meaning it slipped past the filters and landed right in Felix’s inbox.
The analyst claims responsibility for the alert and kicks off the case using a standard playbook. No improvising here—just sticking to proven steps. They open up the essential tools to get the job done: log management to trace events, endpoint security to check the device’s behavior, email security to dig deeper into the message, threat intelligence for any outside clues, and sandbox tools to safely test what the attachment actually does. Each one plays a part in piecing together the bigger picture.
Email and Attachment Analysis
The analyst digs into the email’s message. It’s a lure—offering a free coffee voucher to hook the recipient. Attached is a ZIP file called freecoffee.zip, locked with the password “infected.” That’s already a red flag. Plus, there’s a sketchy link in the body.
Having both a file and a URL bundled in one message raises the danger level quite a bit. Because security tools were blocking the download, the analyst has to temporarily whitelist it, basically telling the antivirus software to back off, just to pull the file down and see what they’re dealing with.
Sandbox Execution and Behavior Review
The analyst runs the ZIP file through the AnyRun sandbox, choosing a Windows 11 environment to see how it acts in real time.
Once executed, the file doesn’t waste any time. It starts showing traits linked to AsyncRAT, a well-known remote access tool.
This conclusion comes from two key clues: mutex artifacts that point to known RAT behavior and a YARA signature match that confirms it. Even worse, the file tries reaching out to a command-and-control server using a specific IP and port, showing it’s not just suspicious, it’s actively trying to phone home.
First up, YARA rules. These are sets of patterns used to spot malware based on how it looks and behaves. When the ZIP file got unpacked and run in the AnyRun sandbox, it tripped a YARA rule tied to AsyncRAT. That was the first solid clue.
Then there’s the mutex. Short for mutual exclusion object, it’s something malware often uses to stop itself from running more than once on the same machine. The one found during analysis was already known to be linked with AsyncRAT. Another check.
Next, the file tried reaching out to a command-and-control (C2) server. It attempted to connect to a specific IP and port, which lines up with how AsyncRAT typically phones home for instructions and sends back stolen data. That behavior alone raised serious flags.
To be extra sure, the file was also checked with VirusTotal. Several antivirus engines picked it up as a Trojan, and the file’s history and hash had already been flagged by the community before. That’s strong backup.
Finally, AnyRun’s behavioral analysis added more weight. It saw the file doing shady stuff—like hiding its presence, trying to stick around after reboot, and quietly sending data out. Those behaviors pushed the threat level even higher.
Put all these pieces together—pattern matches, sketchy behavior, C2 communication, and external confirmations—and you get a clear verdict: AsyncRAT.
Cross-validation via VirusTotal
VirusTotal confirms the threat, labeling the sample as a Trojan. Analysts retrieve the file’s hash and other community notes to enrich their understanding. The presence of multiple AV engines concurring on the threat emphasizes its severity.
Containment and User Impact Assessment
It all starts with checking if the email even made it through. The analyst goes back to the alert and checks the “Device Action” field. It says “allowed,” so yeah—the message got through to Felix’s inbox.
Next step: clean-up. The analyst heads into the Email Security console, locates Felix’s inbox, and deletes the phishing email. No chance of someone clicking it later.
But deleting the email isn’t enough. They need to know if it ran. So they check the logs—searching for any signs the infected file tried calling home. And they find it. Two hits showing the same C2 IP address that popped up in the sandbox analysis. Both from Felix’s machine. That’s confirmation the malware didn’t just land—it launched.
With that, it’s time to act. The analyst uses EDR tools to isolate the device. They find Felix’s machine, hit “Contain,” and boom—it’s cut off from the network. No more outbound chatter. Infection stopped in its tracks.
From there, they log the key evidence: the C2 IP, the attacker’s email, the shady domain, and the file’s hash. These pieces help build a stronger defense for the future, feeding threat intel and blocking similar attacks down the line.
Once everything’s contained and recorded, the analyst wraps up the case. It’s marked as a true positive, meaning it was a real threat. Every required question in the system is answered—even if the notes section was skipped.
All in all, it’s a textbook response: confirm delivery, clean up the email, look for signs of trouble, lock down the endpoint, log what matters, and close it out clean.
Endpoint Containment and Artifact Logging
Felix’s machine is contained using EDR tools. Artifacts like the C2 IP, sender email, attacker’s domain, and file hash are logged for future reference. This not only addresses the current incident but strengthens defense for future threats.
Case Closure
The investigation wraps up with the alert being marked as a “true positive.” No guesswork here—the signs of infection were clear, and every step lined up with policy. During the final review, all the required questions get a green check.
Even though the analyst didn’t fill out the notes section, the rest of the process held strong. From triage to confirmation, it walked through exactly how a phishing case should be handled in a SOC—methodical, focused, and by the book.
