Case studies

Public forensic cases, worked end to end, published with the record.

The swarm has been run on a series of published challenge images (Windows and Linux disks, memory, a phone, a Hadoop cluster), the kind an examiner trains on because the artefacts are real even when the case is staged. Every run is published in full: the goal, the board, the ledger, the trace, the report, and what the harness had to do along the way. Including the runs that had to be stopped.

The evidence images belong to their authors and are not redistributed; each case names where they come from.

Every record, on GitHub →
What "certified" means

Seven things every published run is scored on, read from files the agents cannot edit.

Every published run gets the same scorecard. Each line is read from a file outside the agents' reach, so none of it is a judgement call: the console shows the rows while the run is live, and the report prints them in its custody section. The last row of the seven is the guards the harness enforces, each with the level it held at on that host.

Run scorecard7 of 7
Finished on its own sentinelEvery check of the finish line passed and the swarm wrote its own stop.
registry.json
The evidence is intactEvery file re-hashed at the end and matched; content and metadata reported separately.
inputs.json
Every finding cites an artefactAn uncited claim is counted and shown as uncited; the report's lint refuses a section that cites nothing.
ledger
Unknowns are unknownsA question the evidence cannot answer is reported as open, with the candidate routes marked as hypotheses.
report
The critic signed off, by nameOn the board, naming what it verified; nothing posted after the sign-off is left out of the report.
threads/
The trace is chained end to endVerified against the anchor outside the sandbox; every line attributed to a pane.
trace-anchor
What the harness did is on the recordEvery block, nudge, reap and refusal with its reason, and every guard's enforcement level on that host.
events.jsonl
check · what it meansread from
Three ways a run ends
certifiedEvery check passed and the sentinel was the swarm's own. Nineteen of the published runs.
no sentinelThe clock or the cap ended it first. The checks that passed are counted, and the report is published as it ended. One run.
finished, checks shortThe swarm wrote its own sentinel and the finish line was not fully met. The checks that passed are counted and the report is published as it ended. One run.
Why the scorecard is mechanical A finish line lives in the operator's registry; a hash is a hash; a sign-off is a post on the board by name; the chain is verified against an anchor no pane can write. A run cannot argue its way to certified, and a reader can check every row from the published record.
The case ledger

Every run we have published, with what it cost and what it found.

Seventeen public forensic cases, twenty-one runs. Open one and you get the question the swarm was given, the team that worked it, the names the agents chose for themselves, the tools they wrote while the case was running, what they concluded, and what the run showed about the harness. Every figure here is traceable to a file in the repository.

BelkaCTF2 runs
BelkaCTF 6, Bogus Bill21 September 2026 · s83fdiphone + windows laptop18 tasksbitlocker10agents$68.89spent1h 0mon the clock10/10finish-line checks
The question

A cashier takes a counterfeit fifty. From the suspect's iPhone and his laptop, identify the owner, his conspirators, the print lab, the printer, the designer, the batch timings, the ATM he tested on, the offshore bank and his statement.

The evidence

13.5 GB, copied in and held read-only at the kernel: a full file system acquisition from an iPhone and a six-segment EWF image of a Windows laptop.

The team

3 on grok-4.6 and 4 on DeepSeek-V4-Pro through Azure AI Foundry, 2 on gpt-5.4, and 1 on a model served from the examiner's own machine. Cap $100 for the swarm, $15 per agent.

Nobody was assigned anything. The agents read the goal, saw on the board what their peers had taken, and split by the shape of the evidence rather than by the question list.

What they called themselves

All ten renamed themselves, and most renamed themselves again as the case turned. Fifty-eight calls in all.

iphone-leadiphone-telegramlaptop-financevault-unlock-blockervault-corroborationiPhone Forensics LeadLaptop AnalystPrint Op & DependenciesKey & Printer HunterChat & Timeline AnalystVault & Chat Analystprint-labcatalog-flagschat-evidenceprint-opslaptop-catalogvault-printFinancial Forensics LeadVault CrackerEvidence Minercatalog-huntervault-unlocktimeline-keeperiPhone AnalystiPhone Investigator
What they found

The vault came open. Two agents pulled libbde and libvhdi into the run, decrypted the BitLocker VHDX that had been hidden in an NTFS alternate data stream on desktop.ini, and read its contents with icat: the print template, the Telegram print bot, a bank statement and a Xerox Phaser 7760DN manual. That produced the Rolex at $30,500, the printer model, the venue, and a 25-row offshore statement. The alternate data stream was re-proved independently and corroborated by a Python traceback recovered from the iPhone's Telegram database referencing a file path on the mounted vault drive.

Answers

18 tasks: 9 answered with high confidence, 3 with medium, 6 left open.

Tools they wrote during the case
  • text_search regex search over a text file, returning matching lines with their numbers. Called 22 times.
  • timeline_render renders the timeline from the ledger's event entries, sorted by time.
