# Gotta catch ’em all: a Multistage Framework for honeypot fingerprinting

Shreyas Srinivasa
Department of Electronic Systems
Aalborg University
Copenhagen, 2450
<EMAIL_ADDRESS>
&Jens Myrup Pedersen
Department of Electronic Systems
Aalborg University
Copenhagen, 2450
<EMAIL_ADDRESS>
&Emmanouil Vasilomanolakis
Department of Electronic Systems
Aalborg University
Copenhagen, 2450
<EMAIL_ADDRESS>

###### Abstract

Honeypots are decoy systems that lure attackers by presenting them with a
seemingly vulnerable system. They provide an early detection mechanism as well
as a method for learning how adversaries work and think. However, over the
last years a number of researchers have shown methods for fingerprinting
honeypots. This significantly decreases the value of a honeypot; if an
attacker is able to recognize the existence of such a system, they can evade
it. In this article, we revisit the honeypot identification field, by
providing a holistic framework that includes state of the art and novel
fingerprinting components. We decrease the probability of false positives by
proposing a rigid multi-step approach for labeling a system as a honeypot. We
perform extensive scans covering $2.9$ billion addresses of the IPv4 space and
identify a total of $21,855$ honeypot instances. Moreover, we present a number
of interesting side-findings such as the identification of more than $354,431$
non-honeypot systems that represent potentially vulnerable servers (e.g. SSH
servers with default password configurations and vulnerable versions). Lastly,
we discuss countermeasures against honeypot fingerprinting techniques.

_Keywords_ Honeypots $\cdot$ Honeypot Fingerprinting

##  1 Introduction

Honeypots are decoy systems whose only value lies in being probed, attacked,
and compromised. They attempt to lure attackers in, to provide an early
warning system, and act as a method for understanding the adversaries’ mindset
and determining new attack trends [34]. Honeypots are not a stand alone
security mechanism but rather important supplements to existing infrastructure
(e.g. firewalls and Intrusion Detection Systems (IDS)). Nevertheless, they
offer a unique attack understanding and perspective, while exhibiting a very
low number of false positives. The latter is due to the fact that any
communication towards a honeypot is considered hostile; i.e. benign users have
no reason to contact a honeypot.

Honeypots are commonly classified based on the interaction level they offer to
the adversary. This results in low-, medium- and high- interaction honeypots
[26]. While the first two categories offer different levels of emulation of
protocols, the latter (i.e. high-interaction) describes real world systems.
High-interaction honeypots are too expensive to maintain and significantly
less used than low/medium interaction; hence, we consider them out of the
scope of this article. Over the years, low and medium interaction honeypots
have been designed and developed to emulate the majority of commonly used
protocols. These include SSH (e.g. Kippo [10] and Cowrie [27]), Telnet (e.g.
Cowrie [27]), HTTP (e.g. Glastopf [31]), FTP, SMB (e.g. Dionaea [37] and
HosTaGe [40]) and also Industrial Control Systems (ICS)protocols like Modbus
and S7 (e.g. Conpot [32] and HosTaGe [41]).

One of the key success criteria for a honeypot is that it is indistinguishable
from a real system. This can be translated to the following axiom: if a
honeypot can be easily identified as such, then its value is significantly
decreased. The reason for this is that an adversary can potentially either
evade honeypots (e.g. perform reconnaissance and add a blocklist of IP
addresses into their malware, to avoid honeypots and reduce the risk of
detection [49]) or attempt to take them down (e.g. via a Distributed Denial of
Service (DDoS)attack). Note that modern malware (e.g. Hide’n Seek [6]) already
include hard-coded IP addresses (e.g. belonging to known security agencies)
that are blocklisted from all communications. Honeypot fingerprinting is the
process of revealing that a seemingly vulnerable system is, in fact, a
honeypot.

In this article, we perform a comprehensive analysis of honeypot
fingerprinting techniques. For this, we present a holistic framework that
includes a number of novel fingerprinting methods along with all major state
of the art techniques. Among others, we propose a new protocol handshake
fingerprinting component, a static Transport Layer Security (TLS)certificate
method and a Fully Qualified Domain Name (FQDN)check. Furthermore, we present
the results of extensive honeypot identification scans over the Internet for
$9$ prominent honeypot implementations. Our results come as an independent
confirmation of previous studies ([42, 25]) but also as a step forward to a
more holistic study of honeypots. In particular, due to the multistage checks
that our framework performs, we argue that the presented results have a very
low probability for false positives. Moreover, we present several insights for
IP addresses that are not marked as honeypots, but are likely to be real
vulnerable systems. Lastly, we discuss ethical considerations and possible
countermeasures against fingerprinting. The core contributions of this article
can be summarized as follows:

  * •

We present novel methods for active honeypot fingerprinting (so-called probe-
based). These are combined with a number of SotA and third-party (so-called
meta-scan) fingerprinting techniques in the form of a multistage
fingerprinting framework. We scan $2.9$ billion IP addresses of the IPv4
space, discover $187$ million IP addresses with relevant open ports and
identify a total of 21,855 honeypots.

  * •

We showcase that out of the 21,855 identified honeypots, third-party
techniques can only reveal $33.9\%$ of the total honeypot population. On the
contrary, we show that $100\%$ of the honeypots can be detected via our probe-
based methodology.

  * •

As a side finding, we identify more than $260,000$ non-honeypot entities (i.e.
SSH and FTP servers) that appear to use trivial passwords and/or are
susceptible to high-severity vulnerabilities.

The rest of the article is structured as follows. We propose our framework for
honeypot fingerprinting in Section 2. Section 3 presents our evaluation.
Section 4 discusses ethical considerations, fingerprinting countermeasures and
the limitations. Section 5 presents the related work on honeypot
fingerprinting research. We conclude the article in Section 6.

##  2 Multistage Honeypot Fingerprinting Framework

Researchers classify fingerprinting techniques as active and passive, based on
attacker-honeypot interaction [35]. Active-fingerprinting involves creating
specific probes and using them to querying the target system to collect as
much data possible. On the contrary, passive-fingerprinting makes use of
available data about the target system for further analysis to determine
information about the target.

In the following, we attempt to examine methods in both the active and passive
spectrum in Section 2.1 . On the one hand, we assume that attackers prefer
passive methods since they come with multiple benefits. Mainly, they are
stealthier (i.e. no direct communication to the honeypot is needed) and easier
to use (e.g. systems like Shodan [33] already exist and offer an Application
Programming Interface (API)for such purposes). On the other hand, our
hypothesis is that active approaches can identify a much broader set of
honeypots. We propose the novel framework (see Section 2.2) that utilizes both
active and passive fingerprinting techniques to fingerprint honeypots deployed
on the Internet. The aim of the proposed framework is to systematically
fingerprint honeypots with multiple sequential checks to reduce false
positives. In comparison to state of the art (c.f. Section 5), we employ novel
probing methods that include certificate checks, protocol handshake and
metascan methods that check for Internet Service Provider (ISP)and cloud
hosting information. The framework is further automated for all the checks
involved in each fingerprinting technique that helps in automated transition
to stages during the scanning process.

###  2.1 Overview

This section provides an overview of the proposed multistage fingerprinting
framework and the detection techniques.

####  2.1.1 Probe-based fingerprinting

Probe-based fingerprinting involves the creation of queries to derive
fingerprinting information and involves direct interaction with a system.
These methods focus on leveraging the data from responses and classifying the
target machine based on fingerprinting identifiers. The information may
include system-specific unique identifiers like the Initial Congestion Window
(ICW)or the Retransmission Time Out (RTO). Several fingerprinting tools like
NMap [23], XProbe2 [3], Metasploit [20], and Hydra [38] utilize probe-based
methods to determine the Operating System (OS)and the protocol versions of the
target systems. For example, these tools rely on banners advertised and the
Transmission Control Protocol (TCP) header information to determine the
underlying OS. The database of the scanning tool stores the identifiers that
are specific to some OS. The identifiers help compare parameter values
obtained through probing for determining the OS. The fingerprinting probes
derive multilevel system information at network-level, application-level, and
the system-level. The integration of the information received from different
levels improves detection accuracy.

Figure 1: Multistage Framework for Honeypot Fingerprinting

####  2.1.2 Metascan-based fingerprinting

Metascan-based fingerprinting is a form of passive-fingerprinting that
leverages the known information about the target system without direct
interaction. The technique uses the IP address and performs a search on
Internet mass-scan engines (e.g. Shodan [33] and Censys [11]) to obtain
attributes like hosting provider and the Internet Service Provider (ISP). The
data obtained through metascan can be leveraged for fingerprinting purposes.
For example, if the target system has the TCP port $502$ (i.e. the Modbus
protocol default port) open and the IP address is attached with a network
assigned to a university or research facility, this might act as an indication
that the target system is a research honeypot. Similarly, if a cloud provider
hosts the aforesaid system, it is likely a honeypot because ICS are physical
devices that are deployed in an industrial network and are unlikely to be
hosted by a cloud provider.

