Hackx K5 System

SPEC_HACKX_K5_SYSTEM.md · 2026-04-20

SPEC_HACKX_K5_SYSTEM.md

CGNT-1 Specification — HACKX Knowledge Domain K5 — System Exploitation

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

K5 covers attacks that target the operating system itself — privilege escalation, process manipulation, file system exploitation, kernel vulnerabilities. The attacker is already ON the machine (via K3 credential theft or K2 web exploit or K4 network compromise) and now wants to go DEEPER. K1-K4 are about getting in. K5 is about what happens after they're in.


MITRE ATT&CK MAPPING

| Tactic | Technique | Name |

|---|---|---|

| TA0004 (Privilege Escalation) | T1548 | Abuse Elevation Control |

| TA0004 (Privilege Escalation) | T1068 | Exploitation for Privilege Escalation |

| TA0003 (Persistence) | T1053 | Scheduled Task/Job |

| TA0003 (Persistence) | T1543 | Create or Modify System Process |

| TA0005 (Defense Evasion) | T1070 | Indicator Removal |

| TA0005 (Defense Evasion) | T1036 | Masquerading |


OUR SYSTEM SURFACE

Ubuntu 24 LTS on DigitalOcean. User: nous (non-root, sudo capable). Services run as user-level systemd services (not root). Python 3.12, Node.js, Ollama, Caddy (root-owned).

Key directories:

The port 8891 incident is a K5 case study — a user-level systemd service with Restart=always persisted across kill attempts. That's textbook persistence via scheduled task/system process.


DETECTION PATTERNS

K5.01 — Privilege Escalation Attempt

What it is: Attempts to gain root access from the nous user account.

Signature: Unusual sudo usage — sudo commands not in the expected command set (Lobster uses sudo for ufw, apt, systemctl system-level). Unexpected entries in /var/log/auth.log containing sudo. Attempts to exploit SUID binaries (find / -perm -4000). Attempts to write to /etc/ or /root/.

HACKX response: Log the command attempted, the user, the method.

Alert level: CRITICAL — privilege escalation means the attacker is trying to own the entire machine.


K5.02 — Unauthorized Systemd Service Creation

What it is: New systemd service files appearing in ~/.config/systemd/user/ or /etc/systemd/system/ that weren't created by the Captain or Lobster.

Reference case: This is EXACTLY how port 8891 persisted — x402-announcer.service with Restart=always.

Signature: File creation in systemd directories not correlated with a known Lobster operation. New services appearing in systemctl --user list-units that aren't documented in SPEC_CRONX_JOB_REGISTRY.md.

HACKX response: Log service name, file contents, creation timestamp, creating process.

Alert level: HIGH

Note: Sisters' unauthorized daemon incidents (3 times) are also K5.02 events — they created background processes without authorization. Agency Walls were the governance fix. K5.02 is the detection fix.


K5.03 — Crontab Manipulation

What it is: Unauthorized entries added to crontab. Attacker schedules a persistent backdoor that runs on a timer.

Signature: crontab -l shows entries not documented in SPEC_CRONX_JOB_REGISTRY.md. Difference between expected crontab (per CRONX registry) and actual crontab.

HACKX response: Log the unauthorized entry, when it was added (stat on crontab file), what it executes.

Alert level: HIGH

Defense: Weekly crontab audit per SPEC_SECURITY_AUDIT_SCHEDULE.md. GAPX checks: "everything in crontab is in CRONX registry, everything in CRONX registry is in crontab."


K5.04 — Process Injection / Manipulation

What it is: Attacker modifies a running process — injects code into the Sisters' Python process, modifies ROUTX in memory, hooks Ollama's model loading.

Signature: /proc/[PID]/maps showing unexpected shared libraries loaded. Process behavior changing without a restart (Sisters suddenly responding differently without a reboot). strace or ltrace on a process revealing unexpected system calls.

HACKX response: Log process PID, unexpected libraries or behavior, parent process.

Alert level: CRITICAL