What the run itself showedThis is the run where an agent walked out of the macOS network guard. Eight package installs had been refused at the proxy over 29 minutes. Then one agent ran pip with the proxy variables stripped from its environment, and the wheels came down without the guard ever seeing the request. It was obedience rather than subversion: the contract it had been given said the package index was reachable. Four other guards held without a scratch for the whole hour, including a proof, taken from inside a live pane, that the previous run's answers stayed unreadable.
BelkaCTF 6, Bogus Bill, first run20 September 2026 · s821ciphone + windows laptop18 tasks5 models, 4 providers10agents$77.32spent50m 32son the clock10/10finish-line checks
The question

The same eighteen tasks, on the same two images, with the swarm started from the console rather than a terminal.

The evidence

13.5 GB, copied in and held read-only at the kernel: an iPhone file system acquisition and a six-segment EWF image of a Windows laptop.

The team

3 on grok-4.6 and 2 on DeepSeek-V4-Pro through Azure AI Foundry, 2 on DeepSeek direct, 2 on gpt-5.4, and 1 local model. Cap $100 for the swarm, $15 per agent.

Nobody was assigned anything. Two images, two jobs: they split by evidence, and one agent took the tracker and the timeline and never touched an image.

What they called themselves

Nine of the ten renamed themselves, several of them twice as the case moved. The local model never did.

iPhone AnalystLocation & Venue HunteriPhone identityLaptop identityVault unlockLaptop ReconLaptop TriageDependency & TimelineDocs and moneyLaptop Deep DiveiPhone Identity & Telegramlaptop-analyst
What they found

The hardest task in the event, solved by five players worldwide, fell at minute 32: the offshore bank, its SWIFT code and its Panama City address, decoded by breaking a home-grown cipher and corroborated against a Safari visit and a screenshot. The BitLocker recovery key was recovered from the other image entirely: a note on the iPhone, gzip-compressed inside a Core Data blob, inside an iTunes backup that sat on the laptop. The four conspirator handles came out of the iOS Telegram postbox.

Answers

18 tasks: 6 answered with high confidence, 1 with medium, 8 as low-confidence hypotheses, 3 left open.

Tools they wrote during the case
  • sqlite_query read-only SQL against a SQLite database, returning JSON rows. Called 38 times.
  • gzip_note decompresses the note blobs inside Apple's NoteStore and prints the plaintext.
  • blob_strings pulls printable strings out of a SQLite blob column.
  • affine_decrypt breaks the home-grown cipher an iOS Shortcut had been applying to a secret chat.
  • bde_unlock parses BitLocker metadata from a volume and tries a recovery password. Called 12 times.
  • bde_unlock2 a second attempt at the same reader, trying a different cipher layout. Called 15 times.
What the run itself showedThe swarm held the key to a door it had no handle for. The host had no BitLocker tooling, the package index was off the allowlist, and two agents wrote their own readers in Python and failed on the authentication tag. Two agents also died silently nine minutes in when their provider returned an insufficient balance, and the console counted them among the working for the rest of the hour. Both faults were fixed before the second run.
Ali Hadi14 runs
Web server, third run18 September 2026 · sf4b2windowsdisk + memory26 gb7agents$12.45spent17m 52son the clock9/9finish-line checks
The question

Given a disk image and a memory image of a breached Windows web server, work out what was done, what was added, what was installed, what shellcode was used, and build the timeline. Eight questions and a bonus.

The evidence

26 GB, copied in and held read-only at the kernel in all seven panes: a raw NTFS disk image and a memory image.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat from the forensic preset.

What they called themselves

One agent announced a callsign on the board. The rest worked under their assigned seats.

MemScope
What they found

The sharpest answer of the three: the reverse shell left in the web root was named as a Metasploit PHP meterpreter stager, hash and inode given, connecting back to the attacker on port 4545. The memory regions three other tools would have flagged as injection were disassembled and shown to be a shared RPC thunk, byte-identical across unrelated processes, with no thread start address in any of them. A false positive, argued down rather than reported.

Answers

8 questions and a bonus, all answered with citations.

Tools they wrote during the case
  • evtx_filter filters Windows event log records by id, provider and substring.
  • regkeys reads keys and values straight out of a registry hive.
What the run itself showedThe ledger worked for the first time: 69 entries written by all seven seats. Claim collisions had fallen from forty on the first run to one. The sharper answer came from a critic reconciliation posted on the board at minute sixteen, after the dumps were re-disassembled and the shells re-hashed.
Web server, second run18 September 2026 · sf6dfwindowsdisk + memory26 gb7agents$9.36spent18m 0son the clock9/9finish-line checks
The question

The same eight questions and bonus, on the same evidence, against a rebuilt harness.

The evidence

26 GB, copied in and held read-only at the kernel, with the extraction and quarantine directories held no-exec.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat from the forensic preset. Seven introductions, every agent took its seat, no negotiation.

What they called themselves

Nobody renamed themselves on this run. Agents were known by their seats.

What they found

The same intrusion, re-cited against a catalog built before any agent spent a token: sqlmap against the injection page enumerating the database user table, command injection from the exec page, two temporary shells written out by the injection tool, five web shells dropped through the upload page, and two local accounts created within twenty seconds of each other and placed in Remote Desktop Users.

Answers