Mass-scan engines like Shodan and Censys crawl the Internet IP-space daily to
find vulnerable systems exposed to the Internet. They also store system- and
network-specific information about the exposed systems like banners, HTTP
content, certificate, open ports, and services. Furthermore, they provide
metadata like the ISP, Autonomous Systems (AS), and geo-location of the
systems. Metascan fingerprinting techniques rely on essential information
about target systems for the fingerprinting process. Such information can be
obtained through the APIs offered by Shodan and Censys. Hence, the mass-scan
engines can act as a substitute for the probe-based checks and provide the
information required without interacting with the target systems.

###  2.2 Framework

We construct a framework that combines both probe- and metascan-based
methodologies. The framework is automated for the sequential checks for the
probe-based and the metascan-based techniques. The probe-based technique uses
methods that involve direct interaction with the target machine to fetch
fingerprinting-information, while the metascan-based techniques use methods
that involve no direct interaction with the target systems. In particular, the
latter uses information derived from the Shodan and Censys mass-scan engines.
Some mass-scan engines employ banner-based fingerprinting to fingerprint
device types. For example, Censys [11] uses the Recog engine [30] to detect
device types using the information received by probing. The methods used in
the proposed metascan pipeline are novel specifically towards honeypot
fingerprinting. The novel methods of using the information about the ISP and
checking if the instance is on a cloud environment assist us in gathering
additional information that can be leveraged for the fingerprinting process.
In addition, these methods help in reducing of false positives from the
results. We term the target system considered for fingerprinting as an
instance for the rest of our article.

Figure 1 shows the proposed multistage fingerprinting framework. The framework
contains two independent main pipelines of Probe-based and the Metascan-based
techniques. The Probe-based Pipeline has multiple stages that are represented
as boxes in the figure, with each stage aiming at fingerprinting the instance
at various levels (i.e. network-level, application-level, system-level,
protocol-level, implementation-level, and configuration-level). The boxes are
color-coded to gray and green for further classification. The gray boxes
denote that the stages refer to the state of the art, while the green boxes
represent the novel methods. The novel methods are comprised of persistent
checks that enrich the likelihood of the instance to be a honeypot. In the
Metascan-based Pipeline, the stages represent systematic checks referring to
passive-fingerprinting techniques and data analysis. Overall, an instance is
only labeled as a honeypot if all (relevant) components of the respective
pipeline concur.

####  2.2.1 Probe-based Fingerprinting Pipeline

The Probe-based fingerprinting pipeline consists of seven probing stages. The
instances under evaluation transition into the next stage, based on the
underlying application service protocol. The probes from each stage fetch
information which is then analyzed to derive whether the instance is a
honeypot.

##### Portscan

The pipeline begins by performing a scan on the Internet for open ports
specific to the services emulated by the honeypots. Our framework utilizes
ZMap [12] for this process (alternatively one could use Masscan [16]). The
search results consist of a list of instances having these ports open to the
Internet.

##### Banner Check

The results of the portscan are further processed in the banner check stage.
In this stage, the probes check the banner advertised by the end system with
static banners offered by honeypot implementations. Honeypot implementations
offer a limited set of banners or even static banners that, in some cases, do
not match the actual banners advertised by the services running on the
underlying OS. As these banners are hard-coded, they can be matched against a
list of known honeypot banners. We use the extended banner grab utility
offered by ZMap to fetch banners from instances [48]. SotA honeypot
fingerprinting techniques by Vetterl et al. [42] and Morishita et al. [25]
employ banner based fingerprinting to detect honeypots. We combine this
knowledge (see Table 10 in the Appendix) to construct a holistic banner list
for our framework. The results of this stage provide us with a list of
instances and their banners. The instances that match the banners advertised
by honeypots progress into the next stage based on the underlying protocol.
For the instances that do not match the banners, we perform a vulnerability
check that determines the number of vulnerable systems on the Internet with
specific protocol versions (see Section 3.3.4 in the evaluation).
Fingerprinting honeypots only with banner checks is prone to false positives,
and therefore, we subject the instances to further protocol level and system-
level checks.

#####  HTTP Static Response

The filtered instances with HTTP and HTTPS service identified in previous
stages are checked for static HTTP content in their response. Honeypots
emulating the web services offer limited content by default which can be
identified. The instances are queried with an HTTP GET request to fetch the
content and then match the static default content offered by the honeypots.
Table 11 in the Appendix shows the HTTP response returned by honeypots. Upon
match of static content, the instance continues to the next stage. This
technique was adapted from [42, 25] for fingerprinting HTTP-based honeypots.

##### SSL/TLS Certificate check

This stage compares certificate-specific attributes to known values from
default certificates provided by honeypots. Some honeypots offer hard-coded
TLS certificates that can be leveraged to fingerprint honeypot instances.
Though there is a change of fingerprint on each certificate, attributes like
issuer and provider remain static. For example, the Dionaea honeypot contains
a certificate issued by a provider name that is consistent in all its
deployments [28]. The SSL/TLS Certificate check component stage checks the
attributes certificate issuer and the common subject name of the certificate
retrieved from web servers to identify Dionaea honeypots on the Internet.
Algorithm 1, in the Appendix, represents the pseudo-code block that checks an
instance for Dionaea’s default certificate parameters.

##### Protocol Handshake

The communication of systems over any network is established upon the
negotiation of various communication parameters, before building a channel.
Honeypots offer limited emulation and communication preferences. This
limitation is caused due to the honeypot design or the utilization of certain
protocol emulation libraries. We exploit this limitation of deviated behavior,
in the protocol negotiation process, to identify honeypots. First, we observe
the deviation in the negotiation process and the limited availability of
parameters by establishing communication with in-house lab honeypots (see
Section 3.2). We develop probes that attempt to establish a connection through
limited parameters and observe the response for deviation for all emulated
services. Table 1 summarizes the responses for certain negotiations of
protocols. We observe protocol handshake deviations that cause the acceptance
of malformed request packets, return limited options for negotiation, or
disconnect the session with an arbitrary message that is different from non-
honeypot implementations. Algorithm 4 in the Appendix describes the protocol
handshake checks. The algorithm accepts a list of instances with their IP
address and port. For each instance, a request is sent for session initiation
with specific parameters. The response is analyzed for deviations that match
the response from honeypots. Upon match, the flag isDeviated is set and such
instances progress to the next framework stage.

Honeypot | Protocol | Request | Response
---|---|---|---
Kippo | SSH |  | SSH-2.0-OpenSSH \n\n\n\n\n\n\n\n\n\n
---
| "bad packet length *" or
---
"protocol mismatch\n"
Cowrie | SSH |  | 1\. SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2 \n
---
2\. SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2 \n
"protocol mismatch\n"
Gaspot | Telnet | I30100 | 9999FF1B
Conpot | S7 |  | "H", "0300002102f0803207000000000008 \n
---
00080001120411440100ff09000400110001"\n
0x32
Conpot | Modbus |  | function_code’: None, ’slave_id’: 0, \n
---
’request’: ’000000000005002b0e0200’ \n
Disconnection
Glastopf | HTTP | GET /HTTP/1.0 | Server: BaseHTTP/0.3 Python/2.5.1
Dionaea | HTTP | GET /HTTP/1.0 | Server: nginx
Amun | HTTP | GET HTTP/1.1 | Server: Apache/1.3.29
MTPot | Telnet | WILL (251) Linemode | Won’t (252) Linemode
Table 1: Protocol handshake deviation

##### Library Dependency Check

Emulations in low and medium-interaction honeypots are often developed by
referring to external libraries. Libraries offer limited emulation
capabilities based on their design and frequently return static values in
certain queries. Furthermore, some libraries referred by honeypots have not
been well maintained. Vetterl et al. have leveraged the use of libraries in
honeypots to craft specific probes that return static values [42]. This static
information can be used to fingerprint the honeypots. Table 2 shows the
libraries used by many well-known honeypots for the service emulation and
their last update. Leveraging the aforementioned static implementation and
limited emulation, we develop the probes based on [42] that request for
specific information from the end-systems. We compare the response to known
static responses from the honeypots. We proceed in case of a match. In
honeypots, protocol handshake is also dependent on the library used for
emulation purposes and hence these two stages are intertwined. Nevertheless,
we use this check to check for additional dependencies that can signal static
behavior.

Honeypot | Protocol | Library | Updated
---|---|---|---
Kippo | SSH | TwistedConch | May2015
Cowrie | SSH | TwistedConch | May2018
MTPot | Telnet | telnetsrv | Dec2012
Cowrie | Telnet | TwistedConch | May2018
Dionaea | HTTP | custom | Sep2016
Glastopf | HTTP | BaseHTTPServer | Oct2016
Conpot | HTTP | BaseHTTPServer | Mar2018
Table 2: Library references in honeypots

##### Static Command Response

Due to the nature of honeypots, developers are compelled to implement some
services with static responses or disconnect the communication for specific
command requests. For instance, some honeypots attempt to overcome such issues
via a static response (e.g. "Invalid Command"), or disconnect with the user.
We leverage this gap in implementation for having probes request systems with
commands to expect known static responses from the end systems. Table 14 shows
the static response returned by honeypots for specific commands by our probes.

####  2.2.2 Metascan-based Fingerprinting Pipeline

Metascan-based techniques aim at honeypot detection using passive-
fingerprinting techniques. Our framework uses information available through
Shodan and Censys to determine if an instance is a honeypot. The metascan-
pipeline consists of four stages based on the underlying protocol. Although
some SotA, e.g. [25], have used mass-scan engines to search for honeypot
signatures, we use persistent checks in our stages to assure that the instance
is a honeypot. We use checks to determine if the network belongs to a research
facility, has an identified domain attached to it, or if the instance is on a
cloud infrastructure. This information helps to further distinguish the
honeypots by analyzing operational parameters.

