The alert started as a phishing IR. A BYOD (10.44.132.43) had a continue action on a phishing URL, meaning the user had clicked through a security warning and proceeded. That’s the starting point that turns a routine phishing flag into an active investigation.
Twenty-eight hours of logs. 9,101 sessions. By the end of it the picture was clear enough to call: crypto drainer.
The Payload
The first thing worth looking at was a 22MB SSL payload from 216.198.79.1. That IP came back flagged on VirusTotal as associated with crypto scam infrastructure. 22MB is a meaningful data point: that’s a substantial payload for what most people think of as a “phishing site.” Crypto drainers aren’t simple credential-harvesting pages. They’re JavaScript-heavy applications that interact with browser-based cryptocurrency wallets, request transaction approvals, and drain funds in a single user interaction. The file size fits.
No visibility from the cloud sandbox on this one. The SSL encryption on port 443 means the payload content wasn’t inspectable at the network layer. What we could see was the size, the source, and the VirusTotal verdict on that source IP.
The Beaconing
After the initial payload, the device started beaconing to Cloudflare infrastructure. 180 sessions, 300-second interval, 66 bytes received per session with zero variance across all 180 sessions.
Zero variance is the key detail. Network traffic has noise. Even automated processes that check in on a regular schedule will show some variation in response size due to server-side differences, header changes, timestamp variations. 66 bytes received, identical, across 180 sessions is not normal application behavior. That’s a heartbeat signal, checking whether a command and control channel is still alive and waiting for instructions.
The beaconing was blocked by the firewall. The C2 channel never fully established, which limited what the malware could actually do after the initial infection.
The RFC 1918 Probe
One additional indicator worth noting: the device attempted a connection to 192.168.68.72, a private RFC 1918 address. That probe was blocked.
Malware probing internal RFC 1918 space is a reconnaissance behavior. It’s looking for other devices on the local network, mapping what’s reachable, potentially identifying targets for lateral movement. On a BYOD device that’s connected to a campus network, that behavior is worth flagging explicitly even when blocked. The malware was looking around.
Assessment
Crypto drainer. The combination of a large SSL payload from a known-bad IP, zero-variance Cloudflare beaconing at a fixed 300-second interval, and internal network reconnaissance is a consistent picture. The beaconing being blocked by the firewall limited the damage, and there’s no evidence of successful lateral movement from the network logs.
The financial impact, if any, would be on the user’s end: any connected cryptocurrency wallets that interacted with the drainer page. That’s not something network visibility can assess. The user was notified, given guidance on what to check (connected wallet approvals, recent transactions), and advised to rotate credentials.
Containment
The destination IP was blocked at the firewall. The device was flagged in NAC as requiring a wipe before re-registration. IOCs were submitted to the sector threat intelligence sharing service for broader awareness.
The wipe requirement is the right call for a confirmed crypto drainer on a BYOD. These applications are designed to persist and maintain wallet access. A user who cleans the obvious infection but doesn’t revoke wallet permissions is still at risk. The remediation guidance has to cover both the device and the wallet side.
This writeup describes an incident at a large institution. All internal IPs have been substituted with RFC 1918 ranges and identifying details have been generalized.