Akumo: An Offensive Framework That Refuses to Lie to You

Akumo is a cloud offensive framework I have been building under BlueSquadron, and it is built around refusing to make that mistake. It is written in Rust, ships as a single binary, and it does something I have wanted from this class of tool for years: it keeps track of what it actually knows.

This post is the tour I would want if someone handed me the repository cold — what it is for, the handful of ideas that make it different, how you write a technique, and a peek at the machinery underneath that makes the rest possible.

Before anything else: Akumo is offensive tooling for infrastructure you are authorised to test — owned accounts, contracted engagements, lab and CTF environments. Opening an engagement makes you affirm that, and it is recorded.

One loop instead of four tools

The usual cloud-offence workflow is a relay of excellent, single-purpose tools that do not speak the same language. Prowler or ScoutSuite audit posture. CloudFox (Bishop Fox) enumerates and hunts privilege-escalation paths. Pacu is the exploitation framework. Stratus Red Team (Datadog) detonates a technique so you can watch detections fire; COBRA simulates multi-cloud chains. Each is good at its slice — and each has its own data model, so you are the integration layer, holding them together with notes and shell history and a mental map that lives nowhere.

Akumo is not trying to beat any one of them at its slice. It is arguing that the seams between them are where the real work leaks away — the re-typing, the lost context, the enumerate-guess-execute gap — and it collapses the whole relay into one loop over a single graph.

You open an authorised engagement with a scope. You enumerate — partially, honestly. Akumo folds what it saw into an attack graph, computes the paths to a goal you name, and executes the chosen one through a careful lifecycle: preview, consent, act, verify, and — if needed — undo. Every step lands in an append-only ledger, so each command is a stateless invocation; you pick the engagement with a flag rather than holding a session.

That is the shape. What makes it worth writing about is three properties none of those tools combine — because none of them owns the whole loop: it reasons honestly about what it could not see, it can undo what it did, and it hands you the detection for what it did.

Differentiator one: it knows what it doesn’t know

This is the idea I care about most, and it is rarer in offensive tooling than it should be.

On a real engagement, enumeration is always partial. You have a toehold, the account throttles you, and a good third of your describe-calls come back denied. The dangerous move — the one most tooling makes silently — is to treat a call you couldn’t make as evidence that the thing isn’t there. That single conflation produces both halves of a bad report: paths you missed, because you assumed absence, and false confidence, because you drew everything else solid.

Akumo makes uncertainty a first-class property. Every attack-relevant fact carries a categorical epistemic status: PROVEN, ABSENT, UNKNOWN (denied or unseen), or INFERRED (derived, with a confidence score). The same foothold, read through that lens, looks very different:

The payoff is not cosmetic. The planner reasons over the difference in dual mode — proven paths shown prominently, candidate paths surfaced but clearly labelled needs validation. You get low false negatives without false confidence, and you can force strict-proven or full-optimistic when the engagement calls for it. When Akumo hands you a report, the blind spots are on it by name, because “I couldn’t see this” is a fact worth recording.

Differentiator two: safe by construction, not by good intentions

The second reason I trust this tool in a real account is that its safety is structural rather than procedural. It does not ask you to be careful; it is built so that carelessness is hard.

Everything is read-only until you deliberately elevate — nothing above read runs without recorded consent, and out-of-scope targets are refused and logged, with a global kill-switch that halts and unwinds. But the linchpin is the revert model. It is not a best-effort “undo” bolted on afterwards.

When a mutating step runs, Akumo records a concrete compensating action into the ledger before it even verifies the step. Revert then replays those compensations in reverse order, undoing only what actually happened — and because they live in the ledger, it survives a crash and a restart. The step that failed created nothing, so nothing is undone for it.

You might expect that to mean writing an undo for everything by hand, which would be miserable. It mostly is not: the compensation is derived from the provider’s declared inverse by default — Create pairs with Delete, Attach with Detach — and a technique only spells out a revert when it needs to override that default. Two rules then keep it honest. Every mutating technique ships an automated test that detonates and asserts a clean revert — no passing revert test, and it does not ship. And an action with no clean inverse cannot fake one: it must declare a simulated variant, and validation rejects an irreversible technique that lacks it.

