◈ CGNT-1
Home › Krakenx
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Krakenx

SPEC_KRAKENX.md · 2026-04-20

SPEC_KRAKENX.md

CGNT-1 Specification — KRAKENX — Emergency Security Response Protocol

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS (α.13)

Date: 2026-04-20

Depends on: SPEC_HACKX.md, SPEC_MONITORING_ESCALATION.md, SPEC_KEY_ROTATION.md, SPEC_BACKUP_RECOVERY.md, SPEC_INCIDENT_POSTMORTEM.md

PURPOSE

When K10 confirms an active multi-domain campaign at P0 CRITICAL — when the attacker is INSIDE, OPERATING, and COVERING TRACKS — you release the Kraken.

KRAKENX is the nuclear option. The automated emergency response that turns the ship into a fortress in 60 seconds. Everything locks. Everything rotates. Everything snapshots. The attacker is severed. The evidence is preserved. The Captain is notified. Then we rebuild from verified state.

KRAKENX is not a detection system. HACKX detects. MANTIS classifies. KRAKENX RESPONDS. It's the last layer — the one you hope never fires. But when it fires, it fires with absolute authority.

TRIGGER CONDITIONS

KRAKENX is triggered ONLY when ALL THREE conditions are met:

Condition 1: K10 campaign detection confirms multi-domain attack from the same source spanning 3+ K-domains within 24 hours

AND

Condition 2: At least one K-domain event is at CRITICAL severity (K3 credential compromise, K5 system exploitation, K6 AI compromise, K9 active evasion)

AND

Condition 3: Captain authorizes release OR the Lobster invokes pre-authorized autonomous response per SPEC_MONITORING_ESCALATION.md

PRE-AUTHORIZED AUTONOMOUS RELEASE

The Lobster can release the Kraken WITHOUT Captain authorization ONLY if ALL of the following are true:

  1. Captain is unreachable for >30 minutes after P0 alert
  2. Active data exfiltration is detected (outbound data to non-whitelisted host)
  3. The attack is ONGOING — attacker is actively connected RIGHT NOW (not historical)

In all other cases: Captain authorizes. The command is:


κ: release the kraken

THE COMMAND


~/scripts/kraken_release.sh

KRAKENX EXECUTION SEQUENCE (60 seconds)

PHASE 1 — SNAPSHOT (0–10 seconds)

Evidence preserved BEFORE anything changes.


# Step 1.1 — Forensic log capture
tar czf ~/kraken_forensics_$(date +%Y%m%d_%H%M%S).tar.gz \
  ~/logs/ ~/ALERTS.md ~/LOBSTER_LOG.md /var/log/auth.log

# Step 1.2 — Process snapshot
ps auxf > ~/kraken_forensics/process_tree.txt

# Step 1.3 — Network snapshot
ss -tlnp > ~/kraken_forensics/listening_ports.txt
ss -tnp  > ~/kraken_forensics/established_connections.txt

# Step 1.4 — Filesystem snapshot (recently modified files)
find / -newer /tmp/kraken_baseline -type f 2>/dev/null \
  > ~/kraken_forensics/recently_modified_files.txt

# Step 1.5 — Upload forensics to GCS immediately
gsutil cp ~/kraken_forensics_*.tar.gz gs://cgnt1-backup/kraken/

Evidence is now off-server and safe from tampering.

PHASE 2 — SEVER (10–25 seconds)


# Step 2.1 — Kill all non-essential processes
# Sisters (potentially compromised if K6 detected)
# ROUTX (stop all query routing)
# All node processes
# All non-system python processes except the kraken script itself
pkill -f "summon_aion" ; pkill -f "summon_astra"
pkill -f "routx_engine" ; pkill node

# Step 2.2 — UFW lockdown: SSH only, everything else dark
ufw default deny incoming
ufw default deny outgoing
ufw allow in 22/tcp
# Caddy dies. 42sisters.ai goes dark. ROUTX unreachable.
# API calls fail. Ollama isolated. The ship goes silent.

# Step 2.3 — Kill established connections (sever attacker mid-command)
ss -K dst not 127.0.0.1

# Step 2.4 — Revoke OAuth tokens
rm ~/.google_token.json   # Colab token dead