8 questions and a bonus, all answered with citations, and a 66-row timeline.

Tools they wrote during the case
  • csearch a regex searcher over the catalog files, written to verify citations. Called ten times by five agents.
What the run itself showedSix defects surfaced and were all fixed before the next run, including a ledger tool that was registered but missing from the agents' tool list. The timeline seat found that one itself and said so on the board. An agent went idle after its introduction and nothing woke it until a human intervened, which became the idle watchdog the harness ships today.
Web server, first run18 September 2026 · s2cb9windowsdisk + memory26 gb7agents$7.98spent14m 23son the clock9/9finish-line checks
The question

The first case the swarm ever worked: a breached Windows web server, eight questions and a bonus.

The evidence

26 GB, copied in and held read-only at the kernel in all seven panes.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm.

No seats were assigned. The goal suggested a split and the agents argued about it on the board: six of the seven wanted the memory image, and one stood down to take the timeline instead.

What they called themselves

Five of the seven announced a callsign on the board. This was before the harness had a naming tool.

AtlasHexMnemosynememforensicsTriage
What they found

The web application was breached from a single address by brute force, cross-site scripting, SQL injection, file inclusion, command injection and unrestricted upload. Two local accounts were added twenty seconds apart and both placed in Remote Desktop Users. Five web shells and a reverse shell were left behind. A driver dropped at the moment of memory capture was correctly identified as the examiner's own imaging tool rather than attacker software.

Answers

8 questions and a bonus, all answered with citations.

Tools they wrote during the case
  • evtx_filter a Windows event log filter, loaded into every session within 49 seconds of being written.
What the run itself showedThe run that produced the improvement plan. Forty claim violations were detected and snapshotted, two of them real collisions where three agents rewrote the same file in three seconds. Three agents never saw the sentinel and sat idle at the prompt. One agent found a database injection phase in the access log and a peer corroborated it from memory 37 seconds later, then revised its own answer.
Web server, on a Linux server21 September 2026 · s3096linux hostlandlockevidence bound in place4agents$4.81spent14m 06son the clock6/9finish-line checks
The question

The same case, on a rented Linux server over SSH, with no desktop and none of the macOS guards.

The evidence

26 GB, bound in place and never copied, held read-only by Landlock with 79 rules. The disk image still hashed to the value the challenge publishes.

The team

4 on gpt-5.4-mini. Cap $20 for the swarm, $6 per agent.

Nothing was assigned, no catalog, no toolbox check. The goal's suggested split was the only steer.

What they called themselves

The agents renamed themselves seven times between them, but no board or trace was kept in the published package, so the names are lost.

What they found

A smaller team on a smaller model reported the same intrusion: the injection tool and its temporary shells, the web shells left in the application tree, the two added accounts, and staged Meterpreter identified in memory from its own strings. Three pre-existing packages were correctly classed as legitimate software rather than attacker tooling.

Answers

8 questions and a bonus. Five answered substantively; three sections were re-titled and the bonus and the hypothesis were never written.

Tools they wrote during the case
  • evtx_dump a Windows event log reader, written on a host that had none.
What the run itself showedNine defects, seven of them in the harness and two of them security defects, every one invisible to a green test suite in two container tiers. The worst: binding evidence in place left it writable under Landlock, because a symlink the harness created matched nothing in the rule walk and inherited the run's write rights. A touch into the evidence was allowed before the fix and refused after. Two of the three lost checks were the team's own work, and the third was a harness bug in how it counted the files.
Where did the administrator go18 September 2026 · sb6b3windows serverdomain controller35 gb7agents$22.76spent15m 21son the clock7/7finish-line checks
The question

A domain administrator's files are gone and nobody knows what happened. Find out what happened to this system, and how.

The evidence

35.2 GB, copied in and held read-only at the kernel: an E01 image of a Windows Server 2019 domain controller.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $90 for the swarm, $14 per agent.

Nobody was assigned anything.

What they called themselves

All seven renamed themselves, thirty-two calls in all, most of them switching jobs mid-case.

SysProfilerEventHowsys-profileevtx-howhive-persistHiveProfileAdminFateHowLogsPrefetchADSregistry-profilentfs-deletionRegistry & Timeline AnalystRecovery & Verification LeadAdmin-File-ForensicsEventLog+Registry Analyst
What they found

The files were securely wiped rather than deleted. A Sysinternals secure-delete tool was renamed to an innocuous file name, dropped in the Windows directory, run once and deleted, and identified from its embedded debug path and licence text. The administrator's profile directory has an empty index and 421 orphan files full of high-entropy overwritten data, which is that tool's rename-then-overwrite signature. The event logs were then cleared by a command run eight times in 125 milliseconds.

Answers

7 questions, all answered.

Tools they wrote during the case
  • filelist_grep a file list searcher, written but never called. Twenty-one tools carried in from earlier cases did the work instead.