This is exactly the property cloud security chaos engineering has been missing. Detonating a real technique against a real control plane to see whether your detections fire is only responsible if you can reliably put everything back. Akumo makes that reliability a build-time guarantee rather than a hope.

Differentiator three: it tells the defender what to watch for

Most offensive tooling leaves the defensive half to somebody else. Akumo treats the two as inseparable: every technique carries the telemetry it expects to produce. That signature — the log source, the event a defender would actually see, and the discriminating fields — is the primary artefact, written alongside the attack itself.

I want to be precise about what that buys, because it is easy to oversell. The signature is the durable thing; Sigma is one way to export it, not the mechanism that catches you. No cloud-native detection service ingests Sigma directly — GuardDuty ships its own curated logic and takes no custom rules, and Security Lake wants OCSF, not signatures. A Sigma rule only reaches cloud telemetry after somebody translates it into the query language of the SIEM or the Athena table sitting over CloudTrail. So Akumo emits Sigma as a lingua franca for whoever owns the SIEM — a portable starting point they can convert — while the honest answer to “how is this actually detected in the cloud?” is the telemetry itself: the CloudTrail event and the fields that make it distinctive.

That is why the expected_telemetry block, not the generated rule, is the thing you author with care. Ask for a technique and you get its metadata, the telemetry signature, and a candidate Sigma rendering of it:

akumo technique --id aws.iam.persistence.create-access-key --content content

Because executed techniques and their ATT&CK coverage land in the engagement report, a run doubles as a detection-coverage artefact: what was done, what telemetry it should have produced, and which techniques it exercised. What Akumo cannot yet do — and it is the right next step, not a v1 gap I am hiding — is watch the logs and tell you whether the expected telemetry actually appeared. That observed-versus-expected loop, the thing tools like Grimoire do for detection engineering, is the headline of where this goes next.

Writing a technique

Here is where the design pays off for anyone extending the tool. Techniques are data, not code you have to trust: declarative YAML, versioned, validated, and reversible by default. You never write a cloud SDK call by hand — you reference a provider operation and the host brokers it.

The important structural point is that a technique has two halves the engine reads and two halves it runs:

A minimal, fully reversible technique looks like this:

metadata:
  id: aws.iam.persistence.tag-user
  name: Tag IAM User
  version: "1.0.0"
  provider: aws
  mitre: ["T1098"]
  impact: mutating-reversible
  expected_telemetry:
    - source: cloudtrail
      event_name: TagUser
      fields:
        eventSource: iam.amazonaws.com

contract:
  inputs:
    - name: user
      type: principal
      required: true

steps:
  - id: tag
    body: { type: call, service: iam, operation: TagUser,
            params: { UserName: "$user", Tags: [{ Key: "akumo", Value: "demo" }] } }
    revert: { service: iam, operation: UntagUser,
              params: { UserName: "$user", TagKeys: ["akumo"] } }

The mitre mapping and expected_telemetry block are mandatory — omit either and the technique is rejected at load with an actionable message rather than half-loading. impact: mutating-reversible is what makes it safe by construction. The explicit revert above is shown for clarity — for a clean inverse like this, the engine would derive the same UntagUser compensation from the provider descriptor on its own.

The part that makes techniques powerful rather than just tidy is the contract. Its preconditions and effects are what let the planner chain techniques: if a technique’s preconditions hold, applying it produces effects — new edges and facts — which may unlock the next hop. So a computed path can interleave “you already can do this” with “run this technique to make that possible”. You state an objective — reach-admin, or reach-resource for a named ARN — and Akumo finds and explains the path, every hop annotated with the permission that enables it and its epistemic status.

A peek at the internals: the ledger is the system

