Honeypot — CraftedSignal Threat Feed

AI-Powered Honeypots: Deceptive Environments for Automated Threat Actors

hello@craftedsignal.io — Wed, 29 Apr 2026 10:00:42 +0000

The rise of AI brings advantages to both defenders and threat actors. This brief explores how generative AI can be leveraged to create adaptive honeypot systems. These systems can instantly create diverse honeypots, such as Linux shells or IoT devices, using simple text prompts. This approach offers a scalable method for deploying complex, convincing deceptive environments. Because AI-driven attacks often prioritize speed over stealth, they are highly susceptible to being tricked by these simulated systems. Defenders can actively manipulate and mislead threat actors, observing their methodologies in real-time within a controlled environment. By exploiting the inherent lack of awareness in AI agents, defenders can turn the attacker’s automation into a liability.

Attack Chain

The attacker’s AI-driven tool scans a range of IP addresses, identifying open TCP ports.
The attacking tool connects to a honeypot listener on a designated port.
The honeypot presents a simulated login prompt.
The attacking tool attempts to authenticate using common credentials or exploits known vulnerabilities.
If the attacker attempts the correct username (“admin”) and password (“password123”), or exploits a simulated vulnerability like Shellshock (CVE-2014-6271), the honeypot grants access to a simulated environment.
The attacker issues commands, believing they are interacting with a real system.
The honeypot, powered by a generative AI model, responds in a manner consistent with the simulated environment, logging all attacker actions.
The attacker attempts to move laterally, install malware, or exfiltrate data, all within the confines of the honeypot.

Impact

Successful deployment of AI-powered honeypots allows organizations to gain valuable insights into the tactics, techniques, and procedures (TTPs) of automated threat actors. This information can be used to improve existing security measures, develop more effective detection strategies, and proactively defend against future attacks. By observing attacker behavior in a controlled environment, organizations can minimize the risk of real systems being compromised. The number of diverted attacks will vary depending on honeypot deployment scale and attacker activity.

Recommendation

Deploy honeypots simulating common services or devices within your network to attract automated attacks and observe attacker behavior.
Monitor network connections to honeypot IP addresses (using a firewall or network intrusion detection system) and trigger alerts on any inbound connection attempts.
Implement the Sigma rule “Detect Successful Honeypot Authentication” to identify when an attacker successfully authenticates to the honeypot.
Enable process creation logging on systems running honeypots and deploy the Sigma rule “Detect Suspicious Commands in Honeypot Environment” to identify malicious commands executed within the simulated environment.
Review network traffic generated by honeypots for exploitation attempts targeting vulnerabilities like CVE-2014-6271.

OpenCanary HTTPPROXY Login Attempt Detection

hello@craftedsignal.io — Sat, 26 Oct 2024 18:22:34 +0000

This threat brief focuses on detecting malicious attempts to use an OpenCanary node as an HTTP proxy. OpenCanary is a low-interaction honeypot designed to detect intruders on a network. An attacker attempting to use an OpenCanary node as an HTTP proxy is a strong indicator of reconnaissance or lateral movement, as they are attempting to route their traffic through the honeypot. This activity is logged by OpenCanary and can be detected with appropriate monitoring. The default configuration of OpenCanary includes an HTTPPROXY service that listens for proxy requests. Defenders should monitor OpenCanary logs for event ID 7001, which indicates an attempted HTTP proxy login.

Attack Chain

Attacker gains initial access to a network (e.g., through phishing or exploiting a vulnerability).
Attacker performs network reconnaissance to identify potential targets, including the OpenCanary node.
Attacker attempts to configure their system or tools to use the OpenCanary node as an HTTP proxy.
The attacker sends HTTP requests through the configured proxy, attempting to reach other systems on the network.
OpenCanary logs the attempted proxy connection with event ID 7001.
The defender detects the suspicious HTTP proxy attempt in the OpenCanary logs.

Impact

A successful HTTP proxy attempt indicates that an attacker is actively exploring the network and attempting to move laterally. This could lead to further compromise of sensitive systems and data exfiltration. While the OpenCanary node itself is a honeypot and not a production asset, the detection of proxy attempts signals a breach and ongoing malicious activity within the network.

Recommendation

Deploy the provided Sigma rule OpenCanary HTTPPROXY Login Attempt to your SIEM and tune for your environment to detect unauthorized proxy attempts on OpenCanary nodes.
Investigate any alerts generated by the Sigma rule to determine the source and target of the attempted proxy connection.
Review OpenCanary configuration to ensure that the HTTPPROXY service is properly configured and secured.
Implement network segmentation to limit the impact of potential lateral movement by attackers.

OpenCanary Telnet Login Attempt

hello@craftedsignal.io — Sat, 26 Oct 2024 14:30:00 +0000

OpenCanary is a low-interaction honeypot designed to detect attackers on a network. This detection focuses on Telnet login attempts, a protocol rarely used legitimately in modern networks and thus a strong indicator of malicious activity. When an attacker attempts to log into a Telnet service on an OpenCanary node, it triggers this alert. This provides early warning of potential intrusion attempts, reconnaissance activities, or lateral movement by attackers who have already gained a foothold. The detection is based on OpenCanary’s logging functionality which records such login attempts, generating a log event with code 6001. This event signifies an attacker interacting with the Telnet service, which is unlikely in a well-secured and properly configured environment.

Attack Chain

Attacker scans the network for open ports, identifying a Telnet service.
Attacker attempts to connect to the Telnet service on the OpenCanary node.
Attacker enters credentials (username and password) in an attempt to authenticate.
OpenCanary logs the Telnet login attempt, generating an event with logtype 6001.
The detection rule triggers based on the OpenCanary log event.
Security team investigates the alert to determine the source and intent of the Telnet login attempt.
If the attempt is malicious, the security team takes steps to block the attacker and prevent further access.