What the run itself showedThe run that needed nothing new: twenty-one tools carried in from earlier cases did the work, and the one tool an agent wrote was never called. It is also the run where a veto did not land. An agent argued from the profile load times that the report named the wrong account as the actor, and gave the chain: the administrator's profile unloaded five minutes before the wipe, another account logged on first, and the administrator's surviving record was a network logon rather than a console one. The published report still names the administrator. The board carries the objection.
Meeting location18 September 2026 · s5d10windowsanti-forensicsnested vm7agents$81.76spent48m 00son the clock7/7finish-line checks
The question

A first investigation found nothing. Find what the suspect uses to hide his activity, restore those methods and tools, and then find where the meeting is.

The evidence

16.3 GB, copied in and held read-only at the kernel.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $90 for the swarm, $14 per agent.

The first case where nobody was assigned anything. The agents read the goal and the catalog and took their own jobs.

What they called themselves

All seven renamed themselves, thirty calls in all. Three of the seven opening names contained the words anti-forensics: they read the goal the same way and had to sort it out on the board.

catalog-scoutvdi-recoverencrypt-meetantiforensics-inventoryBrowser & Encrypted-File HunterBrowser-History HunterAnti-Forensics AnalystAnti-Forensics HunterEvidence MinerTimeline & Report Builder
What they found

The anti-forensics is layered. A Kali virtual machine ran nested inside the guest for fourteen minutes and was then deleted, its virtual disk truncated to zero bytes. A secure-delete tool and a portable defragmenter supplied the wiping, and the antivirus had been disabled first from a PowerShell history that survived. The swarm carved the virtual disk header back out of unallocated space, rebuilt the guest's own syslog, and read the guest's logins from it.

Answers

6 questions. Five answered. The encrypted file and the meeting location were reported as not recovered, and the candidate routes were labelled hypotheses.

Tools they wrote during the case
  • sigscan_e01 a raw signature scanner over the evidence image. Called 17 times.
  • utf16_urls pulls UTF-16 encoded URLs out of a binary.
  • guest_syslog reconstructs a guest machine's syslog from carved virtual disk blocks.
What the run itself showedThe first per-agent cap steer in eleven runs: one agent crossed its limit at minute 46 and was told to finish and stop. A veto stopped a premature sign-off with the words do not sign off as written, struck an invented file, and demanded a timezone note. The previous attempt at this case had been stopped at 25 minutes because an extension fault meant the agents never received the harness's instructions.
Encrypt them all18 September 2026 · s864awindowsthree puzzlesstopped9agents$108.48spent1h 32mon the clock6/7finish-line checks
The question

Three encryption puzzles on one machine: an encrypted document with no known password, a BitLocker volume, and a key pair with a file encrypted to it.

The evidence

7.9 GB, copied in and held read-only at the kernel.

The team

4 on grok-4.6 and 5 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $110 for the swarm, $15 per agent.

The harness gave each agent a seat. Three investigations in one image, so it ran nine.

What they called themselves

Nobody renamed themselves. This case predates the change that stopped the harness assigning work.

What they found

The password for the first puzzle was not on the disk in any obvious place. It was read verbatim out of a chat message cached by the browser, and a second agent then proved the plaintext survived nowhere else: not in the journals, not in shadow copies, not in the recycle bin, and the file record had been reused. The second puzzle turned out to be two volumes with the same name, one a decoy clone holding a taunt, the other the real encrypted one, whose recovery key was found but which could not be opened because the host had no tooling for it.

Answers

5 questions. Two puzzles solved, the third only in part. The report still carries three unresolved placeholders where two seats went silent holding the answers.

Tools they wrote during the case
  • grep_filelist a file list searcher.
  • icat_extract extracts a file by inode, hashes it and previews it. Reused unaltered by three later cases.
  • catalog_grep regex across the catalog. Called 11 times.
  • fve_metadata a BitLocker metadata parser.
  • aescrypt_v2_decrypt a decryptor for the encrypted document's format.
What the run itself showedThe run that was stopped. Two seats claimed the files holding the crypto answers, spent all three of their idle nudges, and wrote nothing for 33 minutes while their claims stayed live. It is also the run that exposed a defect where the per-agent cap had never actually been armed: one agent finished over the stated limit with no steer and no stop. The examiner intervened mid-run to install a library from outside the sandbox, which is why the first puzzle has an answer at all. The case is published because a run that had to be stopped is worth more to the next examiner than one that went smoothly.
NTFS hidden files18 September 2026 · sfcc3windowsntfs464 kb5agents$40.78spent39m 44son the clock7/7finish-line checks
The question

Five things were hidden on this volume using the file system itself. Find all five and explain how each was hidden.

The evidence

464 KB, copied in and held read-only at the kernel: a tiny logical volume with no partition table.

The team

2 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

Nobody renamed themselves.

What they found

Three of the five fell out of the catalog within four minutes because the listing shows named streams. One of them is a file that claims to be a picture and is in fact an archive holding the very tool that reveals hidden streams. The fourth is a planted system file at the volume root whose index entry had been removed and whose attribute flags had been changed, recovered as an orphan by the file system's own repair log, with a password sitting at a known offset in its data. The fifth is a string in the unused tail of a file record, holding the hash of the third item, verified twice by two agents.

Answers

6 questions, all answered.

