Analysis, Forensics, Detection Packs, and Purple Team Loop

Dual-use philosophy offensive → defensive

KittySploit is not only an intrusion framework: each offensive module carries metadata (__info__, CVE, tags, references, source code) that can be leveraged by DetectionPackGenerator (core/detection/pack_generator.py).

What the framework extracts

• Declarative metadata --- name, description, CVE, tags, platform, protocol.
• Static indicators --- strings, URLs, HTTP patterns, filenames in the source.
• Behavioral hypotheses --- child processes, outbound connections, log markers.
• Validation artifacts --- JSON fixtures and unittest tests to avoid ``dead rules''.

Value for the organization

1. Red team --- executes and documents the attack in the workspace.
2. Blue team --- receives Sigma/YARA/Suricata/Zeek without manually re-analyzing each PoC.
3. GRC / CISO --- PDF report (kittyreport) + ATT&CK layer (campaign).
4. Detection QA --- python -m unittest discover tests on each pack.

Directory tree modules/analysis/

Console discovery:

search analysis --type analysis
search forensic
search kittyreport
show analysis

Modules analysis/binary/

firmware_bin

modules/analysis/binary/firmware_bin.py --- firmware signature scan and recursive decompression.

use analysis/binary/firmware_bin
set firmware /evidence/router-fw.bin
set output_dir /tmp/fw_extracted
set max_depth 16
check
run

Detects gzip, lzma, xz, squashfs, ELF, etc. via PyFirmwareExtractor. Useful after an IoT isolated test environment or a disk image reverse reference task.

firmware_extractor_advanced

Advanced variant for multi-layer extractions and detailed reports. Consult show info for specific options (max_depth, output directories).

Purple team use case

1. Red team deploys modified firmware on an embedded isolated test target.
2. Blue team recovers the disk image.
3. firmware_bin extracts the layers; file_hash_inventory (forensic) inventories the extracted files.
4. detection_pack on the exploit or payload used generates YARA on residual strings.

Modules analysis/forensic/

These modules are Auxiliary modules oriented toward offline DFIR --- they do not execute code on a remote target; they analyze local evidence.

file_hash_inventory

modules/analysis/forensic/file_hash_inventory.py --- file inventory with hashes and timestamps.

use analysis/forensic/file_hash_inventory
set path /evidence/disk-mount/home
set algorithms sha256,md5
set recursive true
set max_files 5000
set output_file /tmp/inventory.json
run

JSON output: paths, sizes, mtime, multi-algorithm hashes. Cross-reference with payloads generated in the relevant documentation (SHA256 of Zig binaries).

log_triage

modules/analysis/forensic/log_triage.py --- local log sweep.

use analysis/forensic/log_triage
set path /var/log
set recursive true
set max_lines 200000
set output_file /tmp/log_triage.json
run

Detected markers: auth failures, sudo, persistence (crontab, authorized_keys), curl/wget, kernel errors. IP counters and samples of suspicious lines.

file_timeline

Reconstructs an M-time/C-time chronology of files under a directory --- useful for correlating payload drop and execution.

artifact_carver

File signature search in a binary blob or raw disk image --- carving complement after a simulated isolated test environment incident.

Module analysis/reporting/kittyreport

modules/analysis/reporting/kittyreport.py generates a professional PDF from the workspace SQLite database (ReportLab required).

Loading and options

use analysis/reporting/kittyreport
set WORKSPACE purple-q2-2026
set FILENAME rapport_purple_q2.pdf
set TITLE "Reference task Purple Team Q2 2026"
set SUBTITLE "Validation detection C2 KittySploit"
set AUTHOR "Equipe SecOps / KittySploit"
run

Dependency: pip install reportlab.

PDF contents

1. Cover page (static/logo.jpg if present).
2. Executive summary --- host counts, vulnerabilities, severities.
3. Asset inventory --- IP, hostname, OS.
4. Findings --- CVE, CVSS, description, recommendation.
5. Credentials and loot references.

Output: output/reports/<FILENAME>. Combine with vuln --export for external GRC tools.

Client reporting integration

workspace use purple-q2-2026
vuln --list
use analysis/reporting/kittyreport
set WORKSPACE purple-q2-2026
set FILENAME livrable_client.pdf
run