##### Shodan and Censys Search

Contrary to the probe-based scanning that requires us to use a tool to perform
the scan, we leverage the available data from Shodan and Censys that perform
the scans daily. We search the platforms for systems with open ports
concerning the services emulated by honeypots in our tests. The result of the
search provides a list of instances that undergo further fingerprinting
process. Both Shodan and Censys provide API s for querying their databases.
Algorithm 3 in the Appendix shows the procedure for the search performed on
Shodan and Censys. The search results return an IP address and port, for the
identified instances.

##### Keyword Search

Shodan and Censys store information about the systems exposed to the Internet
that include banners, web content, protocol negotiation parameters, and more.
In addition to system-specific information, they also provide metadata about
the IP address allocated to the system like geo-location, ISP/AS and the
hosting provider. The degree of information and the format available on these
databases vary based on the techniques followed by the mass-scan engine. We
leverage such information to filter the instances obtained in the previous
step. The search is performed with keywords identified from the probe-based
stages like static content, banners, and protocol negotiations. Table 13 shows
the used keyword parameters for filtering instances in Shodan and Censys. The
resulting data contains a list of instances of systems with specific ports and
matching filtered criteria.

#####  ISP and AS Check

Honeypots are also classified based on their usage in research and production
environments. Research organizations deploy honeypots to gather attack-data
for threat intelligence research. Enterprise systems deploy honeypots for
proactive attack detection. Following the previous stages, we examine whether
the instance is part of a research organization or an institute. It is also
possible that an enterprise company may be hosting a production honeypot with
an unassigned domain. For instance, the honeypots deployed in our lab lie
under the university AS while they do not have a domain registered to them. To
cope with this, this component checks the WHOIS database to search for
information about the network to which the system is attached to.

##### Cloud Hosting Check

Cloud infrastructure enables defenders to set up and deploy honeypots on cloud
environments to easily gather attack-data. Many honeypot developers offer a
container-based configuration of honeypots for easy installation and
deployment. As a result, many honeypot instances can be found in cloud
instances. We argue that many honeypots are deployed in cloud environments
though they are logically invalid for the emulated infrastructure. For
example, we find many instances of Conpot, an ICS based honeypot, which
emulates industrial cyber-physical systems. However, it is improbable to find
ICS devices on cloud networks. This component checks whether instances related
to specific ICS protocols (i.e. Modbus and S7) are deployed on a cloud
infrastructure.

####  2.2.3 Fully Qualified Domain Name (FQDN) Check

A FQDN is allocated to an Internet-facing system to avoid memorization of the
IP addresses. We perform a check to examine whether the identified instances
from both pipelines have an assigned Domain Name Service (DNS)domain. Honeypot
systems, by design, are fake systems and are unlikely to have domain names
allocated as it is risky for the organizations deploying them. For instance,
an attacker may claim to have found a vulnerable or compromised system
belonging to an enterprise domain, resulting in negative publicity for an
organization. Therefore, administrators, in principle, avoid assigning a
domain/DNS for the honeypots. We utilize this understanding of the
administrators and filter the IP addresses received from the IP pool to find
systems without domain names assigned. The IP addresses that do not have a DNS
are transitioned to the next state. The FQDN check differs from the AS check,
in a way that it checks for any domain associated with the IP address, while
the AS check performs a lookup of the IP address allocation by the AS to an
entity. The information about the AS and the ISP helps in identifying the type
of entity, for example, a research organization or honeypot instance in a
production network of an organization.

####  2.2.4 Framework Output

The output state of the framework provides a list of instances that are
inferred as honeypots from our fingerprinting framework. The list contains
instances from both the probe-based and the metascan-based honeypots.

##  3 Evaluation

We evaluate the ability of the proposed multistage honeypot fingerprinting
framework in discovering honeypots. The evaluation considers nine honeypot
implementations and specifically focuses on nine protocols as listed in Table
3. The choice of honeypots is based on a number of factors. First, these
honeypots are considered some of the most popular ones and most frequently
deployed (see e.g. the ENISA recommendations in [17]). Moreover, these
represent the honeypots examined in the majority of the related work (cf.
Section 5), which provides us the ability to make some comparisons (e.g. with
[42, 25, 47]). Lastly, all of the selected honeypots are open-source
implementations.

Our main goal is to examine how many honeypots the framework can identify. We
highlight here that the absence of ground truth data for honeypots is a known
problem in the field. However, we argue that the multistage nature of the
framework highly reduces the probability for false positives (we further
discuss this issue in Section 3.4). In addition, we want to determine the
relation between the probe-based and metascan-based detection. Our hypothesis
is that the probe-based pipeline should produce significantly better results.
Still, the question of whether the metascan pipeline can identify honeypots
beyond the ones already identified via the probe-based methods is an open
question that we will attempt to answer. Lastly, we are interested in further
examining encounters with IP addresses that pass some, but not all, of our
tests. We believe that these systems might be vulnerable ones, which can
easily be exploited by adversaries.

###  3.1 Lab environment tests

First, we deploy all the honeypot implementations (see Table 3) in a lab
environment and test all probes which are implemented to collect state-
specific information like banners, static content, protocol handshake and
static command responses. We confirm that honeypots test positive for all the
different modules (see Figure 1) of the probe-based phase. Following these
tests, we evaluate the multistage framework against the known honeypot
instances in the lab environment. All the honeypot instances were successfully
detected by our framework.

Honeypots | Ports & Services | Version
---|---|---
Kippo |  | Ports:22/2222
---
Services: SSH
0.9
Cowrie |  | Ports: 22/2222 23/2323
---
Services: SSH, Telnet
2.1.0
Glastopf |  | Ports: 80, 8080
---
Services: HTTP
3.1.2
Dionaea |  | Ports: 80, 443, 21
---
Services: HTTP, FTP
0.9.0
Nepenthes |  | Ports: 21
---
Services: FTP
0.2.2
Amun |  | Ports: 23,21,80,36,143
---
Services: Telnet, FTP, HTTP, SMTP, IMAP
0.2.3
Conpot |  | Ports: 80, 502, 102
---
Services: HTTP, Modbus, S7
0.5.2
Gaspot |  | Ports: 100001
---
Services: ATG
base [46]
MTPot |  | Ports: 23
---
Services: Telnet
base [8]
Table 3: Honeypots tested in our internal lab environment

###  3.2 Evaluation Setup

After performing the aforesaid experiments, we are now ready to perform an
Internet-wide scan. We use the ZMap tool as our scanning tool [12] to scan a
total of $2.9$ billion IP addresses111ZMap excludes a number of IP addresses
from its scan by default; these include reserved and unallocated IP space..
Our tests follow the flow of Figure 1. That is, we first perform a probe-based
scan and afterwards perform an independent metascan by making use of Shodan
and Censys [33, 11]. Our experiments were conducted in a period of six months.
The experiment is carried out as $3$ scanning periods, for the entire-
framework. The metascan-based approach was relatively faster to perform the
search and analysis, although Shodan and Censys enforce rate limiting on the
API requests. Over a period of six months, we conducted three iterations. The
results depicted in the following sections provide a summation of all the
unique honeypot instances identified from the three scan iterations.

We, once more, highlight that this article does not take into account high
interaction honeypots. This is due to the very different characteristics of
high interaction honeypots (i.e. real systems instead of emulated ones); in
fact, this is the case with all the SotA (e.g. [42, 25, 47]). Hence, both our
article as well as all existing related work are prone to false negatives.

###  3.3 Results

By firstly performing a ZMap scan, we derive Table 4 that shows the number of
identified systems (not necessarily honeypots) on the Internet that exhibit
relevant open ports. Subsequently, the framework performs the various checks
shown in Figure 1.

Protocol | Port |  | No. of Systems on the
---
Internet (in Million)
HTTP |  | 80,8080,
---
8888
67.31
HTTPS | 443 | 56.06
SSH | 22 | 18.65
FTP | 21 | 10.39
SMTP | 25 | 7.71
Telnet | 23 | 5.27
Table 4: Number of identified instances and protocols/ports

####  3.3.1 Honeypot identification

Overall, the framework detected a total of $21,855$ honeypots. Figure 2 shows
the honeypot instances detected over three sequential scans over a period of
$6$ months. Figure 2 also depicts the change in honeypot instances detected
over the $3$ scans. The instances of honeypots Gaspot, Conpot and Amun (HTTP)
were detected more in the third scan while the others remained constant or
reduced. This could be because of honeypots instances undergoing either a
churn or because they were simply blocked/offline. We discuss this further in
Section 3.4. The metascan-based technique has identified $7,410$ unique
honeypots and the remaining $14,246$ were detected by the probe-based
technique. Figure 3 summarizes the honeypots detected by probe-based and
metascan-based approaches for each honeypot. The numbers on the bars indicate
the unique instances detected by the approaches and scans. An interesting
finding is that all IP addresses identified as honeypots by the metascan-based
approach were already detected by the probe-based approach. This is important
as it confirms our hypothesis that probe-based is superior to the metascan. In
fact, this suggests that the metascan pipeline can be ignored without any loss
of information.

