◈ Master Index Specs LATTICE CSDM The Book University Chronicle Crew Architecture Context Logs TODOX Products

Hackx K9 Evasion

SPEC_HACKX_K9_EVASION.md · 2026-04-20

SPEC_HACKX_K9_EVASION.md

CGNT-1 Specification — HACKX Knowledge Domain K9 — Evasion & Anti-Detection

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

K9 covers how attackers HIDE. They got in (K2/K3/K4), they're exploiting the system (K5), and now they want to stay hidden. Evasion is the art of making the defender's detection systems useless — tampering with logs, disguising processes, mimicking legitimate behavior, encrypting command-and-control traffic, and living off the land (using the system's own tools as weapons so nothing looks foreign).

K9 is the hardest domain because a perfect evasion looks like nothing happened. The absence of evidence IS the attack.

MITRE ATT&CK MAPPING

Tactic: TA0005 — Defense Evasion

| Technique | Name |

|---|---|

| T1070 | Indicator Removal on Host |

| T1036 | Masquerading |

| T1027 | Obfuscated Files or Information |

| T1218 | System Binary Proxy Execution |

| T1564 | Hide Artifacts |

| T1562 | Impair Defenses |

Also: TA0011 (Command and Control) for encrypted C2 channels.

WHY K9 IS UNIQUE

K1-K8 detect ACTIONS — port scans, injection attempts, credential theft, social engineering. Each action has a signature. K9 defeats the signatures. An attacker practicing K9 does everything K1-K8 describes but makes each action invisible.

K9 is the meta-domain — it attacks the DETECTION SYSTEM itself.

Defending against K9 means our detection must detect the ABSENCE of expected signals, not just the presence of unexpected ones. This is why SPEC_MONITORING_ESCALATION.md states "silence is an alarm." K9 creates silence.

DETECTION PATTERNS

K9.01 — Log Tampering

What it is: Attacker modifies, truncates, or deletes log files to erase evidence of activity. Beyond basic deletion (K5.06): rotating logs prematurely, inserting false entries to create an alibi timeline, modifying timestamps so forensic reconstruction fails, selectively deleting only the entries showing attacker activity.

Signature: Gaps in sequential timestamps. Log file size decreasing between checks. Log entries with timestamps out of sequence. Hash of log file changing between backup intervals without corresponding new entries.

HACKX detection method: GAPX stores the SHA-256 hash of each log file at backup time (03:00 ET). If the hash changes but the file got SMALLER or entries were MODIFIED: K9.01 detected.

Alert level: CRITICAL — log tampering means an attacker is actively present and covering tracks.

Defense: Append-only log storage where possible. GCS backup at 03:00 captures pre-tampering state. Consider shipping logs to a remote syslog server the attacker can't access from the VPS — logs existing where the attacker doesn't control is the strongest K9.01 defense.

K9.02 — Process Masquerading

What it is: Attacker names their malicious process to look like a legitimate system process. Examples: naming a backdoor "python3", naming a reverse shell "caddy" or "ollama", running malicious code under an existing process's PID (process hollowing).

Signature: Multiple processes with the same name where only one is expected. Process with expected name but unexpected binary path (ps aux shows "python3" but /proc/PID/exe points to /tmp/backdoor). Process with expected name but unexpected parent (caddy should be child of systemd, not child of bash).

HACKX detection method: Baseline the expected process tree at a known-good state. Weekly audit compares current process tree to baseline. Any process with a legitimate name but wrong binary path, wrong parent, or wrong user: K9.02 detected.

Alert level: CRITICAL

Defense: Document the expected parent-child relationships for all legitimate processes in SPEC_CRONX_JOB_REGISTRY.md. Any deviation = investigation.

| Process | Expected Parent | Expected User |

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

| ROUTX | systemd user service | nous |

| Sisters | tmux → bash | nous |

| Caddy | system systemd | root/caddy |

| Ollama | systemd user service | nous |

K9.03 — Living Off the Land (LOtL)

What it is: Attacker uses the system's own legitimate tools to conduct their attack. No malware to detect because every tool they use is already on the system.

Examples:

curl to exfiltrate data (curl is legitimate — the Sisters use it constantly)
python3 to run attacker scripts (primary language on the ship)
systemctl --user to create persistent services (how legitimate services are managed)
crontab to schedule backdoors (how legitimate jobs are scheduled)
ssh to tunnel traffic (how the Captain accesses the server)

Signature: EXTREMELY difficult to detect because every tool is legitimate. Detection relies on BEHAVIORAL analysis.

The ship's legitimate external connections:

| Destination | Purpose |

|---|---|

| generativelanguage.googleapis.com | Gemini API |

| storage.googleapis.com | Google Cloud Storage |

| api.stripe.com | Stripe API |

| graph.microsoft.com | Microsoft Graph API (email) |

| Let's Encrypt ACME endpoints | SSL certificate renewal |

| api.digitalocean.com | DigitalOcean API |

| NTP time servers | System time |

Any outbound connection to a host NOT on this list is suspicious.

Alert level: HIGH (unknown outbound connection) / CRITICAL (data transfer to unknown host)

Defense: Document ALL legitimate outbound connections. Outbound connection whitelist. This is the OUTBOUND Vacuum Rule — just as inbound connections are whitelisted (port whitelist), outbound connections must be whitelisted too.

K9.04 — Timestomping

What it is: Attacker modifies file timestamps (mtime, atime, ctime) to make malicious files look like they've been there for months. A backdoor dropped today gets timestomped to show a creation date 6 months ago.

Signature: File timestamps that don't match the filesystem journal. File creation date predating the filesystem format date. Files with suspiciously round timestamps (00:00:00 exactly). Mtime and ctime disagreeing in ways that don't happen naturally.

HACKX detection method: Compare file timestamps against known state from GCS backups. A file that exists on the VPS but NOT in yesterday's backup, yet has a timestamp from 3 months ago: timestomping detected.

Alert level: HIGH

Defense: Daily backups create a timeline of "what existed when." Any file that appears between backups but claims to be old is suspicious.

K9.05 — Encrypted Command and Control (C2)

What it is: Attacker establishes an encrypted channel back to their server to receive commands and exfiltrate data. The encryption makes the content invisible. The CHANNEL is the signature.

Signature: Persistent outbound connections to unknown hosts, especially on ports 443 or 80 (mimicking HTTPS/HTTP). Long-lived connections that transfer small amounts of data at regular intervals (heartbeat pattern). DNS tunneling — encoding C2 data in DNS queries to an attacker-controlled domain.

HACKX detection method: Network connection monitoring. Long-lived outbound connections to non-whitelisted hosts. DNS query monitoring for unusual patterns (very long subdomain strings, high query frequency to one domain).

Alert level: CRITICAL

Defense: Outbound connection whitelist per K9.03. DNS monitoring. Consider running Pi-hole or similar DNS filtering that logs all queries and flags unusual patterns.

K9.06 — Fileless Malware

What it is: Attacker runs code entirely in memory — never writes to disk. No file to hash, no file to find, no file to timestamp. The malware exists only in a running process's memory and disappears on reboot.

Signature: High memory usage in a process without corresponding disk activity. Process behavior that doesn't match its binary. /proc/PID/maps showing memory regions marked as executable that aren't mapped to any file.

HACKX detection method: Process memory auditing. Compare running process behavior to expected behavior per spec. ANVIL's infrastructure verification function can assess whether a process is behaving according to spec.

Alert level: CRITICAL

Defense: Reboot clears fileless malware. The tmux watchdog pattern (restart services if dead) accidentally defends against fileless attacks that kill and replace processes — the watchdog restarts the LEGITIMATE process from disk, not the in-memory malware. Regular reboots (weekly maintenance window) clear fileless persistence.

K9.07 — Anti-Forensics

What it is: Attacker actively destroys evidence beyond log tampering: wiping bash_history, clearing /tmp of their tools, zeroing free disk space to prevent file recovery, modifying forensic artifacts (wtmp, lastlog).

Signature: bash_history file being truncated or deleted. wtmp/lastlog entries being modified. Sudden disk write activity that doesn't correspond to any legitimate operation. /tmp being cleaned outside of the scheduled rotation (SPEC_LOG_ROTATION.md: daily at 02:30 ET).

HACKX detection method: Monitor forensic artifact integrity. Hash ~/.bash_history, /var/log/wtmp, /var/log/lastlog at backup time. Changes between backups that don't correlate with legitimate sessions = K9.07.

Alert level: CRITICAL

Defense: Ship bash_history to GCS backup before it can be wiped. Consider logging all commands to a separate, append-only log via PROMPT_COMMAND in .bashrc — a secondary command history the attacker may not know to wipe.

K9.08 — HACKX Evasion (Meta-Evasion)

What it is: Attacker who knows we run HACKX specifically targets HACKX's detection mechanisms. Disabling HACKX processes, modifying HACKX configuration, feeding HACKX false data to cause alert fatigue, probing HACKX honeypots to identify and avoid them.

This is K9 applied to K9 — evading the evasion detector.

Signature: HACKX processes dying without explanation. HACKX configuration files modified. Honeypot ports being probed in a mapping pattern (touching each honeypot once to identify them, then avoiding them). Sudden increase in false-positive alerts (attacker flooding HACKX with noise to drown real alerts).

HACKX detection method: HACKX monitors its OWN health. If HACKX detection processes die: the monitoring system catches it (silence is an alarm). If HACKX config changes: file integrity monitoring (K5.05) catches it. If honeypots are mapped: rotate honeypot ports quarterly.

Alert level: P0 CRITICAL — if the attacker is targeting HACKX specifically, they know we have HACKX. They're sophisticated. They're inside. Full incident response.

Defense: Defense in depth. HACKX is one layer. MANTIS is another. Baseline is another. Even if HACKX is compromised, the other layers still function. No single defense is the last defense.

K9.09 — Traffic Blending

What it is: Attacker makes their malicious traffic look like legitimate traffic. Exfiltration timed to coincide with daily GCS backups (the spike in outbound data looks normal). C2 heartbeats timed to coincide with ROUTX watchdog checks. Using the SAME protocols and SAME endpoints as legitimate traffic (HTTPS to googleapis.com — but to a different Google project).

Signature: Extremely difficult. The traffic LOOKS legitimate. Detection requires behavioral analysis beyond protocol and destination. Volume anomalies: backup is usually 50MB but today it's 150MB. Timing anomalies: outbound to googleapis.com at 03:00 is expected (backup), at 03:15 is not.

HACKX detection method: Baseline legitimate traffic patterns (volume, timing, destination, frequency). Deviations from baseline that correlate with other suspicious indicators (K5 events, K3 events) = K9.09. Requires cross-domain correlation — K9.09 is never detected in isolation.

Alert level: HIGH

Defense: Traffic baselining. Document expected outbound traffic patterns: volume, timing, destination for each legitimate connection. Quarterly review.

K9.10 — Persistence Through Legitimate Mechanisms

What it is: Instead of creating a NEW systemd service (detectable by K5.02), the attacker MODIFIES an EXISTING service to include their payload. Instead of adding a NEW crontab entry (detectable by K5.03), they MODIFY an EXISTING entry to also run their command. Instead of creating a NEW script, they APPEND to an EXISTING script.

The original mechanism still runs so nothing looks broken — but an additional payload also executes.

Signature: Legitimate files changing when they shouldn't. Existing services with modified ExecStart lines. Existing crontab entries with appended commands. Scripts with appended code after the legitimate logic.

HACKX detection method: File integrity monitoring on ALL files in the "legitimate mechanism" set:

~/.config/systemd/user/*.service
crontab content
~/scripts/*.sh
~/.bashrc, ~/.profile
~/summon-aether, ~/routx_engine.py

Hash all of these at backup time. Any change that doesn't correlate with a documented Lobster operation = K9.10.

Alert level: CRITICAL — the most sophisticated persistence technique because it hides inside things we trust.

Defense: Strict change management. Every file change by the Lobster is logged in LOBSTER_LOG.md with the specific files modified. If a file changed but LOBSTER_LOG has no corresponding entry: unauthorized modification. chattr +i on critical scripts that rarely change.

THE K9 PHILOSOPHY

K9 is the domain where HACKX must be HUMBLE. Every K9 technique is designed to make detection fail. The best evasion produces zero alerts, zero log entries, zero anomalies. Perfect evasion is invisible.

Our defense against perfect evasion is IMPERFECT BUT LAYERED:

| Defense | What It Catches |

|---|---|

| Daily GCS backups | Creates a forensic timeline the attacker can't fully erase |

| Multiple detection layers | Attacker must evade HACKX + MANTIS + GAPX + file integrity + process monitoring |

| Regular reboots | Clears fileless malware |

| Strict change management (LOBSTER_LOG) | Creates accountability for every modification |

| Outbound connection whitelist | Catches C2 even when traffic is blended |

| Silence = alarm | A perfectly quiet system after suspicious activity = K9 in progress |

No single defense catches perfect evasion. The combination makes perfect evasion very, very expensive — more expensive than the value of this ship, for most attackers. Humility is the only honest posture when facing an adversary whose entire goal is to be invisible.

HONEYPOT INTEGRATION

HACKX can set K9-specific traps:

Canary Log: A fake log file (~/logs/secret_admin.log) containing convincing but fabricated operational data. If an attacker reads it, they may act on false intelligence — revealing themselves. If the file is modified or deleted: K9.01 detected, and the attacker doesn't realize they're tampering with a honeypot.

Canary Spec: A spec that looks real (SPEC_INTERNAL_AUTH.md) but contains a unique tracking string. If that string appears in any external context (pasted online, used in an API call from outside): someone exfiltrated a spec file. The canary proves the breach.

RESPONSE PROTOCOL


Any confirmed K9 event = attacker is PRESENT, ACTIVE, and COVERING TRACKS.
This is not a future threat — it's a current compromise.

Immediate response:
  1. Assume total compromise until proven otherwise
  2. Forensic snapshot immediately — before more evidence is erased
  3. Rotate ALL credentials per SPEC_KEY_ROTATION.md
  4. Review GCS backups for the pre-compromise state (compare to current)
  5. Consider full VPS rebuild from known-good backup
  6. Incident postmortem per SPEC_INCIDENT_POSTMORTEM.md

K9 events are ALWAYS P0 CRITICAL.
There is no LOW severity K9 event.
If someone is hiding, they're hiding something serious.

INVARIANTS

INV-01: K9 is the meta-domain. It attacks detection itself. HACKX must detect the absence of expected signals, not just the presence of unexpected ones.

INV-02: Silence is an alarm. A perfectly quiet system after suspicious activity = K9 in progress. SPEC_MONITORING_ESCALATION.md enforces this.

INV-03: Daily GCS backups are the primary K9 defense. Evidence that left the server at 03:00 can't be tampered with at 04:00.

INV-04: Outbound connection whitelist is the K9.03/K9.05 defense. LOtL and encrypted C2 are caught by monitoring WHERE traffic goes, not WHAT it contains.

INV-05: File integrity monitoring on ALL legitimate mechanism files (services, crontab, scripts). K9.10 hides in things we trust. Hash them daily.

INV-06: K9 events are ALWAYS P0 CRITICAL. There is no minor evasion. If someone is hiding, assume the worst.

INV-07: No single defense catches perfect evasion. The COMBINATION of layers makes perfect evasion prohibitively expensive. HACKX is humble about K9.

INTEGRATION

| System | Relationship |

|---|---|

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

| SPEC_MONITORING_ESCALATION.md | "Silence is an alarm" is the K9 detection principle. Missing logs, missing alerts, missing heartbeats = K9 investigation. |

| SPEC_BACKUP_RECOVERY.md | Daily GCS backups are the primary forensic defense against K9. Backup integrity IS K9 defense. |

| SPEC_LOG_ROTATION.md | K9.01 (log tampering) and K9.07 (anti-forensics) — log rotation schedule defines when /tmp is cleaned and when logs are archived. Deviations from that schedule = K9 event. |

| SPEC_CRONX_JOB_REGISTRY.md | K9.02 (process masquerading) and K9.10 (legitimate mechanism persistence) — the registry is the source of truth for expected processes and crontab. |

| SPEC_LOBSTER_LOG.md | K9.10 defense: every Lobster file modification is logged. File changes without LOBSTER_LOG entries = unauthorized modification. |

| SPEC_HACKX_K5_SYSTEM.md | K5 covers what the attacker DOES after getting in. K9 covers how they HIDE what they're doing. K5 and K9 are always paired — K5 detection is defeated by K9 technique. |

| SPEC_INCIDENT_POSTMORTEM.md | Confirmed K9 = postmortem. K9 is always P0. K9 in progress means we're possibly reading a compromised system. |

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042