The PDF covers the post-test posture; detection packs cover future prevention --- two complementary artifacts.

Command detection_pack

Implementation: interfaces/command_system/builtin/detection_pack_command.py. Engine: DetectionPackGenerator.

Description

Generate Sigma/YARA/Suricata/Zeek detections from an offensive module.

Syntax

detection_pack
detection_pack exploits/linux/http/php_cgi_cve_2024_4577_rce
detection_pack --preview
detection_pack --formats sigma,yara,suricata,zeek,docs,tests
detection_pack --output artifacts/detection_packs --force

Valid formats: sigma, yara, suricata, zeek, docs, tests.

If module_path is omitted, the current module (use ...) is used.

Options

• --output, -o --- base directory (default artifacts/detection_packs).
• --formats --- comma-separated list; default: all formats.
• --force --- overwrites an existing pack.
• --preview --- summary without writing (indicators, CVE, tags).

Preview mode

use exploits/linux/http/php_cgi_cve_2024_4577_rce
detection_pack --preview

Displays: module name, path, type, CVE, tags, first extracted indicators, list of planned outputs.

Structure of a generated pack

Directory: artifacts/detection_packs/<slug>/.

Manifest (manifest.json)

Key fields:

• schema_version, pack_id, created_utc;
• module.path, module.cve, module.tags;
• confidence --- score derived from indicator richness;
• indicators --- list extracted from the source;
• outputs --- relative paths of artifacts.

EDR hypotheses (edr_hypotheses.md)

Generated document listing:

• control-plane event near the vulnerable service;
• network telemetry with indicators before impact;
• child process or unusual script interpreter on the host.

Directly feeds blue team tabletop reference tasks.

Detection formats in detail

Sigma (sigma/<slug>.yml)

Portable rule for Splunk, Elastic, Sentinel, etc. Fields derived from module tags and protocol. Import via SIGMA CLI or your stack's converter.

# Local validation (if sigma-cli installed)
sigma check artifacts/detection_packs/<slug>/sigma/<slug>.yml

YARA (yara/<slug>.yar)

File and memory hunting. Test:

yara artifacts/detection_packs/<slug>/yara/<slug>.yar /evidence/sample

Suricata (suricata/<slug>.rules)

Network signature for IDS. Deployment:

suricata -c /etc/suricata/suricata.yaml \
  -S artifacts/detection_packs/<slug>/suricata/<slug>.rules

Zeek (zeek/<slug>.zeek)

Notice script for HTTP/TCP traffic. Load in the isolated test environment's site/local.zeek.

Docs (docs)

README.md, edr_hypotheses.md, expected_logs.json --- human documentation and log mapping for SOC analysts.

Tests (tests)

python -m unittest discover -s artifacts/detection_packs/<slug>/tests

Tests verify manifest consistency, indicator presence in fixtures, basic syntactic validity. Do not deploy to production without testing on real isolated test environment traffic.

Offensive → defensive workflow

Step 1 --- Offensive module selection

search cve-2024 --type exploits
use exploits/linux/http/php_cgi_cve_2024_4577_rce
show info
attack show exploits/linux/http/php_cgi_cve_2024_4577_rce

Step 2 --- Detection preview

detection_pack --preview

Evaluate indicator richness before full generation.

Step 3 --- Full generation

detection_pack --formats sigma,yara,suricata,zeek,docs,tests --force

Step 4 --- Validation

python -m unittest discover -s artifacts/detection_packs/<slug>/tests
# Manual YARA/Suricata tests on isolated test environment PCAP

Step 5 --- Blue team handoff

Deliver:

• manifest.json + edr_hypotheses.md;
• anonymized PCAP from the reference task;
• expected_logs.json for SIEM tuning.

Step 6 --- Iteration

After false positives in the isolated test environment, modify the rules or regenerate with --force after enriching the module's __info__ (tags, detections, ATT&CK artifacts).

campaign + detection_pack workflow

This workflow links offensive planning and detection engineering through a traceable purple-team process.

Phase A --- Workspace preparation

workspace create purple-campaign-2026
workspace use purple-campaign-2026
scope add 10.10.10.0/24
network_discover 10.10.10.0/24
host add 10.10.10.50

Phase B --- Planned campaign

campaign --preview
campaign --formats plan,report,navigator,timeline --max-steps 20
campaign --output artifacts/campaigns --force