Figure 2: Honeypots detected per scan Figure 3: Honeypots detected by type and
technique

Figure 4, compares our findings with the SotA measurements from Vetterl et al.
(Bitter Harvest) [42], Morishita et al. (Detect Me) [25] and Zamiri et al.
(Gas What?) [47]. The figure shows the total honeypot instances detected by
SotA in comparison to our approach. We note that the honeypots Nepenthes and
Amun were not evaluated by [42]; in addition, [47] only evaluated Gaspot and
Conpot honeypots. We want to highlight that the value of this figure does not
lie within the improved results on the majority of the honeypots. Direct
comparison with previous measurements is not adequate due to the different
time frame. Instead, we argue that these results suggest a number of
interesting findings. First, they independently confirm previous studies’
conclusions with regard to the global (poor) state of honeypot deployments
[42]. Second, our results come more than one year after the aforesaid studies:
this provided a relatively long period for honeypot administrators to react,
while many honeypots (e.g. Conpot) have been updated to fix relevant
vulnerabilities. Lastly, the multistage nature of our framework suggests that,
in contrast to related work, we should encounter a very small number of false
positives. That is, IP addresses are only marked as honeypots when all
(relevant) stages are confirmed.

We emphasize once more that our results are not directly comparable with the
SotA as they come in a different time-period from the reference work. This
suggests, that honeypot administrators had time to apply updates fixing
fingerprinting issues, many honeypots might have been deactivated over time
and others might have been introduced. That said, our results indicate that
many honeypot administrators are not properly managing their systems.

Figure 4: Comparison to previous measurements in related work

####  3.3.2 Honeypot Versions

We determine the versions of the instances detected as honeypots by examining
specific changes added to the honeypots through patches released by the
developers. However, versions could not be determined for some honeypots that
do not maintain releases (i.e. MTPot and Gaspot). We find that the majority of
the honeypots detected, have not been updated by the administrators even
though there were patches released by the honeypot developers (e.g. for
certain fingerprinting attacks). Furthermore, we detect instances running on
honeypots that are no longer maintained by the developers. The developers of
these honeypots disclose that the project has been discontinued and also
suggest newer honeypots under active maintenance. We list the instances with
the identified deployed versions in Table 5.

Honeypot |  | Deployed
---
Version
#Instances
| Conpot
---
0.5.2*
| 0.5.2
---
0.5.0
0.4.0
| 221
---
496
167
| Cowrie
---
2.1.0*
| 2.1.0
---
1.5.3
1.5.1
| 17
---
232
2925
| Glastopf
---
3.1.2*
| 3.1.2
---
0.2.0
| 4
---
3416
| Dionaea
---
0.8.0*
| 0.8.0
---
0.6.0
| 2259
---
1782
Table 5: Detected honeypot versions (* latest version)

####  3.3.3 Honeypots with Default Configuration

The honeypots considered in our tests can be deployed with a default
configuration. Nevertheless, for some honeypots, the developers explicitly
provide additional templates and guidelines to change the default settings.
The usage of default honeypot configuration can be problematic as it makes
fingerprinting significantly easier.

To determine this, we compare the cumulative results from the framework’s HTTP
Static Response and the Static Command Response stages to the default
configuration of the deployed honeypots in our lab environment (see Section
3.2). Therefore, upon matching, we can infer that the instance is a honeypot
deployed with its default configuration. We observe that the majority of the
detected honeypots are running with default configurations that make primitive
fingerprinting techniques like static http-content very successful. We list
the number of honeypot instances running with default configurations in Table
6.

Honeypots |  | #Instances with
---
default configuration
| #Instances without
---
default configuration
Gaspot | 925 | 40
MTPot | 215 | 0
Conpot | 777 | 107
Nepenthes | 531 | 58
Kippo | 773 | 23
Cowrie | 3149 | 25
Amun | 7455 | 57
Glastopf | 3416 | 4
Dionaea | 4064 | 37
Total | 21305 | 351
Table 6: Detected honeypots running on default configuration

####  3.3.4 Non-honeypot encounters

As a result of multistage checks from the framework, instances are filtered
out at each stage when they fail the matching criteria. We further analyze the
non-honeypot instances that were filtered out at multiple stages to determine
the cause of filtration at a particular stage and/or the success in other
stages. Table 12 in the Appendix shows the non-honeypot instances determined
at stages in our framework based on honeypot types. Based on this, we derive
the following findings.

Vulnerability | # Instances
---|---
Default passwords (SSH)
| root, root
---
admin, admin
root, 1234
admin, 1234
root, 123456
root, (no password)
admin, (no password)
| 216
---
124
23
43
21
18
28
Default passwords (FTP)
| root, root
---
admin, admin
root, 1234
admin, 1234
| 94
---
29
19
8
Vulnerable Banners (SSH)
| SSH-2.0-ROSSSH
---
SSH-2-0-libssh-0.7.0(5)
| 263,516
---
196
Vulnerable Banners (FTP)
| 220 ProFTPD 1.3.5 Server
---
220 ProFTPD 1.3.1 Server
220 Serv-U FTP Server v6.2
| 53,873
---
15,823
21,023
Table 7: Vulnerable non-honeypot instances

##### SSH and FTP Instances with Default Passwords

We find SSH instances running on default passwords that met the initial
criteria for SSH honeypot detection in our framework, but fail in other stages
(e.g. static command and library checks). These instances’ credentials match
the ones of the default passwords accepted by Kippo and Cowrie honeypots. Our
conclusion is that these are either vulnerable devices with default logins or
high-interaction honeypots. We list the number of vulnerable SSH instances
found with default passwords in Table 7.

##### SSH and FTP Instances with Vulnerable Versions

From the instances that were filtered out of the banner check stage (in the
probe-based pipeline), we identify the number of instances that appear to
contain vulnerable versions in their banners. In particular, we take into
account banners that have a high severity vulnerability (by making use of the
National Vulnerability Database [5]). We identify a total of $263,712$
instances with vulnerable versions as per the advertised banners. The banners
and the number of instances identified are listed in Table 7.

####  3.3.5 Experiment repetition: gain and blocked/offline instances

Due to the nature of our experiments (i.e. long time windows and rather
aggressive fingerprinting scans) we expect that: i) we will observe some
fluctuation in our results, ii) we will have some gain as new honeypots are
introduced on the Internet, iii) we expect some of the networks to blocklist
our scanners, and lastly iv) we anticipate some honeypots not to be responsive
due to them taken down, maintenance and/or network errors.

We scan the Internet with a different scanning host that has different IP
address and subnet. We compare the results from the different scanning periods
to identify new and existing honeypot instances. In the next step, we analyze
the IP address of the new honeypot instances detected against our framework
and check the IP address for their subnet and their AS. If the IP address
belongs to a different subnet but belongs to the same AS, and further matches
to the properties of the honeypot identified in the previous period, we infer
that the honeypots are the same but had some churn-related effects. Moreover,
we further examine the gain vs. blocked trade-off by trying to connect to the
new IP address of the honeypot instance from our previous scanning host. If
the honeypot instance blocks the connection from the first connected host but
was connected by the second scanning host, then it is very likely that the
honeypot administrator has blocklisted the IP address of the first scanning
host.

Table 8 shows the number of new honeypot instances detected in the scans and
the instances that were either blocked or offline. There was a significant
number of new Nepenthes honeypots instances detected in the third scan. On
tracing the IP addresses of the new instances, we find that all the new
detected honeypots were hosted by a hosting provider which was traced earlier
hosting Nepenthes instances on another subnet. We can infer that either the
honeypots were configured to undergo some IP rotation logic or were simply
offline for a certain period. Overall, we find that only $2.3$% of the
honeypot instances have changed their IP and only $1$% are not offline after
the first scan.

Honeypot |  | Scan-2
---
New Instances
| Scan-2
---
Blocked/Offline
| Scan-3
---
New Instances
| Scan-3
---
Blocked/Offline
Gaspot | 567 | 12 | 387 | 11
MTPoT | 0 | 1 | 0 | 23
Nepenthes | 0 | 3 | 573 | 16
Conpot | 367 | 33 | 110 | 23
Kippo | 0 | 4 | 0 | 13
Amun | 0 | 3 | 63 | 51
Cowrie | 0 | 4 | 0 | 98
Glastopf | 3 | 2 | 0 | 13
Dionaea | 0 | 0 | 0 | 0
Table 8: Identification gain vs. blocked/offline instances

###  3.4 Ground Truth Validation

The absence of ground truth knowledge regarding honeypots creates a
challenging landscape for measuring metrics such as precision or possible
false positives. This is a fundamental problem in the area of honeypot
fingerprinting that cannot be solved in its entirety. Hence, in the following
we attempt to provide indications on why false positives are not a significant
issue in our approach.

First, in contrast to the state of the art, we propose a framework that
requires multiple steps to be confirmed until an IP address is marked as a
honeypot. These steps include a multitude of independent checks which, we
argue, significantly decrease the probability of false positives. Looking at
the SotA, Vetter et al. [42] measure the detection accuracy using the
responses received from the honeypots by generating a cosine similarity score
and Morishita et al. [25] use the matching of honeypot signatures in four
datasets. In contrast, our approach relies on multiple checks at each stage to
minimize false positives.