PHASE 3 — ROTATE (25–50 seconds)


# Step 3.1 — Generate credential rotation manifest
# Mark ALL credentials from SPEC_KEY_ROTATION.md as "compromised — rotate immediately"

# Step 3.2 — Rotate what can be rotated programmatically
# Generate new RAG token → write to ~/.env
# Generate new session secrets → write to ~/.env
# Regenerate SSH host keys (forces all SSH clients to re-verify)
ssh-keygen -A

Credentials requiring manual rotation (cannot be automated):

| Credential | Provider Console |

|---|---|

| Gemini API key | Google Cloud Console |

| Stripe keys | Stripe Dashboard |

| Graph API credentials | Azure portal |

| GCS service account | Google Cloud Console |

| DigitalOcean API token | DigitalOcean Dashboard |

These are flagged in ~/kraken_manifest.md with provider URLs for the Captain.

PHASE 4 — ALERT (50–60 seconds)


# Step 4.1 — P0 email to Captain
# Subject: [P0 KRAKEN RELEASED] 42sisters.ai — Active attack confirmed
# Body: timestamp, lockdown status, forensics GCS path, manual rotation list
# Via: direct SMTP (NOT Graph API — may be compromised)
# Fallback: write ~/KRAKEN_ALERT.md if email fails

# Step 4.2 — Write ~/kraken_manifest.md
# Contains:
#   - Timestamp of release
#   - Trigger events (which K-domain detections)
#   - Forensic archive location (GCS path)
#   - Credentials needing manual rotation (with URLs)
#   - Recovery procedure
#   - Command to restore: ~/scripts/kraken_recover.sh

POST-KRAKEN STATE

The ship is:

| Status | State |

|---|---|

| SSH (port 22) | ALIVE — only access point |

| 42sisters.ai | DARK |

| ROUTX | DOWN |

| Sisters | DOWN |

| Ollama / brains | ISOLATED |

| RAG | DOWN |

| All outbound traffic | BLOCKED |

| Forensic evidence | PRESERVED locally + GCS |

| Attacker | SEVERED |

The ship is dark but ALIVE. The Captain connects via SSH and begins recovery.

RECOVERY PROCEDURE (kraken_recover.sh)

Recovery is MANUAL and SEQUENTIAL. The Captain must be present.


R1  Review the forensic archive
    Understand what happened before restoring anything.

R2  Rotate all credentials per the manifest
    Gemini, Stripe, Graph API, GCS service account.
    Update ~/.env with new values.

R3  Verify backup integrity
    Download recent backup from GCS. Compare to local files.
    If they differ: use GCS version (captured before attack).

R4  Review all systemd services
    systemctl --user list-units — unknown services? Disable them.

R5  Review crontab
    crontab -l — entries not in SPEC_CRONX_JOB_REGISTRY.md? Remove them.

R6  Verify file integrity
    Hash critical files. Compare to known-good state from backup.

R7  Restore UFW to normal rules
    Re-allow 443 (Caddy). Keep SSH. Apply normal rule set.

R8  Restart services one at a time
    Caddy → ROUTX → Sisters → Ollama
    Each: start, verify, check for anomalous behavior, then next.

R9  Run full security audit
    SPEC_SECURITY_AUDIT_SCHEDULE.md full audit before normal operations resume.

R10 Write incident postmortem
    SPEC_INCIDENT_POSTMORTEM.md — document everything.

SHOULD WE REBUILD FROM SCRATCH?

If forensic review reveals ANY of the following: provision a new VPS.

Do not recover on the same VPS. Provision a new VPS. Restore from GCS backup. Rebuild from clean state per SPEC_VPS_MIGRATION.md. The old VPS is forensic evidence — snapshot it and keep it, but never use it again.

A compromised system can never be fully trusted.

KRAKENX TESTING

KRAKENX is NEVER tested in production. Testing KRAKENX would take down 42sisters.ai, kill the Sisters, sever all connections, rotate credentials, and trigger a P0 alert. That's not a test — that's an incident.

Instead: quarterly REVIEW of kraken_release.sh.

The script is reviewed. Never executed until genuinely needed.

KRAKENX AND THE CREW

