Attack Lab #4: We Could Quietly Erase Our Own Attack Records — the Audit Log Was Undefended

Attack Lab · Episode 4. Last episode we said we'd go after the audit chain: can the log of a blocked attack be forged or erased? The answer: yes. Two clicks.

The first three episodes went after identity, limits, and attribution. This one goes after Pillar 5: traceability & non-repudiation — when something goes wrong, can you trace it, and can the actor deny it?

Result: we could erase the fact that anything went wrong at all.

The attack: make an attack un-happen

After the gateway blocks an attack, it writes two records: a ThreatEvent (threat log) and an AuditLog entry. Sounds thorough.

The problem: those are just ordinary database rows. Anyone with admin access can delete them. And we handed out the delete buttons ourselves — the "delete" on the threat page, the "clear" for demo data.

Real run, live admin:

1) Attacker sends an over-limit payment
   → blocked at Firewall/Limit, writes ThreatEvent #4021 + AuditLog

2) Admin (or anyone who reaches the admin panel) clicks "delete"
   → ThreatEvent #4021 is gone
   → the audit log holds no trace that anything was ever deleted

3) After-the-fact audit
   → nothing found. The attack looks like it never happened.

Step 2 is fatal: the table that records the attack and the table the attacked party can delete are the same table. A log that can be wiped isn't a log — it's a whiteboard.

A nastier variant is to edit, not delete: change a threat record's counterparty to an innocent address, and the audit now points at the wrong party — the same destination as Episode 3's "poisoned attribution," except this time we're altering the result, not the source.

Root cause: append ≠ delete-proof

We assumed "written to the database" equals "evidence preserved." It doesn't.

Ordinary rows are, by nature, insertable, deletable, editable. Evidence isn't valuable because it was written down — it's valuable because you can tell when it's been altered. We did the first part, not the second. That was Pillar 5 before this fix: a log an honest person can't delete and a dishonest one deletes in one click.

The patch: a hash-chained, tamper-evident log

The fix is simple, but it turns "quietly delete one row" into "rewrite the entire tail of the chain":

Every audit entry now embeds the hash of the previous entry, linked head-to-tail like a ledger:

entryN.hash = sha256( seq | time | actor | action | target | … | entryN-1.hash )

• Delete any middle entry → the next entry's "prev hash" no longer matches. The chain breaks, and verification pinpoints exactly which entry.
• Edit any entry's content → its recomputed hash no longer matches the stored one. Exposed on the spot.
• To do it invisibly, you'd have to recompute and rewrite every entry after it — and the chain's final hash (which we surface on the audit page as a "ledger fingerprint") changes with it. Once that fingerprint has been recorded externally even once, rewriting the tail can't hide.

And we wrote the act of deleting a threat record into that same chain. You can still delete a threat — but the fact that you deleted it goes into a ledger you can't silently alter.

After the patch, the same attacks:

| Attack | Before | After | |---|---|---| | Delete a threat / audit record | 🔴 vanishes without trace | ✅ verify reports "chain broken @ entry N" | | Edit a record's content | 🔴 silently rewritten | ✅ recomputed hash mismatches — exposed | | Append a new record normally | written | ✅ auto-linked, no disruption |

What this fix does NOT do (stated plainly)

A hash chain doesn't make rows undeletable — it makes deletion and edits undeniable. Someone with database access can still physically delete a whole segment; verification will just tell you "it broke here." To make it undeniable even to us, one step remains: anchor the tail fingerprint somewhere we don't control (publish it periodically, or write it to an external chain). Only then is the "rewrite the tail" escape hatch fully closed. We're not pretending we've done that yet — it's next episode's work.

Three lessons

1. The table that holds the evidence can't be one the accused can delete. We put the attack record and the attacked party's privileges in the same layer. The referee and the player can't be the same person.

2. "It's in the database" gives a false sense of safety. Same class of error as Episode 3's "KYA that lies": looks like there's a record, until you actually need it and find it can be edited at will. People who think they have evidence are more dangerous than people who know they don't.

3. We've broken our own gateway four episodes running. Blocked six, missed cumulative limits, found the foundation empty, and could erase the log. That isn't the embarrassing part — refusing to publish it would be. Whether a standard is worth trusting isn't about how complete it claims to be; it's about whether its authors publish the results when they break it themselves — including this one, "we could have erased the evidence."

Next episode

We'll anchor the ledger fingerprint externally, closing the "rewrite the tail" hatch; and while we're there, we'll see whether a mandate can be replayed — take one signed authorization and try to pay with it a second time.

Attack it yourself: oceanalt.com/firewall · Test with your own agent: integration guide

(OceanAlt Attack Lab · research note)