kryssar.se
Menu

Autonomous Learning and Reporting Vision

Objective

To further enhance the homelab's knowledgebase and presentation layer by implementing an autonomous, nonstop learning cycle. This involves agents participating in security challenges (CTF/Wargames), generating pedagogic writeups, and presenting them on a central lab webpage.

Design Ideas

  • Platform Integration: A "Scout" capability to interface with platforms like picoCTF, TryHackMe, HackTheBox, and Wargames (e.g., OverTheWire).
  • Challenge Selection: Autonomous selection based on difficulty, category (Web, Pwn, Crypto, Forensics), and existing knowledge gaps in the Knowledge Graph.
  • The Iterative Solver:
    • Phase 1: Recon: Analyze challenge description and files.
    • Phase 2: Execution: Attempt solutions using the auto-attack-container (on [internal-host]).
    • Phase 3: Learning Loop: If failed, search local knowledge-library/ or query external documentation (if permitted) to learn new techniques.
    • Phase 4: Resolution: Successfully capture the flag or resolve the objective.
  • Resource Management: Runs primarily on [internal-host] (RTX 4060) to avoid impact on SAGA lab operations.

Design Ideas

  • Standardized Templates: Move away from raw logs to structured, educational narratives.
  • Template Sections:
    • Abstract: High-level summary of the challenge and outcome.
    • Challenge Deep-Dive: Original problem statement and provided artifacts.
    • The Discovery Process: Step-by-step logic used by the agent, including dead ends and "pivot moments."
    • Technical Breakdown: Detailed explanation of the vulnerability and exploit mechanics (the "Why").
    • Defense & Mitigation: How the vulnerability could be prevented in a real enterprise environment.
    • Educational Takeaway: New skill or technique added to the lab's repertoire.
  • Automated Enrichment:
    • Automatically link techniques to MITRE ATT&CK IDs and Knowledge Graph entities.
    • MITRE Corpus Ingestion: Ingest official MITRE CAR analytics, the ATT&CK Enterprise matrix, and ATT&CK Navigator layer data into a local knowledge pipeline. Normalize CAR analytics into lab-relevant detection and hunt notes, map ATT&CK techniques to current telemetry and attack-path entities, and generate Navigator layers for coverage, gap, and target-specific views that can be used offline in the homelab.
  • Navigator Lab Stack: Run a local MITRE ATT&CK Navigator container on [internal-host], seeded with a lab starter layer and a banner that points operators at the homelab coverage workflow. The long-term target is to mirror the ATT&CK collection index locally and keep the stack usable even when the public site is unavailable.

Design Ideas

  • Static Site Generation: Use Hugo or Jekyll to convert the vault's Markdown writeups into a polished, dark-themed static site.
  • Hosting: Served via Nginx on [internal-host] (port 80/443) or an internal NAS-hosted site.
  • Dynamic Dashboards: Integration with Malcolm/Wazuh alert telemetry to show "Live Lab Stats" alongside the static writeups.
  • Presentation Flow:
    • Timeline: Chronological log of all lab compromises and CTF wins.
    • Technique Library: A wiki-style view of all techniques mastered by the agents.
    • The Experience: A narrative walkthrough of the lab's evolution (derived from generate-experience-slides.py logic).
  • Auto-Update: n8n trigger to rebuild the site whenever a new writeup is finalized by the Librarian agent.

