Days of account history compared with the alert window: 30 (Source: Wiz, Blue Agent investigation (September 29, 2026))
The first suspect was a developer. It was software.
The alert raised a familiar question: was a developer working remotely over a personal VPN? A case study Wiz published on September 29, 2026 shows the answer was different. The account behind the activity belonged to no employee.
Wiz walks through a real investigation. Two detection rules fired on one actor in an AWS account. One flagged unusual access through a third-party VPN. The other flagged AWS calls made by a known offensive tool.
The actor was svc_automation. It is an IAM service account, meaning a cloud identity for software rather than a person. It was set up in 2018 for CI/CD pipelines, the automated systems that build and ship code. Wiz gives the year the account was created. It does not say how old the access key used in this activity was.
This shows a gap in how many teams read alerts. A machine identity has no travel schedule and no manager to ask whether a login was really theirs. Anyone who copies its key inherits its trust.
How the investigation worked
Wiz calls its automated investigator the Blue Agent. It pulled three clues from the alerts.
First, the software label attached to the requests, known as a user agent, included "kali-amd64". That points to Kali Linux, which Wiz links with hostile use. Second, the traffic came from an address at Zenlayer, a hosting company Wiz says is often tied to VPN exit points. It was geolocated to Taiwan. Third, Wiz offers a rule of thumb: service accounts do not typically use VPNs.
Wiz stresses that any single clue could have an innocent explanation. Together they called for a closer look.
The agent then compared the account's last 30 days of activity. Before the alert, it had used only three Amazon-owned addresses. Its tools were TeamCity Server and aws-sdk-go, and its work was routine: session tokens, its designated CI role and launching servers. During the alert window, the addresses, the tool (aws-cli on Kali) and the actions all changed. Wiz concluded the operator was not the same.
From one account to a production server
Next, the agent looked for any other AWS identity in the tenant using the same network operator. Only two appeared. Both were named svc_automation, in two separate AWS accounts.
In the second account, the activity used a different permanent access key. The Kali marker and the Zenlayer address range stayed the same.
At 09:55 UTC, the actor assumed the CI role from another Zenlayer address. At 10:06 UTC, it sent an SSM SendCommand to a production EC2 instance. SSM is an AWS feature that runs commands on servers remotely. Wiz says the instance name indicated a production domain controller, the server that manages logins on a Windows network.
The agent also examined the data plane, which records actions on stored data rather than on settings. It found three Python scripts placed in an S3 storage bucket from Zenlayer addresses. Their filenames suggested tools for exporting from Microsoft SQL Server, PostgreSQL and billing systems. Wiz says compromised EC2 instances then downloaded and ran them.
Source code was the likely way in
The same Zenlayer address also appeared in GitHub audit logs. A few hours before the AWS activity, those logs show a compromised token used from that address to clone 18 private repositories.
Wiz calls this the likely first step. It notes that private repositories often contain hard-coded AWS keys, database connection strings and service account settings. The attacker may have lifted the svc_automation key from that code.
That link is Wiz's inference. The write-up does not say how the GitHub token was compromised. It does not say how much data left the environment. It also does not say how long the key had existed.
What to ask your team
Wiz says the investigation finished in minutes, where an analyst would spend hours moving between AWS and GitHub logs. That is a vendor describing its own product in one case. Weigh it accordingly. The attack chain is the more useful lesson.
1. How many service accounts hold long-lived access keys, and how old is the oldest key?
2. Do any repositories contain keys or connection strings, and who scans for them?
3. Do alerts on machine identities test for changes in network, tool and action, not only location?
4. Can one stolen source-control token clone every private repository?
5. Can the team follow a single IP address across cloud, code and identity logs in one sitting?
A cloned repository can carry working keys to production. In this case the source does not say how old the key was. Ask that question about your own keys before an alert asks it for you.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wiz.
