Part 2: When Good Malware Fails (Operational Mistakes in the Wild)

Following the initial RBCD attack, the threat actor attempted a second infection on a different user. This time without AnyDesk. But sloppy execution and strong behavioral detection combined to stop the attack cold.

Let’s walk through how the second attempt unfolded, how it failed, and how simple cross-table KQL correlation helped us uncover the full story, including how the attacker tried hiding in the Recycle Bin.

Second Attempt: Same Payload, New Mistakes

Days after the original compromise, a familiar file showed up again: upd22.zip. This time, it arrived on a different machine, and no remote access tools were directly observed. However, Defender logs and file telemetry revealed a similar infection pattern.

Timeline of Events:

1. File Dropped
   upd22.zip appeared in Downloads\
2. Extracted and Renamed
   Contents included:
   • update.vbs
   • upd22.exe
   • update22.js
3. Files Moved to:
   C:\$Recycle.Bin (an attempt to hide them)
4. Executed via:

   WScript.exe "C:\Users\userName\Downloads\upd22\update.vbs"

❗❗ This was the fatal mistake ☠️☠️

Where It All Went Wrong (for the attacker)

Instead of executing from the hidden Recycle Bin path, the attacker ran the script from the Downloads folder which is a known monitored location.

This immediately exposed:

• Execution context (wscript.exe used to run VBScript)
• Full path of the payload
• Logged user session
• Command line parameters
• Process lineage

Defender quickly flagged:

Suspicious 'SuspDCSyncTraffic' behavior was blocked

Despite no signs of RBCD execution this time, the script’s behavior suggested attempted credential access or DCSync-like network activity and that was enough for Defender to stop it.

🔍 Hash Correlation: How We Found the Recycle Bin File

After retrieving telemetry on the upd22.zip event, we pivoted using the file hash to understand where else it appeared. This is where cross-KQL analysis came in.

Step 1: Find the SHA256 hash

DeviceFileEvents
| where FileName == "upd22.zip"
| project TimeGenerated, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessFileName

The hash returned was:

6e70b038319d48a87f14cb5fe70bb74a3026f74cb7640acd1ca13a4c16f0f845

Step 2: Search for that hash elsewhere, including Recycle Bin

DeviceFileEvents
| where SHA256 == "6e70b038319d48a87f14cb5fe70bb74a3026f74cb7640acd1ca13a4c16f0f845"
| where FolderPath contains @"\$Recycle.Bin"
| project TimeGenerated, DeviceName, FileName, FolderPath, ActionType, InitiatingProcessFileName
| order by TimeGenerated desc

Result: The exact same zip file had been moved into the Recycle Bin (Zip was renamed to $RJ6190V.zip ) prior to execution. This suggests the attacker attempted some manual OPSEC , but ultimately failed when executing from a visible path.

Key KQL for Threat Hunting

Locate suspicious ZIP

DeviceFileEvents
| where FileName == "upd22.zip"
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, FolderPath, SHA256

Find VBScript execution

DeviceProcessEvents
| where InitiatingProcessFileName =~ "wscript.exe"
| where ProcessCommandLine has "update.vbs"
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine

Confirm Recycle Bin movement

DeviceFileEvents
| where FolderPath contains @"\$Recycle.Bin"
| where FileName contains "upd22"
| project TimeGenerated, FolderPath, FileName, ActionType

These correlated views gave us full visibility across both filesystem and process telemetry, and tied activity back to the user and device.

Lessons Learned

• Behavioral detections > signature-based detection Defender never needed to know the malware, just what it tried to do.

• KQL pivoting across Defender tables is essential Cross-referencing DeviceFileEvents and DeviceProcessEvents allowed us to discover hidden files and execution patterns.

• Operational sloppiness ruins attacker OPSEC Moving malware to C:\$Recycle.Bin is meaningless if it’s executed from Downloads.

• No admin rights ≠ no danger Even portable apps and user-level script engines like WScript.exe can carry out serious attacks.

✅ Outcome

The attack failed completely due to:

• A poor execution path
• Defender’s behavioral alerting
• Proper monitoring of process and file telemetry
• Swift triage and hash pivoting

No lateral movement occurred. No RBCD this time. The actor got sloppy, and got caught.

Next Steps: Defensive Enhancements 🛡️

• 📁 Monitor execution from suspicious paths like Downloads, %Temp%, and Recycle.Bin
• ⚔️ Use ASR rules to restrict script execution (wscript.exe, mshta.exe, cscript.exe)
• 🧼 Implement auto-clean quarantine on malicious ZIP detections
• 🔁 Enrich detection with file hash tracking and cross-user correlation
• 👨‍🏫 Keep educating users on ZIP-based phishing, impersonation, and script-based malware

Final Thoughts

This is the kind of post-compromise activity that flies under the radar unless your detection strategy looks at what is being done, not just which file is being used.

Behavioral + correlated telemetry = detection wins.

Cheers 🐀