The day after the crypto drainer case, another phishing IR came in. A BYOD (10.44.122.114) had a continue action on a URL that the firewall had flagged as a phishing site. Standard starting point. What made this one worth writing up separately is what the traffic pattern looked like after the click.
The Initial Contact
The phishing infrastructure resolved to 67.20.83.183, which came back confirmed on VirusTotal. Seventy-six seconds after the device made contact with the phishing site, the firewall sinkholed the connection. That’s a fast interception, and it tells you the domain was already known-bad at the network layer before the user finished interacting with it.
A peer analyst had submitted the same IP to the sector threat intelligence sharing service 17 minutes before this case came in. Close enough that we deferred our own submission rather than duplicate the report.
The Burst Pattern
This is the part that stood out. After the initial sinkhole interception, the traffic didn’t stop. It came back in two distinct bursts.
Burst one: 6 sessions. Burst two: 8 sessions. Between them, a 142-minute gap.
That gap is not random. A 142-minute delay between connection attempts is a retry timer, a built-in behavior where the malware waits a defined interval before trying again. This is deliberate design. Malware that hammers a C2 endpoint repeatedly generates obvious volume-based alerts. Malware that tries, waits 142 minutes, and tries again is harder to catch on session count alone.
Both bursts were blocked by the firewall. The sinkhole was doing its job.
Fixed-Size Check-Ins
The session sizes across both bursts were 1,822 to 1,827 bytes, near-zero variance. The same pattern we saw in the crypto drainer case the day before, different malware, same behavioral fingerprint. Fixed-size check-ins with minimal variance are a C2 communication pattern, not application traffic. The malware is sending a structured message of known length, waiting for a response, and repeating.
No visibility from the cloud sandbox on this one either. SSL on 443 meant the payload content wasn’t inspectable at the network layer. What the traffic pattern gave us was sufficient to make the call without it.
The Travel Site
One additional IP came up during the investigation: 45.60.98.86. It resolved to a travel booking site. VT came back clean, behavioral profile looked like normal web traffic, no indicators worth pursuing. Not every IP in a session log is meaningful. Part of the work is knowing when to stop pulling on a thread.
Containment
The destination IP was blocked at the firewall. The device was flagged in NAC as requiring a wipe before re-registration. The user was notified and credentials were rotated.
REN-ISAC submission deferred given the peer submission 17 minutes prior. No point in flooding the feed with duplicate reports on the same infrastructure.
The Pattern Across Two Days
Looking at this case alongside the crypto drainer from the day before, the fixed-size near-zero variance check-in pattern showed up in both. Different campaigns, different infrastructure, same C2 communication design. That’s useful signal for detection engineering: if you’re building rules around session size consistency, this behavioral pattern is worth encoding.
The 142-minute retry timer is also worth cataloguing. Knowing that some malware families implement multi-hour retry delays means that closing an investigation after an initial sinkhole hit without watching for follow-on traffic can leave you with an incomplete picture. Both bursts in this case were caught because the investigation stayed open long enough to see them.
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.