
Finding Gozi: An Italian Malspam Infection
An accounts clerk at an Italian textile firm clicked an overdue-invoice link, downloaded a ZIP, and opened an Internet shortcut that reached out over SMB to pull a second-stage loader. PowerShell and rundll32 ran the Gozi banking trojan, and the workstation began beaconing to a rotating list of bare IP-literal hosts over plain HTTP. Trace the chain from a link-based lure through an SMB stage-2 fetch to the single command-and-control endpoint the trojan settled on, where it also shipped the stolen data.
Start this operation
Investigation Tasks
Complete each task by investigating alerts and submitting your findings.
Triage the morning alert
0An accounts workstation at Borsani Tessile tripped the SIEM this morning: a routine invoice click that turned into an outbound file transfer on an unusual port, then a stream of plain web traffic to addresses with no names attached. Before you pull threads, get oriented. This case starts in a mailbox and ends on the perimeter, and the analyst who caught it has handed it to you. Review the available surfaces and the incident window, then begin working the delivery.
Trace the delivery
15The trail begins with one inbound message that slipped past sender authentication and pointed the recipient at a download instead of carrying the file itself, which kept it clear of the mail scanner. Establish who sent it.
Follow the shortcut off the network
20Downloading and opening the archive did not just present a document. A file inside it turned a double-click into an outbound connection to a separate attacker host on a port that should never leave the building, and that connection pulled the real payload. Identify the external host the shortcut reached out to.
Recover the second stage
15The file pulled across that connection was written to the user profile and then run. Recover the file name of the second-stage loader that the workstation fetched and executed.
Pin the C2 beacon
20Once the trojan ran, it tried a string of external addresses over plain web traffic, most of which went nowhere, before locking onto one and staying there through the day, including a large midday upload. To contain the host you need the address it settled on. Identify the primary command-and-control endpoint it kept returning to.
Classify the execution proxy
15For the incident report, classify how the attacker ran the banking trojan through a trusted, signed Windows binary instead of executing it directly. Map that evasive behavior to its MITRE ATT&CK technique.
6 tasks · 85 points total
Training Tools
Skills You'll Build
Requires foundational alert triage skills. Multiple data sources to correlate.
Prerequisites
- Basic understanding of security alerts
- Familiarity with SIEM concepts
- Familiarity with Firewall concepts
- Familiarity with XDR concepts
Ready to investigate?
More Operations
View allEvilProxy AiTM: Indeed Redirect to M365 Cookie Theft
An executive at a logistics firm clicks a job-themed phishing link that abuses a recruiting platform's open redirect to reach an EvilProxy adversary-in-the-middle page. The page reverse-proxies the real Microsoft 365 sign-in, so the victim completes MFA against the attacker, who captures and replays the post-MFA session cookie. Work the email, web-proxy, DNS, Entra sign-in, and perimeter records to reconstruct the redirect chain, the relay infrastructure, and the MFA bypass.
Lazarus: ManageEngine RCE to QuiteRAT Espionage
An internet-facing ManageEngine ServiceDesk Plus appliance at Caldermoor Networks, a regional network and internet service provider, falls to the unauthenticated SAML RCE (CVE-2022-47966). Code runs as the appliance service account, which curls down a QuiteRAT first-stage implant, profiles the host and domain, installs itself as an auto-start Windows service, and beacons to a single HTTPS C2 that carries control and stolen data alike before pulling a CollectionRAT second stage. Work the ManageEngine web logs, the endpoint process tree, and the perimeter egress to reconstruct the intrusion. North-Korea-nexus actor.
Public by Default: Sensitive Files Pulled From an Open Azure Blob Container
A sensitive-data exposure caused entirely by a storage misconfiguration. A developer set a production Azure Blob container's public access level to anonymous, an external actor swept the *.blob.core.windows.net namespace and found it, listed it with an unauthenticated List Blobs call, then bulk-downloaded the exports — including a config file with a SQL connection string and a nightly database backup — with AzCopy over anonymous HTTPS. Reconstruct the exposure from Azure Storage diagnostic logs and SIEM corroboration, classifying the discovery and collection techniques, in a case where nothing failed and no credential was ever used.