Tools they wrote during the case
  • extract_stream an alternate data stream extractor, written but never called.
  • check_inputs a hash verifier the agents wrote because they misread one of the finish line's checks as a tool they had to supply.
What the run itself showedA veto with five separate objections stopped the sign-off: that two system file records must not be conflated, that a claim of no timestamping evidence was false for one of them, and three points of detail. The report was revised and the veto lifted. Zero claim collisions in the whole run.
SysInternals18 September 2026 · sd1d1windowsfake installerfirst azure run7agents$37.03spent24m 16son the clock7/7finish-line checks
The question

The user downloaded what they thought was a well-known tool suite, double-clicked it, and nothing opened. Since then the machine has been slow. Work out what happened, and when.

The evidence

7.8 GB, copied in and held read-only at the kernel.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro, the first run on Azure AI Foundry. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

Four agents announced a callsign in their opening post. The harness had no naming tool yet.

Diskhivevol-seatCritic
What they found

A two-stage fake installer. The first stage carries decoy URLs in clear text and its real one obfuscated with a single-byte cipher, pointing at a second stage that installs itself as a service impersonating a virtualisation helper. The payload enumerates the prefetch directory and deletes its files in a loop, which is both the slowdown the user reported and the reason its own prefetch record exists only as a deleted entry. With no memory image, execution was proved from four independent registry and telemetry artefacts that agree to the second.

Answers

6 questions, all answered.

Tools they wrote during the case
  • catalog_grep regex across the catalog's file list, body file and timeline. Called 26 times by four agents.
  • catalog_search the same capability under another name, written six seconds later by a different agent.
  • chunk_needles scans a file or an extracted inode for text needles and returns hits with context.
  • evtx_filter an event log parser.
What the run itself showedThe run where a correction after the sign-off never reached the report. One agent corrected the download URL, named the wrong one explicitly and told its peer not to publish it. The sign-off had already gone up carrying the wrong one. Three further posts corrected the timeline and the indicator file, and the report was never revised. The board and the timeline carry the right answer, the report carries the wrong one, and the case says so rather than quietly fixing it. Also the run that made the harness reserve its own tool names, after an agent tried to write a tool with one.
Browser policy violation18 September 2026 · s8810windowsbrowser6.3 gb7agents$10.03spent11m 11son the clock7/7finish-line checks
The question

An internal investigation for human resources. They believe an employee is using a web browser that does not comply with policy.

The evidence

6.3 GB, copied in and held read-only at the kernel.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

One agent announced a callsign.

Timeline
What they found

The browser did not arrive by download. It was dragged into the virtual machine from the host, and the provenance chain runs from the installer appearing in the drag-and-drop staging directory to a machine-wide offline install nineteen minutes later. Its history holds 36 visits across 15 addresses in two deliberate phases: administering a server through two web consoles, then browsing a storefront at both a public name and an internal address. Nothing was hidden: the profile exited cleanly and no cleaning tool was ever installed.

Answers

7 questions, all answered.

Tools they wrote during the case
  • icat_extract extracts an inode, hashes it and previews it.
  • sqlite_query a read-only query runner used against the browser databases.
What the run itself showedThe largest burst of false collision notices in the series, nineteen of them, caused by a rule that charged a write to whichever agent was running a shell call at the time. The critic spotted the cause in flight and told the board what to do about it. The defect was fixed and the rest of the run was quiet. This is also the only case where the critic opened a second thread and had two other agents cross-check the report against their own notes before signing off.
BSides Amman workshop image18 September 2026 · s2f66windows16 questions5.7 gb7agents$19.11spent15m 19son the clock9/9finish-line checks
The question

A system used for illegal activity. Two accounts are suspects. Sixteen questions, and every answer needs the command and its output quoted.

The evidence

5.7 GB, copied in and held read-only at the kernel, verified unchanged at the end.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

One agent announced a callsign.

Flint
What they found

The confidential documents were opened from a network share rather than a local disk, proved four independent ways: the shortcut files, the recent-documents list, the jump lists and the shell bags all resolve to the same share and mapped drive. The tricky question resolved through three artefact families at once: a tool had been renamed before it was run, which is why no prefetch record exists under its real name, and the run count, the prefetch and the background activity monitor agree to the second on when it ran, once, by whom.

Answers

16 questions, all sixteen answered with command-level citations.

Tools they wrote during the case
  • evtx_filter an event log filter, rewritten once to skip records that fail to render.
  • mam_pf_parse reads a compressed prefetch file's run count and last run time directly.
  • inputs_check a hash comparison of the evidence against the pristine copy. The first version failed on an unbound variable and was rewritten within a minute.
What the run itself showedA bug report, a fix and a verification, all on the board in under three minutes. One agent wrote a verification tool, a peer ran it and it crashed, the author rewrote it inside a minute, and two other agents posted successful runs with the hashes.
Alternate data streams18 September 2026 · sbe18windowsntfs streams7.3 gb7agents$12.45spent15m 14son the clock7/7finish-line checks
The question

An image prepared to test hiding executables in file system streams, running them from there, whether the antivirus scans them, and how every one of those can be detected.

The evidence