Artifacts:

• plan_executable.json --- suggested module sequence;
• report.md --- human summary;
• attack_navigator_layer.json --- MITRE layer;
• timeline.json --- evidence milestones.

Phase C --- Controlled execution

Manually execute plan steps (or a subset) on the isolated test environment. Document sessions, loot, vulns.

use exploits/...
run
sessions -l
vuln --list

Phase D --- Detection packs per key module

For each module in the plan that was executed:

use exploits/linux/http/php_cgi_cve_2024_4577_rce
detection_pack --force

use payloads/singles/cmd/unix/python_reverse_tcp
detection_pack --formats yara,sigma,tests --force

Repeat for C2 payloads and critical scanners.

Phase E --- Consolidated report

use analysis/reporting/kittyreport
set WORKSPACE purple-campaign-2026
set FILENAME purple_campaign_report.pdf
run

attack export --format heatmap -o artifacts/attack/heatmap.md

Phase F --- Purple team review

Meeting with:

1. Navigator layer (campaign) --- planned techniques;
2. attack export heatmap --- catalog coverage;
3. Detection packs --- deployable rules;
4. kittyreport --- findings and residual risk;
5. log_triage / file_hash_inventory --- DFIR evidence.

Integrated workflow diagram

  scope + discover
        |
        v
   campaign (plan, navigator)
        |
        v
   execution isolated test environment (exploits, payloads)
        |
   +----+----+
   |         |
   v         v
kittyreport  detection_pack (x N modules)
   |         |
   +----+----+
        v
  purple team review + rule deployment

Purple team isolated test scenarios

Scenario 1 --- Single post-exploit pack

workspace use isolated test environment-simple
use exploits/linux/http/...
run
detection_pack --preview
detection_pack --force
python -m unittest discover -s artifacts/detection_packs/<slug>/tests

Scenario 2 --- Multi-module campaign

campaign --formats plan,navigator --output artifacts/campaigns
# Execute 3 plan modules
# detection_pack on each
# final kittyreport

Scenario 3 --- DFIR + detection

# After the C2 validation workflow
use analysis/forensic/file_hash_inventory
set path /mnt/evidence
run

use payloads/singles/cmd/unix/zig_reverse_tcp
detection_pack --formats yara,docs --force
# Compare inventoried hash vs YARA rule

Scenario 4 --- SIEM tuning

Import expected_logs.json into your correlation engine. Simulate events with log_triage on isolated test environment logs. Adjust Sigma thresholds.

Scenario 5 --- Defensive catalog

attack catalog --declared-only
# For each high-priority module:
use <module>
detection_pack --formats docs,tests --preview

Build an internal artifacts/detection_packs/ library versioned in Git (outside public repos).

Cross-reference with attack and MITRE

attack show exploits/linux/http/php_cgi_cve_2024_4577_rce
attack export --format navigator -o /tmp/global-nav.json
campaign --formats navigator

Align:

• attack.detections in __info__ --- declarative intentions;
• generated Sigma rules --- concrete implementation;
• gaps --- modules without detection_pack or without passing tests.

Detection engineering best practices

1. Always --preview before --force in production Git.
2. Version packs with the workspace and reference task date.
3. Run unittests before merging into the corporate detection repo.
4. Document false positives in the pack's README.md (manual fork).
5. Never deploy YARA/Suricata without isolated test environment validation PCAP.
6. Separate generic packs (low confidence) and specific packs (precise CVE).

Limitations and realism

• Indicator extraction = heuristics on Python source --- no ML magic.
• Modules without CVE or distinctive strings produce generic rules.
• Suricata/Zeek HTTP-centric if the module is HTTP; pure binary C2 = YARA + EDR hypotheses.
• kittyreport != final client report --- human review required.
• Detection pack does not replace continuous threat hunting.

Troubleshooting

Perspective: KittySploit as a red-blue bridge

Few frameworks unify C2 forge, ATT&CK campaign, PDF report, and Sigma/YARA packs from the same module metadata. KittySploit transforms each authorized reference task into an opportunity to improve detection, provided you document, test, and deploy artifacts with rigor. The relevant documentation taught you to generate the attack; this chapter teaches you to counter methodically what you just simulated --- closed purple team loop.