Guardian: honeypots, anomalies, and AD honeytokens

Why Guardian exists

In pentesting, an IP that responds ``too well'' to everything (SSH, FTP, HTTP, SMB open with generic banners) is often a honeypot or deception. Connecting to it en masse:

• alerts the defensive team with your source IP;
• falsifies mapping (phantom services);
• may violate rules of engagement (interaction with honeypot infrastructure).

Guardian (core/guardian_manager.py) analyzes each operation: response time, deception indicators, per-host history, cumulative honeypot score. It also feeds honeytoken AD detection (accounts that have never authenticated but attract attackers).

Architecture and thresholds

Default configuration (see guardian config):

Risk score weights: response time (30 %), honeypot indicators (25 %), honeypot profile (20 %), suspicious history (15 %), consecutive anomalies (10 %).

Activation at engagement start

guardian enable
guardian enable --verbose
guardian enable --verbose --auto-action
guardian status
guardian config

• --verbose --- each evaluation is logged (useful in isolated test environment).
• --auto-action --- automatic blacklist on CRITICAL alerts (use with caution; prefer manual mode on client engagements until calibrated).

Golden rule: enable Guardian before the first scanner or mass portscan on an unknown network.

How Guardian detects a network honeypot

Behavioral signals

1. Abnormal latency --- systematically slow or too fast responses vs baseline.
2. Honeypot indicators --- strings in banners, Cowrie-like behavior, Dionaea, learned signatures (guardian learn).
3. Accumulation --- multiple open ports with inconsistent fingerprints.
4. History --- same IP flagged several times in few interactions.

Manual target test

guardian test 192.168.1.50
guardian test 192.168.1.50 --deep

--deep mode enriches analysis (more risk components, detailed recommendations). Use it before exploiting an ambiguous service on extended Metasploitable or client network.

Workflow after CRITICAL alert

1. Stop running modules (jobs, Ctrl+C if needed).
2. Read guardian alerts --count 5 --- note confidence, evidence.
3. Validate out-of-band (ping, traceroute, OSINT correlation).
4. If honeypot confirmed: guardian blacklist add <ip> --reason "Cowrie SSH".
5. If false positive: guardian ack <ip> --note "Dev server, WAN latency".
6. Document in workspace and exclude IP from scope if trap confirmed.

Blacklist, whitelist, and false positives

guardian blacklist add 10.0.0.99 --reason "Honeypot isolated test environment Cowrie"
guardian blacklist show
guardian blacklist remove 10.0.0.99

guardian ack 10.0.0.42 --note "Qualys scanner legitime"
guardian alerts --count 20

guardian ack reduces honeypot score, adds the host to the internal whitelist, and counts a false positive in statistics (guardian status).

Baseline mode

guardian learn --operations 100

Analyzes the last 100 recorded operations to refine:

• latency baselines;
• honeypot signatures (learned_patterns.honeypot_signatures);
• estimated model accuracy (displayed after learning).

In isolated test environment: first run scans against DVWA/Metasploitable (known targets), then guardian learn to separate ``normal isolated test environment'' from ``suspicious''.

Integration into pre-flight run

When Guardian is active, the framework can display a preview before module execution on an IP: active monitoring, blacklist size, quick evaluation. If the host is blacklisted, the operator is warned --- this avoids relaunching an exploit against an identified trap.

Metasploitable scenario: services are real in the container; Guardian helps you train the reflex of ``read the alert before run''. Deploy a Cowrie honeypot in parallel on another IP to watch alerts rise.

Active Directory honeytokens

Concept

A honeytoken (or honeyaccount) is an AD account created to be touched by an attacker. It is never used legitimately (lastLogon empty, logonCount null or very low) but has attractive attributes (name svc_backup, apparent privileges).

Guardian implements the lastLogon oracle: enumerated accounts whose authentication history is empty or inconsistent = high score.

Hunt modules

Two modules feed Guardian:

Hunt via SMB (recommended)

guardian enable
use scanner/smb/honeytoken_hunt
show options
set rhost 10.0.0.10
set domain CORP
set username ""
set password ""
set auto_blacklist true
run

Advanced options:

• min_score --- report threshold (default: ``suspicious'' threshold).
• users / computers --- filter account types.
• auto_blacklist --- automatic Guardian registration if probable.

Hunt via LDAP

use scanner/ldap/honeytoken_hunt
set rhost dc.corp.local
set rport 389
set domain CORP
run

Identity consultation

guardian identities show
guardian identities show --min-score 60 --count 50
guardian identities ack CORP\_backup --note "Valid service account, never logged in"
guardian identities ack svc_scan --domain CORP --note "Approved scanning account in ROE"

Each entry displays essential fields: sam_account, domain, honeytoken_score, verdict, signals, and never_logged_on.

What to do when a honeytoken is detected?

1. Do not attempt authentication to ``test'' without explicit mandate.
2. Note the account in the report as an indicator of defensive maturity.
3. If the client confirms a trap: guardian identities ack after validation.
4. Exclude the account from bruteforce lists (search + credential modules).
5. Inform the lead via secure channel --- the SOC may already see your SAMR enumeration.

Internal Isolated Test Network

workspace create guardian-lab-2026
workspace use guardian-lab-2026
scope add 10.0.0.0/24
guardian enable --verbose

network_discover -r 10.0.0.0/24
use auxiliary/scanner/portscan/tcp
set rhosts 10.0.0.0/24
set ports 22,80,445,3389
set threads 20
run

guardian alerts --count 15
guardian test 10.0.0.15 --deep

use scanner/smb/honeytoken_hunt
set rhost 10.0.0.10
run

guardian identities show --min-score 50
guardian status

For each CRITICAL IP: blacklist or documented ack. Record: IP / score / decision / justification table.

Correlation with scanner and agent

• scanner can trigger many operations --- Guardian learns quickly.
• agent --safety-profile discreet slows down but does not replace Guardian on honeypots.
• Before agent --approve-risk intrusive: check guardian blacklist show.

Manual honeypot indicators (outside Guardian)

Keep these reflexes even without an alert:

Statistics and maintenance

guardian status
guardian disable   # end of mission

status displays: threats detected, honeypots, honeytokens, false positives, learning accuracy. Mentally reset between clients (different blacklists).