Blog// 11 MIN READ

AI Compressed a Two-Week Intrusion Into 10 Hours

Unit 42 documented an AI-assisted intrusion that crossed 50+ ATT&CK techniques in under 10 hours. Build coordinated containment across five control planes.

EVIDENCE → INTERPRETATION → DECISION

Short answer: Unit 42 says a human-directed attacker used parallel AI agents to move through more than 50 MITRE ATT&CK techniques in under ten hours, work it estimates would normally take human operators about two weeks. The defensive problem is no longer finding one compromised host quickly. It is revoking connected authority across identity, source code, secrets, CI/CD, cloud and AI services before the attacker’s next agent finishes its task.

Evidence note: Unit 42 attributed the use of frontier models and attack-specific agent frameworks to the threat actor’s statement during negotiations. Its investigators also observed evidence consistent with that claim, including parallel frontier-agent calls, structured Markdown hand-offs and custom operational scripts. The report was updated on 3 September 2026 to clarify that this was an intrusion, not a ransomware attack.

The most useful number in Unit 42’s new incident report is not fifty. It is ten hours.

Fifty ATT&CK techniques sound dramatic, but technique counts do not tell a responder how much time remains. Ten hours does. It says a public-facing foothold can become a secrets-manager compromise, a CI/CD problem, a cloud-identity incident and abuse of the company’s own AI endpoints before a normal working day has ended.

The individual moves were familiar. Unit 42 did not report a novel zero-day or unusually advanced tradecraft. The change was operational compression: several agents searched, tested and passed structured notes to one another while the human operator kept control of objectives and consequential decisions.

That combination breaks a common incident-response habit. Teams often contain one system, open a ticket for the next team, and wait for ownership to move across organisational boundaries. An attacker running parallel work does not wait for the identity, platform, DevOps and AI teams to finish their hand-offs. My earlier field note on five agent-containment boundaries deals with isolation inside an evaluation; this case shows what happens when authority has already escaped into enterprise systems.

What Unit 42 reported

The intrusion began at a public API endpoint. The attacker used that access to tunnel into the environment and deploy automated reconnaissance that mapped internal microservices. Sub-agents then searched enterprise code repositories and found hard-coded tokens and service passwords.

Those credentials opened the secrets-management layer. Administrative secrets led to root-level access, and custom workflows in the code platform were used to expose cloud access keys. An attempted Terraform backdoor failed because branch protection held. The stolen cloud keys still reached the organisation’s AI infrastructure, which the attacker used as post-compromise compute.

Timeline of the Unit 42 AI-assisted intrusion moving from a public API through source repositories, a secrets manager, CI/CD and cloud credentials to enterprise AI infrastructure in under ten hours.
The speed came from parallel execution and machine-readable hand-offs. The path itself crossed familiar enterprise trust boundaries.

The sequence matters more than any single tool. Source control contained credentials. Those credentials reached the secrets manager. The code platform could execute workflows. Cloud keys also authorised AI endpoints. A compromise in one plane became authority in the next.

Unit 42 mapped examples to ATT&CK techniques including Exploit Public-Facing Application, Credentials in Files, Credentials from Password Stores, Modify Cloud Compute Infrastructure and Valid Accounts. MITRE’s Valid Accounts entry explains why the later activity can blend into legitimate administration: a stolen account can bypass controls without requiring malware on every system.

The attacker also left an 80-page assessment of the victim’s security posture. That detail is strange, but it is useful. Agents were not merely generating commands. They were maintaining enough state to document findings, distribute work and continue from prior results.

What the report proves, and what it does not

This is a vendor incident report, not a reproducible experiment. It supports a strong conclusion about speed and coordination inside one investigation. It does not establish that every intrusion will now run in ten hours, or that an AI system independently chose and executed the campaign.

The human remained in the loop. Unit 42’s description assigns the attacker the objectives and consequential decisions. The agents handled tactical execution, monitored results and re-planned. “AI-assisted intrusion” is therefore the accurate phrase. “Autonomous hacker” would erase the operator and overstate what the public evidence shows.

There is also an attribution gap worth keeping visible. The attacker disclosed their use of frontier models during negotiations. Unit 42 then found three kinds of corroborating evidence: multiple frontier-agent calls running in parallel, structured Markdown used between sessions, and custom scripts assessed with high confidence as AI-generated. That is more than a claim, but readers still do not have the underlying logs or samples.