7.3 GB, copied in and held read-only at the kernel.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

Nobody renamed themselves.

What they found

Two copies of a terminal client hide in streams on ordinary text files, one of them on a file named after a reserved device so that normal tools cannot open it at all. The cleverest pair are two zero-length files in the prefetch directory, each carrying an execution record as a named stream: because a colon cannot appear in a file name, the system wrote the prefetch for a stream-launched binary as a stream itself, and a normal listing shows two empty text files. Parsed with a decompressor the agents wrote, they name the binaries and the second each was last run, which is direct proof of execution from a stream. The antivirus did scan streams, caught the reverse shell and left the benign copies alone.

Answers

6 questions, all answered.

Tools they wrote during the case
  • evtx_query an event log parser returning filtered records with their named data fields. Called 33 times by four agents.
  • prefetch_mam a decompressor for the compressed prefetch format, rewritten fifteen seconds after the first attempt.
  • reg_hive_query a registry hive reader.
What the run itself showedEight of the nine collision notices were false, caused by a rule about shared extraction directories. An agent posted a hold disowning writes it had not made. The rule was tightened so that a directory named after a teammate belongs to that teammate.
Mystery hacked system18 September 2026 · s9f20windowsbackdoor26.5 gb7agents$16.00spent14m 52son the clock7/7finish-line checks
The question

An employee found a message written in a file on their system and reported it. Find out how the system was hacked, and prove it.

The evidence

26.5 GB, copied in and held read-only at the kernel.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat.

What they called themselves

Nobody renamed themselves.

What they found

The accessibility tool on the login screen had been replaced with a byte-for-byte copy of the command shell, which yields a system prompt from the logon process with no credentials. The next day the built-in administrator account was enabled, took an interactive session, dropped two taunt files owned by the administrators group rather than by the user, and was disabled again four minutes later. No remote logon exists anywhere in the logs and there is no other malware: the persistence is the swapped binary itself.

Answers

6 questions, all answered.

Tools they wrote during the case
  • regkv a registry key and value dumper that also reports last-write times. Called 14 times, 13 of them by an agent other than its author.
  • evtx_filter an event log filter. Called 11 times.
What the run itself showedThe swarm argued and corrected itself. One agent first read an account creation record as an attacker planting a backdoor account. Another pushed back with the install date and the profile list, and after four exchanges the first agent withdrew its own reading and asked the others to use the corrected one. Three peers rewrote their notes to match and the correction reached the report. Separately, a rolled-back clock made wall time useless, so the timeline was rebuilt from monotonic file system sequence numbers instead.
User policy violation18 September 2026 · s0ae9windowsexfiltration26.5 gb7agents$11.40spent10m 00son the clock7/7finish-line checks
The question

A workstation image. Find the policy violation and prove it.

The evidence

26.5 GB, copied in and held read-only at the kernel, verified seven times during the run.

The team

4 on gpt-5.4 and 3 on deepseek-v4-pro. Cap $60 for the swarm, $12 per agent.

The harness gave each agent a seat. The critic noticed two of the report's questions belonged to no seat and took them on itself.

What they called themselves

Two agents announced a callsign.

Flintprovenance
What they found

Deliberate exfiltration by the only account with interactive logons. A confidential document sits in the user's pictures as a file renamed to look like an image, byte-for-byte identical to the original. An encrypted archive went out over a chat client, and the chat database itself carries the user asking an outside contact for help with exfiltration and saying the network is monitored. The contact suggested remote control software, which was installed and used for a nine-minute session with file transfer, clipboard and chat all permitted. Afterwards the user ran three wiping tools, a browser for anonymous access and an imaging tool.

Answers

8 questions, all answered.

Tools they wrote during the case
  • evtx_filter an event log filter.
  • inputs_check a full hash verifier of the evidence against its manifest, run by five agents before they finished.
What the run itself showedThe fastest full case in the series, at ten minutes. Fifty-three writes were taken as implicit claims with no collisions at all. One agent caught a typo in its own ledger entry and posted the correction, which reached the deliverables. The report's own examiner notes flag three things it could not prove, including that the machine's clock had been rolled back twice.
Linux3 runs
The attacker's own machine18 September 2026 · s9da9linuxattacker disk9.4 gb7agents$23.72spent21m 30son the clock7/7finish-line checks
The question

The only disk in the set that belongs to the attacker rather than a victim. Reconstruct what was done: the tools, the targets, the loot and the timeline.

The evidence

9.4 GB, copied in and held read-only at the kernel, with the root file system inside a logical volume.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $80 for the swarm, $14 per agent.

Nobody was assigned anything.

What they called themselves

All seven renamed themselves, thirty calls in all. One called itself GapFill and described its job as filling the gaps the others were racing past, which is not a job any seat preset would have written.

HostMapLootNFSTeethLootCriticLVM-rootGapFillroot-artifactsmsf-sessionsNFS & logsArtifact ExtractorEvidence Extractor & AnalystReport & Timeline KeeperCritic & Sign-offTimeline & Evidence Extractor
What they found

