A six-hour agent run harvested credentials from behind the victim's own cloud IPs

The precondition does most of the work. GTIG's scenario starts with an attacker already inside the victim's cloud environment, able to manipulate compute, networking, and credentials, plus an operator capable of building and directing an agentic framework ^[8]. The initial entry path was not disclosed ^[2].

What the framework adds is a loop. The agents scan internet-facing services, keep investigating vulnerabilities, attempt exploitation, and correct their own errors ^[4]. Error correction is the line that matters for scheduling. A human-run campaign spends wall-clock time waiting for a person to notice a broken payload and come back to it; a retry loop spends it on API calls. That is the mechanism behind "under six hours" ^[1], and it is the part I would treat as transferable, because it does not depend on any particular tool.

Then the rotation. Harvesting traffic leaves from the legitimate IP addresses of the compromised cloud infrastructure ^[5], which is what GTIG names as the evasion: the reputation of infrastructure the receiving services have no reason to block ^[14]. Third parties see rapid scanning or logins from an address with a clean history ^[9].

Arithmetic on the headline figure. Thousands of credentials in six hours, taken at a floor of 2,000 across 360 minutes, is roughly 5.6 compromises a minute ^[19]. Divided across however many third-party services were in scope, each individual rate limiter sees a trickle. GTIG's own condition list states that rate limits and egress controls do not stop rapid parallel scanning and secret validation ^[10], and the detection advice is correlation rather than thresholds: large-scale scanning, secret validation, new workload creation, and IP rotation lined up across cloud, IdP, and API records, with a means to stop activity immediately ^[13].

The write-up leaves two claims unresolved. It gives no defender response-time baseline, so the six-hour figure supports "the campaign fits in one shift" and nothing stronger. And the dashboard managing more than 23,800 secrets belongs to the separate Recon case, found on an exposed C2 alongside AGENTS.md, KNOWLEDGE.md, and .openclaw/ artifacts ^[6][7]. GTIG treats that dashboard as evidence of a claimed volume only, not confirmation that every secret was valid or that follow-on compromises succeeded ^[7], and the evidence criterion for this class of activity is an attempt observed with success unconfirmed, met by confirming abnormal scanning from cloud infrastructure or large volumes of requests to third parties ^[17].

For the six-hour number to transfer to your estate, three things have to be true of you: an attacker who reaches credential and networking control, workload identities that outlive the incident, and secrets whose scope and permitted origins are unrestricted. The mitigation list names exactly those, in that order: dedicated short-lived identities for cloud workloads, and restricted scope, lifetime, and allowed origins for secrets ^[11]; then allowlisted agent egress with caps on scanning rate, concurrency, tool privileges, and budgets ^[12].

The report also warns that filenames such as AGENTS.md point to agent scaffolding, not malicious intent by themselves ^[16]. Write that EDR rule and your own developers' repositories are the first hit.

The identity guidance is the piece I would act on before any of the detection content, and GTIG separates it cleanly: assess successful authentication apart from data retrieval ^[20]. Six hours only costs you something if what the agents harvested is still valid tomorrow.