Black Basta: Email Bomb to Encryption

Black Basta operators detonated their encryptor across the estate, and the compromised file server sits at the centre of the blast radius. Before you can contain, you need to know how far the operator reached from it. Working from the firewall record, determine the internal host the file server reached over server-to-server file-sharing traffic as the intrusion moved deeper into the network. Submit that destination host's IP.

Encryption is the last act; before it, the operators stole data. Telemetry shows a WinSCP SFTP session pushing an archive out to attacker-controlled infrastructure earlier in the intrusion. To understand which assets were exposed, identify the internal system that initiated that outbound transfer. Submit its IP.

Moving between the file server and the rest of the estate took more than stolen credentials — the operator stood up a relay to tunnel traffic through a compromised host. Triage of the activity around the Quick Assist session points to a binary dropped to disk to proxy connections deeper into the network. Examine the process and file-system artifacts and submit the exact name of that file.

The same infrastructure that received the stolen archive was reachable from inside long before exfiltration — it traces back to the social-engineering lure that opened the intrusion, a Teams approach from an external Microsoft tenant impersonating IT support. Correlate the early external-tenant contact with the later beaconing and submit the external domain the operators used as their command-and-control and exfiltration channel.

With the control domain established, you need IP-level indicators to feed containment and threat intel. Early in the intrusion the firewall recorded a spike of outbound traffic from a compromised internal system to an external host that does not belong to any sanctioned service. Identify the external destination address the internal host was reaching out to and submit it.

You now want to prove the command-and-control activity originated on the workstation where the remote-assist session ran, not somewhere downstream. Shortly after that session, the workstation began reaching out to attacker infrastructure. Examine the outbound activity from that host following the Quick Assist session and submit the external command-and-control IP it contacted.

The callbacks you traced did not come from an obviously malicious process — they rode inside a signed, trusted updater. The operators achieved durable execution by placing a malicious library alongside that updater so it would be loaded in place of the legitimate one (DLL search-order hijack). On the victim workstation, identify the planted library that the OneDrive updater loaded and submit its cryptographic hash so it can be blocked fleet-wide.

The planted library could only load because a process the operators controlled invoked it. Reconstruct the execution chain that began when the analyst was talked through the Quick Assist session: it spawns a command interpreter that ultimately launches the binary which side-loads that library. Walk the process tree to its final payload and submit the cryptographic hash of that executable.

Stepping back to how the operators first authenticated as the user: the social-engineering session let them harvest a session token, which they then replayed from their own infrastructure. The authentication telemetry early in the intrusion holds the external address behind that abuse. Inspect the early failed and anomalous logon activity and submit the external source network address tied to the credential/token replay.

Every thread you have pulled — the side-loaded library, the C2 callbacks, the stolen token — converges on a single endpoint: the workstation where an analyst was socially engineered into starting a Quick Assist session that handed the operators their first foothold. Close the investigation by identifying that originally compromised workstation from the network evidence and submit its internal IP so it can be isolated.