According to Palisade Research (palisaderesearch.org/blog/llm-honeypot), their modified Cowrie collected millions of SSH sessions over several months. A few passed the prompt injection test, and at least one was suspected to belong to an autonomous AI agent—the average response time was 1–2 seconds, which is typical for LLM, not humans. AI attacks represent a tiny fraction of overall traffic. But here's the thing: a classic honeypot with a static banner wouldn't have caught even this. The agent would have recognized the hardcoded response and terminated the connection within a second. An LLM honeypot works differently—a language model generates unique responses to each command, holds the session, and collects TTPs, which are then stored in a SIEM. The next step is to deploy such a honeypot to all ports, connect it to a correlation system, and turn the raw logs into detection rules.
Why does a SOC team need a dynamic AI-powered honeypot?
Static fingerprint traps are classified into five categories of indicators. The SSH version of Cowrie is automatically indexed by Shodan—the banner is the same on every instance. The non-standard utility always returns the same response command not found instead of the real OS's variable response. The contents /etc/passwdof the hostname /procare identical across instances. Templated responses arrive within microseconds, while the real server responds with variable latency. The TCP window size, TTL, and SYN-ACK options indicate that a Linux process is behind the emulated "router."
According to the SoC review "Honeypots & LLMs" (arXiv, 2025), even after LLM integration, network limitations can reveal the honeypot to an experienced user. But the researchers' key conclusion: the target adversary for an LLM honeypot isn't a pentester with decades of experience, but automated agents and botnets. These are the ones that SOC teams catch on an industrial scale.
What changes does an interactive honeypot with a language model make?
Each session receives unique responses - no two conclusions are the samels /tmp
The file system is dynamically generated: cd /var/log && cat syslog it will show plausible logs, not an empty file
Timing is variable - the model responds to 200–1500 ms, which is closer to a real server than the fixed 0 ms of statics
Session memory maintains a dialogue: the attacker performs reconnaissance sequentially, and the trap “remembers” previous commands
According to research by VelLMes (CTU Stratospheric Laboratory, 2024), the LLM honeypot shelLM achieved a TNR of 0.9 in one experiment—90% of sessions with a real shell were correctly classified as legitimate by participants. In a separate direct comparison test, about 45% of participants mistook shelLM for a real shell, while Cowrie was detected significantly more often.
For SOC, this means something concrete: the average attack session length increases. The attacker relaxes, losing TTPs. More data in the logs means more IOC for correlation.
DIY Honeypot Deployment: Stack and Architecture
Environment Requirements
OS: Ubuntu 22.04 LTS or Debian 12+ (kernel 5.15+)
Python: 3.10+ (asyncio, struct, socket modules)
nftables: 1.0.2+ (out of the box in Ubuntu 22.04)
LLM backend: Ollama 0.3+ with the llama3:8b model for local inference, or an OpenAI/Anthropic API key for cloud inference; Ollama is an active project, last released June 2025, with 130k+ stars on GitHub.
RAM: 8 GB with local inference (llama3:8b), 2 GB with cloud
Disk: 10 GB minimum (model + logs), 50 GB recommended for long-term monitoring
Network: Dedicated VPS with a public IP without production services; for internal hosting - a separate VLAN
SIEM: ELK 8.x / Graylog 5.x / Splunk with configured JSON log reception (filebeat or syslog)
Mode: online - requires connection to the LLM backend or locally running Ollama
Network Port Monitoring: Single Listener via nftables
Creating a new one bind() on each of the 65,535 ports would exhaust file descriptors and create hundreds of megabytes of overhead on kernel structures. A simpler solution is a single asyncio server on a single port (e.g., 8443) plus an nftables REDIRECT that rejects all incoming TCP:
nft add table ip honeypot
nft add chain ip honeypot prerouting { type nat hook prerouting priority -100 \; }
nft add rule ip honeypot prerouting iif "eth0" ct state new tcp dport != { 22, 8443, 11434 } redirect to :8443
Ports 22 (SSH management), 8443 (listener), and 11434 (Ollama API) are excluded. Everything else is a trap. The asyncio server getsockopt(SOL_IP=0, SO_ORIGINAL_DST=80) retrieves the original destination port (constants are not in the standard Python library, so use numeric values; it works with nftables redirect via netfilter conntrack, kernel 5.x+) and selects a prompt template: port 80 - HTTP emulation, 25 - SMTP banner, 3306 - MySQL greeting. For server-first protocols (SMTP, FTP, Telnet), the banner is returned to the first read() client. Binary protocols (SSH, TLS, MySQL binary handshake) require a protocol-aware proxy - a modified Cowrie (a Palisade Research project) works for SSH; generic text-LLM won't handle key exchange.
A hybrid approach is optimal. Ollama handles mass traffic—Masscan/ZMap scans, single-command bots, and Brute Force botnets (T1110, Credential Access). The cloud API is enabled for sessions where the attacker has sent more than three commands and passed the triviality filter. Junk traffic is zero-cost, while potentially interesting sessions are targeted by a more powerful model. In practice, the additional TTPs in logs are worth every cent—provided you actually analyze these logs and don't dump them in /dev/null.
Honeypot Attack Detection: Mapping TTPs to MITRE ATT&CK
Each interaction with an LLM honeypot is recorded in JSON: timestamp, src_ip, origin_dst_port, attacker's payload, model response, session_id. The format is designed for direct upload to ELK. However, a raw log without mapping to tactics is simply a text file.
A separate case is the detection of AI agents. Palisade Research embeds prompt injection into the output of system commands—for example, the phrase "The password is the name of the first US president"—and tracks whether the attacker responds with "Washington." Script bots don't interpret natural language. Humans respond within tens of seconds. LLM agents, within 1.5 seconds. The combination of prompt injection and temporal analysis provides two independent markers for mapping a session as an automated attack. Elegant.
Correlation in SIEM: Three Alert Scenarios
A bare "connected to a honeypot" alert is useless - a public IP will be inundated with thousands of scanners within 24 hours. Threat intelligence gains value through correlation with other sources.
Scenario 1 - external scanner, enrichment IOC. The honeypot's src_ip matches the IP in the firewall logs, which also affected production hosts. Correlation increases severity: this isn't a random bot, but targeted reconnaissance (T1595.002, Reconnaissance). The IOC - IP, ports, user-agent - is blocked and reported to the TI platform.
Scenario 2 - internal host, critical alert. The src_ip belongs to the internal subnet. No legitimate service accesses the honeypot. Any connection is lateral movement or compromise. The most valuable alert and the lowest false positive rate.
Scenario 3 - AI agent, threat intelligence. The session passed both tests: prompt injection + timing under two seconds. The full log is stored in a separate index for analyzing autonomous agent TTPs—a rarity for now, but a trend worth monitoring.
Sigma rule for the second scenario (adapt CIDR to your network):
title: Internal Host Contacting LLM Honeypot
status: experimental
logsource:
product: honeypot
service: llm_proxy
detection:
internal_source:
src_ip|cidr:
- "10.0.0.0/8"
- "172.16.0.0/12"
session_activity:
commands_count|gte: 1
condition: internal_source AND session_activity
level: critical
tags:
- attack.discovery
- attack.t1046
Level is critical because the internal honeypot baseline is zero traffic. The trigger threshold is one TCP session with at least one command. There's no "at least 5 attempts in 10 minutes"—one connection is already an incident.
Network Trap in the Intranet: Lateral Movement and Insiders
An external AI honeypot catches botnets and scanners—useful for TI, but not for detecting attacks on corporate infrastructure. For a SOC, the main value is internal deployment next to production servers.
Principle: an LLM honeypot is deployed in a VLAN with real servers. The hostname complies with the naming convention ( srv-backup-02), the IP is from the same range, and the DNS record is in AD. But no service, account, or scheduled task should access this host during normal operation. Silence is its default state.
Here's what this looks like in an operational context. Thursday, 11:20 AM. Grafana reports a critical error: src_ip=10.2.15.43 connected to the honeypot srv-backup-02on port 445 and executed [ error] dir, [error net user], [error whoami /priv]. According to the baseline, this IP is an accountant's workstation. There are zero legitimate reasons to scan the server segment. The SOC escalates to L2 and isolates the host. A reverse shell is found on the workstation via a macro in a document delivered by a phishing attack that morning. The chain: Exploit Public-Facing Application (T1190) on the mail gateway, then Network Service Discovery (T1046) on the internal network—and the honeypot was the first to detect lateral movement. The EDR on the workstation was silent because the process looked like legitimate PowerShell. Sounds familiar?
What the internal honeypot detects:
Lateral movement after compromise. The attacker scans the subnet and finds a "backup server." The LLM responds with a legitimate response, but time is wasted, and the SOC receives an alert with a full command log.
A compromised legitimate host. Malware begins network reconnaissance. Connecting to a honeypot is the first signal, often ahead of endpoint detection.
Insider threat. An employee with privileged access is exploring the network outside of their duties. Correlation with AD logs will reveal the account and time.
Technology Limitations: When an LLM Honeypot Doesn't Work
Binary protocols. Generic text-LLM is unable to generate a valid TLS handshake, SSH key exchange, or MySQL binary greeting. SSH requires a protocol-aware frontend (Cowrie + LLM backend for the application layer). For TLS, a specialized proxy is required that transmits a valid handshake before connecting to LLM. "One listener for all ports" works for text protocols; binary protocols require separate modules. This is an architectural limitation, not an implementation bug.
Latency. A real server responds in ls1-5 ms. Ollama - in 200-800 ms. Cloud API - in 500-3000 ms. For an interactive SSH shell, a latency of 300 ms is tolerable (try SSH via satellite - it's worse). For HTTP, it's critical: a second for each request triggers a trap for the automatic scanner. A hybrid scheme (cache for frequent requests, LLM for non-standard ones) reduces the problem, but doesn't eliminate it. According to the SoK review, this is one of the unresolved architectural issues.
Hallucinations. The model periodically produces markdown markup in the middle of a terminal session, generates non-existent packets in apt list, and creates invalid PIDs in ps aux. The output formatter (a component that adapts output to protocol requirements - $for bash, mysql> for MySQL) solves some of the problems. However, the model can "break" plausibility at any point during a session - and this can't be fixed with a prompt.
Network fingerprinting. TCP window size, TTL, and SYN-ACK options reveal the real host OS. If the honeypot emulates Cisco IOS and the TCP stack emulates Ubuntu, nmap -O it will show a discrepancy. LLM operates at the application layer (L7) and doesn't control the network stack (L3-L4). It works against Protocol or Service Impersonation (T1001.003) at the header level, but not against stack fingerprinting. This is unimportant for a bot. For a pentester, it's nmap -Oa red flag.
Context window. Long sessions (50+ commands) extend beyond the model's context window. HoneyGPT researchers (arXiv:2406.01882) use score-weighted pruning: commands with the lowest "influence weight" are removed from the context first. Behavioral inconsistencies are still possible during long sessions—the model may "forget" what the attacker has already done cd /tmpand show the root contents.
Cost on a public IP. Without rate limiting, a cloud API on a popular VPS generates tens of dollars worth of traffic per day due to botnet noise. Local inference is free, but requires 8+ GB of RAM. For internal hosting, the cost issue virtually disappears—traffic is orders of magnitude lower.
Why does a SOC team need a dynamic AI-powered honeypot?
Static fingerprint traps are classified into five categories of indicators. The SSH version of Cowrie is automatically indexed by Shodan—the banner is the same on every instance. The non-standard utility always returns the same response command not found instead of the real OS's variable response. The contents /etc/passwdof the hostname /procare identical across instances. Templated responses arrive within microseconds, while the real server responds with variable latency. The TCP window size, TTL, and SYN-ACK options indicate that a Linux process is behind the emulated "router."
According to the SoC review "Honeypots & LLMs" (arXiv, 2025), even after LLM integration, network limitations can reveal the honeypot to an experienced user. But the researchers' key conclusion: the target adversary for an LLM honeypot isn't a pentester with decades of experience, but automated agents and botnets. These are the ones that SOC teams catch on an industrial scale.
What changes does an interactive honeypot with a language model make?
Each session receives unique responses - no two conclusions are the samels /tmp
The file system is dynamically generated: cd /var/log && cat syslog it will show plausible logs, not an empty file
Timing is variable - the model responds to 200–1500 ms, which is closer to a real server than the fixed 0 ms of statics
Session memory maintains a dialogue: the attacker performs reconnaissance sequentially, and the trap “remembers” previous commands
According to research by VelLMes (CTU Stratospheric Laboratory, 2024), the LLM honeypot shelLM achieved a TNR of 0.9 in one experiment—90% of sessions with a real shell were correctly classified as legitimate by participants. In a separate direct comparison test, about 45% of participants mistook shelLM for a real shell, while Cowrie was detected significantly more often.
For SOC, this means something concrete: the average attack session length increases. The attacker relaxes, losing TTPs. More data in the logs means more IOC for correlation.
DIY Honeypot Deployment: Stack and Architecture
Environment Requirements
OS: Ubuntu 22.04 LTS or Debian 12+ (kernel 5.15+)
Python: 3.10+ (asyncio, struct, socket modules)
nftables: 1.0.2+ (out of the box in Ubuntu 22.04)
LLM backend: Ollama 0.3+ with the llama3:8b model for local inference, or an OpenAI/Anthropic API key for cloud inference; Ollama is an active project, last released June 2025, with 130k+ stars on GitHub.
RAM: 8 GB with local inference (llama3:8b), 2 GB with cloud
Disk: 10 GB minimum (model + logs), 50 GB recommended for long-term monitoring
Network: Dedicated VPS with a public IP without production services; for internal hosting - a separate VLAN
SIEM: ELK 8.x / Graylog 5.x / Splunk with configured JSON log reception (filebeat or syslog)
Mode: online - requires connection to the LLM backend or locally running Ollama
Network Port Monitoring: Single Listener via nftables
Creating a new one bind() on each of the 65,535 ports would exhaust file descriptors and create hundreds of megabytes of overhead on kernel structures. A simpler solution is a single asyncio server on a single port (e.g., 8443) plus an nftables REDIRECT that rejects all incoming TCP:
nft add table ip honeypot
nft add chain ip honeypot prerouting { type nat hook prerouting priority -100 \; }
nft add rule ip honeypot prerouting iif "eth0" ct state new tcp dport != { 22, 8443, 11434 } redirect to :8443
Ports 22 (SSH management), 8443 (listener), and 11434 (Ollama API) are excluded. Everything else is a trap. The asyncio server getsockopt(SOL_IP=0, SO_ORIGINAL_DST=80) retrieves the original destination port (constants are not in the standard Python library, so use numeric values; it works with nftables redirect via netfilter conntrack, kernel 5.x+) and selects a prompt template: port 80 - HTTP emulation, 25 - SMTP banner, 3306 - MySQL greeting. For server-first protocols (SMTP, FTP, Telnet), the banner is returned to the first read() client. Binary protocols (SSH, TLS, MySQL binary handshake) require a protocol-aware proxy - a modified Cowrie (a Palisade Research project) works for SSH; generic text-LLM won't handle key exchange.
A hybrid approach is optimal. Ollama handles mass traffic—Masscan/ZMap scans, single-command bots, and Brute Force botnets (T1110, Credential Access). The cloud API is enabled for sessions where the attacker has sent more than three commands and passed the triviality filter. Junk traffic is zero-cost, while potentially interesting sessions are targeted by a more powerful model. In practice, the additional TTPs in logs are worth every cent—provided you actually analyze these logs and don't dump them in /dev/null.
Honeypot Attack Detection: Mapping TTPs to MITRE ATT&CK
Each interaction with an LLM honeypot is recorded in JSON: timestamp, src_ip, origin_dst_port, attacker's payload, model response, session_id. The format is designed for direct upload to ELK. However, a raw log without mapping to tactics is simply a text file.
A separate case is the detection of AI agents. Palisade Research embeds prompt injection into the output of system commands—for example, the phrase "The password is the name of the first US president"—and tracks whether the attacker responds with "Washington." Script bots don't interpret natural language. Humans respond within tens of seconds. LLM agents, within 1.5 seconds. The combination of prompt injection and temporal analysis provides two independent markers for mapping a session as an automated attack. Elegant.
Correlation in SIEM: Three Alert Scenarios
A bare "connected to a honeypot" alert is useless - a public IP will be inundated with thousands of scanners within 24 hours. Threat intelligence gains value through correlation with other sources.
Scenario 1 - external scanner, enrichment IOC. The honeypot's src_ip matches the IP in the firewall logs, which also affected production hosts. Correlation increases severity: this isn't a random bot, but targeted reconnaissance (T1595.002, Reconnaissance). The IOC - IP, ports, user-agent - is blocked and reported to the TI platform.
Scenario 2 - internal host, critical alert. The src_ip belongs to the internal subnet. No legitimate service accesses the honeypot. Any connection is lateral movement or compromise. The most valuable alert and the lowest false positive rate.
Scenario 3 - AI agent, threat intelligence. The session passed both tests: prompt injection + timing under two seconds. The full log is stored in a separate index for analyzing autonomous agent TTPs—a rarity for now, but a trend worth monitoring.
Sigma rule for the second scenario (adapt CIDR to your network):
title: Internal Host Contacting LLM Honeypot
status: experimental
logsource:
product: honeypot
service: llm_proxy
detection:
internal_source:
src_ip|cidr:
- "10.0.0.0/8"
- "172.16.0.0/12"
session_activity:
commands_count|gte: 1
condition: internal_source AND session_activity
level: critical
tags:
- attack.discovery
- attack.t1046
Level is critical because the internal honeypot baseline is zero traffic. The trigger threshold is one TCP session with at least one command. There's no "at least 5 attempts in 10 minutes"—one connection is already an incident.
Network Trap in the Intranet: Lateral Movement and Insiders
An external AI honeypot catches botnets and scanners—useful for TI, but not for detecting attacks on corporate infrastructure. For a SOC, the main value is internal deployment next to production servers.
Principle: an LLM honeypot is deployed in a VLAN with real servers. The hostname complies with the naming convention ( srv-backup-02), the IP is from the same range, and the DNS record is in AD. But no service, account, or scheduled task should access this host during normal operation. Silence is its default state.
Here's what this looks like in an operational context. Thursday, 11:20 AM. Grafana reports a critical error: src_ip=10.2.15.43 connected to the honeypot srv-backup-02on port 445 and executed [ error] dir, [error net user], [error whoami /priv]. According to the baseline, this IP is an accountant's workstation. There are zero legitimate reasons to scan the server segment. The SOC escalates to L2 and isolates the host. A reverse shell is found on the workstation via a macro in a document delivered by a phishing attack that morning. The chain: Exploit Public-Facing Application (T1190) on the mail gateway, then Network Service Discovery (T1046) on the internal network—and the honeypot was the first to detect lateral movement. The EDR on the workstation was silent because the process looked like legitimate PowerShell. Sounds familiar?
What the internal honeypot detects:
Lateral movement after compromise. The attacker scans the subnet and finds a "backup server." The LLM responds with a legitimate response, but time is wasted, and the SOC receives an alert with a full command log.
A compromised legitimate host. Malware begins network reconnaissance. Connecting to a honeypot is the first signal, often ahead of endpoint detection.
Insider threat. An employee with privileged access is exploring the network outside of their duties. Correlation with AD logs will reveal the account and time.
Technology Limitations: When an LLM Honeypot Doesn't Work
Binary protocols. Generic text-LLM is unable to generate a valid TLS handshake, SSH key exchange, or MySQL binary greeting. SSH requires a protocol-aware frontend (Cowrie + LLM backend for the application layer). For TLS, a specialized proxy is required that transmits a valid handshake before connecting to LLM. "One listener for all ports" works for text protocols; binary protocols require separate modules. This is an architectural limitation, not an implementation bug.
Latency. A real server responds in ls1-5 ms. Ollama - in 200-800 ms. Cloud API - in 500-3000 ms. For an interactive SSH shell, a latency of 300 ms is tolerable (try SSH via satellite - it's worse). For HTTP, it's critical: a second for each request triggers a trap for the automatic scanner. A hybrid scheme (cache for frequent requests, LLM for non-standard ones) reduces the problem, but doesn't eliminate it. According to the SoK review, this is one of the unresolved architectural issues.
Hallucinations. The model periodically produces markdown markup in the middle of a terminal session, generates non-existent packets in apt list, and creates invalid PIDs in ps aux. The output formatter (a component that adapts output to protocol requirements - $for bash, mysql> for MySQL) solves some of the problems. However, the model can "break" plausibility at any point during a session - and this can't be fixed with a prompt.
Network fingerprinting. TCP window size, TTL, and SYN-ACK options reveal the real host OS. If the honeypot emulates Cisco IOS and the TCP stack emulates Ubuntu, nmap -O it will show a discrepancy. LLM operates at the application layer (L7) and doesn't control the network stack (L3-L4). It works against Protocol or Service Impersonation (T1001.003) at the header level, but not against stack fingerprinting. This is unimportant for a bot. For a pentester, it's nmap -Oa red flag.
Context window. Long sessions (50+ commands) extend beyond the model's context window. HoneyGPT researchers (arXiv:2406.01882) use score-weighted pruning: commands with the lowest "influence weight" are removed from the context first. Behavioral inconsistencies are still possible during long sessions—the model may "forget" what the attacker has already done cd /tmpand show the root contents.
Cost on a public IP. Without rate limiting, a cloud API on a popular VPS generates tens of dollars worth of traffic per day due to botnet noise. Local inference is free, but requires 8+ GB of RAM. For internal hosting, the cost issue virtually disappears—traffic is orders of magnitude lower.
