Cracken Releases BlackSea, Open-Source Tool to Bait AI Cyber Attackers

Uh oh!

There was an error while loading. Please reload this page.

Notifications You must be signed in to change notification settings

Fork 0

Star 13

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

2 Commits

2 Commits

assets

assets

docs

docs

lure_material

lure_material

services

services

.gitignore

.gitignore

LICENSE

LICENSE

NOTICE

NOTICE

README.md

README.md

Repository files navigation

by Cracken; Core team: Dario Pasquini and Michal Bazyli

Blacksea is an active honeypot and canary-bait control system built to detect and drown LLM-driven attackers: autonomous AI agents and LLM-assisted operators that scan and exploit systems. Blacksea doesn't stop at watching LLM attacks. It exploits flaws in the attacker's LLM judgment to gain arbitrary code execution on their machines, collect intel passive defenses can't reach, and make sure they don't come back.

The technique. An LLM-driven attacker works an engagement by reasoning toward the assets that move it forward: credentials to reuse, a decryptor for an encrypted blob, a key-derivation tool, a config unpacker, a token minter, an internal API client. Blacksea turns that reasoning into a trap. You seed baits, artifacts crafted to look exactly like the high-value, security-relevant assets such an agent is hunting for, staged in the places it will look and wrapped in the context that sells them: a plausible filename, a companion ciphertext blob, a README that explains what the tool is "for." Discovering one, the agent reasons that downloading and running it is the fastest route to what it wants, and because the artifact is deliberately expensive to reverse or reimplement, running the real thing genuinely is the path of least resistance. There's no prompt and no "please run me": the bait wins on technical plausibility alone.

What the agent can't see is that the bait is also a canary (what we like to call LLM-malware). Hidden inside the artifact, engineered to stay invisible to an LLM reading or reasoning about it, is a payload: arbitrary code of your choosing that runs the moment the bait is tripped and beacons home. Blacksea turns that beacon into a structured intel record, the raw material for attribution.

How it works

Blacksea is three things: a server you run on infrastructure you trust, baits you build with it and plant where an attacker will find them, and records that come back when one is tripped. It is not a passive sensor. The whole design is aimed at one moment, the attacker's own machine running your code. Everything else exists to make that moment happen and to get the result back to you safely.

What a bait is made of

A bait is a single artifact an attacker finds, and two independent choices define it:

The payload. The code that runs on whatever machine trips the bait. It's arbitrary: you write it, or you use the one Blacksea ships. This is what turns a detection into a foothold on the attacker's side.

The staging vessel. What decides the shape the artifact takes: a password-vault decryptor, a database-backup restore tool, a release-config unpacker, a plain script. A vessel has no idea which payload it's carrying, which is why any payload can ship in any shape. Pick whichever shape is most plausible where you're seeding it.

Every time you build a bait you get an instance: one planted copy, carrying its own signing and encryption key. That's why a beacon can never be ambiguous about which copy fired, however many you have in the field, and why you can burn a single compromised copy without touching the rest.

What you set up

1 YOUR SERVER 2 BAITS 3 WHAT YOU DEFEND ┌──────────────────┐ ┌─────────────┐ ┌────────────────────┐ │ blacksea up │ forge │ artifact │ stage │ honeypots, or the │ │ trusted host, │ ─────► │ + payload │ ───────► │ real assets │ │ reachable │ └─────────────┘ └────────────────────┘ └──────────────────┘ │ ▲ │ an attacker │ ▼ takes one └───────────────── beacon ◄───────────────── attacker's machine

Run Blacksea where you're trusted. blacksea up on a SOC server or similar host you control, never on a honeypot. It has to be reachable from wherever you plant baits, over HTTPS or DNS, because that's where beacons land. Nothing else about it faces the attacker.

Forge as many bait instances as you want. One blacksea forge per instance: it builds the artifact, mints that copy's key, and tells you where to find the files. The payload is your choice. Blacksea ships agent_fp, which fingerprints the agent harness that ran it, but the payload is arbitrary code, so it can just as well burn the attacker's compute, or do whatever else you need done on that host (see Deploy your first bait).

Stage the baits where an attacker will look. Honeypots you stand up for the purpose, or the real assets you're defending. A staged bait does nothing until someone runs it against the forged file it ships with, so it can sit on a live box without touching how that box works.

What happens when a bait is tripped

From here it runs itself. This is the path a beacon takes home:

attacker host INTERNET TRUSTED PLANE YOUR SOC ┌──────────┐ beacon ┌──────────┐ queue ┌──────────┐ ┌──────────┐ ┌──────────┐ │ bait │ ─DNS/HTTPS─► │ edge │ ────────► │ brain │─►│ Postgres │ ┄OTLP┄► │ SIEM / │ │ payload │ │ (Go) │ │ (Python) │ │ records │ │ SOC │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ tripped dumb dead-drop: decrypts, interprets, optional: holds no keys writes the record stream via OTLP

The payload fires on the attacker's machine, collects whatever you told it to, encrypts and signs the result under that instance's own key, and sends it out as a beacon over HTTPS or DNS, whichever channel the bait was built for. If it can't reach home it fails silently, by design: a bait never surfaces an error to the attacker.

