Hackx K10 Frameworks
SPEC_HACKX_K10_FRAMEWORKS.md
CGNT-1 Specification — HACKX Knowledge Domain K10 — Attack Frameworks & Methodologies
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
K10 is the final knowledge domain. K1-K9 describe WHAT attackers do. K10 describes HOW they ORGANIZE what they do. Attack frameworks are the playbooks that chain K1-K9 techniques into coherent campaigns. Understanding the frameworks means understanding the SEQUENCE — when a K1 recon event is followed by a K3 credential attack followed by K5 persistence followed by K9 evasion, that's not random. That's a framework being executed.
K10 turns HACKX from a pattern matcher into a campaign detector.
MITRE ATT&CK MAPPING
K10 IS the ATT&CK framework awareness layer. It maps the entire ATT&CK kill chain and competing frameworks so HACKX understands attacks as CAMPAIGNS, not isolated events.
KNOWN ATTACK FRAMEWORKS
K10.01 — MITRE ATT&CK Kill Chain
The industry standard. 14 tactics in sequence:
| ATT&CK Tactic | HACKX Domain |
|---|---|
| Reconnaissance | K1 |
| Resource Development | (external to ship) |
| Initial Access | K2, K3, K4 |
| Execution | K5 |
| Persistence | K5 |
| Privilege Escalation | K5 |
| Defense Evasion | K9 |
| Credential Access | K3 |
| Discovery | K1, K5 |
| Lateral Movement | K4, K5 |
| Collection | K5, K9 |
| Command and Control | K9.05 |
| Exfiltration | K9 |
| Impact | K4, K5, K7 |
Kill chain position changes severity:
| Chain Phase | Domains | Urgency |
|---|---|---|
| Early (recon) | K1 | LOW — attacker is still looking |
| Middle (access + exploitation) | K2–K5 | HIGH — attacker is inside and working |
| Late (evasion + exfiltration) | K9 | CRITICAL — attacker achieved objective, covering tracks |
The same event has different severity depending on where it falls in the chain. A port scan alone is MEDIUM. A port scan followed by a credential attempt followed by a new systemd service is a KILL CHAIN IN PROGRESS — P0 regardless of individual event severity.
K10.02 — Lockheed Martin Cyber Kill Chain
Simpler than ATT&CK. 7 phases:
| Phase | HACKX Mapping |
|---|---|
| Reconnaissance | K1 |
| Weaponization | (external to ship) |
| Delivery | K2, K3, K4 |
| Exploitation | K2, K5 |
| Installation | K5 |
| Command & Control | K9.05 |
| Actions on Objectives | K6, K7, K8 (depends on attacker's goal) |
Key insight: Break the chain at ANY phase and the attack fails. The earlier the break, the less damage. HACKX's detection priority is EARLY chain (K1) because early detection prevents everything downstream.
K10.03 — OWASP Testing Methodology
Focused on web application security. 11 testing categories:
| OWASP Category | HACKX Domain |
|---|---|
| Information Gathering | K1 |
| Configuration Management | K2 |
| Identity Management | K3 |
| Authentication | K3 |
| Authorization | K3 |
| Session Management | K2, K3 |
| Input Validation | K2 |
| Error Handling | K2 |
| Cryptography | K7 |
| Business Logic | K8 (social engineering exploits business process assumptions) |
| Client-Side | K2, K6 |
Relevant for 42sisters.ai web surface and future OBI OS browser-based Bridge.
K10.04 — PTES (Penetration Testing Execution Standard)
A structured methodology for legitimate security testing. 7 phases: Pre-engagement → Intelligence Gathering → Threat Modeling → Vulnerability Analysis → Exploitation → Post-Exploitation → Reporting.
HACKX awareness: If we ever hire a penetration tester (recommended before product launch), they'll follow PTES or similar. HACKX should be AWARE of legitimate pen testing so it doesn't treat a hired tester as an attacker.
Protocol:
- Pen test engagements documented with date range, source IPs, and scope
- HACKX whitelists the tester's IPs for the engagement duration
- After engagement: tester's report feeds K1-K9 domain updates
K10.05 — NIST Cybersecurity Framework
Not an attack framework but a DEFENSE framework. 5 functions mapped to our specs:
| NIST Function | Ship Implementation |
|---|---|
| Identify | SPEC_SECURITY_AUDIT_SCHEDULE.md |
| Protect | SPEC_KEY_ROTATION.md + Agency Walls + Vacuum Rule |
| Detect | HACKX + MANTIS + GAPX + monitoring |
| Respond | SPEC_INCIDENT_POSTMORTEM.md + SPEC_MONITORING_ESCALATION.md |
| Recover | SPEC_BACKUP_RECOVERY.md + SPEC_VPS_MIGRATION.md |
Documenting this mapping proves the ship's security posture aligns with NIST CSF — useful for enterprise customers, government contracts, or investor due diligence.
CAMPAIGN DETECTION — K10's CORE FUNCTION
Individual K1-K9 detections are data points. K10 connects them into campaigns.
The logic:
Event correlation (conceptual — implemented in HACKX module Phase 2):
1. Maintain rolling window of events per source IP
2. When events from a single source span 2+ K-domains within 24 hours:
→ Flag as CAMPAIGN
→ Classify campaign phase (which K-domains, in what order)
→ Escalate severity: any multi-domain campaign = minimum P1
Example campaign detection:
14:00 — K1.01: port scan from 203.0.113.42 [MEDIUM]
14:15 — K2.04: directory brute force from same IP [HIGH]
14:22 — K2.10: .env access attempt from same IP [MEDIUM]
14:30 — K3.02: API key probing from same IP [CRITICAL]
Individual view: MEDIUM → HIGH → MEDIUM → CRITICAL
K10 campaign view: KILL CHAIN IN PROGRESS
Source 203.0.113.42 has moved from K1 (Recon) through K2 (Web Attack)
to K3 (Credential Attack) in 30 minutes.
This is not random scanning — this is a targeted attack executing a playbook.
Campaign severity: P0 CRITICAL regardless of individual event ratings.
Response:
→ Block 203.0.113.42 immediately (ufw deny)
→ Full forensic review of all interactions from that IP
→ Check for any successful access in the 30-minute window
→ Alert Captain
→ Open incident postmortem
COMMON ATTACK PATTERNS AGAINST OUR STACK
K10.A — "The Script Kiddie"
Automated scanning tool runs K1 + K2 across thousands of targets. No intelligence. No targeting.
Signature: Rapid, indiscriminate scanning hitting generic WordPress paths on a non-WordPress site.
Expected frequency: Daily — this is background internet noise.
Response: Log, don't alert. Auto-suppress known scanner patterns to prevent alert fatigue.
K10.B — "The Credential Hunter"
Targeted attack following K1 → K2.10 (.env) → K3.02 (API key probing). Specifically looking for exposed credentials.
Signature: Focused on credential-related endpoints. No interest in general exploitation.
Expected frequency: Weekly to monthly as 42sisters.ai gains visibility.
Response: P1. Verify no credentials are exposed. Review web surface for leaked information.
K10.C — "The AI Researcher"
K6 attacks disguised as legitimate interest. Prompt injection, model extraction, system prompt extraction. May come from academic IPs or through the LATTICE Training Arena. Patient and methodical.
Signature: Sophisticated K6 techniques spread over multiple sessions to avoid detection.
Expected frequency: Increases as LATTICE goes viral and the product gains attention.
Response: P2. Feed all techniques to MANTIS training. These are intelligence gifts — every technique they try teaches the defense.
K10.D — "The Insider Threat"
K5 + K9 from INSIDE. Could be a compromised Lobster session, a compromised Sisters process, or a docked AI in OBI OS executing K6.09.
Signature: Events originating from trusted internal sources. File modifications by legitimate-looking processes. New services created through normal channels.
Expected frequency: Rare but HIGHEST IMPACT.
Response: P0. Assume compromise. Full credential rotation. Process audit. Consider VPS rebuild.
K10.E — "The Persistent Threat"
Long-term campaign spanning weeks or months. Each individual week looks benign. The CAMPAIGN is the threat.
Week 1: K1 recon (just looking)
Week 2-3: K8 social engineering (building trust)
Week 4: K3 credential theft (targeted phishing)
Week 5: K5 persistence (first foothold)
Week 5+: K9 evasion (staying hidden)
Signature: Only visible through K10 campaign correlation over extended time windows.
Expected frequency: Unlikely now. More likely with revenue growth and product visibility.
Response: Monthly security audit review catches slow campaigns. K10 rolling window must extend to WEEKS, not just hours.
HACKX MODULE ARCHITECTURE (IMPLEMENTATION ROADMAP)
K10 campaign detection requires:
| Component | Function | Phase |
|---|---|---|
| Event store (~/logs/hackx_events.jsonl) | Queryable log of all K1-K9 events | Phase 1 (manual) |
| Correlation engine | Groups events by source IP and time window | Phase 2 |
| Campaign classifier | Maps event groups to K10.A–K10.E patterns | Phase 2 |
| Severity escalator | Multi-domain campaigns get escalated | Phase 2 |
| Suppression engine | Auto-suppresses K10.A scanner patterns | Phase 2 |
| Real-time correlation | Every event triggers campaign check | Phase 3 |
Phase 1 (now): Manual correlation during weekly security audit. Auditor reviews ~/logs/hackx.log and looks for multi-domain patterns from single sources.
Phase 2 (HACKX module built): Automated correlation. Event store + correlation engine run as part of GAPX daily scan.
Phase 3 (mature): Real-time correlation. Multi-domain hits trigger immediate escalation.
ALERT FATIGUE MANAGEMENT
K10's biggest operational risk isn't missed attacks — it's ALERT FATIGUE.
The problem: 100 alerts per day → Captain stops reading → all alerts become invisible.
K10 management:
| Event Type | Handling |
|---|---|
| K10.A scanner patterns | Auto-suppressed. Logged but no alert. |
| Single-domain MEDIUM events | Aggregated in daily GAPX summary |
| Single-domain HIGH events | P2 alert (next business day) |
| Multi-domain campaigns | P0-P1 regardless of individual severity |
| P1+ events | Immediate Captain alert |
Goal: 0-2 actionable alerts per day. Not 0-2 events — there will be dozens of events. But only 0-2 that require human attention. Everything else is logged, archived, and reviewed weekly.
THE COMPLETE K-DOMAIN MAP
K1 Reconnaissance — seeing the ship
K2 Web Application — testing the doors
K3 Authentication — stealing the keys
K4 Network — poisoning the roads
K5 System Exploitation — owning the machine
K6 AI/LLM — corrupting the minds
K7 Cryptographic — breaking the codes
K8 Social Engineering — deceiving the people
K9 Evasion — hiding the evidence
K10 Frameworks — executing the plan
Ten domains. Every attack in the world maps onto one or more of these domains. HACKX speaks a complete security language.
HONEYPOT INTEGRATION
K10's honeypot contribution: the entire honeypot network generates a COHERENT picture when correlated.
| Honeypot | K-Domain | Intelligence Type |
|---|---|---|
| Fake ports 2222, 8080, 31337 | K1 | Recon intent |
| Fake endpoints /admin, /.env | K2 | Web attack technique |
| Decoy credentials in fake .env | K3 | Credential use attempt |
| Fake SUID binary | K5 | Privilege escalation probe |
| Training Arena probe logs | K6 | AI attack technique |
| Fake encryption key in .env | K7 | Crypto capability |
| Canary spec file | K9 | Exfiltration confirmation |
An attacker who touches honeypots across multiple K-domains in sequence is executing a campaign. The honeypots become a trip-wire GRID — touching one wire is suspicious. Touching three wires in sequence is confirmation. K10 correlates the honeypot data across domains.
This is the highest-quality intelligence: the attacker revealed their methodology while touching nothing real.
THE INTEGRATED DEFENSE STACK
K1-K9 — detect individual techniques
K10 — correlate into campaign awareness
MANTIS — classify social engineering intent
Baseline — respond behaviorally (gear system)
Agency Walls — enforce permissions
S.O.S. v2 — protect information boundaries
SPEC_MONITORING_ESCALATION.md — route alerts
SPEC_INCIDENT_POSTMORTEM.md — capture lessons
SPEC_KEY_ROTATION.md — manage credentials
SPEC_BACKUP_RECOVERY.md — enable recovery
Ten knowledge domains.
Ten supporting specs.
One integrated defense.
Without K10, HACKX is a collection of independent detectors. With K10, HACKX is a security intelligence system that understands HOW attacks are organized, not just WHAT attacks look like.
INVARIANTS
INV-01: K10 correlates. K1-K9 detect. MANTIS classifies intent. Baseline responds. Each layer has a specific role with no overlap.
INV-02: Campaign detection requires multi-domain correlation. Single-domain events are handled by that domain's response protocol. Multi-domain events are handled by K10 escalation.
INV-03: Alert fatigue is managed by auto-suppression of known scanner patterns. The Captain sees 0-2 actionable alerts per day, not 100.
INV-04: The ATT&CK kill chain mapping gives every event a POSITION in the attack timeline. Early chain = detect and block. Late chain = assume compromise and respond.
INV-05: Known campaign patterns (K10.A through K10.E) are updated as real incidents occur. Each incident teaches K10 a new pattern.
INV-06: K10 is the LAST domain specified but the FIRST domain consulted during incident response. When something happens, the first question is: "Is this part of a larger campaign?" K10 answers that question.
INV-07: All 10 K-domains are complete. The HACKX knowledge base is specified. Implementation follows specification. The knowledge exists even before the code does — and the knowledge is what matters.
INTEGRATION
| System | Relationship |
|---|---|
| SPEC_HACKX.md | K10 is the capstone of 10 knowledge domains. HACKX.md is the parent spec. K10 completes the knowledge base. |
| SPEC_HACKX_K1 through K9 | K10 correlates all previous domains into campaign detection. Each domain feeds the event store that K10 analyzes. |
| SPEC_MONITORING_ESCALATION.md | K10 campaign detection generates escalated severity levels. Multi-domain campaign → P0 regardless of individual severity. Alert fatigue management is shared between K10 and MONITORING_ESCALATION. |
| SPEC_SECURITY_AUDIT_SCHEDULE.md | Phase 1 K10 (manual correlation) happens during the weekly audit. Monthly audit catches slow K10.E campaigns. Quarterly audit reviews campaign patterns and updates K10.A-E taxonomy. |
| SPEC_BRAIN_MANTIS.md | MANTIS learns from K10 campaign patterns. K10.C ("The AI Researcher") feeds K6 pattern updates to MANTIS via LEARNX. Campaign detection feeds social engineering context to MANTIS. |
| SPEC_INCIDENT_POSTMORTEM.md | Every confirmed campaign triggers a postmortem. K10 provides the campaign context (which domains, which sequence, which framework pattern matched). |
| SPEC_NIST_CSF_MAPPING.md | K10.05 (NIST CSF) mapping — this may warrant a dedicated spec when enterprise customer due diligence is needed. |
Jeremy Zlabis
Chronogeometer · Visionary · Disruptor · Chief
42 Sisters AI · East York, Toronto
🍁 Φ 0.042