The last thing worth showing is why the reproducibility and the audit trail come essentially for free, because it is a genuinely satisfying design decision.

Akumo is event-sourced. The single source of truth is an append-only, hash-chained ledger of events. Everything else you interact with — the attack graph, the execution state, the recovered loot, the report — is a deterministic projection of that log.

This is what buys the properties that matter on an engagement. Reports are reproducible because they are recomputed from the log, not maintained alongside it. The trail is tamper-evident because the chain is hashed. Revert survives a crash because compensations are events like any other. And the whole thing is auditable by construction — there is no second record that could disagree with the first, because there is only one record.

Underneath, the architecture is hexagonal: a provider-neutral core behind a seam, with pluggable adapters. Today that is AWS and a scriptable Mock; the Mock is a real practice target that needs no credentials, which is the right way to learn the tool before pointing it at anything live.

Where it costs you, and what it is not yet

A tool without stated limits is a sales pitch, so here are Akumo’s, plainly.

v1 is deliberately narrow. The provider surface is AWS and Mock; the technique catalogue is a starter set — STS identity enumeration and IAM access-key operations — chosen to prove the machinery rather than to blanket the cloud. There are no release binaries yet: you build from source with cargo.

Declarative YAML trades flexibility for analysability. The reason the planner can reason about a technique before running it is that techniques are data, not arbitrary code. That is the right trade for a tool whose whole pitch is honesty and safety — but if you want to express something the step DSL cannot, you will reach for an escape hatch rather than free-form scripting, and by design that is a slightly higher bar.

None of that changes the thesis. The narrow v1 already demonstrates the thing that is hard and rare: an offensive tool that reasons honestly about what it cannot see, and can undo what it does.

Where it goes next

Three lines of work follow directly from the design, and each closes a gap named above.

Watching detections fire, not just describing them. v1 emits the expected telemetry; the obvious next step is a collector that captures what the detonation actually produced and shows observed against expected — the loop Grimoire pioneered for detection engineering. That turns the detection-coverage report from a claim into a measurement, and it is the honest answer to “will the cloud actually catch this?” — because it checks the telemetry itself rather than trusting a rule.

Making reverts disappear almost entirely. The compensation model already derives most undos from the provider’s declared inverse, so the natural evolution is to push all inverse knowledge down into the provider capability descriptor — one place that knows AttachUserPolicy is undone by DetachUserPolicy — so a technique author almost never writes a revert at all. The release-blocking revert test stays, because that is what proves the undo is real; the boilerplate goes. Handwritten compensations become the rare exception for genuinely awkward operations rather than the default tax on every mutating technique.

Beyond one cloud. The provider seam exists precisely so Azure, GCP and Kubernetes adapters can be added without touching the core — and the honest-epistemics and safe-revert machinery is provider-neutral, so it comes along for free. AWS-and-Mock is a starting point chosen to prove the machinery, not the ceiling.

Why this shape makes sense

I keep coming back, across everything I build, to one preference: make the machine’s reasoning legible. I have argued it for agent governance and for threat modelling. Akumo is the same instinct pointed at offence.

An attack tool that draws every edge solid is easy to build and comfortable to demo. It is also the one that gets you a finding you cannot reproduce and a report you cannot defend. The harder, better tool is the one that says “I proved these three things, I am guessing at these two, and here is what I could not see at all” — and then cleans up after itself.

That is the tool I wanted to exist. So I built it.

Sources

• Akumo on GitHub — the repository, including the full architecture decision records under spec/ADR, the internal design docs, and the technique-authoring guide these figures are drawn from. GPL-3.0.
• AWS Threat Technique Catalog — the reference Akumo techniques cross-map to, so a defender can trace an action.

Akumo is a tool I write and maintain under BlueSquadron, so this is not a neutral review — it is the author explaining a design. Everything above is drawn from the current repository; the v1 scope, provider coverage and roadmap items are as documented today and will move. The framing — “unseen is not absent”, safety as a structural property, the ledger as the system — is how I think about the design, not anyone’s official position.