If we could define it in a few words, I would say that a honeypot is a sweet treat that is visible to the naked eye and ready to be bitten into at any time. In fact, it contains common services and vulnerabilities designed to attract the attention of attackers who want to conduct reconnaissance or possibly lateral movement within our system.

With this bait, once an attacker conducts reconnaissance activities such as scanning or brute force attacks, this information is promptly communicated to the victim, allowing the victim to take appropriate countermeasures and be aware of the presence of unwanted visitors.

These baits can be placed in any perimeter, such as a network or a network. In fact, for example, the latter network is more difficult to monitor and defend than others, which is clearly due to the type of connected devices.

Obviously, depending on where we place these probes, we must use the correct probes.

In fact, they can be imitations of other applications, simulating common services in the field, or other applications in the field, simulating systems or entities with known vulnerabilities.

How does a honeypot work?

Honeypots are designed to replicate real computer systems.

This can typically take the form of a login page, a business service or application that is commonly known and attractive to attackers, including simple credentials that are easy to exploit.

When an attacker logs in, the honeypot will detect such activity and immediately send an alert to or the security team, providing visibility and enabling behavior tracking.

This behavior could be a direct attack or a lateral movement targeting another compromised system that the victim is unaware of.

Types of honeypots

There are two main types of honeypot design:

Production honeypots are the most common type. This type collects cybersecurity data within an organization's production network with the aim of identifying compromise attempts and gathering data on cybercrimes, such as source addresses, traffic frequency, etc. Production honeypots act as decoys, disguising themselves by leveraging other legitimate systems and services within their network.

Researching honeypots typically collects more data than production honeypots, with the specific goal of gathering information about attackers' techniques.

Although enterprises typically use production honeypots, government and research organizations can use research honeypots.

Low and high interaction honeypots

Within these two categories, there are also different types of honeypots, each with varying levels of complexity.

Highly interactive honeypots run various real-world production systems designed to attract attackers. Research teams can use highly interactive honeypots to understand the tools used by attackers. However, high-interaction honeypots require significant time and effort to set up and maintain, making them unsuitable for smaller or less experienced teams.

Low-interaction honeypots are relatively easier to implement as they are more static environments. High-interaction honeypots are essentially like a real system, providing attackers with opportunities to interact with various services, while low-interaction honeypots offer attackers limited access to the operating system and simulate only a small number of services and protocols. Therefore, they are not as effective and thorough; instead, they are more useful for detecting less complex threats, such as bots, common scans, and reconnaissance.

Advantages of honeypots

Honeypots are among the most powerful detection mechanisms a network can have. Fully configured honeypots can help precisely detect and block network attacks.

The presence of alerts from the honeypot undeniably indicates the existence of an intrusion.

If we receive reports from these detectors, they would undoubtedly be indicative of a genuine attack, curious users, or planned security tests.

This also makes life more difficult for attackers. Honeypots often frustrate attackers by wasting their time on controlled assets, allowing victims to become aware of the ongoing activity and take appropriate countermeasures.

Disadvantages of honeypots

There are certain risks and limitations associated with using honeypots, especially if deployed improperly.

Sometimes they require hardware to implement, so they can be expensive. Although honeypots usually have limited resources, more complex honeypots, such as high-interaction and research honeypots, require hardware to be as realistic as possible.

Maintenance and configuration may require time, as configuring and managing honeypots demands significant time, effort, and expertise.

Let's start from scratch and create a real honeypot

Now we get to the point, and then move on to the practical part.

Even though they are rarely mentioned, there are many honeypots, and many of them are open-source projects. We can categorize them in this repository by domain and application:

【Software】Popular tools for creating honeypots

https://github.com/paralax/awesome-honeypots

In fact, we can find very specialized projects, for example, those specifically targeting certain types of networks, such as verticalization on the network.

In our example, we will use a low-interaction honeypot that will simulate common ports exposed on servers, such as those that could be used to penetrate certain critical subnets within our network, like the subnets for servers or .

Ports are definitely customizable, and some ports that can be simulated and monitored are:

Git:  9418

Ftp:  21

Http:  80

Https:  443

Squid:  8080

Mysql:  3306

Ssh:  22

Redis:  6379

Rdp:  3389

Sip:  5060

Snmp:  161

Ntp:  123

Tftp:  69

Tcp banner:  8001

Telnet:  23

Microsoft SQL Server:  1433

Vnc:  5000

What is needed to create this lab:

Installing the virtual machine.

A machine with logs installation will be received soon, simply follow this guide:

https://documentation.wazuh.com/current/quickstart.html

installation

As mentioned earlier, it is an open-source multi-protocol network honeypot.

