This article details the process of integrating a honeypot, specifically the Teapot universal honeypot project, with the Wazuh security monitoring platform. The objective is to centralize honeypot alerts and logs within a Wazuh instance, enabling comprehensive analysis and alerting through an Elasticsearch cluster.

Honeypot Setup and Log Sources

The Teapot honeypot, available on GitHub, serves as a versatile tool for collecting malware, Advanced Persistent Threat (APT) group information, and detecting internal network reconnaissance. Two primary log sources from the Teapot honeypot are targeted for integration:

1. Suricata Alerts: The data/suricata/eve.json file logs network intrusion detection system (NIDS) events. These alerts can indicate malicious certificates, web application attacks, and other network-level threats detected by Suricata.
2. Cowrie Logs: The data/cowrie/cowrie.json file records SSH login attempts. This is particularly useful for identifying internal actors attempting unauthorized access to network resources.

Wazuh Agent Configuration and Deployment

To ingest these logs into Wazuh, a Wazuh agent must be installed on the honeypot server. The configuration involves defining a log collection stanza within the Wazuh agent's configuration file (ossec.conf).

The configuration specifies:

• Log Format: json to ensure proper parsing of the log data.
• Log File Paths:
  • data/cowrie/cowrie.json for Cowrie SSH logs.
  • data/suricata/eve.json for Suricata alerts.

The Wazuh agent is then deployed to the honeypot server. During installation, the agent typically generates a random hostname. It is recommended to modify this hostname in /etc/hostname to align with the organization's naming conventions, making the honeypot less conspicuous.

Wazuh Manager Rule Creation

After the agent is deployed and communicating with the Wazuh manager, custom rules are created on the manager to process and trigger alerts based on the ingested honeypot logs. These rules are managed under Management > Rules > Custom Rules.

The rule structure includes:

• Suricata Alert Rules:

  • A primary rule is established to identify Suricata alerts by referencing the default Suricata rule ID (86601).
  • To differentiate alerts from multiple honeypots, an additional condition is added to match the specific agent.name of the honeypot. This allows for grouping alerts per honeypot.
  • Subsequent rules are designed to trigger based on the alert.severity field within Suricata alerts. Severities are categorized as:
    • Severity 1 (Highest)
    • Severity 2
    • Severity 3 (Lowest)
  • These rules extract details such as the alert signature, source IP, and destination IP.

• Cowrie Log Rules:

  • A rule is created to decode the cowrie.json log as JSON.
  • It specifically looks for events where the event_id field matches "cowrie.login.failed". This rule captures failed SSH login attempts.
  • The rule then extracts relevant information, including the username and password used in the attempt.

Rule Testing and Alert Verification

Wazuh's rule testing feature is utilized to validate the custom rules.

• Cowrie Rule Test: A test is performed for the Cowrie login failed rule, which successfully identifies a login attempt with the username "user" and password "please subscribe."
• Suricata Rule Test: Testing the Suricata rules may initially trigger the generic Suricata alert ID (86601) if the agent name condition is not met during the test.

To verify the rules in practice, the system monitors the Wazuh manager's security events.

• Suricata Alerts: Alerts for network scans, such as Nmap scans against the honeypot, are observed. The custom rules ensure that source and destination IP addresses are captured and included in the alert descriptions.
• Cowrie Alerts: To generate a Cowrie alert, an SSH connection is made to the honeypot's port 22 using the username "open secure" and password "please subscribe." This attempt is logged, and the details, including the source IP address, are stored in Elasticsearch.

Important Note on Cowrie Logs: The Cowrie honeypot replicates SSH services and logs usernames and passwords in clear text. For internal deployments, it is crucial to inform operations teams that any legitimate SSH access attempts to port 22 will be logged. Legitimate SSH access to the honeypot server itself is available on port 64295.

Centralized Logging and Alerting Benefits

By integrating honeypot logs into Wazuh, organizations can:

• Centralize Security Data: Consolidate alerts from honeypots into a single Security Information and Event Management (SIEM) stack, eliminating the need for separate log management systems (like an independent ELK stack for the honeypot).
• Enhance Threat Detection: Leverage Wazuh's rule engine to trigger alerts based on specific honeypot activities.
• Facilitate Incident Response: Use the collected data to pivot across internal network alerts, correlating honeypot activity with other security events.
• Automate Outbound Alerting: Configure Wazuh to send notifications (e.g., emails) to security teams for critical honeypot alerts, such as Suricata severity one events.

This integration streamlines security operations by providing a unified view of potential threats detected by the honeypot within the broader security monitoring framework.