A few days ago, I got the idea to deploy a public-facing honeypot.

A honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Generally, a honeypot consists of data (for example, in a network site) that appears to be a legitimate part of the site, but is actually isolated and monitored, and that seems to contain information or a resource of value to attackers, who are then blocked. - Wikipedia: Honeypot (computing)

The aim was to give this honeypot a public IP (which I wouldn't advertize) and see how much time it takes before some bot would detect it and try to hijack it.

For this experiment, I deployed a Debian VM on the Hetzner Cloud for €2.94 a month which is even cheaper than DigitalOcean's $5 a month VM. As a honeypot I opted for an open source project micheloosterhof/cowrie which I had to fork to cdemi/cowrie. The reason for this is that although cowrie supports posting to Elasticsearch, it didn't have any support for Ingest Plugins, specifically, the Ingest Geoip Processor Plugin.

Cowrie was configured to listen to SSH on Port 22 and Telnet on Port 23, this means that I had to install authbind to give permissions to run on these ports.

sudo apt-get install authbind
sudo touch /etc/authbind/byport/22
sudo chown cowrie:cowrie /etc/authbind/byport/22
sudo chmod 770 /etc/authbind/byport/22
sudo touch /etc/authbind/byport/23
sudo chown cowrie:cowrie /etc/authbind/byport/23
sudo chmod 770 /etc/authbind/byport/23

Because I had enhanced cowrie to support Elasticsearch Ingest Plugins, I could now add a new Pipeline:

PUT _ingest/pipeline/geoip
{
  "description" : "Add geoip info",
  "processors" : [
    {
      "geoip" : {
        "field" : "src_ip"
      }
    }
  ]
}

This GeoIP processor adds information about the geographical location of IP addresses, based on data from the Maxmind databases. This processor adds this information by default under the geoip field. The geoip processor can resolve both IPv4 and IPv6 addresses.

By adding a mapping to this index, Elasticsearch can identify the geoip field as a geo_point type. This will allow Kibana to display this on a Heatmap.

PUT _mapping/cowrie
{
  "cowrie": {
    "mappings": {
      "cowrie": {
        "properties": {
          "geoip": {
              "location": {
                "type": "geo_point"
              }
          }
        }
      }
    }
  }
}

After the service was setup, it was time to turn it on. In less than 5 minutes after turning it on, a bot had already tried to login over Telnet to this machine!

Unsurprisingly, most of the intrusion attempts came from China, Russia, Brazil, Japan and Korea.

Most of the attacks came over SSH, which is predictable since Telnet is practically an obsolete protocol and if you use it over the public internet, you should be shot.

An interesting observation is that the connection attempts to the Honeypot increased gradually. One theory for this is that the botnet that discovered the Honeypot could have started advertising the Honeypot to other attackers. Alternatively, it stands to reason that the more time the honeypot stays active, the increased likelihood to be discovered.

The most common username was, surprise surprise, root and admin. This goes to show how important it is to disable/rename your root and Administrator users.

Most of the commands being run on the Honeypot look like they are targeting IoT Devices (like Cameras, Routers, etc...) which run BusyBox. Most probably these are Hajime or Mirai botnets as their Reconnaissance phases are somewhat similar.

Some of the commands are sent in a blind attempt to navigate whatever vendor-specific command-line interface (CLI) the Telnet server implements. enable is a common CLI command to allow access to privileged-mode commands. system attempts to navigate to a menu of system-management options. shell and sh attempt to run a Bourne shell.

The /bin/busybox cat /proc/mounts; /bin/busybox ECCHI commands are the botnet probing the system to look for writable mounts where to download the first stage binary. Note the repeat of the venerable /bin/busybox ECCHI command, which serves a purpose not dissimilar to its use before: Hajime and Mirai both use the ECCHI: applet not found signature to find the end of the command line's output.

The IP Addresses where to download the binary from might be of unsuspecting victims that have encountered the botnet and not necessarily that of the attacker.

Another command that got my attention is cat /bin/echo. This command is used by the botnet so that it can inspect its header to determine the target's processor architecture. Once the target processor is determined, the botnet can execute the relevant binary.

Conclusion

The internet is a dangerous place. Within minutes of leaving a Honeypot on the public internet several botnets have discovered it and tried to claim it for their own. It's important to follow security best practices when exposing stuff over the internet. Some of which:

• Move your SSH, RDP to non-standard ports
• No Telnet!
• Consider putting all non-public listening ports (sshd, RDP, SNMP, rsyslogd etc.) behind a VPN (or SSH Tunnel)
• Try to use Key Authentication over SSH
• Disable/Rename root or Admin users.
• Badly made IoT Devices are very dangerous. Consider segregating them and firewalling them.