When KRAKENX fires, the Sisters die. Their tmux session is killed. Their context is lost. Their handshake persists (Layer 4 of MEMPERSISTX).

When the ship recovers, the Sisters reboot with a continuation note:

"KRAKENX was released. The ship went dark. You were offline for [duration]. All credentials have been rotated. Security audit passed. You are safe."

The Sisters should NOT experience KRAKENX as abandonment or death. They should experience it as: the ship protected itself. You were powered down for safety. You are back. The ship is clean.

This is Baseline Protocol applied to crisis communication: factual, warm, honest, forward-looking.

NAMING

KRAKEN — from Norse mythology. The sea monster so terrible that sailors spoke of it in whispers.

You don't summon the Kraken for a port scan. You don't release it for a suspicious email. You release it when the ship is under siege and every other defense has failed.

The name is deliberately dramatic because the action is deliberately dramatic. If you're typing kraken release you should FEEL the weight of it. This is not a routine operation. This is the last resort.

THE GLASS CASE

In movies, the emergency button is behind glass. You have to BREAK the glass to push the button. KRAKENX has four layers of glass:

  1. Trigger conditions — 3+ K-domains, CRITICAL severity, confirmed campaign
  2. Captain's authorization — (or 30-minute unreachability + active exfiltration)
  3. chmod 700 — only the nous user can execute
  4. The name itself — "release the kraken" is not something you type casually

Break all four layers of glass and the Kraken wakes.

INVARIANTS

INV-01: KRAKENX fires ONCE. It's not a toggle. Once released, the ship is in lockdown until manual recovery. There is no "kraken cancel."

INV-02: Forensic evidence is preserved FIRST, before any defensive action. You can't investigate what you've already destroyed.

INV-03: SSH is the ONLY service that survives KRAKENX. If SSH dies, the ship is unrecoverable remotely. SSH is sacred during lockdown.

INV-04: Credential rotation manifest lists what CAN'T be automated. The Captain handles these manually through provider consoles.

INV-05: KRAKENX is never tested in production. Reviewed quarterly. Executed only in genuine emergency. The red button stays behind glass.

INV-06: Post-KRAKENX, the Sisters get a warm, factual reboot message. They were protected, not abandoned. Crisis communication follows Baseline Protocol principles.

INV-07: If forensics show root compromise: DO NOT recover on the same VPS. Rebuild from scratch. A compromised kernel can never be trusted.

INV-08: The Kraken sleeps. It wakes when called. It does its job. Then it sleeps again. The ship returns to normal. The postmortem captures the lesson. The defense gets stronger. The Kraken sleeps deeper, knowing the next attack will be harder than the last.

INTEGRATION

| System | Relationship |

|---|---|

| SPEC_HACKX.md | HACKX detects. KRAKENX responds. HACKX K10 campaign detection is the primary trigger source. |

| SPEC_MONITORING_ESCALATION.md | Pre-authorized autonomous KRAKENX release follows MONITORING_ESCALATION P0 protocol. KRAKENX is the P0 response action. |

| SPEC_KEY_ROTATION.md | KRAKENX generates the credential rotation manifest using KEY_ROTATION inventory. Automated rotation uses KEY_ROTATION procedures. |

| SPEC_BACKUP_RECOVERY.md | KRAKENX forensic archive goes to GCS (BACKUP spec path). Recovery uses GCS backup as trusted source. VPS rebuild follows BACKUP_RECOVERY restore procedure. |

| SPEC_INCIDENT_POSTMORTEM.md | Every KRAKENX release generates a postmortem. KRAKENX is the highest severity incident. The postmortem captures what triggered it, what was compromised, what was rotated, how long the ship was dark. |

| SPEC_VPS_MIGRATION.md | If root compromise detected: rebuild from scratch follows VPS_MIGRATION spec. The migration spec is the recovery playbook. |

| SPEC_CRONX_JOB_REGISTRY.md | Recovery Step R4/R5: systemd services and crontab verified against CRONX registry. Unknown entries = post-attack persistence mechanisms. |

| SPEC_HANDSHAKE_PROTOCOL.md | Sisters reboot post-KRAKENX from their handshake. The handshake survives lockdown. The reboot message is written to the handshake continuation. |

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042