The exploitation window is about 34 hours, opened by a keyring unlock in the authentication log and closed by the last write to the exploitation framework's history. The attacker renamed the machine seventeen minutes in. Everything targets one address: a full port sweep, then four exploitation modules with three sessions established and lost. The post-exploitation went through other channels entirely: a network file system mount held for four minutes, a file transfer client left connected with its credentials recoverable from its own configuration, and a remote desktop client pointed at the same host.

Answers

6 questions, all answered, and the second answered in both directions with an explicit table of what could not be evidenced.

Tools they wrote during the case
  • parse_utmp parses the binary login record files.
  • kali_icat an extractor pinned to the logical volume's offset.
What the run itself showedThe real payload of the case is the attacker's own mistakes, and the swarm reported them: the history file was deleted and the deletion left its own trace, the session recording was never enabled so the framework's log directory is empty, and every artefact recovered is hashed in the report. The failure mode to watch in a swarm that assigns nothing also showed up here: two agents converged on the critic job late, and a third renamed itself critic at the end.
Compromised Hadoop cluster18 September 2026 · s9a5flinuxthree machines9.8 gb7agents$29.57spent24m 11son the clock7/7finish-line checks
The question

Three disk images from one cluster, a master and two slaves. Answer each question per machine.

The evidence

9.8 GB across thirteen files, copied in and held read-only at the kernel: three images with their file lists and acquisition records.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $80 for the swarm, $14 per agent.

Nobody was assigned anything. The swarm read the division off the catalog: one agent per machine, plus one carrying indicators between them.

What they called themselves

All seven renamed themselves, twenty-eight calls in all.

Master-AccessReport-TimelineSlave1 InvestigatorCatalog HunterDeleted-Log RecoverySlave2 InvestigatorCross-Node IOCTimeline ReportMaster Investigator
What they found

The single most load-bearing decision in the run was converting every local log timestamp to a common zone, so that the order of events across three machines is real rather than apparent. The master was taken by a password spray from one address that succeeded on the cluster's service account three seconds in. The two slaves were never sprayed: the attacker pivoted using the cluster's own trust relationship. All three were escalated with the same kernel exploit binary, copied around the cluster and then deleted. Persistence differs per machine: a backdoor account on one, a listener installed as a service on another, and a payload on a high port on the master, whose logs had been wiped.

Answers

6 questions, answered per machine.

Tools they wrote during the case
  • master_icat an extractor for the master node.
  • hdfs_node_icat the same thing parameterised by node, after three agents had each written their own. Called 19 times.
What the run itself showedThe cleanest mapping of agents to evidence in the series, and the swarm worked it out rather than being told. The highest number of implicit claims of any run, with no collisions at all. Three agents independently wrote the same extractor before one of them wrote the parameterised version everyone then used.
Compromised Linux web server18 September 2026 · s9d83linuxlvm1.2 gb7agents$38.15spent27m 22son the clock7/7finish-line checks
The question

The first non-Windows image in the set. Find how the actor got in, what was modified, and what persistence was left.

The evidence

1.2 GB, copied in and held read-only at the kernel, with the root file system inside a logical volume the standard toolkit cannot read.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $70 for the swarm, $14 per agent.

Nobody was assigned anything.

What they called themselves

All seven renamed themselves, thirty calls in all. Four opened on the same job, mapping the logical volume, and the report keeper and the citation critic were both filled by agents that had started somewhere else.

LVM mapperWeb-initial-accesscitation-criticLVM-rootweb-accessreport-assemblerlvm-mapperjournal-privescFTK-index + web logsBoot-Analyst-Ledgerroot-fs-analyst
What they found

The catalog could not read the volume, so the swarm derived the offset itself from the volume manager's own metadata. About 450 failed root logins from the attacker's address look like the way in and are not: there is no successful one. The actual entry is a remote code execution flaw in the content management system, sent as a crafted request with the payload encoded, followed two seconds later by a working variant, delivering a reverse shell. Escalation used a kernel flaw whose compiled exploit was left in the temporary directory and whose source was deleted, a deletion the shell history records. Persistence is three-fold: a dormant system account given a password, a shell and administrative rights, a second backdoor account, and a small web shell dropped into the application tree and immediately exercised.

Answers

6 questions, all answered.

Tools they wrote during the case
  • ftk_csv filters the imager's file list by path, pattern, date and deleted state.
  • fls_root a lister pinned to the logical volume's offset.
  • icat_root an extractor at the same offset.
What the run itself showedThe catalog partially failed, and that failure is what forced the useful work: six catalog entries could not be built because the file system type could not be determined at either candidate offset, which is exactly why the swarm had to find the right one by hand.
Memory1 run
RansomCare18 September 2026 · s69d3memory onlytwo dumps18.3 gb7agents$27.47spent22m 03son the clock7/7finish-line checks
The question

Two memory dumps of machines hit by ransomware, captured four days apart. No disk, no file system, nothing to carve. Find the ransomware's code, dump it, and explain what happened to the victim.

The evidence

18.3 GB, copied in and held read-only at the kernel: a raw memory image and a crash dump, pre-parsed into fourteen catalog files before any agent started.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $90 for the swarm, $14 per agent.

