March 17th was a two-case day. Both involved C2 traffic. Both involved BYOD devices. Both got flagged and contained. They were not the same situation, and treating them the same way would have been a mistake. The difference came down to one field in the firewall logs.
Case 1: replevysquab.top
The domain name alone is worth a moment. replevysquab.top is the kind of name that comes out of a domain generation algorithm, random and nonsensical, and not something a legitimate service would register. When you see a DGA-style domain in your logs, the bar for “this is probably fine” is very high.
The scope of this one was the first thing that stood out. Over the week of March 10-17, we had 34,989 sessions across 76 hosts hitting the PAN sinkhole. The firewall had been intercepting traffic destined for this domain and redirecting it to the sinkhole IP, which means the malware thought it was reaching its C2 but was hitting a dead end. 76 hosts is a lot of noise, and noise and infection are not the same thing.
Separating Signal from Noise
This is where the firewall action field matters. Of those 76 hosts, the vast majority had block-continue actions. That means the firewall served a warning page and the connection stopped. The user did not proceed. The firewall worked.
One host (10.44.120.98) had continue actions. That means the user actively bypassed the warning and the traffic went through. That is a confirmed infected device, not a potentially exposed one.
A second host (10.44.140.144) had 1,168 block-continue sessions. High volume, but every single one was blocked. Not confirmed infected.
The investigation focused on 10.44.120.98. The beacon interval was approximately 60 seconds, which is a standard C2 check-in cadence. Consistent interval, consistent byte sizes, sessions spread across the day.
Domain Fronting
The Joe Sandbox community analysis on this one surfaced something worth noting: domain fronting via google.com. The malware was routing its C2 traffic through Google’s CDN infrastructure, using a legitimate domain as cover for the actual destination. This is a deliberate evasion technique. Network controls that only look at the outer layer of the request see Google, not the actual C2 endpoint.
No Threat Prevention or WildFire hits on this one, which means no confirmed payload delivery. The sinkhole was intercepting the C2 channel before anything could come through. Contained, but the device was still infected and beaconing.
Containment
The confirmed infected device was blocked at the firewall. The MAC address was blocked from NAC re-registration. The second device (10.44.140.144) was noted in the investigation record but not blocked outright, since every session had been successfully stopped by the firewall.
Case 2: entryway.world
Same day, different case. entryway.world is less obviously DGA than replevysquab.top but still not a domain you would expect to see in legitimate traffic.
85 sessions from a single guest BYOD (10.44.89.167), 9-second beacon interval, port 80 HTTP. The 9-second interval is aggressive, fast-polling C2 behavior. Port 80 is worth noting too: most modern C2 traffic rides SSL on 443 to blend in with normal web traffic. Port 80 is unencrypted and less common, which makes it easier to spot but also suggests either an older malware family or one that’s not particularly concerned about detection.
The sinkhole intercepted this one too. No Threat Prevention or WildFire hits.
The Guest Registration Problem
When I went to look up the device in NAC, the MAC address wasn’t there. Not blocked, not flagged, just absent. The most likely explanation is an expired guest registration. Guest portal registrations have a limited validity window in this environment, and when they expire the device drops out of NAC entirely. That makes attribution harder, with no user account tied to the device, no name, and no way to send a notification.
The containment options are the same regardless: block the MAC from re-registering at the guest portal.
This writeup describes incidents at a large institution. All internal IPs have been substituted with RFC 1918 ranges and identifying details have been generalized.