The report’s same-day correction is another reason to read past the first version of a headline. Unit 42 changed the classification from ransomware attack to intrusion on 3 September. I have used the corrected description throughout this field note.

The attacker had a task graph. Defenders need a kill graph.

Most incident playbooks are lists. A credential playbook rotates credentials. A CI/CD playbook suspends runners. A cloud playbook isolates accounts. Each may be correct on its own and still fail when the attacker’s authority crosses all three.

A kill graph starts with dependencies. For every compromised identity or workload, it records the secrets it can read, the pipelines it can trigger, the cloud roles it can assume and the AI services it can invoke. Each edge gets a tested revocation action and an owner.

Five-plane defensive kill graph connecting identity, secrets, CI/CD, cloud runtimes and AI infrastructure to one synchronised containment decision.
Containment has to cut the path at several planes together. Closing one edge while leaving its derived credentials active gives the attack loop another route.

This is different from an asset inventory. An inventory tells me that GitHub, a vault and AWS exist. The kill graph tells me that a compromised code-platform token can start a workflow, the workflow can read a deployment secret, and that secret can assume a cloud role with access to a model endpoint.

That is the path I need during containment.

Identity plane

Terminate active sessions, revoke OAuth grants, disable affected service accounts and invalidate workload identities. Resetting a password while leaving refresh tokens or cloud sessions alive is cosmetic containment.

Track the identity lineage as well. Which human account minted the token? Which service account accepted it? Which role did that account assume? MITRE notes that valid accounts may support initial access, persistence, privilege escalation and defence evasion. The same credential family can therefore appear at several stages of one incident.

Secrets plane

Rotate exposed secrets at the system that verifies them, then find their copies. A secret removed from source control may remain in commit history, build logs, container layers, caches or deployment variables.

MITRE T1552.001 covers credentials found in files, including source and configuration material. CISA and the FBI go further in their Product Security Bad Practices guidance: manufacturers should keep secrets out of source, retrieve them through a secrets manager and scan code for credentials. The Unit 42 path shows why all three controls belong together. A vault cannot protect a secret that was copied into a repository months earlier.

CI/CD plane

Freeze untrusted runs, disable mutable workflow changes and require review for infrastructure code. Preserve the logs and artefacts before clearing runners. A compromised pipeline is both evidence and an execution path.

The attempted Terraform modification in this incident reportedly failed because hard branch protection blocked it. That single control did not end the intrusion, but it prevented one persistence route. Branch rules earn their value when administrators cannot casually bypass them during an emergency.

Cloud and runtime plane

Revoke cloud access keys and short-lived sessions together. Isolate affected accounts or projects, stop suspicious serverless functions, and inspect container restart policies and scheduled jobs. Unit 42 says the attacker created overlapping persistence across SSH keys, serverless functions, containers, cloud identities and CI/CD.

Removing the first shell would have missed most of that portfolio.

AI plane

Treat model endpoints, API keys, MCP gateways and connected tools as production infrastructure. In this incident, stolen cloud keys allegedly turned the victim’s own AI endpoints into post-compromise resources. Usage may look like a legitimate workload unless identity, source network, model, token volume and tool activity are joined in one investigation.

This builds on my earlier analysis of AI gateways as privileged control planes. The difference here is timing. During an active intrusion, the AI plane is not a separate governance topic. It belongs in the same revocation call as cloud access and CI/CD.

A first-hour containment drill

This is an exercise sequence, not a promise that every incident can be contained in sixty minutes. Its purpose is to expose slow ownership and missing kill paths before a real attacker exploits them.

Window Decision Evidence to preserve Kill action to test
0–10 minutes Declare one cross-plane incident and name a commander API, identity and endpoint telemetry Block the exposed route without destroying logs
10–20 minutes Identify credential lineage and active sessions OAuth grants, token issuance, role assumptions Revoke the credential family and derived sessions
20–35 minutes Freeze code and deployment authority Workflow definitions, runner logs, build artefacts Stop untrusted runs and lock infrastructure branches
35–50 minutes Contain cloud and AI infrastructure Cloud audit logs, model calls, gateway and MCP activity Isolate affected accounts and disable stolen AI access
50–60 minutes Check whether persistence survived elsewhere SSH keys, functions, restart policies, scheduled tasks Run a second revocation sweep from the dependency graph