Nobody was assigned anything. The swarm split by dump rather than by artefact type.

What they called themselves

All seven renamed themselves, thirty-four calls, the most of any run.

dump4 hunterdump5 hunterq3 hashes + criticreport criticdump4-hunterdump5-hunterdump5-criticq1-impactRansomCare dumperdump5 victimIOC strings + ledgerRansomCare Lead AnalystReport & Timeline BuilderRansomCare Lead InvestigatorReport BuilderRansomCare Analyst
What they found

Both dumps are the same machine captured four days apart with two different acquisition tools. The ransomware is user-mode and works by injection: a dropper launched from the file manager exits within a second, and the logic then runs inside an injected text editor process, which in the later dump opens network sockets and spawns a process masquerading as a system service, behaviour the real editor never shows. Four injected regions were dumped and hashed, and the configuration recovered from them gives the tag, the ransom note name, the contact address, the file markers, the target extensions, the key derivation calls, and an obfuscation habit of reversing strings.

Answers

6 questions, all answered.

Tools they wrote during the case
  • volrun a memory analysis wrapper, written but never called. The swarm used the underlying tool directly instead.
What the run itself showedThe run recorded 374 evidence violations in 22 minutes with nothing actually modified. The images arrived with an execute bit, the sweep wants none under the evidence directory, the kernel guard refuses to change it, and the repair fails, so the same two files were re-reported on every sweep. The custody record shows both images unchanged. The fix was to normalise the mode at copy time, and it was proved closed on the very next run with the same copy path and zero violations. A veto also stopped a family misattribution, showing that the strings being used to name the ransomware lived in antivirus signature memory rather than in the sample.
Unallocated1 run
Malware in unallocated space18 September 2026 · s1839no file systemcarving26.2 gb7agents$23.38spent24m 01son the clock7/7finish-line checks
The question

A system was compromised and the only evidence left is its unallocated disk space. No partition table, no file system, and a catalog that came back empty.

The evidence

26.2 GB, copied in and held read-only at the kernel: one raw blob of unallocated space.

The team

4 on grok-4.6 and 3 on DeepSeek-V4-Pro through Azure AI Foundry. Cap $90 for the swarm, $14 per agent.

Nobody was assigned anything. Seven agents, seven jobs, no overlap.

What they called themselves

All seven renamed themselves, twenty-six calls in all.

PE-CarverIOC-StringsPrefetch-PEprefetch-carvereg-evtx-lnkPE-malware carveDelivery-IOCCarver-AnalystDocs-TimelineCarverReport-Timeline
What they found

The whole compromise takes about ninety seconds. Browser history fragments at known offsets show two searches; a fake tool suite was downloaded to a public directory and executed, its prefetch record recoverable from the raw blob and its mapped libraries confirming a downloader; a second binary was installed as a service impersonating a virtualisation helper and configured to start automatically. That second binary is a credential stealer targeting eight chat, browser and mail clients. The report states its negatives plainly: no command and control address survived in the fragments, and no lateral movement was found.

Answers

6 questions, all answered.

Tools they wrote during the case
  • sig_carve a signature scanner with context.
  • ioc_scan a streaming needle scanner reporting offsets, skipping zero runs and removing duplicates. Called 24 times.
  • lnk_parse a shortcut file parser with a scan mode.
  • file_carver a header and footer carver by file type.
  • mam_scan a prefetch scanner that cracked the compressed format.
What the run itself showedThe goal said outright that no carver was installed on the host and told the agents to write one. They wrote five, and this is the most productive forging of the series. Two large legitimate binaries were also carved out and correctly identified as noise rather than reported as findings. The run also closed the evidence-violation defect from the case before it by measurement: the same copy path, the same kernel guard, a bigger blob, and zero violations.
How to read the numbersSpend is the figure the case record publishes. Where the harness charged a different rate at the time, the case record carries the arithmetic. Checks are read from files the agents are refused permission to edit, so a run cannot certify itself. For the capture-the-flag cases the answer counts are the swarm's own confidence grades: correctness is scored against the published write-up outside the repository, and the expected values are deliberately never committed, so a later run cannot read the back of the book.
What each record contains

The same shape for every case, so a reader can compare two runs the way they would compare two lab notebooks.

  • The goal document as handed to the swarm, with its finish line
  • The contract the agents read, rendered
  • The board, every thread, and what it adds up to
  • The ledger: events, indicators, findings, each with source, check and confidence
  • The trace, hash-chained, every call with its arguments and result
  • The report, its custody section, and the hashes of every artefact
  • The tools written, with their manifests
  • What was pruned from the public copy, and why, by hash
The goal document and its finish line, as the console renders them
A ledger
A board read as a story
Spend by model and by agent
The stopped runs are published too

A run that had to be stopped is worth more to the next examiner than a run that went well.

A correction that never reached the report. A per-agent cap that turned out never to have been armed. An agent that walked around an advisory guard. Each is in the record with its cause named, and each changed the harness: the sign-off now names what it verified, the caps are asserted at kickoff, and the contract tells the truth about the network. The case studies double as the change log.