ESC

Type to search, or jump to a section

Getting StartedArchitectureHoneypot EngineDetectionObservabilityOperationsTestingReference
> PressHaven alpha
Home › Docs › Detection

Detection

How the honeypot system detects and identifies adversaries

Detection runs entirely inside the request path. Each non-static request is analysed by pure Lua rules, scored, and either forwarded to production or diverted to the session's honeypot pool. The same rules also produce the structured reasons used for logging and AbuseIPDB reporting.

Detection Pipeline Overview

The honeypot detection pipeline ingests adversary traffic and produces actionable detection signals through a layered chain, implemented as a series of pure Lua modules (no ngx.* dependency, unit-testable under a plain Lua interpreter) driving an adapter half that performs I/O:

  1. Traffic Capture — Nginx reverse proxy forwards HTTP requests; pattern_analyzer.analyze_request() runs once per non-static request.
  2. Lua Pattern Matching — pattern_rules.lua and vulnerability_rules.lua match request URIs, headers, and arguments against seeded CVE exploit patterns.
  3. Suricata Correlation — suricata_rules.lua parses eve.json alerts into structured records and converts them into risk-score deltas.
  4. Risk Scoring — pattern_analyzer.lua accumulates scores; router.lua accumulates onto a decaying session base.
  5. Routing Decision — router.lua's 12-stage decision pipeline diverts high-risk requests to isolated honeypot pool instances.
  6. Reporting — abuseipdb_rules.lua gates external AbuseIPDB reporting and enriches comments with matched CVEs.

Explore Detection

What is detected Detection Capabilities URI, header and argument patterns, automation detection, upload analysis, honeytokens and sophistication classification. Technique + module tables What is seeded Seeded CVEs The explicitly matched WordPress plugin CVEs, the Suricata alert path and the AbuseIPDB reason-to-category mapping. 13 CVEs · 6 reason types Network layer Suricata Network IDS SID allocation, the OWASP WSTG category index and the eve.json parsing and severity-to-score contract. 70+ SIDs One catalogue Pattern Database Every CVE, generic signature, upload and header rule, scanner tool and Suricata SID, with provenance, scores and attack lessons. 133 patterns · 15 CVEs · 70 SIDs Scoring details Advanced Signals Vulnerability patterns, threat-alert processing, reportability rules, the scoring model and escalation-aware decay. Decay policy Identity recovery Device & GDPR Signature A consent-gated, one-way signature that re-recognises a returning visitor after a cookie and storage wipe, without storing anything about them. Privacy-preserving

Coverage Areas

Direct CVE detections Plugin-specific and generic WordPress vulnerability patterns matched against URI, arguments and specific headers.
Generic attack patterns SQL injection, XSS, command injection, path traversal, file inclusion, deserialization, template and code injection.
Network IDS detections Suricata signatures aligned to OWASP WSTG categories, converted into severity-graded score deltas.
Behavioural signals Brute force, scanning, automation, request-rate anomalies and per-session history accumulation.
Sophistication classification Weighted signals classify traffic as scripted, AI-assisted, manual or unknown.
Honeytokens Injected fake credentials are scanned for in inbound requests; a hit confirms compromise with high confidence.

Detection Stages

StageAnalyserWSTGScore Impact
1URI pattern analysisWSTG-INPV, CONF, INFO+15 base per generic; +5..+80 per specific
2Header analysisWSTG-ATHN, AUTHZ+50 flagged UA; +50 CVE header; +10 missing UA
3CVE pattern matchingWSTG-AUTHZ, INPV+40 per CVE matched
4IP reputation + rate—+variable (threat_intel); +20 high rate
5Request methodWSTG-INPV+10 OPTIONS/TRACE; +15 override
6Automation detectionWSTG-INFO, ATHN+5..+30 per tool; +15 rapid streak
6bAJAX upload analysisWSTG-INPV-10Variable (upload_rules)
7Prompt-injection probe—+filter risk/2

Thresholds & Scaling

  • Honeypot threshold: 80 (raised from 50 to reduce false positives)
  • Max risk score: 100 (hard cap)
  • IP reputation cap: 10 per request on shared (NAT) addresses
  • Decay half-life: 300s, scaled by offense count via decay_policy.lua
  • Permaflag: After 5 offenses or a single request scoring 100

Honest Assessment

Strengths: Multi-layered detection (12 routing stages), explainable scoring, severity-graded Suricata integration, decay system prevents permanent poisoning, NAT protection, sophistication classification.

Limitations: Same-host Suricata testing gap (unverified against genuine external traffic), threshold tuning needed for legitimate API clients, generic pattern false positives (historical), decay complexity (4 tunable params), honeytoken coverage (only 5 types), no ML, Suricata rule maintenance (70+ SIDs).