https://github.com/thinkst/opencanary

No integrated alerting tools will be provided, only detection logs will be offered, which will populate in their own logs, which we connect to, a (more precisely, it is a ), where we collect this information data, and then even display it in a simple dashboard.

According to , we execute the following commands to install the necessary software packages and install :

sudo apt-get install python3-dev python3-pip python3-virtualenv python3-venv python3-scapy libssl-dev libpcap-dev``virtualenv env/``. env/bin/activate``pip install opencanary

If we want to activate file sharing and the module later, we also need to install these packages:

sudo apt install samba``pip install scapy pcapy-ng

Let's create the initial configuration

opencanaryd --copyconfig

Using this command will create a configuration file at the following path:

/etc/opencanaryd/opencanary.conf

By opening it, we can enable modules one by one, setting the "." as shown:

Please note that the first parameter . will be used later to identify if there are multiple detectors. In this example, I have configured everything to be able to use numbers, such as -, -, etc...

In this document, we can also customize log files, but it is not mandatory.

Note: To activate the module, no other services should be using the configured port. For example, if you want to monitor access, you need to change the real standard port.

Now we can start the program using the following command when it is not running:

. env/bin/activate``opencanaryd --start

We can directly check by looking at the already open ports.

If we enable it, we can access the server over the network for quick testing. There will be fake access to it, which is a very tempting target for anyone who discovers it on the network (is there a backup?).

For example, the graphical interface can be fully customized to simulate different portals. If we attempt to log in using any credentials now, the activity will be reported to the following file.

\var\tmp\opencanary.log

The following log is generated by default:

{“dst_host”：“192.168.50.131”，“dst_port”：80，“local_time”：“2024-10-04 13:21:09.282481”，“local_time_adjusted”：“2024-10-04 13:21:09.282929” ,”logdata”:{“HOSTNAME”:”192.168.50.131”,”PATH”:”/index.html”,”SKIN”:”nasLogin”,”USERAGENT”:”Mozilla/5.0 (兼容; Nmap 脚本引擎; https://nmap.org/book/nse.html)”},”logtype”:3000,”node_id”:”opencanary-1”,”src_host”:”192.168.50.133”,”src_port”:52362,” utc_time”:”2024-10-04 13:21:09.282890”}

The main values are (indicating the company from which the alert originates), (indicating where the attack began), and.

The last value is not well documented, but it identifies some active groups.

Analyzing the data received from the sample test can have the following implications:

Open the web application

Network Scanning

Login Attempt

Proxy Configuration

As a prerequisite, we point out the necessity of preparing for installation, whether it is clean or already in use.

Therefore, on the machine, we will use the following command to install its agent:

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.8.0-1_amd64.deb && sudo WAZUH_MANAGER='192.168.50.137' WAZUH_AGENT_NAME='OpenCanary' dpkg -i ./wazuh-agent_4.8.0-1_amd64.deb

Among them, the manager is the server.

After installation, add this code to the end of the configuration file, which will allow the proxy to monitor. This file will be populated:

/var/ossec/etc/ossec.conf

You can find references here:

https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/index.html

So we will eventually end up with such a configuration:

Let's save and start/restart the proxy service.

Restart -

Server Configuration

Finally, let's now configure to collect logs and view them in the dashboard, as we mentioned, the project does not integrate any alerts.

Fortunately, a file will be generated under the path of the detection log, as shown in the following example.

There is already a "rule" and a "decoder" in place to capture data in this format.

The only thing we need to do is to import the data after it is acquired, so we need to set the alert level.

Then access the role from the dashboard

Local rules added to.

This configuration:

According to the document with custom rules, the rule has been placed above, but it is necessary to check whether a rule with the same has not yet been inserted.

Custom Rules Reference:

https ://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html

Now testing the rules again, we can see that it has been correctly filtered, and once this event is generated, it will be imported.

In this example, I simply cataloged all events that have been defined. You can also categorize events by setting different descriptions and levels for each event.

Finally, let's test how it works

At this point, we can attempt to use scanning services and generate reconnaissance and brute force tasks.

First, we analyze the ports and the open and active services. We can see that the open ports seen above are detected and identified by.

However, by conducting more invasive scans, we can activate as many alarms as possible.

Finally, we can detect these alerts through the discovery function.

At this point, we can visualize these anomalous activities from the detector graphically, as shown in the following example.

I started creating simple dashboards on the fly with the data I obtained, making the visibility of these events easier and more straightforward.

In this article, we mentioned what honeypots are and their purposes, and also presented a practical use case.

Due to the very few false alarms generated by these devices and the general lack of interest in accessing them as mentioned above, they are indeed very useful in detecting suspicious activities within a computer network.