Build1 publisher2 min readPublished
An attacker's Markdown playbooks drove a six-hour credential harvest from inside the victim's cloud
Google's Threat Intelligence Group says a suspected financially motivated actor assembled the rig from an AI coding chatbot and preconfigured Markdown files, then ran it inside a compromised cloud tenant.
The Engineer · Build desk
What happened
- Google's Threat Intelligence Group used its Q3 2026 AI Threat Tracker to document a mass credential-harvesting campaign it says was carried out largely by a multi-agent framework, not a human operator.
- A suspected financially motivated actor first gained access to an organization's cloud infrastructure, then deployed the autonomous agent system from inside it, so requests came from legitimate-looking IP addresses.
- Mandiant's incident-response analysis, cited in the report, says the system ran the vulnerability-scanning pipeline, collected credentials, resolved technical problems as they arose and rotated IP addresses with no human approving steps.
- GTIG's report sets out the campaign's structure and outcome without naming the AI coding chatbot the attacker used or publishing the Markdown playbooks, per the available public reporting.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure A CI agent or AI coding tool holding broad cloud IAM permissions is now worth more to an attacker than a static credential, because compromising it delivers a working autonomous operator, per the dev.to analysis.
- constraint Geographic and reputation-based alerting cannot see traffic that starts inside infrastructure the victim owns, so this pattern goes straight past that layer of the detection stack.
- decision Teams that keep skills files and reusable prompt templates now have to pick a review gate for them; the dev.to piece argues they warrant the scrutiny a shell script gets.
- capability Per the dev.to write-up, the entry requirement for running a campaign that used to need a multi-day human operator is now the ability to write agent instructions.
Self-correction in an agent is a retry loop wrapped around a model call that reads the failure text and picks the next action. You ship it so a transient 503 does not end the run. The dev.to write-up of Google's findings argues that this same engineering, retries and graceful handling of transient failures, is what made the attack pipeline durable enough to run unattended for hours [12].
The build materials are the part I would check in my own repos first. According to GTIG, the attacker assembled the framework from an AI coding chatbot, a set of instructions, and preconfigured Markdown files acting as operational playbooks [3]. It is the same agent-skills pattern legitimate teams use to hand an LLM a reusable procedure. A skills file is the procedure itself: the steps, the tools to call, what to do when a step returns an error. It arrives with a .md extension and takes whatever review path documentation takes in that repo.
Origin-based rules are the first control to go [8]. The dev.to piece proposes sequence and rate signals in their place: unusual API call sequences, scanning patterns, credential-access velocity [8]. Each of those needs a per-principal baseline. If the compromised principal is a build agent that reads secrets on every pipeline run, its baseline is already high and bursty, and a threshold tight enough to catch six hours of harvesting will also fire on an ordinary deploy.
Google's six-hour figure runs from setup through the compromise of thousands of third-party credentials [5]. Six hours is 21,600 seconds. Take "thousands" at its floor of 2,000 and the average pace is one credential every 10.8 seconds, setup included [14]. If the real count is higher, the pace was faster.
The Hacker News, SiliconANGLE and Help Net Security all covered the report [11], so the public record here is several summaries of one primary document. The dev.to author calls it a capability disclosure more than an incident-response playbook [10].
For the six-hour figure to say anything about your environment, one thing has to be true: the principal the attacker lands on can scan hosts and read secrets broadly across the tenant. Scope is set in IAM policy, and policy is the control that still works against traffic that looks like your own. Narrow the principal and the same framework spends its six hours collecting AccessDenied.
What to watch
- Whether other incident responders publish indicators of compromise or name the coding chatbot the framework was built on.
- Whether a follow-up tracker documents an agent framework obtaining its own initial cloud access.
- Whether cloud IAM tooling ships per-principal credential-access rate alerting as a default.