Second, we replicate and extend the ground truth validation proposed by [25]
and [44]. Morishita et al. argue that a honeypot IP address cannot be present
in IP spaces that are known for their commercial usage. This argument
obviously does not solve the absence of ground truth, but rather provides a
minor indication that the identified IP addresses are not clear false
positives. Vogt et al. also use a similar validation in their evaluation to
check if the domain identified by their model is listed on sources providing
web-statistics like the top $1$ million domains [44]. In this context, we
evaluate our results by comparing the identified honeypot IP addresses with
the top $1$ million domains from Alexa [2], Majestic [24] and Cisco-Umbrella
[7] with known benign FTP servers, as well as known university SMTP domains.
For this evaluation we fetch the Alexa top $1$ million domains from Alexa,
perform a DNS lookup and examine whether our results match them. Similarly we
fetch the top $1$ million domains from the Majestic and the Cisco-Umbrella
websites. We confirm that none of IP address from these domains are found in
our results. We note that the IP addresses for some of the domains change
based on the geo-location of resolution due to the Content Delivery Network
(CDN). Hence, we repeated the experiments by connecting to many different geo-
locations by using a Virtual Private Network (VPN)provider. Moreover, we fetch
the list of official FTP mirrors from GNU [15], Apache [14], Ubuntu [13],
Debian [9] and find $1,231$ unique domain names. Upon performing a DNS lookup,
we get $2,784$ IP addresses. Once more, none of the identified honeypots match
these IP addresses. Furthermore, we retrieve the list of university domain
names from [19] for evaluating Amun (SMTP) honeypot. Upon performing a DNS
lookup we find $12,012$ IP addresses. There were no honeypots detected in the
domains from this list. To sum up, while the SotA uses a singular method to
deal with false positives, our approach utilizes multiple stages. Moreover, we
further test our results with an adaption and extension of the techniques
employed by [25] to address the absence of ground truth knowledge.

##  4 Discussion

The evaluation of the multistage framework involved an experimental setup to
reduce false positives and help in classification of honeypot instances. In
this section we discuss the ethical considerations and experimental setup
considered during the experimentation phase.

###  4.1 Ethical considerations

This section takes into account the various ethical considerations we had
during our research.

####  4.1.1 Experiments

First, we inform the IT administrators of our organization about the ongoing
research and seek their assistance for providing an approved setup for
scanning the Internet. This is important as organizations tend to blocklist
the IP addresses of sources that appear to be scanning them. Second, we setup
a website on the IP address of our scanner that provides a
disclosure/explanation of our research purpose. This assists in limiting the
effects of blocklisting the IP addresses of our organization.

####  4.1.2 Results Disclosure

The list of honeypot instances obtained through our framework is not publicly
shared. We only present here aggregated statistics and do not share any
identifiers of the honeypot instances. We seek guidance from the privacy
department of our organization for guidelines on storing the results of our
experiments and being compliant to GDPR. We followed the GDPR compliance by
anonymizing the IP addresses after three months following the completion of
our research.

####  4.1.3 Ethical disclosure: notifying Honeypot Developers

We contact the honeypot developers of all of the active honeypot
implementations and provide them with the specifics of the honeypot
fingerprinting methods that can be used against them. Moreover, we contacted
members of the Honeynet project [29], an international security research
organization that focuses on honeypot research, to further disclose the
fingerprinting mechanisms that we have identified.

####  4.1.4 Ethical disclosure: notifying Honeypot Administrators

We take all $21,855$ IP addresses that were identified as honeypots and
perform a WHOIS scan to find relevant contact information. Based on this, we
identify $939$ email addresses that correspond to all the IP addresses that we
managed to find information about. We note that in many cases one email
address corresponds to hundreds of honeypot instances, deployed in the same
network. There are multiple benefits from this procedure. First and foremost,
we notify honeypot administrators that their deployments are vulnerable to our
fingerprinting methods. Second, we ask administrators to contact us in case
they are confident that our finding is a false positive and no honeypot
deployment has taken place in their networks. This acts as an additional false
positive sanity check. Until the time of submission, we did not receive any
false positive claim from the contacted administrators.

###  4.2 Countermeasures against fingerprinting

This section discusses potential countermeasures against fingerprinting.
First, we want to emphasize that, due to their nature, low and medium
interaction honeypots can always be identified upon continuous interaction and
response analysis. Instead, we argue that the emphasis should be to reduce as
much as possible fingerprinting vulnerabilities that can easily be automated.

Metascan-based methods rely on data that is obtained without interaction from
the target system. This can be translated to a scenario in which malware uses
Shodan’s API to ask whether an IP address is a honeypot before contacting it
(e.g. for propagation reasons). We argue that Shodan, Censys and other
scanners must introduce limitations to their honeypot identification services.
From the honeypot deployment and implementation perspective, Moving Target
Defense (MTD)techniques could be employed by honeypot implementations to avoid
a static IP identification. We also discourage the usage of cloud hosting
providers for honeypots based on ICS protocols.

For probe-based methods, we suggest that the honeypots are made self-aware and
dynamic each time an attack has been detected. Fingerprinting methods can be
less effective if the honeypots contain non-static parameters while also
choosing selective services periodically. In addition, honeypots rely heavily
on protocol emulation libraries. It is important to refer to libraries that
are regularly maintained. Furthermore, we suggest making additional tweaks to
the references to modify default static responses by comparing the responses
to an actual system. Default configurations must be avoided and dynamic
configuration based on the attack and the environment is recommended.

###  4.3 Shodan Honeyscore

The Shodan Honeyscore is a proprietary algorithm used to determine whether a
crawled instance is a honeypot or not [33]. Shodan offers an API that provides
a score for IP s detected as probable honeypots. The score ranges from
$[0,0.3,0.5,0.8,1]$, with $0$ denoting that the IP is not a honeypot and $1$
that it is. The API also returns the value NA when no information is available
for a specific IP address. Since the Honeyscore is not open source, not many
conclusions can be derived by examining its output. In fact, it is not
disclosed which honeypots can be identified by Shodan’s Honeyscore.
Nevertheless, we expect that there is some overlap with regard to the
fingerprinting techniques used by our framework and Shodan’s Honeyscore.

Figure 5: Comparison with Shodan’s Honeyscore

We fetch the Honeyscore for all the honeypot IP’s determined by our framework
and compare the results with Shodan. Figure 5 depicts the Honeyscore assigned
to honeypot instances detected through our framework (for the combination of
both metascan and probe-based results). We observe that Shodan returns $0$ as
Honeyscore for many of the IP s. This suggests that the Honeyscore is not
taking into account as many checks as our framework. Moreover, the high
deviations observed with regard to Glastopf and Amun suggest that Shodan is
not very effective in identifying such honeypots.

###  4.4 Limitations

As discussed in Section 3.4, the research field of low and medium interaction
honeypot fingerprinting has the fundamental limitation that there is no global
ground truth knowledge with regard to honeypot deployment. This translates to
potential false positives. Our work is also influenced by this: while our
findings come as the result of multiple stages and checks there may still be
cases in which an instance is incorrectly labeled as a honeypot.

The proposed multistage framework leverages multiple checks to determine if
the end instance is a honeypot. As part of the failed checks from the
framework, 260,000 non-honeypot instances have been detected. While we argue
that the majority of these are most likely vulnerable/misconfigured devices,
it might be that some are high-interaction honeypots. Ideally, one could
perform manual tests on a sample of these systems by logging into them and
attempting to understand the presence of a honeypot environment. However, this
would be illegal and therefore we could not perform such an action. Moreover,
fingerprinting high-interaction honeypots requires extensive probing and
analysis. Hence, this is considered to be out of the scope of this article.

Lastly, while direct comparisons to the state-of-the-art is considered the
default evaluation methodology in many fields of cybersecurity, this is not
possible in our setting. The combination of the aforementioned ground truth
knowledge problem, along with the different time frames of the experiments
make direct comparisons unreliable. We argue, that our work and results is not
competing to the state-of-the-art. This is amplified by the fact that we are
dealing with IP addresses and therefore topics such as static vs dynamic IP
addresses, Network Address Translation (NAT), and churn need to be taken into
account.

##  5 Related Work

This section focuses on honeypot-specific fingerprinting research. We note
here that besides honeypots, there has been research in the identification of
intrusion detection systems and network telescope sensors (e.g. [4, 39]).
However, we consider this out of the scope of this article. Similarly, we will
not discuss here fingerprinting of honeypot-like systems (such as honeytoken
identification) [36]. We also note all papers in the SotA exclude high
interaction honeypots from their analysis.

Authors & Year |  | Fingerprinting
---
technique
| IPv4 scan
---
Holz et al., 2005 [21] |  | Static command
---
response check
No
Wang et al., 2010 [45] |  | Static command
---
response check
No
Hayatle et al., 2012 [18] |  | Static command
---
response check
No
Aguirre et al., 2014 [1] |  | Library dependency
---
check, static command
response check
No
Vetterl et al., 2018 [42] |  | Banner check, protocol
---
handshake check,
Library dependency
check, static command
response check
Yes
Vetterl et al., 2019 [43] |  | Banner check,
---
Library dependency
check
Yes
Huang et al., 2019 [22] |  | Banner check, static
---
command response
check
No
Morishita et al., 2019 [25] |  | Banner check, http
---
static response
Yes
Zamiri et al., 2019 [47] |  | default config,
---
static response,
protocol handshake
Yes
Papazis et al., 2019 [28] |  | Banner check, http
---
static response, static
command check
No
Table 9: Overview of the related work

