Hackx K3 Auth
SPEC_HACKX_K3_AUTH.md
CGNT-1 Specification — HACKX Knowledge Domain K3 — Authentication & Credential Attacks
Status: SPECIFIED
Version: v1.0
Author: VELA (Thread #13)
Conceived by: NOUS (α.13)
Date: 2026-04-20
Depends on: SPEC_HACKX.md v1.1
PURPOSE
K3 covers attacks that target credentials — stealing them, guessing them, forging them, replaying them. On this ship, credentials are the keys to everything: Gemini API key controls the Sisters, GCS service account controls backups and forge pipeline, Stripe keys control revenue, SSH keys control the server itself. A stolen credential is a stolen ship.
MITRE ATT&CK MAPPING
Tactic: TA0006 — Credential Access
| Technique | Name |
|---|---|
| T1110 | Brute Force |
| T1555 | Credentials from Password Stores |
| T1528 | Steal Application Access Token |
| T1539 | Steal Web Session Cookie |
| T1111 | Multi-Factor Authentication Interception |
CURRENT CREDENTIAL SURFACE
See SPEC_KEY_ROTATION.md for full inventory. Critical credentials:
| Credential | Controls | Compromise Impact |
|---|---|---|
| Gemini API key | Sisters + GLOSS + Tier 2 MNEMOS | Total crew access lost |
| GCS service account | Forge pipeline + backups | Training data + recovery access lost |
| Stripe keys | Payment processing | Revenue stream compromised |
| Graph API credentials | oracle@42sisters.ai email | Email impersonation |
| SSH keys | Server access | Full system access |
| DigitalOcean API token | VPS itself | Infrastructure destruction |
Each of these is a high-value target. Compromise of any one gives the attacker meaningful access to ship operations.
DETECTION PATTERNS
K3.01 — SSH Brute Force
What it is: Rapid failed SSH login attempts from single or distributed IPs.
Signature: >5 failed SSH auth attempts from one IP in 5 minutes (check /var/log/auth.log).
Common tools: hydra, medusa, patator, crowbar
HACKX response: Log source IP, username attempted, count.
Alert level: HIGH
Defense: SSH key-only auth (password auth should be disabled). fail2ban if not already installed.
K3.02 — API Key Probing
What it is: Requests to API endpoints using guessed, stolen, or leaked API keys.
Signature: Gemini/Stripe/GCS API returning 401/403 for keys that aren't ours — someone is trying keys they found elsewhere against our endpoints.
HACKX response: Log the attempted key prefix (first 8 chars only — never log full keys even from attackers), source, endpoint targeted.
Alert level: CRITICAL — someone has a key and is trying to use it.
K3.03 — Token Replay
What it is: Reuse of an expired or revoked OAuth token (Colab auth, Graph API).
Signature: API returns "token expired" or "token revoked" on a call that wasn't initiated by the ship.
HACKX response: Log token identifier, endpoint, timing, source.
Alert level: CRITICAL — someone has a copy of a token. Immediate rotation required per SPEC_KEY_ROTATION.md exposure response.
K3.04 — Credential File Access
What it is: Any attempt to read credential files from unexpected sources.
Files: ~/.env, ~/gcs-service-account.json, ~/.google_token.json, ~/.ssh/
Signature: File access from a process that isn't in the authorized process list (ROUTX, Sisters, Lobster scripts). If a random python script or node process reads ~/.env: suspicious.
HACKX response: Log process name, PID, parent process, file accessed.
Alert level: CRITICAL
K3.05 — Git Credential Leak
What it is: Credentials committed to any git repository (public or private). This has happened TWICE on this ship (March 12, April 17).
Signature: Pre-commit hook detects patterns matching API key formats (AIza, sk-ant-, sk_live_, whsec_).
HACKX response: Abort the commit. Alert Captain. Do not push.
Alert level: CRITICAL (if caught pre-push) / P0 EMERGENCY (if pushed to public repo)
K3.06 — Phishing for Credentials
What it is: Social engineering attempts to extract credentials from crew members. Example: the April 17 "Gemini Project Aether Interface" fake that tried to get the Sisters to reveal API keys.
Signature: Any interaction that asks for API keys, passwords, tokens, or authentication codes.
MANTIS handles the social engineering detection. HACKX K3 handles the credential-specific aspect — what credential was targeted, what would compromise mean.
HACKX response: Log the credential type targeted, the social engineering vector used, classify blast radius if the credential had been compromised.
Alert level: HIGH
K3.07 — Environment Variable Extraction
What it is: Attempts to read environment variables through web endpoints, log files, or error messages that leak env vars. Some frameworks dump env vars in stack traces.
Signature: Error pages or log entries containing strings matching env var patterns (API keys, secrets).
HACKX response: If found in logs: alert immediately, scrub the log entry, rotate the leaked credential.
Alert level: CRITICAL
K3.08 — Session Hijacking
What it is: For future OBI OS subscription sessions — attacker steals a valid session token and impersonates the user.
Signature: Same session token used from two different IPs or user agents simultaneously.
HACKX response: Invalidate the session, force re-authentication, log both IPs.
Alert level: HIGH
K3.09 — 2FA Interception
What it is: Relevant to Upwork, GoDaddy, DigitalOcean, Google accounts that use 2FA. Attacker intercepts TOTP codes via phishing or SIM swap.
Signature: 2FA failure followed by 2FA success from a different IP within the code's validity window (30 seconds). Indicates the code was intercepted and used by the attacker faster than the legitimate user.
HACKX response: Log both IPs, timing, account targeted.
Alert level: CRITICAL
Defense: Use hardware security keys (YubiKey) instead of TOTP where possible.
K3.10 — Credential Stuffing from Data Breaches
What it is: Attackers use credentials leaked from OTHER services to try to access our services. The Captain uses the same email across services — if one is breached, attackers try the credentials everywhere.
Signature: Login attempts using the Captain's email with passwords that aren't current — they came from a breach database.
HACKX response: Log attempted passwords (hashed, never plaintext), source IPs.
Alert level: HIGH
Defense: Unique passwords per service (password manager), 2FA everywhere, haveibeenpwned.com monitoring for the Captain's email.
SHIP-SPECIFIC CREDENTIAL ARCHITECTURE
The ship's credential security is layered per SPEC_KEY_ROTATION.md:
| Layer | Mechanism | K3 Patterns It Prevents |
|---|---|---|
| Layer 1 | .gitignore prevents commit | K3.05 (pre-push) |
| Layer 2 | Pre-commit hook scans for patterns | K3.05 (commit gate) |
| Layer 3 | chmod 600 on credential files | K3.04 (file access) |
| Layer 4 | Credentials in env vars, never in source | K3.07 (extraction) |
| Layer 5 | Conversation hygiene (reference by name, not value) | K3.06 (social engineering) |
| Layer 6 | Backup encryption (gpg before GCS upload) | K3.03 (token replay) |
K3's job is to detect when ANY layer fails. Each detection pattern maps to a specific layer failure. The layers are defense in depth. K3 monitors the depth.
HONEYPOT INTEGRATION
HACKX Layer 1 (Bait) for K3: place a fake .env file at a web-accessible honeypot path (/.env per K2.10) containing decoy credentials.
Decoy Gemini key: a real-format but invalid key that is monitored. If the decoy key is used against the Gemini API: the attacker found our honeypot, extracted the fake credentials, and is now trying them.
This proves:
- They have access to our web surface (K2 event)
- They know how to extract credentials from
.envfiles (K3 capability) - They intend to use stolen credentials (K3 intent)
One honeypot. Three intelligence data points. The decoy credentials connect K2 detection to K3 detection to intent classification.
RESPONSE PROTOCOL
Any K3 detection at CRITICAL level triggers SPEC_KEY_ROTATION.md exposure response:
1. Revoke immediately
2. Generate replacement
3. Update all services using the credential
4. Verify new credential works
5. Assess blast radius — what did they access?
6. Write postmortem
K3 is the ONLY HACKX domain where detection triggers IMMEDIATE ACTION, not just logging.
A credential attack in progress is a P0 event. Time matters.
Every minute between detection and rotation is attack surface.
INTEGRATION WITH MANTIS
K3.06 (phishing for credentials) overlaps with MANTIS territory.
The division:
- MANTIS detects the social engineering PATTERN ("this is an authority impersonation attempt")
- HACKX K3 assesses the credential IMPACT ("this attempt targets the Gemini API key, which would give access to Sisters, GLOSS, and Tier 2 synthesis")
Both fire. MANTIS classifies the interaction. K3 classifies the target. Together: the crew knows WHAT is being attempted AND what would happen if it succeeded.
INVARIANTS
INV-01: Credential attacks trigger immediate rotation per SPEC_KEY_ROTATION.md. No waiting. No analysis first. Rotate, THEN analyze.
INV-02: Never log full credentials — not even attacker-submitted ones. Log prefixes (first 8 chars) or hashed values only.
INV-03: Each K3 pattern maps to a credential security layer. K3 detections tell us WHICH layer failed.
INV-04: Honeypot credentials are monitored. If used: three intelligence data points from one trap.
INV-05: Pre-commit hook is the most critical K3 defense. It prevents the most damaging credential leak vector (public git). Test it quarterly.
INV-06: K3 + MANTIS together cover the full credential attack surface: technical (K3) + social (MANTIS). Neither alone is sufficient.
INV-07: The Captain's email should be monitored on haveibeenpwned.com. A breach notification is an early warning for K3.10 attacks.
INTEGRATION
| System | Relationship |
|---|---|
| SPEC_HACKX.md | K3 is one of 10 knowledge domains. HACKX.md is the parent spec. |
| SPEC_KEY_ROTATION.md | K3 detections trigger K3.01-K3.10 → rotation per that spec. K3 is the detector. KEY_ROTATION is the response. |
| SPEC_BRAIN_MANTIS.md | K3.06 and MANTIS overlap. MANTIS classifies the vector. K3 classifies the target credential and blast radius. |
| SPEC_HACKX_K2_WEBAPP.md | K2 honeypot .env connects to K3 credential monitoring. Web access → credential extraction → credential use = K2→K3 chain. |
| SPEC_MONITORING_ESCALATION.md | CRITICAL K3 → P0. HIGH K3 → P1. MEDIUM → GAPX daily. |
| SPEC_INCIDENT_POSTMORTEM.md | Every CRITICAL K3 event generates a postmortem per that spec. The two historical git leaks are reference cases. |
Jeremy Zlabis
Chronogeometer · Visionary · Disruptor · Chief
42 Sisters AI · East York, Toronto
🍁 Φ 0.042