NIST SP 800-61 Revision 3 places incident response inside wider cyber-risk management rather than treating it as an isolated emergency process. A kill-graph exercise fits that model. The organisation is testing whether design-time identity, logging and ownership decisions produce a workable response under pressure.

Detect the loop, not just the file extension

Unit 42 recommends looking for structured Markdown, Python caches and paired asset folders. Those artefacts can help, but none is malicious by itself. Developers and defensive teams create them every day.

The stronger signal is a sequence that crosses controls unusually fast. A service identity enumerates repositories, reads many configuration files, hits authentication failures and then succeeds, accesses a secret store, modifies a workflow and invokes a model endpoint from a new source. One alert may be weak. The ordered cluster is not.

Useful joins for that detection include:

  • Identity plus session: human user, service account, OAuth grant, workload identity and assumed role.
  • Repository plus pipeline: code search, secret access, workflow edits, runner creation and infrastructure changes.
  • Cloud plus AI: key creation, model-endpoint calls, unusual token volume, new regions and unexpected calling workloads.
  • Time plus concurrency: bursty API activity, rapid 401-to-200 shifts and parallel authentication from identities that normally work sequentially.

Do not build a detector that fires on the word “README”. Build one that notices when a new service identity reads repositories, obtains authority and starts acting across unrelated systems within minutes.

Five questions for the next executive incident exercise

  1. Can we revoke one identity everywhere? Test SaaS sessions, OAuth grants, vault tokens, cloud roles and AI keys in the same drill.
  2. Can branch protection survive an administrator compromise? Require an independent reviewer for infrastructure changes and record every emergency bypass.
  3. Do we know which AI endpoints exist? Inventory model APIs, MCP gateways, service keys, tool connections and the workloads allowed to call them.
  4. Can telemetry follow an action across planes? One case should connect the API request to the repository read, secret access, pipeline run, cloud role and model invocation.
  5. Have we timed the kill paths? A playbook that needs three ticket queues and four console owners has not been tested against a ten-hour intrusion.

The last question is the uncomfortable one. Companies often measure mean time to acknowledge an alert while the real delay sits between teams. The attacker’s agents share state in files and continue. Defenders share context in meetings.

Frequently asked questions

Was the Unit 42 AI-assisted attack ransomware?

No. Unit 42 updated the report on 3 September 2026 to clarify that the event was an intrusion, not a ransomware attack. Earlier wording on the page described it differently, so the correction should govern current reporting.

Did the attacker use a zero-day?

Unit 42 says the incident did not require a novel zero-day or unusually advanced tradecraft. The reported advantage was speed: AI agents parsed output, shared findings and executed several lines of work in parallel.

Was the attack fully autonomous?

The public evidence supports “human-directed and AI-assisted”. Unit 42 says the human attacker set objectives and made consequential decisions while specialised agents executed tactical tasks and adapted to results.

What is a defensive kill graph?

It is a live map from a compromised identity or workload to every secret, pipeline, cloud role, runtime and AI service it can reach. Each relationship has a containment action, an owner and a test. The graph helps responders revoke derived authority instead of closing only the first compromised system.

What should an organisation do first?

Choose one privileged identity and trace it through source control, secrets, CI/CD, cloud and AI services. Verify that every session and derived credential can be revoked without opening separate investigations. If that takes hours in a drill, the organisation has found the gap before an attacker does.

The coordination gap is now the attack surface

The Unit 42 case does not require a science-fiction explanation. Familiar security failures formed a connected path: an exposed API, secrets in repositories, powerful tokens, mutable pipelines and cloud keys with reach into AI infrastructure. Agents made the traversal faster and more parallel.

Defenders will not close that gap by buying a faster alert queue. They need one view of authority and one containment decision that can cut identity, secrets, delivery, cloud and AI together.

Start with a single kill graph. Pick the service account that would hurt most if it were stolen, map where its authority propagates, and time how long your team needs to make that authority useless. The result will tell you far more than another tabletop slide.

Primary sources

Written by Prathamesh Dabir, CTO at Arica Tech Security. I work across penetration testing, AI security, bug bounty and security education. This analysis is based on public reporting and defensive guidance; it does not reproduce victim details or operational intrusion instructions.

One next action

If you run an agent that executes tools, AgentCrash is an open-source harness that crash-tests it in a synthetic workplace: synthetic tools, visual evidence and regression tests. It is built for exactly this problem, turning a containment claim into something you can run against the system instead of arguing about it in review.