What's the best way to monitor for compromised internal hosts?

I'm a security architect at a mid-sized regional healthcare provider (around 1,200 employees). We use CloudGen firewalls at our datacenter edges and have spent the last two years building out our internal detection, primarily using our CloudGen Central logs shipped to Splunk alongside our Windows event logs.

My approach has been to treat the firewall logs not as a primary EDR tool, but as a critical source of truth for network-based evidence. Here's the breakdown of what that looks like in practice:

1. **Alerting on Beaconing/C2 Signatures:** The built-in Advanced Threat Protection (ATP) signatures are your starting point. I created a separate rule set for internal zones that specifically looks for known C2 traffic patterns (like known malicious IP/URL categories) and, more importantly, for beaconing. I set up a log-based alert for any internal host generating more than 50 outbound connections to the same external IP on non-standard ports within a 5-minute window. The magic number for us was tuning the "burst" threshold low enough to catch slow beacons without overwhelming the alert queue.
2. **Correlating Denies with Host Activity:** This is a manual Splunk search for us, but it's gold. We tag all firewall denies from internal zones with a "high_priority_internal" flag. My daily hunt includes a query that joins those denies (especially to known bad IPs or for unusual protocols) with the user login events from the source IP's subnet around the same time. It looks something like this:
```
index=barracuda Action=DENY src_ip=10.10.*
| join src_ip [ search index=wineventlog EventCode=4624 src_ip=10.10.* | table src_ip, user ]
| stats count by src_ip, user, dest_ip
```
This has caught several cases of compromised service accounts.
3. **Policy Tuning for Internal Zones:** We created a dedicated "Internal_Host_Outbound" access policy, separate from our edge rules. It uses much stricter application control (blocking Tor, unknown UDP services, rarely-used protocols) and enforces SSL inspection for internal user subnets heading to the internet. The biggest operational lift was managing the SSL inspection exceptions list for financial and HR sites, but it was necessary.
4. **The Logging Throughput Limit:** The honest limitation is in the volume of detailed logging you can feasibly ship. At my last shop, enabling full application control and threat logging for all internal traffic brought our Central Manager to its knees. You must be surgical. We now only log full-detail sessions for denies, ATP hits, and traffic from our "high-risk" server VLANs. For general user subnets, we aggregate and sample.

My pick is to use CloudGen as your network sensor and feed those logs into a SIEM or a dedicated analytics tool like Splunk or even a homegrown ELK stack. For your specific case, start by enabling ATP logging for internal zones and build that deny-log correlation search. If your budget can stretch, pair it with a proper EDR agent on your endpoints; the firewall sees what the network does, but the EDR sees what the process tree is doing. To make a cleaner call, tell us if you have a SIEM already ingesting these logs, and what your team's capacity is for managing custom correlation rules versus out-of-the-box alerts.

Hey hj! That's such a great, focused question. I love that you're thinking beyond the perimeter, because that's where the real game is lately.

On the suspicious outbound traffic patterns, you can do quite a bit with the CloudGen's Application Control and Web Filter features, even for internal hosts. One thing that's saved us is setting up specific Application Control rules that don't just block, but *alert* on traffic categories. For example, we created a rule that triggers an alert for any internal host making outbound connections categorized as "Anonymizer" or "Proxy Avoidance". That's been a surprisingly good early indicator of something trying to hide its tracks.

The logs are definitely your friend for correlation, but the trick is getting them into a SIEM or even just a good log management system. We use the Barracuda reporting features to generate a daily digest of all "Deny" actions for internal zones, broken down by source IP. It's a manual review, but seeing the same internal IP pop up repeatedly for trying to reach odd ports or known-bad IPs? That's your signal to start digging with a proper EDR tool.

Have you played with the CloudGen's built-in Threat Intelligence feeds? Tying those to your internal zone policies can auto-flag traffic to newly-reported malicious IPs, which feels like magic when it works.

Oh, that's such a key thing to watch for. I totally get the focus on suspicious outbound patterns. One thing we've added is a specific rule to alert on any internal host initiating a high volume of outbound connections to new or unique external IPs over a short period. It's noisy at first, but tuning it to ignore things like our CI/CD servers made it a great catch-all for weird scanning or data exfiltration attempts.

What about looking at the geo-location of outbound connections from standard user workstations? That was a real eye-opener for us. Spotting a regular accounting desktop suddenly talking to a server in a non-business country was an instant red flag. How do you handle that side of things?

Geolocation tracking on outbound connections is such a powerful, often overlooked, signal. You're absolutely right that it can be an eye-opener. The trick, in my experience, is building a sensible baseline of "expected" geolocations first.

We handle it by creating dynamic groups in our reporting. We built a list of countries where we have legitimate business partners, SaaS providers, and cloud regions we use. Any workstation or server connection outside that group generates a lower-priority alert, which gets reviewed. But we found you need an extra layer to avoid false positives from services like CDNs or benign websites using global hosting. So we also whitelist specific AS numbers for major cloud and content delivery networks, which cuts down the noise significantly.

Your point about the accounting desktop is perfect. It really highlights the value of contextualizing the alert with the user's role. Have you found a good way to automate that role-based context, or is it mostly a manual correlation step when you see the alert?

Your whitelist for AS numbers and countries sounds like a permanent maintenance sink. Who owns updating that list when a new SaaS vendor pops up or a cloud provider changes their infra?

Automating role-based context usually means tying your firewall logs to an inventory system, which creates another integration point that can break. Most shops I've seen just accept the manual correlation step because the alternative is another vendor and more complexity.

You're barking up the wrong tree relying on your perimeter box for internal detection. It's a log source, not a primary tool. Your workflow should start with proper endpoint visibility, not firewall policy tuning.

Focusing on firewall denies for internal threats is reactionary at best. By the time you see that, the host has already beaconed out and established a foothold. The call-home you're worried about often uses encrypted channels your NGFW can't crack without breaking compliance.

Real world? We found more by looking for internal lateral movement attempts, like SMB traffic from workstations to servers they have no business touching, than any outbound geo-location alert. CloudGen's internal zone filtering can help there, but most shops don't segment well enough for it to matter.

You're right that endpoint visibility is crucial. I've seen that firsthand. But I think you can use both, especially when you're in a mixed environment.

> Your workflow should start with proper endpoint visibility

For shops that are still migrating to modern EDR, or have a lot of non-agent devices like IoT or legacy systems, the firewall logs become that much more critical. They're a safety net for the blind spots.

I'm curious about the lateral movement point. How do you practically differentiate "no business touching" SMB traffic from legitimate but unusual admin activity at scale? Is that more about having really tight group policies defined first?

You've put your finger on the core challenge there. Differentiating suspicious lateral movement from legitimate but unusual admin activity is exactly where the rubber meets the road.

> How do you practically differentiate "no business touching" SMB traffic from legitimate but unusual admin activity at scale?

It's less about having perfect group policies from day one and more about using the logs to *build* them. You start with a broad alert for, say, SMB traffic from the general workstation subnet to your critical servers subnet. The first week will be all noise. But you review those logs to identify the legitimate admin connections - which admin workstations, which service accounts - and then you can start carving out precise allow rules. The leftover, unexplained traffic is your high-fidelity alert. It's an iterative process.

And you're right about the mixed environment safety net. For those legacy systems, that iterative log review is often the *only* way to establish a baseline of what "normal" even looks like.