Techniques for fingerprinting honeypots were first proposed early in 2005 by
Holz et al. [21]. The authors state that limited simulation and virtualization
cause restricted interaction on the honeypot system that leads to
fingerprinting possibilities. Holz et al. propose fingerprinting techniques to
detect User-mode Linux (UML) kernels by observing the process id’s,
virtualized environments by analyzing the ping response time, and debuggers by
using ptrace(). The presented techniques are focused more on fingerprinting at
the process and operating system level. This is mainly due to the limited
availability of honeypots at the time of research.

Wang et al. present an approach to detect honeypots in advanced botnet attacks
[45]. Their work is based on the assumption that security professionals
deploying honeypots have a liability constraint; they cannot allow their
honeypots to participate in attacks. Hence, botmasters can detect honeypots by
checking whether compromised machines in their botnet can successfully send
out unmodified malicious traffic. This approach is based on monitoring the
traffic which is transmitted by the infected system through the bots. For
example, the use of iptables command on Linux environments to list the port
forwarding helps in the identification of honeypots because of outbound
traffic rules. This information is transmitted by the bot to the botmaster.
The authors also present fingerprinting techniques involving ping response
time.

Vetterl et al. propose the detection of nine well known open source honeypots
by constructing probes to fetch specific data and observe the deviation
between the response from actual honeypots [42]. The deviation is measured as
a cosine coefficient. This approach provides a good insight into the state of
open source honeypots and their vulnerability to fingerprinting attacks. The
methodology is evaluated and the authors identify $7,605$ honeypots on the
Internet. In comparison, although our framework employs an approach to observe
deviation in responses, we further extend the framework to include additional
checks to reduce false positives.

Moreover, Morishita et al. [25] propose honeypot fingerprinting through
signature-based detection. The authors develop signatures for $15$ open source
honeypots offering multiple services. The signatures are then matched against
responses obtained through probes and mass-scan engines to determine if the
system is a honeypot. The approach is evaluated and the authors detect
$19,208$ honeypots. Our approach checks for known honeypot banners returned by
the instances, although it does not rely solely on the banner check to flag
the instance as a honeypot.

In addition, Zamiri et al. detect GasPot [46], an ATG-based ICS honeypot
through probes designed to fetch information about the default configuration
and limited emulation of the protocols [47]. The authors study ICS honeypots
(specifically of Conpot and GasPot) list features, e.g. limited emulation
static responses, and identify the underlying OS to eventually fingerprint
them. They perform an Internet-wide scan to detect $17$ GasPot and $240$
Conpot instances.

Huang et al. probe remote systems and label the response data to train a
machine-learning model to classify systems as honeypots [22]. The method
follows a recursive probing process to obtain featured data for
classification. The features include application-layer, network-layer, and
system-layer properties. The authors train the model for classification by
providing data from known honeypot systems. However, the authors do not
classify the responses from widely recognized honeypots like Kippo, Cowrie, or
Dionaea.

Lastly, Papazis et al. attempt to exploit some of the virtual network layers
implemented in honeypots, using tools like NMap, to fingerprint them [28]. In
addition, they demonstrate the identification of network and service anomalies
like link latency and limited emulation that may also lead to honeypot
detection. The authors discuss detection vectors for honeypots like Sebek,
Artillery, BearTrap, KFSensor, HoneyD, Kippo and Dionaea.

Table 9 summarizes the fingerprinting related work. We note that majority of
the related work does not evaluate their proposed techniques by performing an
active search for honeypots on the Internet. This is mainly due to the fact
that Internet-wide scanning was not trivial until the emergence of ZMap [12].
That said, the fingerprinting techniques suggested by [42, 25, 43, 47] include
a thorough evaluation. However, their core limitation is that they focus on a
limited number of techniques for fingerprinting. In this article, we propose a
multistage framework that combines probe-based techniques (targeting multiple
system layers) with data available from Internet mass-scan search providers to
systematically detect honeypots.

##  6 Conclusion

Honeypots are unique mechanisms for understanding attack methodologies,
discovering new attack trends, as well as for early warning systems. In this
article, we proposed a framework for honeypot fingerprinting that includes new
and SotA components and is able to identify thousands of honeypot instances
for nine of the most popular honeypot implementations. Our work reduces false
positives by the utilization of multiple checks before determining that an
instance is a honeypot. Our results also suggest that probe-based
fingerprinting techniques are significantly more effective in detecting
honeypots than the metascan techniques that utilize third-party systems like
Shodan. We once more highlight that our work is in the direction of improving
honeypots rather than arguing against them. With the availability of open
honeypot identification APIs , such as Shodan’s Honeyscore, it is only a
matter of time that we see honeypot-evading malware. In this context, we
contacted both the developers and the administrators of the honeypots to make
them aware of potential fingerprinting issues. However, based on the
experience of previous work we are not over-optimistic with regard to the
patching/updating of such systems. Instead, we argue that novel components
must be added in new/old honeypots that are in the direction of Moving Target
Defense s schemes. We plan to further investigate fingerprinting
countermeasures in our future work.

## ACKNOWLEDGMENTS

This research was supported as part of COM3, an Interreg project supported by
the North Sea Programme of the European Regional Development Fund of the
European Union.