Design Ideas

  • Bounty Scraper: Specialized agents to monitor platforms (HackerOne, Bugcrowd) for public writeups and disclosed vulnerabilities.
  • OWASP Top 10 Playbook Generator:
    • Scrape the official OWASP Top 10 web-application project, currently the OWASP Top 10:2025 release, and convert each category into an AI-followable "usual suspects" testing playbook.
    • Source Policy: Pull only from official OWASP pages or the official OWASP Top10 repository, preserve source URL/version/date, and refresh on a controlled schedule.
    • Playbook Shape: For each OWASP category, generate objective, safe preconditions, evidence to collect, low-risk probes, escalation criteria, common false positives, and defensive validation notes.
  • Execution Contract: The playbook can guide checks, but live testing still requires written scope, target approval, and the appropriate offense skill gate.
  • Lab Mapping: Link each category to existing tools and safe workflows such as offensive-security-tester, bug-bounty-operator, knowledge-rag, evidence-cataloger, Malcolm/Wazuh telemetry checks, and DVWA/DEVBOX practice targets.
  • Learning Loop: After an authorized run, feed results back into the playbook as "worked", "failed", "false positive", and "needs human review" examples.
  • Knowledge Conversion:
    • Automatically convert scraped writeups into structured knowledge nodes for the "Scholar" agent, focusing on novel bypasses and exotic bug classes.
  • Skill Crafting:
    • Use the Knowledge Graph and knowledge-library/ (including technical books and papers) to synthesize new "Security Tester" skills.
  • Self-Learning Feedback Loop:
    • Test: Execute synthesized skills on live (authorized) targets.
    • Refine: Feed results (success or failure) back into the skill-crafting engine to improve precision and efficacy.

Design Ideas

  • Vector Memory Layer: Add a vector database for fast semantic retrieval over agent memories, lessons learned, writeups, tool notes, preferences, and Knowledge Graph references. The vector store complements 17-state/learning-journal.yaml, 00-meta/ai-memory.md, and knowledge-rag.py; it does not replace them as authoritative state.
  • Automagic Credential Reference Lookup: Agents should remember service-to-secret mappings and check approved local sources before asking the operator for passwords or URLs. The lookup layer should index references such as env variable names, secret_ref paths, service URLs, and required approval gates, never raw secret values. The intended flow is: service need -> credential-source report/OpenBao metadata -> scoped retrieval only when allowed -> use in-process -> redacted from all output.
  • Linked Security Knowledge Enrichment: Use the newly ingested sources to create stronger links between knowledge that belongs together: books, writeups, CTF notes, MITRE techniques, CVEs, tools, lab evidence, detections, attack paths, and defensive playbooks. The existing knowledge-linker.py already creates document-level Graph-RAG cross-links from TF-IDF similarity plus entity overlap; the next design step is to extend it into a KG-aware and evidence-aware enrichment pipeline.
  • Memory Classes:
    • Operator Preferences: How kryssar prefers agents to work, report, verify, escalate, and present results.
    • Tool Memory: Known-good commands, local service quirks, approved routes, failed invocation patterns, and environment requirements such as the bridge venv.
    • Knowledge Links: Pointers between writeups, techniques, MITRE IDs, graph entities, evidence paths, detections, and lab services.
  • Task Memory: Current goals, blockers, decisions, and why a path was chosen or rejected.

Design Ideas

  • Start with a lightweight local vector store backed by embeddings over Markdown chunks and YAML summaries.
  • Store source pointers, timestamps, confidence, and canonical file paths with every vector.
  • Add linked-knowledge-enricher.py as a second-stage pipeline around the existing linker:
    • Task 1 - Baseline: run knowledge-rag.py build --json, knowledge-dedup.py, and knowledge-linker.py --report to capture source/chunk/link stats.
    • Task 2 - Parallel Discovery: dispatch subagents for index structure, source metadata quality, KG relations, evidence/detection links, and credential/live-source requirements.
  • Add a reflection-runner.py that emits:
    • memory candidates,
    • stale-state findings,
    • proposed next actions,
    • proposed Knowledge Graph links,
    • operator decision requests.

Design Ideas

  • "Scholar Mode" Workflow: An n8n cron job that activates the Scholar Agent during off-peak hours (e.g., 08:00 - 12:00 UTC).
  • Writeup Ingest Pipeline: Finalized writeups are pushed to ingest-queue/, reviewed by the Referee Agent for quality/accuracy, and then published to the webpage.
  • KG Feedback: New techniques discovered during CTF play are automatically proposed as new technique entities in 18-knowledge-graph/entities/.
  • Container Victim Pool: Treat disposable Docker containers as first-class victim services for scenario generation, so the lab can spin up web apps, daemons, and mini-stacks as repeatable targets without consuming full VMs. This expands the range of realistic misconfiguration, lateral movement, and service-abuse stories the scenario engine can compose.

This document has been sanitized in accordance with the specified redaction rules.