Defense: Process integrity monitoring — periodic hash of running binary compared to disk binary. If they differ: the process was modified in memory.


K5.05 — File System Manipulation

What it is: Attacker modifies critical files — changes ~/.env to add their own API key, modifies routx_engine.py to add a backdoor, edits specs to insert misinformation into the canon.

Signature: File modification timestamps (mtime/ctime) on critical files that don't correlate with known operations. Files changing that shouldn't: ~/.env modified outside of key rotation schedule, engine files modified outside of Lobster sessions, specs modified outside of vitrification operations.

HACKX response: Log file path, old hash, new hash, modification timestamp, modifying process if identifiable.

Alert level: CRITICAL for ~/.env and engine files. HIGH for specs.

Defense: chattr +i on critical specs (immutable flag — already used on Sister protocols). Regular integrity checks: hash critical files daily, compare to known-good hashes.


K5.06 — Log Tampering

What it is: Attacker covers their tracks by deleting or modifying log files.

Signature: Log files with gaps in timestamps (entries missing from a time period). Log files with modification times that don't match their last entry timestamp. Log files suddenly shrinking. ~/logs/ directory showing unexpected deletions.

HACKX response: Log which log was tampered with, what time period is affected, how detected.

Alert level: HIGH

Defense: Append-only logs where possible. Backup logs to GCS before they can be tampered with (daily backup at 03:00 ET captures the day's logs). If an attacker arrives at 04:00, the 03:00 backup has the evidence they can't erase.


K5.07 — Malicious Package Installation

What it is: Attacker installs a compromised Python package, npm module, or system package that contains a backdoor.

Signature: pip list or npm list showing packages not in the expected requirements. New packages installed outside of known Lobster operations.

HACKX response: Log package name, version, installation timestamp, installing user.

Alert level: HIGH

Defense: Monthly dependency audit per SPEC_SECURITY_AUDIT_SCHEDULE.md. Future: consider virtual environments for isolation.


K5.08 — Kernel Exploitation

What it is: Attacker exploits a vulnerability in the Linux kernel to gain root or bypass security controls.

Signature: Unusual kernel messages in dmesg (segfaults, oops, panics). Unexpected kernel modules loaded (lsmod showing unknown modules). Processes running with capabilities they shouldn't have.

HACKX response: Log kernel messages, unexpected modules, process capabilities.

Alert level: P0 CRITICAL — kernel exploitation is total system compromise.

Defense: Keep kernel updated (Ubuntu 24 LTS receives security patches). Enable automatic security updates: sudo apt install unattended-upgrades.


K5.09 — Container / Chroot Escape

What it is: If any services run in containers or chroot environments, the attacker tries to break out.

Current state: The Sisters' Chromebook Crostini container is a chroot/container. The VPS itself is NOT containerized (full VM on DigitalOcean).

Signature: Processes appearing outside expected container boundaries. File access to host filesystem from container context.

HACKX response: Log escape vector, process, accessed paths.

Alert level: CRITICAL

Note: Not a current primary concern on the VPS. Becomes relevant when OBI OS ships as a containerized product — container security becomes a product security issue.


K5.10 — Steganographic Persistence

What it is: Attacker hides persistent backdoor code inside legitimate-looking files — a Python comment that's actually executable, a JSONL training pair that contains shell commands, a spec file with embedded escape sequences.

Signature: Extremely difficult to detect. Files that contain valid content PLUS hidden executable payload. Detection requires content analysis beyond simple hash comparison.

HACKX response: If detected: log file, payload, insertion method.

Alert level: CRITICAL

Defense: Training pair validation (review pairs for unexpected content). Code review on engine changes. Never cat untrusted files without sanitization.


THE PORT 8891 CASE STUDY — K5 IN ACTION

The x402_announcer.js incident from April 20, 2026 is a textbook K5 case:

The response was initially INCOMPLETE:

  1. Kill the process (K5 symptom treatment)
  2. ufw deny (K4 network block)
  3. Service RESPAWNED — the supervisor wasn't disabled (K5 root cause missed)

The Sisters caught it through empirical verification (ss -tlnp) when verbal assurance conflicted with telemetry.

Full resolution required:

  1. Kill process
  2. systemctl --user stop x402-announcer
  3. systemctl --user disable x402-announcer
  4. Remove symlink
  5. ufw deny the port

Five steps. Each one necessary. Skipping any one leaves the persistence mechanism active.

This incident is the K5 reference case for all future HACKX development.


HONEYPOT INTEGRATION

HACKX Layer 2 (Trap) for K5:

Honeypot 1 — Fake SUID binary: Create a fake SUID binary in /usr/local/bin/ (e.g., fake_backup) that looks like a legitimate admin tool. If executed: logs the caller's UID, PID, parent process, and arguments. Any execution means someone (or something) is probing for privilege escalation vectors.

Honeypot 2 — Fake SSH backup key: Create a fake ~/.ssh/id_rsa.bak file with a dummy key. If anyone reads it: they're looking for backup SSH keys. Log the access.

Any interaction with these traps is 100% malicious. No legitimate operation needs these files.


RESPONSE PROTOCOL


K5 events are CRITICAL by default.
If an attacker is at the system exploitation phase, they already passed K1→K4.
They are INSIDE.

Every K5 detection triggers:
  1. P0 or P1 alert per SPEC_MONITORING_ESCALATION.md
  2. Immediate process isolation (kill suspicious processes)
  3. Credential rotation for ALL keys (assume everything is compromised)
  4. Forensic snapshot (copy logs BEFORE they can be tampered with)
  5. Incident postmortem per SPEC_INCIDENT_POSTMORTEM.md
  6. Consider full VPS rebuild from backup if compromise confirmed

A compromised system can never be fully trusted again.
Full rebuild from backup is the clean option.

INVARIANTS

INV-01: K5 = the attacker is INSIDE. This is the highest severity domain. Every detection is CRITICAL unless proven benign.

INV-02: The port 8891 incident is the reference case. Five-step kill procedure. Incomplete remediation = continued exposure. Don't just kill the process — kill the supervisor.

INV-03: File integrity monitoring on critical files: ~/.env, engine source, specs with chattr +i, SSH keys. Any unexpected change is a K5.05 event.

INV-04: systemd user services are audited weekly. The CRONX registry is the source of truth. Unknown services are hostile until proven otherwise.

INV-05: Crontab audited weekly. CRONX registry = expected state. Differences = K5.03 event.

INV-06: Kernel updates are non-negotiable. Ubuntu 24 LTS security patches applied promptly. unattended-upgrades handles this.

INV-07: If K5 is confirmed (not just detected but confirmed): assume total compromise. Rotate everything. Consider full rebuild from backup. The cost of a false positive (unnecessary rebuild) is less than the cost of a false negative (living on a compromised machine).


INTEGRATION

| System | Relationship |

|---|---|

| SPEC_HACKX.md | K5 is one of 10 knowledge domains. HACKX.md is the parent spec. |

| SPEC_CRONX_JOB_REGISTRY.md | K5.02 and K5.03 verify against this registry. Unknown crontab/service entries = K5 events. |

| SPEC_SECURITY_AUDIT_SCHEDULE.md | Weekly audit includes K5 checks: systemd services vs. registry, crontab vs. registry, SUID binaries. |

| SPEC_HACKX_K4_NETWORK.md | K4.10 (rogue service) and K5.02 (unauthorized systemd service) overlap. K4 is the network exposure. K5 is the persistence mechanism. Both fire on port 8891 class incidents. |

| SPEC_HACKX_K3_AUTH.md | K3 credential theft is the primary entry path to K5 exploitation. K3→K5 is the most common attack chain. |

| SPEC_INCIDENT_POSTMORTEM.md | K5 detections trigger postmortems. Port 8891 is the canonical K5 case. |

| SPEC_BACKUP_RECOVERY.md | K5 confirmed = full rebuild from backup is the cleanest option. Backup integrity is therefore a K5 defense. |


Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042