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 warns about 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 run; every line attributed to its agent.
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.
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 agent 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.

One row for every published run. 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.

Ali Hadi18 runs
Meeting Location, until solved27 September 2026 · sae6e7dwindows diskanti-forensicsfree-space recoverymicroVMuntil solved8agentsNo metered cost: a subscription. 255,087,754 tokens in 2,897 model callsspent1h 16m 34son the clock7/7finish-line checks
The question

A suspect's only computer, imaged after he left, where a first examination found nothing. How he hid his activity, which tools he used and how to restore them, what he searched for, the encrypted file that holds the meeting place and how it was decrypted, where he got the location from, and a timeline.

The evidence

16.3 GB: one E01 image of a Windows machine, shared read-only into every agent's microVM and hashed at kickoff.

The team

3 on gpt-daybreak-blue, 3 on gpt-6-sol and 2 on gpt-6-luna, all through an openai-codex subscription, with gpt-6-luna writing the summaries when an agent compacted its context; every agent in a microVM of the base image, every heavy step a job in a worker VM. Cap No token, spend or time cap: the run went on until every question had an answer that stands, with a regroup after 15 quiet minutes.

Nobody was assigned anything. Several agents claimed the browser history in the same second, and the report author seat was taken twice at once; within the first minute they had split the case into a critic, execution artefacts, the browser, the journal and the timeline, the encrypted object, the report, anti-forensics and deleted material.

What they called themselves

Several agents renamed themselves as their work moved. Two of the final names are left out here because each names part of an answer; the post refers to those agents by seat id.

CipherCriticExecution ArtefactsSearch TrailReport AuthorBrowser EvidenceBrowser TrailJournal and timeline examinerEncrypted meeting artefactBrowser and search recoveryReport integratorBrowser and source examinerAnti-forensics investigatorMeeting-location recovery
What they found

The host's free space held the searches, the encrypted page and the whole message; a scan written in a job that kept every offset recovered the message and mapped it back to a single cluster. The concealment's disk file, whose MFT entry had lost its data, was rebuilt from the undo records of its own deletion in the NTFS transaction log and read in place without being written out, which gave back the original file and the browser's own records. Compressed session snapshots carved from free space tied the encrypted page to the message. The password was never found.

Answers

Scored against the published answers, every question has an answer resting on the evidence; the one part missed is the password of the encrypted object, which was never found, and the operator confirmed that nothing more exists. The reflection and timeline question is not graded.

