Fake Zoom to Ransomware: The Social Engineering Pipeline

CORP-WKS-102 (user adriana.garcia) is the first host paged in this incident. Early in the morning the user browsed to what looked like a Zoom download page, and moments later a process chain kicked off that the EDR later tied to this whole campaign. Work out exactly what was delivered to the endpoint: name the executable that landed on disk and ran, masquerading as the video-conferencing client.

You have named the fake Zoom installer that ran on CORP-WKS-102. Before that file spread any further, the IR team needs a durable indicator to push to the blocklist and to pivot across the estate. Recover the cryptographic file hash of that installer binary as the EDR and Sysmon recorded it.

The installer did not detonate its payload directly. On CORP-WKS-102 it spawned a chain of signed, trusted Windows utilities to stay under the radar of signature-based detection. Walk that process hierarchy to its deepest link and identify the legitimate system binary the attacker ultimately abused to compile and run their in-memory code.

Once the abused build utility was running in memory on CORP-WKS-102, it reached back out to its operator. The host's outbound traffic during the initial-access window should reveal where it called home. Identify the external internet address this compromised endpoint beaconed to so the channel can be blocked at the perimeter.

With a foothold and a C2 channel on CORP-WKS-102, the operator began authenticating to that workstation directly from outside the network. Within a day of the initial compromise the SIEM logged remote logon attempts against the host that did not originate from any corporate subnet. Pin down the external address the attacker was authenticating from.

Days after the initial intrusion, the operator returned to CORP-WKS-102 and dropped a fresh executable into the user's temporary AppData directory, running it under adriana.garcia to advance the operation. Recover the file hash of this second-stage binary so it can be hunted for across the rest of the environment.

The campaign’s objective was ransomware, and that means neutralising recovery options first. During the post-exploitation phase, the operator pivoted to the backup infrastructure on SRV-BACKUP-01 and ran tooling aimed at the backup product’s stored credentials. Identify the script used to harvest those credentials.

To keep a grip on the environment independent of the original victim, the operator provisioned their own local account on SRV-CONFLUENCE-01 and granted it administrative rights. Comb the Windows Security logs on that server for the account-lifecycle and privileged-group changes the attacker made, and determine the name of the account they stood up for persistence.

The operation eventually moved into its destructive phase: ransomware staging was kicked off from the domain controller and pushed outward. Rather than copying the encryptor by hand, the attacker leaned on a software-deployment service to roll it out at scale. Examine the EDR detections around the staging activity and identify the deployment service binary the attacker repurposed.

The deployment service did its job and the encryptor ran on CORP-WKS-102, closing the loop from a fake Zoom download to full ransomware impact. To attribute the activity to a specific ransomware family and complete the incident record, locate the ransom note the operator dropped on the host and report its exact filename.