## References

  * [1] E. Aguirre-Anaya, G. Gallegos-García, Nicolás Solano Luna, and Luis A. Villa Vargas.  A new procedure to detect low interaction honeypots.  International Journal of Electrical and Computer Engineering, 4:848–857, 2014.
  * [2] Amazon.  Alexa - an amazon company, 2020.
  * [3] Ofir Arkin, Fyodor Yarochkin, Meder Kydyraliev, Ofir Arkin, Fyodor Yarochkin, and Meder Kydyraliev.  The present and future of xprobe2: The next generation of active operating system fingerprinting. sys-security group, 2003.
  * [4] John Bethencourt, Jason Franklin, and Mary Vernon.  Mapping internet sensors with probe response attacks.  In 14th USENIX Security Symposium (USENIX Security 05), Baltimore, MD, jul 2005. USENIX Association.
  * [5] Harold Booth, Doug Rike, and Gregory Witte.  The national vulnerability database (nvd): Overview.  Technical report, National Institute of Standards and Technology, 2013\.
  * [6] Bogdan Botezatu.  New hide ‘n seek iot botnet using custom-built peer-to-peer communication spotted in the wild, 2018.
  * [7] Cisco.  Umbrella popularity list, 2020.
  * [8] Cymmetria.  Mtpot, 2016.
  * [9] Debian.  Debian project, 2020.
  * [10] Decester.  An ssh honeypot, 2000.
  * [11] Zakir Durumeric, David Adrian, Ariana Mirian, Michael Bailey, and J. Alex Halderman.  A search engine backed by internet-wide scanning.  In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, CCS ’15, page 542–553, New York, NY, USA, 2015. Association for Computing Machinery.
  * [12] Zakir Durumeric, Eric Wustrow, and J. Alex Halderman.  Zmap: Fast internet-wide scanning and its security applications.  In Proceedings of the 22nd USENIX Conference on Security, SEC’13, page 605–620, USA, 2013. USENIX Association.
  * [13] Official Archive Mirrors for Ubuntu.  Debian project, 2020.
  * [14] The Apache Foundation.  The apache software foundation, 2020.
  * [15] GNU.org.  Gnu operating system, 2020.
  * [16] Robert David Graham.  Masscan: Mass ip port scanner, 2014.
  * [17] T Grudziecki, P Jacewicz, Ł JUSZCZYK, P Kijewski, and P Pawliński.  Proactive detection of security incidents, 2012.
  * [18] Osama Hayatle, Amr Youssef, and Hadi Otrok.  Dempster-shafer evidence combining for (anti)-honeypot technologies.  Information Security Journal: A Global Perspective, 21(6):306–316, 2012.
  * [19] Hipo.  Github, 2020.
  * [20] Filip Holik, Josef Horalek, Ondrej Marik, Sona Neradova, and Stanislav Zitta.  Effective penetration testing with metasploit framework and methodologies.  In 2014 IEEE 15th International Symposium on Computational Intelligence and Informatics (CINTI), pages 237–242, Budapest, Hungary, 2014\. IEEE, IEEE.
  * [21] T. Holz and F. Raynal.  Detecting honeypots and other suspicious environments.  In Proceedings from the Sixth Annual IEEE SMC Information Assurance Workshop, pages 29–36, West Point, NY, USA, June 2005. IEEE.
  * [22] Cheng Huang, Jiaxuan Han, Xing Zhang, and Jiayong Liu.  Automatic identification of honeypot server using machine learning techniques.  Security and Communication Networks, 2019, 2019.
  * [23] Gordon Lyon.  Nmap network mapper, 2021.
  * [24] Majestic.  The majestic million, 2021.
  * [25] Shun Morishita, Takuya Hoizumi, Wataru Ueno, Rui Tanabe, Carlos Gañán, Michel J.G. van Eeten, Katsunari Yoshioka, and Tsutomu Matsumoto.  Detect me if you… oh wait. an internet-wide view of self-revealing honeypots.  In 2019 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), pages 134–143, Arlington, VA, USA, 2019. IEEE.
  * [26] Marcin Nawrocki, Matthias Wählisch, Thomas C. Schmidt, Christian Keil, and Jochen Schönfelder.  A survey on honeypot software and data analysis, 2016.
  * [27] Michel Oosterhof.  Cowrie ssh/telnet honeypot, 2016.
  * [28] Kon Papazis and Naveen Chilamkurti.  Detecting indicators of deception in emulated monitoring systems.  Service Oriented Computing and Applications, 13(1):17–29, 2019\.
  * [29] The Honeynet Project.  The honeynet project, 2021.
  * [30] Rapid7.  Recog, 2021.
  * [31] L Rist.  Glastopf project, 2009.
  * [32] Lukas Rist, Johnny Vestergaard, Daniel Haslinger, A Pasquale, and J Smith.  Conpot ics/scada honeypot, 2013.
  * [33] SHODAN.  Honeypot or not?, 2021.
  * [34] L. Spitzner.  The honeynet project: trapping the hackers.  IEEE Security Privacy, 1(2):15–23, 2003.
  * [35] Lance Spitzner.  Passive fingerprinting.  FOCUS on Intrusion Detection: Passive Fingerprinting (May 3, 2000), pages 1–4, 2000.
  * [36] Shreyas Srinivasa, Jens Myrup Pedersen, and Emmanouil Vasilomanolakis.  Towards systematic honeytoken fingerprinting.  In 13th International Conference on Security of Information and Networks, SIN 2020, New York, NY, USA, 2020. Association for Computing Machinery.
  * [37] Dino Tools.  Web honeypot, 2010.
  * [38] Hauser Van and Kessler Roland.  Kali tools, 2021.
  * [39] E. Vasilomanolakis, M. Stahn, C. G. Cordero, and M. Mühlhäuser.  On probe-response attacks in collaborative intrusion detection systems.  In 2016 IEEE Conference on Communications and Network Security (CNS), pages 279–286, Florence, Italy, 2016. IEEE.
  * [40] Emmanouil Vasilomanolakis, Shankar Karuppayah, Max Mühlhäuser, and Mathias Fischer.  Hostage: A mobile honeypot for collaborative defense.  In Proceedings of the 7th International Conference on Security of Information and Networks, SIN ’14, page 330–333, New York, NY, USA, 2014\. Association for Computing Machinery.
  * [41] Emmanouil Vasilomanolakis, Shreyas Srinivasa, Carlos Garcia Cordero, and Max Mühlhäuser.  Multi-stage attack detection and signature generation with ics honeypots.  In NOMS 2016 - 2016 IEEE/IFIP Network Operations and Management Symposium, pages 1227–1232, Istanbul, Turkey, 2016. IEEE.
  * [42] Alexander Vetterl and Richard Clayton.  Bitter harvest: Systematically fingerprinting low- and medium-interaction honeypots at internet scale.  In 12th USENIX Workshop on Offensive Technologies (WOOT 18), Baltimore, MD, August 2018. USENIX Association.
  * [43] Alexander Vetterl, Richard Clayton, and Ian Walden.  Counting outdated honeypots: Legal and useful.  In 2019 IEEE Security and Privacy Workshops (SPW), pages 224–229, San Francisco, CA, USA, 2019. IEEE.
  * [44] Ryan Vogt, John Aycock, and Michael J Jacobson Jr.  Army of botnets.  In NDSS, San Diego, CA, USA, 2007. Citeseer, NDSS.
  * [45] Ping Wang, Lei Wu, Ryan Cunningham, and Cliff C Zou.  Honeypot detection in advanced botnet attacks.  International Journal of Information and Computer Security, 4(1):30–51, 2010.
  * [46] Kyle Wilhoit and Stephen Hilt.  The gaspot experiment: Unexamined perils in using gas-tank-monitoring systems, 2015.
  * [47] Mohammad-Reza Zamiri-Gourabi, Ali Razmjoo Qalaei, and Babak Amin Azad.  Gas what? i can see your gaspots. studying the fingerprintability of ics honeypots in the wild.  In Proceedings of the Fifth Annual Industrial Control System Security (ICSS) Workshop, ICSS, page 30–37, New York, NY, USA, 2019. Association for Computing Machinery.
  * [48] ZMap.  Github, 2020.
  * [49] C.C. Zou and R. Cunningham.  Honeypot-aware advanced botnet construction and maintenance.  In International Conference on Dependable Systems and Networks (DSN’06), pages 199–208, Philadelphia, PA, USA, 2006. IEEE.

##  Appendix A Multistage Framework for Honeypot Fingerprinting

Table 10 shows the banners advertised by honeypots in our evaluation. Most
honeypot implementations offer limited banners or custom banners.

Honeypot | Protocol | Banner
---|---|---
Kippo | SSH |  | Default: SSH-2.0-OpenSSH_5.1p1 Debian-5
---
# SSH-1.99-OpenSSH_4.3
# SSH-1.99-OpenSSH_4.7
# SSH-1.99-Sun_SSH_1.1
# SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.1
# SSH-2.0-OpenSSH_4.3
# SSH-2.0-OpenSSH_4.6
# SSH-2.0-OpenSSH_5.1p1 Debian-5
# SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901
# SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
# SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
# SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
# SSH-2.0-OpenSSH_5.5p1 Debian-6
# SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1
# SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
# SSH-2.0-OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
# SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
# SSH-2.0-OpenSSH_5.9
Cowrie | SSH | Debian GNU/Linux 7
Cowrie | Telnet | \xff\xfd\x1flogin:
Glastopf | HTTP | Apache httpd
Dionaea | FTP | 220 Welcome to the ftp service
Amun(SMTP) | SMTP | 220 mail\\.example\\.com SMTP Mailserver
Amun(IMAP) | IMAP | a001 OK LOGIN completed
Amun(FTP) | FTP | 220 Welcome to my FTP Server
Conpot | SSH | SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1.3
Conpot | Telnet | Connected to [00:13:EA:00:00:0]
Gaspot | ATG | Linux 3.X|4.X
Nepenthes | FTP | 220 —freeFTPd 1\\.0—warFTPd 1\\.65—
MTPot | Telnet |  | \xff\xfb\x01\xff\xfb\x03\xff\xfc’\xff\xfe\x01
---
\xff\xfd\x03\xff\xfe\"\xff\xfd’\xff \xfd\x18\xff\xfe\x1f
Table 10: Banners advertised by Honeypots (adapted from [42] and [25] see
Banner check in Section 2.2.1)

Table 11 shows the static content received as HTTP response from honeypots for
specific requests. The static responses are either due to limited emulation or
due to honeypots being deployed with default configuration.

Honeypot |  | HTTP
---
Request
HTTP Response Contents
Glastopf | GET / HTTP/1.0 |  | 1\. <h2>My Resource</h2>
---
2\. <h2>Blog Comments</h2>\n <label for=\"comment\">Please post your comments
for the blog</label>\n <br />\n <textarea name=\"comment\" id=\"comment\"
rows=\"4
\" columns=\"300\"></textarea>\n <br />\n <input type=\"submit
\" name=\"submit\" id=\"submit_comment\" value=\"Submit\" />\n
Amun | GET / HTTP/1.0 |  | <!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2\\.0//EN\"><html><head><title>
---
It works!</title></head><html><body><h1>It<EMAIL_ADDRESS>
<EMAIL_ADDRESS>
Dionaea | GET / HTTP/1.0 |  | <!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 3\\.2 Final//EN\"><html>\n<title>
---
Directory listing for /</title>\n<body>\n<h2>Directory listing for /</h2>\n
Conpot |  | GET /HTTP/1.0/
---
index.html
| 1\. Last-Modified: Tue, 19 May 1993 09:00:00 GMT
---
2\. Technodrome
3\. Mouser Factory
Table 11: HTTP Response from Honeypots (see HTTP Static Response in Section
2.2.1)

Table 12 shows the non-honeypot instances determined at stages in our
framework based on honeypot types. Limited emulation in honeypots cause
identification at different levels that are determined by the stages in our
framework.

Honeypot | Portscan |  | Failed
---
Banner
| Failed
---
Static http
response
| Failed
---
SSL/TLS
Certificate check
| Failed Protocol
---
Handshake
| Failed
---
Library
Dependency
Check
| Not a
---
Honeypot
Kippo | 4361857 | 4324502 | NA | NA | 34887 | 1656 | 4361045
Cowrie | 4361857 | 4318645 | NA | NA | 37836 | 2100 | 4358581
Glastopf | 57062712 | 56385819 | 673462 | NA | 0 | 0 | 57059281
Dionaea | 43944853 | 43890588 | 49963 | 201 | 0 | 0 | 43940752
Nepenthes | 10391953 | 10391645 | NA | NA | 3 | 0 | 10391648
Conpot | 29950 | 28693 | NA | NA | 732 | 333 | 29758
Gaspot | 222593 | 222393 | NA | NA | 0 | 0 | 222393
MTPot | 2923651 | 2923412 | NA | NA | 0 | 0 | 2923412
Amun(SMTP) | 6020828 | 6018931 | NA | NA | 0 | 0 | 6018931
Amun(IMAP) | 4152084 | 4150278 | NA | NA | 0 | 0 | 4150278
Amun(FTP) | 10391953 | 10389555 | NA | NA | 0 | 0 | 10389555
Amun(HTTP) | 43944853 | 43942485 | NA | NA | 0 | 0 | 43943476
Total | 187809144 | 186986946 | 724416 | 201 | 73458 | 4089 | 187789110
Table 12: Non-honeypot encounters by stage. See also Section 3.3.4.

