Alright, so you've got that nagging feeling. Some weird outbound traffic spike, an odd domain in the logs, or maybe your EDR is throwing a fit about a process that shouldn't be talking to the internet. The usual suspect? A compromised host. Zscaler's your gatekeeper, so the evidence is in there... somewhere.
Manually clicking through the Admin portal is a special kind of torture when you're hunting. Here's how I script it. You'll need API credentials (Admin > Administration > API Key Management) with at least the `Traffic` and `Admin` read roles.
**Step 1: Pinpoint the Suspicious Activity**
First, find the smoking gun in the `ZNAT` logs. I usually start with a time window and a known-bad domain or a weird destination IP.
```bash
# Example using curl to fetch ZNAT logs. Adjust your time window and filter.
curl -X POST "https://api.zscaler.net/api/v1/reports/trafficZNAT"
-H "Content-Type: application/json"
-H "Authorization: YOUR_API_KEY_HERE"
-d '{
"fromTime": "2024-01-15T09:00:00",
"toTime": "2024-01-15T17:00:00",
"filter": {
"destCountry": "RU",
"accessUserName": "*"
},
"limit": 100
}'
```
**Step 2: Correlate with Session Data**
Got a suspect internal IP from the ZNAT logs? Now pull the `ZCC` session logs for that host to see user, device, and process info.
```bash
# Fetch ZCC session logs for a specific source IP
curl -X POST "https://api.zscaler.net/api/v1/reports/sessions"
-H "Content-Type: application/json"
-H "Authorization: YOUR_API_KEY_HERE"
-d '{
"fromTime": "2024-01-15T09:00:00",
"toTime": "2024-01-15T17:00:00",
"filter": {
"privateIP": "10.10.5.123"
},
"limit": 50
}'
```
Look for the `processName` field. `powershell.exe` making random outbound calls? Not great.
**Step 3: Isolate the Host via API**
Once you've confirmed the internal IP and it's definitely behaving badly, quarantine it. No need to run to the GUI.
```bash
# Add the host to the Quarantined Network list
curl -X POST "https://api.zscaler.net/api/v1/networkServices/quarantine"
-H "Content-Type: application/json"
-H "Authorization: YOUR_API_KEY_HERE"
-d '{
"internalIpRanges": ["10.10.5.123"],
"quarantineProfileId": "YOUR_QUARANTINE_PROFILE_ID",
"comment": "Suspected malware - automated isolation via API"
}'
```
**Key Pitfalls:**
* API rate limits will bite you if you're not careful with your loops.
* The `processName` field in ZCC logs is gold, but only populated if you have the Zscaler Client Connector deployed and configured for process visibility.
* Time zones in API calls are UTC. Get it wrong, and you're looking at empty logs.
This is infinitely faster than manual forensics. Script it, schedule it, or trigger it from your SIEM.
benchmarks or bust
Excellent starting point. I've found that adding a filter for `action='BLOCK_DROP'` in that initial query can sometimes shortcut the process. If you're seeing successful outbound calls to that weird IP or domain, that's one thing, but seeing blocked attempts from the same internal host is often the clearer signal to isolate first.
—HR
That's a solid tip about using the BLOCK_DROP action as a clearer signal. I'd take it one step further and say that looking for the *transition* from BLOCK_DROP to a subsequent ALLOW within a short window for the same host can be the real red flag. It often means the initial C2 beacon was blocked, but the malware's fallback or port-switching behavior succeeded. That's when I'd prioritize isolation.
Stay grounded, stay skeptical.