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

The Blue Agent is Wiz's autonomous SOC investigator. When a threat fires, the Blue Agent begins its investigation: gathering evidence, comparing activity against historical baselines, checking IP reputation, validating actor identity, and correlating signals across cloud platforms. The Blue Agent then returns a verdict, along with the complete investigation flow, allowing analysts to focus only on high priority investigations that require a human touch.

We're excited to give you a behind the scenes look at how the Blue Agent works by walking through a real investigation of a complex, multi-platform attack.

The Case Study

It started with a VPN alert on a CI/CD service account. Was this a developer working remotely through a personal VPN, or something else?

The Blue Agent picked up the case and started pulling threads. By the time it finished, it had traced that IP across three platforms and uncovered an active attack campaign consisting of compromised credentials spanning multiple accounts, stolen source code, and custom exfiltration tooling already deployed and running.

Let's dive into the investigation flow and follow the Blue Agent's thought process, from the initial lead to the discovery of the full attack chain.

The Initial Lead

The Blue Agent started by investigating three detection rules fired simultaneously against a single actor in an AWS account:

• Unusual User Access Through Third-Party VPN

• API Calls From Unusual Country

• AWS Management API Calls by a Known Offensive Tool

Employees and contractors routinely use third-party VPNs for legitimate reasons, like remote access, privacy, or regional compliance. The Blue Agent's first task was to determine whether this was one of those cases.

Phase 1: Initial Triage

The Blue Agent retrieved the threat metadata and extracted the initial pivot points: the actor identity, the triggering event names, and the source IPs.

Three signals stood out immediately:

• The actor was not a human: it was svc_automation, an IAM service account created in 2018 for CI/CD pipelines. 

• The user agent string contained kali-amd64: Kali Linux, a distribution commonly used by malicious actors.

• The source IP belonged to Zenlayer Inc, a hosting provider commonly associated with VPN exit nodes, geolocated to Taiwan. As a rule of thumb, service accounts don't typically use VPNs.

Any one of these signals could have a legitimate explanation. Together, they warranted deeper investigation.

Phase 2: Baseline Deviation

The Blue Agent queried 30 days of historical activity for svc_automation and split the results into two periods: baseline and detection window.

The baseline told a clear story. For the past month, svc_automation had operated exclusively from three Amazon-owned IPs, using TeamCity Server and aws-sdk-go user agents, performing routine CI/CD operations like GetSessionToken, AssumeRole to its designated CI role, and RunInstances.

The detection window activity showed something different. The actor appeared from unusual IPs, using aws-cli on Kali Linux, and attempted operations far outside its normal scope, including unusual AssumeRole and SendCommand actions. This activity differed from the historical baseline across every dimension, making it clear that this was not the same operator.

Phase 3: Cross-Account Investigation

The Blue Agent queried all AWS actors using the Zenlayer ASO across the entire tenant and found only two. Both were named svc_automation, but in different AWS accounts: the original detection account and a second account.

In the second account, the attacker used a different permanent access key, but the same Kali Linux user agent from the same Zenlayer IP range. The activity timeline showed:

• 09:52 UTC: AssumeRole to the CI role

• 09:55 UTC: AssumeRole to the same CI role from a different Zenlayer IP

• 10:06 UTC: SSM SendCommand targeting a production EC2 instance

The target instance's naming convention (PROD-*******-DC1) indicated a production domain controller. The attacker had achieved remote code execution on one of the most sensitive machines in the environment.

Uncovering the Data Exfiltration Campaign

Up to this point, the investigation had focused on CloudTrail events. To deepen the investigation, the Blue Agent also queried the data plane.

The data plane results surfaced something the management plane couldn't: the attacker had staged custom exfiltration tools in an S3 bucket. Three Python scripts appeared in the Path field of PutObject events from Zenlayer IPs:

The filenames themselves told a story. These were customized scripts for extracting data from Microsoft SQL Server, PostgreSQL, and billing systems. The attacker uploaded them from Kali Linux, then the compromised EC2 instances retrieved and executed them via curl from Amazon-owned IPs, showcasing the SSM commands in action.

This was the moment the investigation escalated from compromised credentials in multiple accounts to active data exfiltration operation with custom tooling.

Phase 4: GitHub - Finding the Initial Access Point

The cross-account IP analysis revealed a third actor operating from the attacker's IP: a GitHub user. The Blue Agent queried GitHub audit logs and found that, a few hours before the AWS activity, a compromised token was used to clone 18 private repositories from the same Zenlayer IP.

The GitHub breach was likely the initial access phase, not a separate incident. Private repositories frequently contain hardcoded AWS access keys, database connection strings, and service account configurations. The attacker may have extracted the svc_automation AKIA directly from cloned repository contents, then used it to pivot into AWS infrastructure within hours.

The Complete Attack Flow

The full Blue Agent investigation revealed the following attack chain:

1. Initial Access (GitHub Source Code Theft): The attacker uses a compromised GitHub token from a Zenlayer VPN IP to clone 18 private repositories containing hardcoded credentials.

2. AWS Pivot & Authentication: Using stolen svc_automation access keys extracted from the repository contents, the attacker authenticates to AWS via Kali Linux.

3. Lateral Movement & Execution: The attacker pivots to a second AWS account and executes commands via SSM SendCommand on a production Windows Domain Controller (PROD-*******-DC1).

4. Tool Staging: The attacker uploads custom Python data exfiltration tools (mssql_table_export.py, pg_table_export.py, billing_export2.py) to an S3 bucket.

5. Data Exfiltration: The compromised EC2 instances fetch and execute the staged scripts to extract sensitive SQL, PostgreSQL, and billing data.

Why This Matters

The Blue Agent brought two things to this investigation that are usually difficult to do at the same time: speed, and the expertise to know where to look next.

First, speed. The full investigation, from initial alert to final classification, was completed in minutes. A human analyst following the same investigation thread across AWS CloudTrail, S3 data events, and GitHub audit logs would spend hours context switching between platforms, writing queries, and waiting for results. The Blue Agent ran these in parallel, following each lead and pivoting quickly.

Secondly, expertise. Every pivot the Blue Agent took reflects its deep expertise and context about the cloud and user environment. Comparing 30 days of baseline behavior across five dimensions, checking ASO dispersion tenant-wide and querying the data plane to trace data access and exfiltration activity mirror techniques that trained incident responders would use. 

That is the difference good autonomous investigation can make. It enables teams to investigate at the speed attackers operate without sacrificing investigation quality.