The first alert came in from the IDS flagging XOR-encoded C2 traffic from an internal host (10.44.146.80) to an external IP (107.151.183.81). One device, one destination, non-standard port. Not unusual on its own. What made it worth pulling on was the timing: every session was between midnight and 7 AM, and the ports were rotating through 1084, 2201, 7022, and 9999. Consumer apps don’t behave that way.
One Host Becomes Six
The first move after confirming the alert wasn’t to dig deeper on the original device. It was to query the firewall logs for any other host talking to 107.151.183.81.
That’s the triage sequence that matters here: IDS alert fires, you extract the destination IP and timeframe, then you use the firewall as a wide-angle lens. You don’t know the scope of an incident until you check.
The query came back with five additional hosts:
| Host | Notes |
|---|---|
10.44.146.80 | Original detection |
10.44.142.168 | Same beacon pattern |
10.44.113.22 | Same beacon pattern |
10.44.115.230 | Same beacon pattern |
10.44.146.224 | Same beacon pattern |
10.44.136.150 | Same beacon pattern |
All BYOD. All beaconing exclusively between midnight and 7 AM. All to the same destination. One device is an incident. Six devices on the same C2 infrastructure is a cluster, and the scope changes everything about how you respond.
What the IDS Caught
Beyond the XOR-encoded C2 alert, the IDS was flagging a range of behaviors on these hosts:
- MZ executable in response traffic. The DOS header is the calling card of a Windows PE file. Seeing one arrive over an unexpected channel is a strong indicator that a payload was being delivered.
- External IP lookup attempts. Malware checking its own external IP, common as part of geolocation logic or sandbox detection.
- DoH attempts. DNS-over-HTTPS is blocked in this environment, so the attempt didn’t succeed. The fact that the malware tried tells you something about how it was built.
- P2P traffic. Not common on managed networks and a known distribution and fallback channel for some RAT families.
- Discord DNS resolution. Discord’s CDN infrastructure gets abused heavily for malware hosting and C2. Resolution alone isn’t definitive, but in this context it fit the pattern.
- Tencent Cloud activity. Worth flagging as an infrastructure data point, not inherently malicious on its own.
The collective fingerprint identified the malware family as PcClient.bal, a Remote Access Trojan with a long history and a lot of variants. Not sophisticated, but effective enough to run undetected on six devices for long enough to establish a pattern.
Why the Firewall Didn’t Catch It
The short answer is that there was no deny rule for 107.151.183.81. The traffic was allowed by an existing egress policy, the destination IP wasn’t on any threat feed at the time, and there were no matching signatures for the threat prevention engine or cloud sandbox to fire on. The firewall did exactly what it was configured to do.
This is worth being direct about because it’s easy to frame this as a firewall failure. It wasn’t. The allow rule existed for a reason, and the firewall isn’t a magic box that knows in advance which IPs will eventually be used for malware C2. What this incident illustrates is the cost of allow-by-default egress posture: when something slips through on a permitted port to an unknown destination, the only thing left to catch it is behavioral detection.
Which the IDS did.
The after-hours traffic pattern was the tell. A 3 AM connection to a numeric IP on port 9999 doesn’t look like anything legitimate, and queries filtered by time-of-day surface things that daytime-baseline queries miss. The clock-time of traffic is signal.
Containment
Three steps, in order.
The destination IP was blocked at the firewall, which severed the C2 channel for all six hosts simultaneously.
All six source IPs were added to the EDR block list, which propagated the block to the endpoint layer and tagged the devices for remediation tracking.
All six MAC addresses were blocked from NAC re-registration. On a BYOD network you can’t reimage the device, you can’t run remediation scripts, and you can’t verify what the user actually does at home. What you can control is network access. A device that can’t re-register can’t reconnect until someone physically brings it in or the user confirms remediation through another channel.
Whether each user actually cleaned their device is an open question. That’s the honest reality of BYOD incident response.
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.