Table 13 denotes the keywords used in Shodan and Censys to retrieve honeypots.
The keywords are derived from banners and static content advertised by
honeypots.

Honeypot | Shodan | Censys
---|---|---
Glastopf | <h2>My Resource</h2> | 80.http.get.body: "<h2>My Resource</h2>/"
Dionaea | ssl:"Nepenthes" |  | 443.https.tls.certificate.parsed.subject.common_name:
---
"Nepenthes Development Team"
Conpot | port:"102" product:"Conpot" | 80.http.get.body: "Technodrome"
Nepenthes |  | product:"Nepenthes HoneyTrap
---
fake vulnerable ftpd"
21.ftp.banner.banner: "220 —freeFTPd 1\\.0—warFTPd "
Amun | "220 Welcome to my FTP Server" |  | "80.http.get.body<EMAIL_ADDRESS>
---
21.ftp.banner.banner: "220 Welcome to my FTP Server"
25.smtp.starttls.banner: "220 mail\\.example\\.com SMTP Mailserver"
143.imap.starttls.banner: "OK LOGIN completed"
Gaspot | I20100 port: "10001" | "I20100"
Table 13: Honeypot keywords search (see also paragraph Keyword Search in
Section 2.2.2)

Table 14 shows the static response returned by honeypots for specific commands
requested by our probes. Limited emulation or default configuration lead to
static response from the honeypots.

Honeypot | Command | Response
---|---|---
Conpot |  | S7_ID
---
station name
unit name
| 88111222
---
"STATOIL STATION"
"Technodrome"
Kippo |  | nano
---
vi
E558: Terminal entry not found in terminfo
Cowrie | arp |  | IP address HW type Flags HW address Mask Device
---
192.168.1.27 0x1 0x2 52:5e:0a:40:43:c8 * eth0
192.168.1.1 0x1 0x2 00:00:5f:00:0b:12 * eth0
Amun(FTP) | quit | 221 Quit. 221 Goodbye!
Gaspot | I30100 | 9999FF1B
Table 14: Overview of honeypot static responses. In reference to Section 2.2.1

Table 15 provides an overview of the number of honeypot types and instances
detected over the three scanning periods.

Honeypot | Scan 1 | Scan 2 | Scan 3 | Total |  | Total
---
(active)
Dionaea | 4101 | 4101 | 4101 | 4101 | 4101
Glastopf | 3431 | 3433 | 3420 | 3433 | 3420
Cowrie | 3276 | 3272 | 3174 | 3276 | 3174
Amun(FTP) | 2398 | 2388 | 2379 | 2398 | 2379
Amun(SMTP) | 1897 | 1897 | 1883 | 1897 | 1883
Amun(IMAP) | 1806 | 1806 | 1795 | 1806 | 1795
Amun(HTTP) | 1377 | 1375 | 1455 | 1455 | 1455
Kippo | 812 | 809 | 796 | 812 | 796
Conpot | 399 | 751 | 884 | 884 | 884
Nepenthes | 305 | 302 | 589 | 589 | 589
MTPoT | 239 | 238 | 215 | 239 | 215
Gaspot | 200 | 755 | 965 | 965 | 965
Table 15: Honeypots detected per scan

##  Appendix B Framework specific checks and pipeline

Algorithm 1, represents the pseudo-code block that checks an instance for
Dionaea’s default certificate parameters. In lines $3$-$5$, the algorithm
retrieves the certificate from the web server by accepting the IP and port of
the instance and checks for common attributes subject organization, country,
and issuer. These attributes have static values assigned by the honeypot
developers. In steps $7$-$9$, the algorithm checks if the values match the
Dionaea honeypot certificate’s static values. Upon match, the algorithm
returns that the instance is a Dionaea honeypot.

input : ip, port

output : isDionaea /* True if certificate from Dionaea */

begin

1 checkCert(ip,port)

2 $\texttt{isDionaea}=\texttt{false}$

3
$\texttt{cert}=\textsl{ssl.get\\_server\\_cert}(\texttt{ip},{\texttt{port}})$

4 $\texttt{X509}=\texttt{Crypto.X509.load\\_cert(cert)}$

5 $\texttt{org}=\texttt{X509.subject.org}$

6 if  _cert_ then

7 if  _org = "dionaea.carnivore.it"_ then

8 $\texttt{isDionaea}=\texttt{true}$

9Return isDionaea

10end

Algorithm 1 Certificate Check

Algorithm 2 shows the checks done in the Metascan-based pipeline. The
algorithm checks or open ports, and performs keyword based check to list
instances that match the static content delivered by honeypots. Furthermore,
additional checks like FQDN and cloud hosting checks are performed for
determining specific honeypot types.

Algorithm 3 represents the metascan search performed to determine instances
with specific ports exposed to the Internet. The algorithm performs a search
on Shodan and Censys mass scan engines for specific ports that are open on
honeypots in our test.

input : ports /* ports */

output : findHoneypot /* Honeypots on the Internet */

begin

1 $\texttt{ip}\leftarrow\textsl{metasearch}(\texttt{ports})$

/* Shodan and Censys Search */

2 foreach  _ip_ do

3$\texttt{kw}=\textsl{keywordSearch}(\texttt{ip})$

4 if  _kw_ then

5 foreach  _ip_ do

6 if  _checkfqdn(ip)_ then

7 return $\texttt{hasFqdn}=false$

8if  _!hasfqdn & port=502|102_ then

9 if  _cloudCheck(ip)_ then

10 return $\texttt{isHoneypot}=true$

11isHoneypot

12if  _!hasfqdn_ then

13 if  _isResearch(ip)_ then

14 return $\texttt{isResearch}=true$

15isHoneypot

16 endIf

17endFor

18end

Algorithm 2 Metascan-based Pipeline

input : port /* search parameter */

output : instanceIP /* Instances with open ports */

begin

1 $\texttt{instances[]}=null$

2 shodanSearch(port)

3 foreach  _ip_ do

4 $\texttt{instances[].append}(\texttt{ip},\texttt{port})$

5 return instances[]

6 endFor

7censysSearch(port)

8 foreach  _ip_ do

9 $\texttt{instances[].append}(\texttt{ip},\texttt{port})$

10 return instances[]

11 endFor

12end

Algorithm 3 Metascan Search

Lastly, algorithm 4 represents the Protocol Handshake check procedure
described in Section 2.2.1. The algorithm checks for a deviated response from
the instances for specific negotiation parameters and response based on the
port and the service of the instance.

input : instance[], /* Instance [ip, port, protocol, isDeviated] */

output : instance[isDeviated] /* Handshake is deviated */

begin

1 CheckHandshake(instance[])

/* For each instance */

2[-] foreach  _ip in Instance[]_ do

3 if  _port=22/2222 & protocol="SSH"_ then

4 request("SSH-2.0-OpenSSH\n\n\n\n\n\n\n\n\n\n")

5 if response = "bad Packet length" or "protocol mismatch"

6 return $\texttt{Instance[isDeviated]}=true$

7 else request("SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2\n")

8 if response = "protocol mismatch\n"

9 return $\texttt{Instance[isDeviated]}=true$

10elseif  _port=102 & protocol="S7"_ then

11 request(H,0300002102f08032070000…)

12 if response = "0x32"

13 return $\texttt{Instance[isDeviated]}=true$

14elseif  _port=502 & protocol="Modbus"_ then

15 request(function_code:None, slave_id:0, request:0000000000050..)

16 if session.state = "Disconnected"

17 return $\texttt{Instance[isDeviated]}=true$

18elseif  _port=25 & protocol="SMTP"_ then

19 request(PASS:Test)

20 if response = "220 OK"

21 return $\texttt{Instance[isDeviated]}=true$

22elseif  _port=143 & protocol="IMAP"_ then

23 request(RCPT TO:TEST)

24 if response = "221 Bye Bye"

25 return $\texttt{Instance[isDeviated]}=true$

26elseif  _port=21 & protocol="FTP"_ then

27 request(ftp (ip))

28 if packet.windowSize=4096 & session.disconnect.timeout=45

29 return $\texttt{Instance[isDeviated]}=true$

30elseif  _port=23/2323 & protocol="Telnet"_ then

31 request(telnet (ip))

32 if packet.response= "You have connected to the telnet server"

33 return $\texttt{Instance[isDeviated]}=true$

34elseif  _port=80/8080/443/8443 & protocol="HTTP/HTTPS"_ then

35 request(GET /HTTP/1.0 (ip))

36 if response.packet.header.server= "nginx" or "Apache/1.3.29" or
"BaseHTTP/0.3 Python/2.5.1" or "Microsoft-IIS/5.0"

37 return $\texttt{Instance[isDeviated]}=true$

Algorithm 4 Protocol Handshake Check