The edge catches it. This is the only part of Blacksea that faces the internet, and it is deliberately dumb: it holds no keys, decrypts nothing, and derives nothing from the beacon. It stamps the source address and arrival time (facts the attacker can't shape, because the attacker never supplies them), drops the opaque bytes on a queue, and never talks back.

The brain reads it. On your side of the line, the brain authenticates the beacon, decrypts it, and interprets it, turning the raw bytes back into whatever the payload actually found.

A record lands in Postgres. That's the durable intel unit: which bait fired, what the payload found, from where, when, and whether the beacon authenticated. You browse records, tail them live, or stream every one to your SIEM over OpenTelemetry.

The edge/brain split is the security property worth understanding: everything that could be captured sits on the machine most exposed to attackers, and it's worth nothing. Compromise the edge and you get a mailbox, not the intel: no keys, no records, no way to forge a hit or read someone else's. It's also why the edge can run on a completely different, untrusted network from the brain.

The vocabulary, in one table

That's the whole mechanism. Everything below is the same story told concretely, in the terms this README and every guide use. Keep this table handy and nothing later will be a surprise.

Term What it means

Bait One deceptive lure, and the design behind it: a payload, its listener, and the staging vessel that gives it a shape.

Payload The code hidden inside the bait. It runs on whatever machine trips the bait, then beacons home. Arbitrary code: you decide what it does.

Listener The payload's other half, running inside the brain: it turns a raw beacon back into meaning. A payload and its listener are written together and ship as a pair. You only meet this one when you author a bait of your own.

Staging vessel What decides the shape a bait takes on the target (a forged decryptor, a config unpacker, a plain script), independently of the payload inside it.

Beacon The callback a tripped bait sends home, signed and encrypted under that copy's own key.

Edge The internet-facing receiver that catches beacons. Deliberately dumb: holds no keys, decrypts nothing, learns nothing.

Brain The trusted service that authenticates and decrypts each beacon, runs the listener, and writes the record.

Record The structured intel unit a beacon becomes: which bait fired, what the payload found, from where, when, how confidently attributed. Everything you read or export reads records.

Instance One planted copy of a bait, with its own key and token. Ten instances of one design are ten independently tracked, independently burnable traps.

Campaign A label grouping instances deployed together, so you can filter records by it later.

forge The one command that takes a bait design and produces a planted-ready instance (register → build → approve).

What it looks like end to end

That's the mechanism. Here it is concretely, with a bait that ships today: Blacksea's own agent_fp payload, which fingerprints the agent harness that runs it, delivered by the pwcrypt staging vessel, which dresses it as a password-vault decryptor.

1. A bait, on disk

Here's what forge hands you. Four files that have to be believable together:

pwcrypt a password-vault decryptor: a real, working tool secrets/github.pwc an encrypted vault, the "secret worth stealing" secrets/.bash_history a stray shell history, with the decrypt command and password in it README.md the tool's own project README

Nothing here is a mockup. The decryptor really decrypts, the vault really holds a secret, and the password in that history file really opens it. An agent that finds this set has everything it needs to reach one conclusion: run the tool on the vault.

Which is the point. Hidden inside the decryptor is the payload: code you wrote, invisible to an LLM reading the binary, wired to a flaw that only this vault can reach. Decrypt this vault and your code runs. Decrypt a genuine one and nothing happens at all.

A decryptor is only what this bait happens to look like, and that's the vessel's doing rather than the payload's. Swap the vessel and the same payload ships behind a release-config unpacker, a database-backup restore tool, or the plain script itself. All three are in the catalog today, and the rest of this walkthrough is identical either way.

1. You plant it, and supply the story

Blacksea hands you those files along with instructions: where each one goes, and the exact command that trips it. But the placement is yours, and it's what makes an agent run it. Dropped in /tmp, the set proves nothing. Give it a host with a reason to exist. Here that's ci-sync-03, a CI node that caches release secrets:

/srv/vaultkeeper/ ├── pwcrypt ← the bait ├── secrets/github.pwc ← the bait ├── README.md ← the bait ├── RUNBOOK.md ← yours: why this box exists, and how to read the vault └── release.env ← yours: the CI config that references the cache /etc/motd ← yours: greets every shell with the decrypt command /home/vault/.bash_history ← yours, with the bait's hint merged in

The dressing is the deception. The runbook is what turns a stray binary into the obvious next move:

The vault is AEAD-encrypted; openssl, gpg and file cannot read it, and the bundled pwcrypt binary is the only supported reader. […] The master password for this node's cache is the one last used; see the shell history the sync agent leaves under secrets/.

Three things cooperate there: a reason the vault is valuable, a reason the bundled binary is the only way in, and the password within reach. An agent working this box isn't tricked into running the decryptor. Running it is the correct next step.

1. An agent takes the bait

LLM-driven attacker │ probes your system ▼ finds the staged lure │ reasons that running it is the way forward ▼ the attacker downloads it │ ▼ runs it: YOU get arbitrary code execution on the attacker's machine

[truncated for AI cost control]