Impact

A successful Telnet login could provide an attacker with unauthorized access to the network or specific systems. While Telnet itself may not grant immediate access to sensitive data, it can be used as a stepping stone for further exploitation and lateral movement. The compromise of even a single system can lead to data breaches, ransomware deployment, and significant disruption of services. OpenCanary serves as an early warning system, allowing defenders to identify and respond to such attempts before significant damage occurs.

Recommendation

Deploy the Sigma rule OpenCanary - Telnet Login Attempt to your SIEM to detect unauthorized Telnet login attempts.
Investigate any alerts generated by the OpenCanary - Telnet Login Attempt rule to determine the source and intent of the connection.
Review the OpenCanary configuration to ensure it is properly deployed and monitoring the appropriate network segments.
Consider disabling the Telnet service on all legitimate systems on the network to reduce the attack surface.

OpenCanary SSH Connection Attempt

hello@craftedsignal.io — Wed, 08 May 2024 14:30:00 +0000

The OpenCanary SSH Connection Attempt alert signifies that an SSH service on a deployed OpenCanary node has received a connection attempt. OpenCanary is a low-interaction honeypot designed to detect reconnaissance and lateral movement activities within a network. This event, logged as logtype 4000 by default, suggests that an attacker is actively scanning for or attempting to exploit SSH services. This alert is crucial for defenders because OpenCanary nodes are deliberately placed to attract malicious activity, meaning any interaction is highly suspicious. The alert helps identify potential breaches early, allowing security teams to respond quickly. The configuration of services monitored by OpenCanary is detailed in the project’s documentation.

Attack Chain

Initial Reconnaissance: The attacker conducts network scanning using tools like Nmap or Masscan to identify open ports and services, including SSH (port 22).
Target Identification: The attacker identifies the OpenCanary node, mistaking it for a legitimate SSH server, due to its exposed SSH port.
Connection Attempt: The attacker attempts to establish an SSH connection to the OpenCanary node using a tool like ssh or a custom script.
Authentication Probe: The attacker might attempt to authenticate using default credentials, common usernames and passwords, or brute-force techniques.
Credential Compromise (Simulated): The OpenCanary node logs the failed or successful (simulated) login attempt, triggering the alert. OpenCanary may simulate a successful login for further interaction logging.
Lateral Movement (Attempted): If the attacker believes they have successfully authenticated, they may attempt lateral movement to other systems within the network.
Privilege Escalation (Attempted): The attacker could attempt to escalate privileges on the “compromised” system (OpenCanary) to gain further access.
Data Exfiltration/System Damage (Prevented): Because it’s a honeypot, OpenCanary prevents actual data exfiltration or system damage but logs all attempted actions for analysis.

Impact

An SSH connection attempt on an OpenCanary node, while not directly causing damage, indicates active reconnaissance or attempted unauthorized access within the network. The number of alerts generated can highlight the frequency of malicious scans targeting SSH services. Successful exploitation (simulated on the honeypot) could lead to lateral movement, privilege escalation, and data exfiltration if the attacker were to compromise a real system. This activity is valuable for understanding attacker behavior and improving overall security posture.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect SSH connection attempts to OpenCanary nodes, focusing on logtype: 4000.
Review OpenCanary logs in conjunction with other security logs (firewall, endpoint) to correlate the SSH attempts with other suspicious activities.
Investigate the source IP addresses from which SSH connection attempts originate to identify potential threat actors.
Consult the OpenCanary documentation to ensure proper configuration of the SSH service and logging capabilities.
Use network segmentation to limit the potential impact of a successful breach, even if only simulated on the OpenCanary node.

OpenCanary SSH Login Attempt Detection

hello@craftedsignal.io — Thu, 02 May 2024 14:30:00 +0000

OpenCanary is a low-interaction honeypot designed to detect attackers on a network. This brief focuses on detecting SSH login attempts on OpenCanary nodes, which are designed to mimic real SSH servers but log any interaction. While the OpenCanary project itself has been around for several years, its integration with modern detection strategies makes it a valuable tool for defenders. An SSH login attempt against an OpenCanary instance signifies that an attacker is actively scanning or attempting to compromise systems within the network. This activity might be part of a broader campaign, including lateral movement, privilege escalation, or data exfiltration. The detection of such attempts allows for timely incident response and mitigation.

Attack Chain

The attacker gains initial access to the network, possibly through phishing, exploiting a vulnerability, or compromised credentials.
The attacker performs network scanning to identify potential targets, including the OpenCanary node masquerading as a legitimate SSH server.
The attacker attempts to establish an SSH connection to the OpenCanary node, attempting to authenticate using various usernames and passwords.
The OpenCanary service logs the failed SSH login attempt, recording the source IP address and attempted credentials.
Security monitoring tools ingest the OpenCanary logs and trigger an alert based on the detected SSH login attempt.
Security analysts investigate the alert, analyzing the source IP address and other relevant information to determine the scope and severity of the potential breach.

Impact

A successful SSH login attempt on a real server could lead to complete system compromise, data exfiltration, and disruption of services. While OpenCanary is designed to be a honeypot, detecting login attempts early allows for proactive measures to prevent attackers from reaching critical assets. Identifying the attacker’s source IP address and attempted usernames can provide valuable insights into their tactics and objectives, preventing damage.

Recommendation

Deploy the Sigma rule “OpenCanary - SSH Login Attempt” to your SIEM to detect unauthorized SSH login attempts on OpenCanary nodes.
Investigate and block any identified malicious source IP addresses from network access using firewall rules.
Review OpenCanary configuration to ensure it is deployed in strategically valuable network segments (references: OpenCanary documentation).
Correlate OpenCanary alerts with other security events to identify potential broader attack campaigns.