The Blue Agent POV: Investigating Multi-Platform Data Exfiltration Across AWS and GitHub

What it is

A Wiz vendor case study of its "Blue Agent" autonomous SOC investigator. The summary already carries the full attack chain (GitHub token → 18 repos → svc_automation AWS keys → second account → SSM against a DC → S3-staged exfil scripts). What it doesn't carry is the investigative methodology — the specific signals, detection rules, and pivots an engineer could reproduce in their own tenant.

How it works — the reproducible pivots

The investigation opened from three detection rules firing simultaneously on one actor:

• Unusual User Access Through Third-Party VPN
• API Calls From Unusual Country
• AWS Management API Calls by a Known Offensive Tool

Triage extracted three corroborating signals from threat metadata: actor was a service account (svc_automation, an IAM account from 2018), user-agent string contained kali-amd64, and source IP belonged to Zenlayer Inc (a known VPN-exit hosting provider). The stated heuristic: service accounts don't normally use VPNs, and any one signal is explainable but the combination is not.

Baseline deviation compared 30 days of history split into baseline vs. detection window across five dimensions: source IP, user agent, and operation type. Baseline for svc_automation = three Amazon-owned IPs, TeamCity Server/aws-sdk-go agents, and routine GetSessionToken/AssumeRole/RunInstances. Detection window = unusual IPs, aws-cli on Kali, and out-of-scope AssumeRole/SendCommand.

The cross-account pivot is the technique worth stealing: query all tenant actors sharing the attacker's ASO (autonomous system org) — this surfaced a second svc_automation in a different account using a different permanent key but the same Zenlayer range. Then query the data plane, not just CloudTrail: the exfil scripts surfaced as filenames in the Path field of S3 PutObject events from Zenlayer IPs. Management-plane logs alone would have missed them. The curl-based fetch of those scripts came back from Amazon-owned IPs (the compromised EC2 instances), confirming SSM execution.

What to do

Concrete detections this implies:

• Alert on service accounts authenticating from VPN/hosting-provider ASOs.
• Baseline service-account IP + user-agent + API-call set; flag deviation on any dimension.
• Pivot on shared ASO/IP tenant-wide to find sibling compromised keys in other accounts.
• Correlate S3 data-plane PutObject Path values against CloudTrail management events and GitHub audit logs to catch staged tooling.

Caveats

This is a vendor marketing piece; the "minutes vs. hours" speed claim and the agent's efficacy are unmeasured and self-reported. The instance name (PROD-*******-DC1) and repo-key extraction are inferred by the investigation, not proven in the text ("may have extracted"). No CVE, no product version, no code — the value is the methodology, not a patchable finding.