Deception Technologies and Honeypots

Deception technologies are security controls that deliberately create fake assets—systems, networks, files, or credentials—to mislead attackers and detect unauthorized activity. They are based on the principle that legitimate users have no reason to interact with decoys, so any interaction is likely malicious. The Security+ SY0-701 exam covers three main types: - Honeypots: Individual decoy systems (e.g., a fake server running vulnerable services) - Honeynets: Networks of multiple honeypots simulating a real production environment - Honeyfiles: Decoy files (e.g., fake password files, database dumps) that trigger alerts when accessed

The deception lifecycle involves four phases: 1. Deployment: Decoys are placed alongside real assets. They must appear realistic—running actual services (SSH, HTTP, SMB) with plausible data. Tools like Honeyd or Modern Honey Network (MHN) automate this. 2. Attraction: The decoy is made discoverable but not advertised. Attackers find it via scanning (e.g., Nmap) or by following fake breadcrumbs (e.g., honey tokens in configuration files). 3. Detection: Any interaction—a port scan, login attempt, file access—generates a high-fidelity alert. Because no legitimate user should touch the decoy, false positives are near zero. 4. Intelligence Gathering: The decoy logs attacker commands, tools, IPs, and techniques. This data feeds threat intelligence platforms (e.g., MISP) and can be used to update firewall rules or IDS signatures.

Honeypot Types: - Low-interaction honeypots: Simulate services but don't provide a full OS. Example: honeyd listens on ports and emulates service banners. Pro: safe, low resource. Con: limited interaction, easier to detect. - High-interaction honeypots: Run real operating systems and applications. Example: a fully patched Windows server with fake data. Pro: rich data, harder to detect. Con: higher risk if compromised—must be isolated. - Pure honeypots: Full production systems with no modifications, but monitored. Rarely used due to risk.

Honeynets: A network of honeypots behind a honeywall (a gateway that controls and monitors traffic). The honeywall prevents the attacker from using the honeynet to attack real systems. Data capture happens at the gateway.

Honeyfiles and Honey Tokens: - Honeyfiles: Decoy files (e.g., passwords.txt, customers.db) planted on file shares. When accessed, they trigger alerts via File Integrity Monitoring (FIM) or Windows Event Log (Event ID 4663). - Honey tokens: Fake credentials (e.g., admin:password123) embedded in config files. Any use of these credentials triggers an alert, often via a fake Active Directory account with no real privileges.

Attackers' countermeasures: Sophisticated attackers detect honeypots by looking for:

Defenders' deployment:

Setting up a low-interaction honeypot with Honeyd:

# Install honeyd on Ubuntu
sudo apt-get install honeyd

# Create a config file for a fake Windows server
cat > /etc/honeypot.conf << EOF
create windows
set windows personality "Windows 10"
set windows default tcp action reset
add windows tcp port 445 open
add windows tcp port 139 open
set windows uptime 365 days
bind 192.168.1.100 windows
EOF

# Start honeyd
sudo honeyd -d -f /etc/honeypot.conf -p /etc/nmap-os-db

Using honey tokens in Active Directory:

# Create a fake user account with no real access
New-ADUser -Name "svc_backup" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true

# Enable auditing on this account
Set-ADUser -Identity "svc_backup" -AccountNotDelegated $true

Detecting honeyfile access via Sysmon:

<Sysmon eventID="11" onmatch="include">
  <Rule name="Honeyfile Access" groupRelation="or">
    <TargetFilename condition="contains">secret.docx</TargetFilename>
  </Rule>
</Sysmon>

The NIST SP 800-115 (Technical Guide to Information Security Testing) and MITRE ATT&CK (Technique T1535 - Deception) reference honeypots. The exam expects you to know that honeypots are detective and deterrent controls, not preventive—they don't stop attacks but help identify and analyze them.

Scenario 1: Detecting Lateral Movement in a Corporate Network A SOC analyst notices unusual outbound traffic from an internal workstation to an IP that hosts a honeypot. The honeypot is configured as a fake HR database server. The analyst opens the honeypot logs and sees that the workstation ran net use \\192.168.1.100\HR_Share and attempted to open employees.xlsx. The analyst immediately quarantines the workstation via endpoint protection (e.g., CrowdStrike). Further investigation reveals the workstation was compromised via a phishing email. The attacker was attempting to exfiltrate data. The correct response: block the workstation, reset credentials, and scan the network for lateral movement. Common mistake: ignoring the alert because it came from a decoy, assuming it's a false positive. In reality, any decoy interaction is malicious.

Scenario 2: Honeypot as a Research Tool A threat intelligence team deploys a high-interaction honeypot on the internet to capture malware samples. They use a custom Python script that emulates a vulnerable WordPress site. Within hours, the honeypot logs multiple SQL injection attempts. The team captures the payloads and identifies a new variant of a web shell. They share the IOCs with the ISAC (Information Sharing and Analysis Center). The engineer uses tcpdump to capture full packet data and strings to extract URLs. Correct response: preserve the evidence, analyze the malware in a sandbox, and update WAF rules. Common mistake: not isolating the honeypot from the production network, leading to a real compromise.

Scenario 3: Insider Threat Detection via Honey Tokens An organization plants honey tokens—fake database credentials—in a shared configuration file on a developer's workstation. A week later, an alert fires because the honey token account was used to log in to the VPN. The SOC investigates and finds that a disgruntled employee used the credentials to access the network from home. The correct response: disable the honey token account, revoke VPN access, and initiate HR procedures. Common mistake: treating the alert as a false positive because the credentials were fake—the alert is real because any usage is unauthorized.