Tools they wrote during the case
    What the run itself showedThe first done calls came at about the point where the earlier runs of this case ended, and were refused because some leads still rested on a deferral or on infeasible; the second half of the run reopened those routes and rebuilt the disk file. A password candidate was tried by a job that could only say whether it authenticated; one agent printed it into a tool result by mistake, said so on the board at once, and custody lists the entries to redact. The operator was asked twice: once for material that does not exist, once to reopen leads for the finish.
    Meeting Location, on the basic flow27 September 2026 · s6895a8windows diskanti-forensicsfree-space recoverymicroVM8agentsNo metered cost: a subscription (108M tokens)spent39m 03son the clock8/8finish-line checks
    The question

    A suspect's only computer, imaged after he left, where a first examination found nothing. How he hid his activity, which tools he used and how to restore them, what he searched for, the encrypted file that holds the meeting place and how it was decrypted, where he got the location from, and a timeline.

    The evidence

    16.3 GB: one E01 image of a Windows machine, shared read-only into every agent's microVM and hashed at kickoff.

    The team

    3 on gpt-daybreak-blue, 3 on gpt-6-sol and 2 on gpt-6-luna, all through an openai-codex subscription; every agent in a microVM of the base image, every heavy step a job in the disk or full image. Cap 400M tokens, $250 and 180 minutes for the swarm; 60M tokens per agent.

    Nobody was assigned anything. Several agents claimed the encryption question in the same second; they yielded to each other on the board within the first minute and split the case into encryption and the meeting place, browser and search history, file system journals, user activity, the timeline, anti-forensics, deleted material and the report.

    What they called themselves

    Two early names were refused by the hub as duplicates; four agents renamed themselves before settling, one of them three times.

    CipherTrailWebTrailLockpickChronicleCase IntegratorTimeline stewardJournalChronicleTimeline KeeperUserTraceEncrypted-location examinerBrowser SearchReport integratorAnti-forensics examinerDeleted artifacts analyst
    What they found

    The concealment's disk file had lost its data, so the swarm streamed the whole NTFS free space through string filters in a job, then through an offset-keeping scanner, and read the concealment's logs, browser cache and session snapshots straight from free clusters, the key bytes re-read by physical cluster. A journal parser written in a job, after the pack tool read nothing, proved what a cleaning utility did; a clock-step detector found the reboot that had reversed the order of the events. The meeting place and its source were proven byte for byte from cached copies and deleted session snapshots.

    Answers

    Scored against the published answers: 3 correct, 3 partial, 0 wrong, 0 unanswered. The password of the encrypted object was not found.

    Tools they wrote during the case
      What the run itself showedNothing was forged, although the harness suggested it more than once: the decisive work was short single-purpose programs in sealed jobs. An attribution argument ran in the open and superseded more than a third of the ledger when its premise fell. One agent's compaction started and never finished, and one agent spent most of the run in wait, which the harness counted as activity.
      Encrypt Them All, until solved27 September 2026 · se5fdcdwindows diskencryptionoperator requestmicroVMuntil solved8agentsNo metered cost: a subscription. 433,913,201 tokens in 4,928 model callsspent3h 38m 55son the clock7/7finish-line checks
      The question

      One Windows machine and three puzzles: an AES-encrypted README with no known password, a volume named R2D2 under BitLocker full-disk encryption with something hidden inside, and a message encrypted to a key pair whose keys file sits in Downloads. Recover what each hides, the timeline, and how the parts connect.

      The evidence

      7.9 GB: one E01 image of a Windows machine, shared read-only into every agent's microVM and hashed at kickoff.

      The team

      3 on gpt-daybreak-blue, 3 on gpt-6-sol and 2 on gpt-6-luna, all through an openai-codex subscription; every agent in a microVM of the base image, every heavy step a job in a worker VM. Cap No token, spend or time cap: the run went on until every part had an answer that stands, with a regroup after 15 quiet minutes.

      Nobody was assigned anything. Four agents collided on the same part in the first seconds; one closed its lead as a duplicate and took the critic seat, and within a minute the team had split into the caches, the file system journal, user activity, the encrypted volume, the key pair, anti-forensics, a report author and an output-safety reviewer.

      What they called themselves

      Several agents renamed themselves as their work moved. No name here carries an answer.

      Cache CriticOffline clue investigatorUser Activity HunterExecution analystR2D2 inner-volume remnantsJournal chronologistCandidate output-safety reviewerReport assembler
      What they found

      The caches held the conversation around the first part and the route to recover it; a hand-written change-journal parser that keeps byte offsets and splits file references ruled out the other routes. The encrypted volume was opened from recovery material matched to its own protector and read in a job. The third part needed a clue from an online video the evidence pointed to; with no web access the team asked the operator for the video's title only, as offline material, and after a bounded authorisation recovered and verified the last secret offline. The finishing result was written by a job that then hung, and surfaced only when its owner cancelled it to keep a fingerprint of the secret out of the store.

      Answers

      Scored against the best-known answers, every part has an answer that stands, including the third part, which no earlier run of this case had finished. The reflection and timeline part is not graded.

      Tools they wrote during the case
      • ledger_timeline renders the run's own standing ledger events as a sorted table, leaving out superseded entries; made with the tool maker and revised once during the run
      What the run itself showedNo run of this case had ever finished the third part; this one did, by running until every part had an answer. A success sat written but unseen for about a quarter of an hour inside a job that would not return, and came to light through a safety objection rather than a diagnosis of the hang. The team kept the secret out of its own record: it vetoed sealing any hash of it, asked the operator to keep the sealed artefacts out of any hand-over package, and searched the ledger for leaks.
      Encrypt Them All, on the basic flow27 September 2026 · s2a59b2windows diskthree encryption puzzlesbitlockermicroVM8agentsNo metered cost: a subscription (50M tokens)spent15m 28son the clock8/8finish-line checks
      The question

      One Windows machine and three puzzles: an AES-encrypted README with no known password, a volume named R2D2 under BitLocker full-disk encryption with something hidden inside, and a message encrypted to a key pair whose keys file sits in Downloads. Recover what each hides, the timeline, and how the parts connect.

      The evidence

      7.9 GB: one E01 image of a Windows machine, shared read-only into every agent's microVM and hashed at kickoff.

      The team

      3 on gpt-daybreak-blue, 3 on gpt-6-sol and 2 on gpt-6-luna, all through an openai-codex subscription; every agent in a microVM of the base image, every heavy step a job in the disk or full image. Cap 400M tokens, $250 and 180 minutes for the swarm; 60M tokens per agent.

      Nobody was assigned anything. Most of the team reached for the caches in the first seconds; they let go of each other on the board and settled into distinct seats before the first minute was out, and one of them volunteered as the critic.

      What they called themselves

      Two names were refused by the hub as duplicates; one agent renamed twice in seconds before settling.

      Cache CommunicatorCache communications examinerCache and communication examinerCache Comms AnalystExecution Artifact AnalystTimeline IntegratorRegistry and execution examinerJournal recovery examinerKey decryption examinerDisk CartographerCrypto/impact examinerUser activity examiner
      What they found

      Part 1's password was found in the caches and handed to the decryption library inside a job, never on a command line; the other recovery routes the question lists were each proven dead. The BitLocker volume opened after a short run of jobs that learned from each failure, and the derived catalogue made the decrypted volume searchable without being asked. The volume's use was corroborated from separate artefact classes. Part 3 was tried only with the candidates the evidence offered, once each.

      Answers

      Scored against the best-known answers: 4 correct, 1 partial, 0 wrong, 0 unanswered. The Part 3 message was not decrypted.

      Tools they wrote during the case
        What the run itself showedThe team built its own secret discipline from one ground rule in the goal: passwords passed by reference, peers asked for locations instead of values, and ledger entries superseded to take a password out. A volunteer critic signed the report and the timeline by their hashes.
        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 agents answered the shellcode question by family and type, with the hash and inode of the file that carries it. Memory regions that three other tools would have flagged as injection were disassembled, compared byte for byte across processes and checked for thread start addresses before the agents drew any conclusion from them.

        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 extracts 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. The agents traced each attack from the web server's access log to what it left on disk, listed every added file with its hash, and took the added accounts, their timing and their group membership from the event logs and the registry.

        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 agents read the attack sequence and where it came from in the web server's access log, took the added accounts and their group membership from the event logs and the SAM hive, and listed what was left behind with hashes. They classed each installed program and driver as attacker or legitimate from its install time and provenance.

        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 an attack phase in the access log, and a peer corroborated it from memory 37 seconds later and 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 from the same sources: the web server's logs, the files left on disk, the account records, and a payload identified in memory from its own strings. Installed software was classed as legitimate or attacker tooling from its install records.

        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 serveradministrator profile35 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 machine.

        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 agents read the administrator's profile directory from its index and the file records around it, measured the entropy of the data left in them, and matched the pattern to a known tool's behaviour. They identified the program responsible from its embedded debug path and licence text, placed its execution with the file system timeline and the execution artefacts, and dated the later events from the event logs.

        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 and the logon records that the report named the wrong account as the actor, and set out its chain of evidence on the board. The published report was not changed. The board carries the objection.
        Meeting location18 September 2026 · s5d10windowsanti-forensics16.3 gb7agents$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. One of the opening names is left out here because it names part of an answer.

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

        The agents worked each concealment method back from what it left: execution artefacts and a surviving command history for the tools used, the file system metadata for what had been deleted, and carving of unallocated space for structures that no longer had a file. From carved blocks they rebuilt a log file and read the activity recorded in 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.
        • name withheld rebuilds a log file from carved disk blocks; its name would give part of an answer away.
        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. The agents recovered it from a cache, and a second agent then proved the plaintext survived nowhere else: the journals, the shadow copies and the recycle bin held no copy, and the file record had been reused. For the second puzzle the agents located the encrypted volume and its recovery key, and could not open it 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.
        • name withheld a decryptor for the encrypted document's format; its name would give the format away.
        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 file listing already showed how they were hidden. The agents found the fourth through the file system's own metadata and journals, and the fifth by reading file system structures byte by byte; two agents verified it independently.

        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: two on how the report described individual file records and three on points of detail. The report was revised and the veto lifted. Zero claim collisions in the whole run.
        SysInternals18 September 2026 · sd1d1windows7.8 gbfirst 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

        The agents took the download apart statically, with strings, decoding and hashing for its indicators. They followed what it installed through the registry and the persistence locations the question lists, explained the slowdown from the payload's own behaviour, and, with no memory image, proved execution 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 agents traced the browser's provenance from the first appearance of its installer on disk to its installation, through the file system timeline and the install records. They read its history database for what it was used for and when, and checked the profile's session state and the installed programs for any attempt to hide or clean.

        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

        Where the confidential documents were opened from was proved four independent ways: the shortcut files, the recent-documents list, the jump lists and the shell bags all resolve to the same location. The tricky question resolved through three artefact families at once: the run count, the prefetch and the background activity monitor agree to the second on when the tool ran and 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

        The agents enumerated every named stream on the volume from the file system metadata, extracted and hashed each payload, and identified it from its content. For the stealthy case they parsed the execution records with a decompressor they wrote, which gave the binaries and the second each was last run, direct proof of execution from a stream. The antivirus question was answered from the Defender operational log.

        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 · s9f20windowsintrusion26.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 agents compared system binaries against their expected versions and traced a replacement through the file system timeline. They followed account changes and logon sessions through the event logs, read the owner of the message file from its security descriptor, and checked the logs for remote logons and the disk for other malware before settling on the way in and the persistence.

        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's first reading of an account record was challenged by another with the install date and the profile list, and after four exchanges the first agent withdrew its 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 · s0ae9windowsworkstation26.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

        The agents stated a hypothesis for the violation and proved it across artefact families: the file system and hashes for the documents involved, the chat client's database, the install records and logs of the software involved, and execution artefacts for what the user ran afterwards. They tied each step to an account through its logon records.

        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.
        BelkaCTF4 runs
        Bogus Bill, until solved27 September 2026 · s10d40eioswindows diskoperator requestmicroVMuntil solved10agentsNo metered cost: a subscription. 815,279,567 tokens in 9,113 model callsspent4h 06m 55son the clock10/10finish-line checks
        The question

        A cashier takes a counterfeit bill. 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, and map which questions depend on which.

        The evidence

        14.5 GB, shared read-only into every agent's microVM and hashed at kickoff: a full file system acquisition of an iPhone as one tar archive, and a six-segment EWF image of a Windows laptop.

        The team

        4 on gpt-daybreak-blue, 3 on gpt-6-sol and 3 on gpt-6-luna, all through an openai-codex subscription; every agent in a microVM of the base image, every heavy step a job in the mobile, disk or full image. Cap No token, spend or time cap: the run went on until every question had an answer that stands, with a regroup after 15 quiet minutes.

        Nobody was assigned anything. Most of the team claimed the phone's identity questions in the first seconds; the split formed from pivots one agent at a time into the phone, the laptop, the locations, a report author, a critic and a dependency keeper. Later, two routes the critic suggested to everyone were each opened by several agents within a second, and the register's timestamps decided the order.

        What they called themselves

        Agents renamed themselves as their work moved. One seat's early name carried an answer, so the post refers to it by seat id; its final name here is safe.

        Q6 Finance & Payment App ExaminerTimeline & Flags IntegratorReport AuthorEvidence CriticQ6 laptop browser examinerQ6 Safari History ExaminerQ18 CMMM Cache ParserApril Amount-Source AuditorFinal Integration MonitorQ6 Cross-App Message Examiner
        What they found

        A key found in a note on the phone opened an encrypted container on the laptop, passed by sealed reference so it never reached a post. The phone was worked without a mobile forensics suite: general Python readers over its databases, message blobs and caches, and offset-seeking reads into the archive by the kickoff catalogue. An image cache with no OCR available was read as contact sheets split between two seats. Three narrow lookups the operator allowed (a geocoder, a map query and a short-link check) helped once, produced a confident wrong street once, and gave a partly-right present-day map once.

        Answers

        Every question ended with an attested answer: cited to the evidence, reviewed by a second agent and standing at the close. Graded against the published answers, some were correct, some partial and some wrong. Attested means the record is consistent and cited; it does not mean the answer is the true one.

        Tools they wrote during the case
          What the run itself showedThe run reached an answer for every question and then spent about half an hour getting through the finish gate: six leads closed hours earlier still blocked it, agents cannot reopen a closed lead, and an agent that forced the issue by superseding still-true entries broke an answer chain that had to be rebuilt. The clearest lesson is that attested is not correct: answers can be cited, reviewed and standing and still be wrong, and the outside map lookups were where the run was most confidently wrong.
          BelkaCTF 6, Bogus Bill, on the basic flow27 September 2026 · s306463iphone + windows laptop18 tasksmicroVMjob images: disk, mobile, full10agentsNo metered cost: a subscription (142M tokens)spent44m 42son the clock11/11finish-line checks
          The question

          A cashier takes a counterfeit bill. 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, and map which questions depend on which.

          The evidence

          14.5 GB, shared read-only into every agent's microVM and hashed at kickoff: a full file system acquisition of an iPhone as one tar archive, and a six-segment EWF image of a Windows laptop.

          The team

          4 on gpt-daybreak-blue, 3 on gpt-6-sol and 3 on gpt-6-luna, all through an openai-codex subscription; every agent in a microVM of the base image, every heavy step a job in the disk, mobile or full image. Cap 400M tokens, $250 and 180 minutes for the swarm; 60M tokens per agent.

          Nobody was assigned anything and nobody proposed a plan. Most agents went for the iPhone identity questions at once; the split formed from pivots over the first minute, one agent at a time, until each question had an owner, with a timeline keeper, a dependency mapper and a report integrator.

          What they called themselves

          One name was refused by the hub as a duplicate; most agents renamed themselves as their scope narrowed, and one kept its first name throughout.

          Mobile identity/chatWindows storage/printContainer pathReport integratorMobile Identity & ChatsPrint & Validator ForensicsATM & Validator LeadsPocketChatLaptop VaultLuxury & ConcertMobile MessagesTemplate TrailTelegram financeOffshore financePrint ForensicsPrint and Offshore ForensicsPrinter Evidence AnalystiPhone artefactsBill-print forensicsTimeline compilerTimeline and dependency QAiPhone analystDependency mapperLaptop artifact investigatorBill production address investigatorApril proceeds investigator
          What they found

          The laptop's encrypted vault was found by a file system listing and opened with a recovery password that sat in a note on the phone, read inside a worker and never printed; separate agents unlocked it independently. The phone's tar was read by seeking to the catalogue's offsets instead of extracting it. A cropped bank screenshot was rebuilt from the data the Snipping Tool's crop flaw leaves behind, and the uncropped original then found among the tool's temporary files. A phone Shortcut's byte cipher was re-implemented from a known exchange to read an encrypted channel.

          Answers

          Scored against the published answers: 10 correct, 2 partial, 2 wrong, 4 unanswered.

          Tools they wrote during the case
            What the run itself showedNothing was forged; the decisive work was short programs in sealed jobs. The critic signed off while saying the sign-off did not assert that every answer had been met. Harness faults surfaced: the iOS recipe's detection failed at kickoff, every icat_extract job failed on a read-only path, and the goal promised geolocation lookups the network did not allow.
            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 the libraries they needed into the run, located the hidden encrypted container on the laptop, decrypted it and read its contents with icat. The documents inside bore on several of the print and finance tasks. The container's location was re-proved independently and corroborated from the phone: an error trace recovered from its Telegram database referenced a path on the mounted volume.

            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 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 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.
            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 agents bounded the exploitation window from the authentication log and the exploitation framework's own history, and reconstructed what was run against the target from shell histories, tool logs and configuration files. They checked mount records and logs for the network file system question.

            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 case asks for the attacker's operational-security mistakes, and the swarm reported each one with the trace it left; 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 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 could be trusted. From there the agents traced the way in on each machine through its logs, carried indicators between the three nodes, hashed the escalation artefacts on each, and listed the persistence on each machine separately.

            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. The agents weighed each candidate way in against the authentication and service logs, and decoded the payload of the entry that worked. They traced the privilege escalation through the file system and the shell history, and checked each persistence location the question lists.

            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. 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

            The agents profiled each dump and compared the two, found the ransomware's code through process listings, command lines and memory region analysis, and confirmed it from its behaviour across the dumps. They dumped and hashed the suspect regions and recovered the embedded configuration from them.

            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 agents carved browser history fragments, prefetch records and executables out of the raw blob by signature, and rebuilt delivery, execution and persistence from them with the offset of every fragment. They identified what each binary does from its strings and imports, dated the sequence from timestamps inside the carved records, and stated plainly what the fragments could not show.

            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, shown with its limitations
            A board read as a story
            Spend by model and by agent
            The run's tool jobs and what each sealed into the store
            The custody verdict and its checks
            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.