Conference PaperPDF Available

A honeypot-driven cyber incident monitor: lessons learned and steps ahead


Abstract and Figures

In recent years, the amount and the sophistication of cyber attacks has increased significantly. This creates a plethora of challenges from a security perspective. First, for the efficient monitoring of a network, the generated alerts need to be presented and summarized in a meaningful manner. Second, additional analytics are required to identify sophisticated and correlated attacks. In particular, the detection of correlated attacks requires collaboration between different monitoring points. Cyber incident monitors are platforms utilized for supporting the tasks of network administrators and provide an initial step towards coping with the aforementioned challenges. In this paper, we present our cyber incident monitor TraCINg. TraCINg obtains alert data from honeypot sensors distributed across all over the world. The main contribution of this paper is a thoughtful discussion of the lessons learned, both from a design rational perspective as well as from the analysis of data gathered during a five month deployment period. Furthermore, we show that even with a relatively small number of deployed sensors, it is possible to detect correlated attacks that target multiple sensors.
Content may be subject to copyright.
A honeypot-driven cyber incident monitor:
lessons learned and steps ahead
Emmanouil Vasilomanolakis
*, Shankar Karuppayah
§, Panayotis Kikiras*, Max Mühlhäuser
Telecooperation Group, §National Advanced IPv6 Center, *AGT International,
TU Darmstadt - CASED Universiti Sains Malaysia Darmstadt, Germany
In recent years, the amount and the sophistication of cyber
attacks has increased significantly. This creates a plethora
of challenges from a security perspective. First, for the effi-
cient monitoring of a network, the generated alerts need to
be presented and summarized in a meaningful manner. Sec-
ond, additional analytics are required to identify sophisti-
cated and correlated attacks. In particular, the detection of
correlated attacks requires collaboration between different
monitoring points. Cyber incident monitors are platforms
utilized for supporting the tasks of network administrators
and provide an initial step towards coping with the afore-
mentioned challenges.
In this paper, we present our cyber incident monitor TraC-
INg.TraCI N g obtains alert data from honeypot sensors dis-
tributed across all over the world. The main contribution of
this paper is a thoughtful discussion of the lessons learned,
both from a design rational perspective as well as from the
analysis of data gathered during a five month deployment
period. Furthermore, we show that even with a relatively
small number of deployed sensors, it is possible to detect
correlated attacks that target multiple sensors.
Categories and Subject Descriptors
H.4 [Information Systems Applications]: Miscellaneous;
C.2.0 [Computer-Communication Networks]: General:
Security and Protection
General Terms
Incident Monitor; Honeypot; Alert Correlation; Cyber Se-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee. Request
permissions from
SIN ’15, September 08 - 10, 2015, Sochi, Russian Federation
Copyright 2015 ACM 978-1-4503-3453-2/15/09 $15.00
With the increase of cyber attacks in both numbers, as
well as in sophistication, it is becoming evident that more
advanced techniques and mechanisms are required to de-
tect attacks and to identify new trends and patterns in the
adversaries’ strategies. This also implies that relying only
upon traditional lines of defense, such as Intrusion Detec-
tion Systems (IDSs) and dynamic firewalls alone, would not
be able to provide a holistic coverage on detecting novel and
emerging patterns of attacks [20].
probed, attacked or compromised [16]. They can comple-
ment other detection mechanisms, e.g., IDSs, by providing
a more active and in-depth view on attackers’ activities. At
the same time, by definition, honeypots produce zero false
positives and they are able to detect even unknown and
novel attacks. They can be classified based on the level
of interaction that is offered to attackers. On the one hand,
high-interaction honeypots are real systems that exhibit cer-
tain vulnerabilities. Thus, they require constant monitoring
and their maintenance is very demanding. On the other
hand, low-interaction honeypots, simulate network opera-
tions on the TCP/IP stack level, and therefore can provide
a lightweight and straightforward defense mechanism.
Feeding honeypot alert data into a cyber-incident moni-
tor provides a number of significant benefits. As mentioned
above, in contrast to IDSs, honeypots do not produce false
positives. Therefore, the security administrator can focus
on real attacks rather than speculating from the observed
results. In addition, observing epidemic behavior, e.g., mal-
ware spreading, becomes more likely when analyzing attacks
from several collaborating honeypots.
In essence, the inclusion of different type of alerts, e.g.,
from IDSs and honeypots, increases the affluence of new
data to be processed by the administrators. However, due to
the different focus and content of alerts generated by differ-
ent systems, integrating these alerts into a single platform,
creates a multitude of challenges. Cyber incident monitor-
ing systems are developed to overcome this problem by pro-
viding an aggregation and visualization interface to unify
the various alert generators into a single system that assists
the user to make informed decisions. Starting from a broad
overview, users can decide to dive into specific alerts to as-
sess a particular reported cyber incident.
Not much work has been done that specifically focuses on
the design of a cyber incident monitor, or the lessons learned
from its usage. Dshield1, and honeymap2are two examples
of monitors that publish their data openly through the In-
ternet. In [7], Katti et al. provide a wide-scale analysis
focusing on correlated attacks. Even though their work can
be considered slightly outdated, it is the basis on which we
establish the definitions of correlated attacks (cf. Section
3.3). Some work has also been conducted towards provid-
ing an analysis of the lessons learned from such distributed
monitoring deployments [9, 11] and honeypots [8]. However,
most of this work focuses only on presenting basic attack
statistics and does not consider correlated attacks.
In this paper, we present TraCINg3, which stands for TU
Darmstadt Cyber Incident moNitor, and is an open-source
centralized cyber incident monitor that supports a number
of different types of honeypots. Tra CINg is able to visual-
ize attacks, provide statistics, present the geo-location infor-
mation of malicious users, and perform several other user-
centric operations. We explain the design rational of our
system and discuss the initial results from a five month de-
ployment period. Our results, indicate a multitude of inter-
esting findings. First, we notice many attack trends such as
the most popular protocols and ports, the most persistent
countries of origin, etc. Second, we observe that even with
a relatively small deployment of sensors, it is still possible
to detect attacks manifested by the same source on multiple
sensors. Furthermore, these correlated attacks motivate the
need for collaboration between different monitoring points
in detecting targeted or distributed attacks.
The remainder of this paper is organized as follows: In
Section 2, we describe our system’s design and provide jus-
tification behind the various design choices that we made.
Section 3, provides insights and an analysis of our findings
for a deployment period of five months. Section 4, discusses
the lessons learned from our experience with the cyber in-
cident monitor, problems that we faced, as well as hints on
how to overcome them. Finally, Section 5 concludes this
In this section, we provide a description of TraC IN g ’s de-
sign, including three main parts: the architecture, the dif-
ferent types of supported honeypot sensors, and the alert
2.1 Architecture and Design
TraCI N g is an open-source centralized cyber incident mon-
itor that obtains alert data from geographically distributed
honeypot sensors. In our system, sensors are currently de-
ployed in three different continents, namely: Europe, Asia
and the America. Tra CINg follows a classic client-server
architecture and uses an HTTPS server for receiving data,
along with a Public Key Infrastructure (PKI) for the authen-
tication of the sensors. The front-end, written in node.js[17],
supports the integration of, e.g., OpenStreetMap [6] for the
visualization of attack origins and targets (cf. Figure 1(b))
and VirusTotal4for obtaining additional information on iden-
tified malware.
All gathered information is available to security adminis-
trators via a user-centric GUI with a plethora of different
views (two of them shown in Figure 1) and functions, e.g.,
the creation of statistics, on-demand detailed information,
live and replay mode of the alert data, etc.
(a) Default TraCINg view
(b) OpenStreetMap integration
Figure 1: TraCINg GUI examples
2.2 Sensors
TraCI N g supports and utilizes a number of sensors that
can be distinguished into two main types: dionaea honey-
pots and mobile honeypots. Here, we shortly discuss these
types of honeypots along with the implementation specifics
of our sensors.
Dionaea Honeypots.
Our main detection mechanism uses the dionaea5low-
interaction honeypot, that is considered to be the state of
the art in its honeypot class, i.e., low-interaction [15]. We
utilized dionaea honeypots in two different ways. First,
we deployed dionaea on regular machines, i.e., virtual ma-
chines (VMs), as well as Raspberry Pis. The latter allows
for an easy copying of systems, to be able to reuse them, and
introduces convenient plug-n-play support for the sensors.
Second, we also deployed some dionaea sensors as cloud
instances. This is important for being able to monitor attack
traffic that may be specific to geographical regions. Thus,
via the utilization of cloud providers, we were able to deploy
our sensors in different continents. Furthermore, cloud ser-
vices provide resilience and uptime reliability for our sensors
which ensures uninterrupted monitoring.
Mobile Honeypots.
TraCI N g also provides support for obtaining data from
mobile honeypots, i.e., from HosTaGe which is developed
by us in our former work [19, 18]. HosTaGe is a lightweight
low-interaction honeypot for mobile devices for detecting
malicious wireless network environments. The motivational
idea behind HosTaGe is to alert users on the security status
of the wireless network they are connected to. In addition,
the combination of HosTaGe’s collaboration techniques and
synchronization with TraC I Ng, creates additional benefits
for the users. For instance, users can learn from others,
about the global security status of wireless networks in their
city, or country. Moreover, the diverse data that is sent to
TraCI N g can also provide us with valuable and more accu-
rate input for the detection of correlated attacks and latest
trends from the behavior of malicious users and malware.
2.3 Alerts
TraCI N g supports input from any type of honeypot or
IDS, with the only restriction being to utilize the respec-
tive input interface for submitted alerts. Sensors need to
convert their alerts into a well-determined JSON6format
that is being supported by the input interface. Therefore,
it is straightforward to add support for other honeypots.
For instance, to enable TraC INg support for the dionaea
honeypot, we implemented the respective alert export func-
tionality as an internal dionaea module.
Another important property, that is related to alerts, is
the frequency of the exchanged alerts. In the current version
of our system, alert data is sent instantaneously upon the
detection of an attack by the honeypot to TraC I Ng,except
for HosTaGe honeypots in which, the exchange frequency is
determined by the user or by the auto-upload functionality
(when the mobile device has Internet connectivity, e.g., via
a wireless network). Take note that the frequency of the ex-
changed alerts could also lead to some attacks on the sensors
(cf. Section 4 Probe-Response attacks).
The generated alerts that are submitted to TraCI N g con-
tain the following attributes:
Time-stamp: The date and time specifics of an attack.
Id: A unique identifier for each alert.
Sensor Type: A field that differentiates between dif-
ferent honeypots, e.g., dionaea, HosTaGe, etc.
IP: The source and destination IP address of attacks
(this information is excluded from the end-users’ per-
spective, i.e., from the GUI, to maintain privacy).
Ports: The source and destination port of attacks.
Attack type: The type of the detected attack, e.g., a
portscan, a shellcode injection, etc.
Geo-location Information: The geo-IP information, and
the name of the city and country.
Authorization Status: A boolean id that indicates whether
a sensor posses a signed certificate from the main TraC-
INg Certificate Authority (CA) via the usage of a PKI.
MD5 hash: The MD5 hash of the malware collected
from a honeypot (when applicable).
Log : Whenever possible, the whole communication be-
tween the attacker and the sensor is logged, and can
be presented to the user on demand.
In this section, we present the results of a five month ob-
servation period (March to July 2014) of TraC I Ng with a
total of five sensors deployed in three different continents.
3.1 System Setup
During the period of our analysis, we collected data from
five different honeypots that were continuously monitoring
and sending alerts to TraCI N g. The specifics of our deployed
sensors are summarized in Table 1. In more details, two
sensors were located in Malaysia within a /24 sub-network.
In addition, two sensors were deployed as cloud instances
in USA within different /8 networks. Finally, one sensor
was deployed in Greece. As we will also discuss in Section
3.3, the dynamics of the alert data are important for the
subsequent analysis of the attacks, especially in a correlated
Sensor Name Country Common Subnet Prefix
MY-01 Malaysia /24
MY-02 Malaysia
USA-01 USA /8
GR Greece -
Table 1: Sensor description
For our analysis, we restrict our evaluation to the station-
ary deployed dionaea honeypots only. Data gathered from
our mobile honeypots was removed as the number of users
making use of the mobile honeypot, at that time, was im-
mature (and restricted only to Germany). Thus this would
introduce bias into our analysis. Nevertheless, our analysis
shows that even with a relatively low number of sensors, a
large amount of distributed and correlated attacks can be
A preliminary overview of recent results gathered from us-
age of mobile honeypots, between March and May of 2015,
is as following. Approximately 1000 alerts were sent from
four different countries (i.e., Germany, United Arab Emi-
rates, Italy, and Columbia). In a glance, 62% of the attacks
were shellcode injection, 24% were targeting the TELNET
protocol, 6.6% were targeting HTTP, and finally 4% were
MySQL brute-force attacks.
3.2 Data analysis
In total, our sensors recorded 898,570 alerts during the
examined period, from 30,101 distinct IP addresses, hav-
ing their origin in 146 different countries. However, it is
interesting to note that attacks from USA and China alone,
represented about 80% of the total number of alerts recorded
by our system. Nevertheless, we have verified that this ob-
servation is not influenced by the geographical location of
the deployed sensors.
Table 2, presents a summary of the most popular attack
types along with the number of attack occurrences. The
attack description column of the table depicts the specifics
of the attacks. In this case MySQL,MS SQL,VOIP,and
SMB refer to malicious activity specific to these protocols,
Figure 2: Graph representation of the alert data: attackers clustered close to their main targets and single-
dimensional correlation seen as edges connecting to neighbor clusters
Attack Description Total Number of Attacks
Portscan 507,571
MySQL 156,960
Transport Layer 116,414
VoI P 84,641
SMB 30,239
MS SQL 2,325
Shellcode Injection 420
Table 2: Most popular attack types and the corre-
sponding number of occurrences
Port Protocol/Service Number
of Attacks
135 RPC 24,667
139 NetBIOS 20,249
23 Tel n e t 11,058
80 HTTP 10,735
445 SMB 9,294
443 HTTPS 3,400
25 SMTP 2,558
21 FTP 1,658
110 POP3 1,153
143 IMAP 597
Table 3: Top 10 attacked ports and protocols
e.g., a brute-force attack. Moreover, the Transport Layer
describes cases in which the adversary connected to a port,
but no further activity was possible due to honeypot-related
limitations, e.g., dionaea not being able to handle the con-
nection. With respect to dionaea’s VOIP emulation capa-
bilities [21], the majority of the detections were brute-force
attacks and scans conducted with tools such as SipCli7.
In addition, Table 3 shows the most targeted ports and
protocols. A number of findings come as a result of our anal-
ysis. First, around 56% of the total attacks were portscans.
This can be considered as something that is expected, es-
pecially with the rise of open source Internet-wide network
scanners, e.g., ZMap [4]. In addition, it should be noted
that bias can be introduced from such tools when utilized
by researchers. Nevertheless, we consider this insignificant
with regards to the overall analysis. Second, most of the de-
tected MySQL attacks were brute-force attacks using default
user-names and passwords. The most prominent one being
a combination of root as a user-name along with a blank
password. Moreover, Table 3 indicates that several attacks
targeting Windows OS specific protocols and services, e.g.,
the MS-RPC,andNetBIOS, are still prominent. This also
confirms that several old worm variants, e.g., Conficker [12],
still hold an imposing position in the overall attack prop-
agation scene. Lastly, we identified that a number of the
attacks that were targeting Telne t were conducted by inse-
cure/infected embedded devices, e.g., IP web-cams.
3.3 Correlation of attacks
We classify correlated attacks in a twofold manner, differ-
entiating between single-dimensional and a two-dimensional
correlation of attacks, by following a similarity-based strat-
egy [5]. Single-dimensional correlation, groups attacks with
the same origin, e.g., the same source IP address. Thus, it
can be defined as the set of alerts originating from the same
source IP address that target more than one sensor through-
out our observation, i.e., the entire observed duration of five
months. Two-dimensional correlation includes time as an
additional parameter, i.e., attacks that are observed within
a specific time window.
7SipCli VoIP audit tool:
Single-dimensional correlation.
The analyzed dataset can be modeled as a directed graph
G=(V,E), where the set of nodes Vrepresent all IP ad-
dresses involved in the detection process, i.e., both sensors
and malicious users. The origin and the target nodes of an
attack, are represented as a set of directed edges (u, v)with
u, v V, that exist between the nodes.
Figure 2, is a representation of our alert dataset, that de-
picts two major findings: attack origins can be clustered,
by vicinity, into three clusters and the single-dimensional
correlation can be seen as the edges that connect to neigh-
boring clusters. Specifically, the dataset was transformed to
a directed graph with 30,106 nodes representing all distinct
IP addresses (both sensors and malicious users), while edges
correspond to the respective connections, i.e., adversaries
connecting to the sensors. Figure 2 depicts, in a glance, an
overview of the activities in our dataset.
The five different sensors (differentiated by distinct col-
ors) converge into the three main clusters. The clustering
is done based on the geo-location information of the sensors
(cf. Section 3.1). As such, from the five deployed sen-
sors, four of them were coupled into clusters of two. This
is also explained in our system setup description in Section
3.1. The Malaysian sensors (within a /24 network) create
tightly coupled clusters due to the high percentage of com-
mon attackers. In addition, we observe that the two sensors
in the USA, even though having distinct /8 networks, are
also close to each other. Figure 2, also clusters the attackers
based on the intensity of the alerts/attacks observed origi-
nating from them, i.e., nodes are placed closer to the sensors
they attacked intensively. Moreover, single-dimensional cor-
relation is observed when edges of a cluster (same color), are
connecting to neighboring clustering groups, i.e., an adver-
sary targeting multiple sensors.
A similar analysis, from another perspective, on the ratio
of single-dimensional correlation is shown in Figure 3. In
more details, we plot the relationship between the percent-
age of unique attackers and the targeted sensors. Almost
50% of the total number of attacks target at least two dif-
ferent sensors, during the five month period under inves-
tigation. However, a portion of this finding might be due
to the ’closeness’ of two sensors, i.e., sensors located within
the same /24 sub-network. Nevertheless, as we discuss in
the following section, even with the inclusion of time as a
parameter, we observe an almost continuous attacking be-
havior on multiple sensors simultaneously.
Two-dimensional correlation.
In single-dimensional correlation, the basis for our anal-
ysis is exclusively based on the source IP address of the
adversaries. While this is reasonable, we argue that the
time frame in which attacks take place is also an impor-
tant factor that needs to be taken into account. There is
a significant difference between distributed attacks target-
ing multiple widespread sensors within a small time window
and the ones that target multiple sensors across longer time
period, i.e., days or even weeks.
Figure 4 presents the number of unique attackers target-
ing multiple sensors within a short time frame. In more
details, this two-dimensional correlation, is measured with
a sliding window of one hour (measurements taken every 30
minutes). The 30 minutes time interval takes into account
the state of the art in IPv4 network scanning. As of now
Figure 3: Ratio of unique attackers targeting multi-
ple sensors
Figure 4: Unique attackers within a sliding window
of one hour and with measurements taken every 30
one of the fastest Internet-wide scanners is a able to scan
the IPv4 address space in approximately 45 minutes (via a
random cyclic selection of IP addresses) [4]. Thus, with our
chosen time interval we attempt to reduce bias introduced
by researchers’ activities utilizing such mechanisms.
We note that for the sake of clarity, we applied vertical
jitter to the points in the plot. Moreover, we also restricted
the figure to only two months (May to July 2014) of the
overall period. Nevertheless, similar activity was observed
for the removed time-frame. Throughout the observations,
we notice a pattern of attacking behavior in which, at least
one unique attacker is targeting three or four different sen-
sors (within a 30 minutes observation window). Further-
more, there are also cases in which, up to four different
adversaries targeted three sensors. Cases like this, might
indicate the discovery of a new vulnerability and thus the
possibility of extensive scans over the Internet for exploitable
insecure systems. Finally, the majority of two-dimensional
correlation was portscans. In addition, for the cases of three
and five overlapping sensors, we also detected MySQL and
VOIP brute-force attacks.
In this section, we discuss the lessons learned and the
shortcomings that we encountered during the design, as well
as the deployment phase of our cyber incident monitor.
Correlated attacks and number of sensors.
Although our system is already able to detect correlated
attacks, we believe that its accuracy can be further im-
proved. When sensors are sparsely deployed in the IP space,
we may miss out correlated attacks simply because the time
taken to observe such an attack is too long, e.g., more than
30 minutes. Therefore, the accuracy and efficiency of our
system, i.e., the required time to detect correlated attacks,
can be improved by increasing the number of sensors. This
ensures that epidemic worm propagation and new vulner-
abilities can be detected at a faster rate than the current
implementation. Thus, we plan to deploy more sensors and
distribute them uniformly across the various classes of IP
address, i.e., /8 and /16 sub-networks. Moreover, the idea
behind collecting alerts from mobile honeypots (cf. Section
2.2) also further bridges this gap of being able to detect cor-
related attacks more accurately and in a shorter time frame.
While performing stress tests to our system with a high
load of incoming traffic, e.g., more than 50Kof alerts per
day, we observed a bottleneck that relied in the utilized
database (which was not always able to handle these re-
quests). Thus, our initial decision to use a SQLite database
during the proof of concept phase was no longer relevant
with an increased number of alerts or sensors. We migrated
our alerts and re-deployed on MongoDB that is now able to
cater our current scenarios better and also facilitate future
An interesting real world example of such an attack peak
was during the first quarter of April 2014. During that
timespan our cyber incident monitor had been receiving al-
most 40,000 alerts per day, with alerts being either portscans
or targeting the transport layer. We assume that this was
not a coincidence but rather related with the well known
heartbleed OpenSSL vulnerability [2], that was discovered
during the aforementioned days.
Although our system design provides real-time visualiza-
tion of the alerts, which is contributed by its centralized
architecture, it also presents itself as a single point of fail-
ure. Moreover, the architecture itself will turn into a bot-
tleneck when the number of new sensors is massively in-
creased, hence affecting the scalability of the system itself.
We envision a new version of our system that utilizes a com-
pletely decentralized architecture and will be able to include
additional new sensors while providing increased resilience,
redundancy and scalability to the overall system.
Probe-Response attacks.
Recently research has been conducted [13, 14, 3] that fo-
cuses on methods that can be utilized by attackers to suc-
cessfully detect monitoring sensors that publish their find-
ings publicly via the Internet. In these attacks, so-called
probe-response attacks, the adversary produces alerts that
contain a unique watermark and starts disseminating them
over the IP address space that the attacker considers as pos-
sible for including sensors. The malicious user can subse-
quently compare the results produced from the cyber in-
cident monitor, for the specified time period in which the
probe-response attack is performed, and thus be able to cre-
ate a list of possible addresses of sensors via a reductio ad
absurdum method.
Probe-response attacks have not been implemented in the
wild by malware. However, a malware with such capabilities
would be able to evade a large amount of cyber-incident sen-
sors and thus it will be more likely to spread unnoticed for a
longer time period. Moreover, as reported in [14], defending
against such attacks is not a trivial task. As such, han-
dling probe-response attacks will be one of the main consid-
erations of our future work. For instance, countermeasures
might include the addition of noise data to the publicly pub-
lished results, by following a uniform random distribution.
In addition, these attacks assume a public exposure of the
alert data, and thus can be avoided via an internal usage of
Honeypot-specific issues.
During our honeypot deployment we encountered vari-
ous problems that are related to the dionaea honeypot it-
self, and should be considered for such deployments. First,
nowadays many honeypots (including dionaea, nepenthes
[1], etc.) can be detected relatively easily with network scan-
ning tools such as nmap [10]. Therefore, researchers should
consider changing the default parameters of such honeypots.
For instance, a honeypot with many conflicting ports active
(e.g., Windows and Linux OS specific ports simultaneously
active), is easier to be detected. Second, in some cases,
portscans have to be handled carefully. In more details, a
default dionaea installation will react to a portscan by acti-
vating services for each of the scanned ports. In the worst
case scenario, this may result to approximately 65,000 ser-
vices (i.e., all the possible port numbers) activated for each
scanned IP address. Thus, techniques to prevent such cases
should be taken into account (e.g., dionaea does offer solu-
tions for this problem).
Privacy and Trust.
As part of our future goal to enrich our system with a
more diverse selection of sensors, we need to ensure that the
privacy of data from external contributors, e.g., individual
users or organizations, is assured. We plan to provide this
by including a level of filtering and obfuscation that ensures
that private information, e.g., real IP addresses, are filtered
and not stored in our system’s database. Inclusion of new
and unknown sensors to our system may lead to internal at-
tacks, e.g., alert spoofing. These attacks could in turn affect
the accuracy of the entire system. Nevertheless, we plan to
overcome such attacks by deploying a trust mechanism be-
tween the participating sensors along with the existing PKI,
to ensure that the authenticity of sensors is always ensured
before accepting alerts in our system.
Distribution of Sensors.
An observation made after deploying our sensors in the
cloud was that in some cases, we received large amounts of
alerts due to attacks that seemed to be targeting particu-
larly the cloud vendor itself. More specifically, we detected
a Distributed Denial of Service (DDoS) while we were ex-
perimenting with the deployment of sensors in the same
cloud provider; yet in totally different geographical loca-
tions. Therefore, it should be noted that although many
cloud providers offer deployment of instances all over the
world, the range of IP addresses that is utilized is specific
and in many cases, well known to malicious entities. More-
over, if sensors are only placed within a single cloud provider,
this may introduce bias in the final results; attacks that tar-
geted only the cloud provider(s) might be misinterpreted as
though they were attacks taking place all over the globe.
Sophisticated adversaries as well as the increased number
of attacks in general, create challenges both in the detec-
tion and the analysis phase. Furthermore, the successful de-
tection of correlated attacks, requires the collaboration be-
tween different monitoring points. Cyber incident monitors
provide a way for researchers and security administrators to
efficiently create a holistic view of their monitored networks.
In this paper, we presented a cyber incident monitor,
TraCI N g, that is driven by honeypots. We discuss about its
architecture and the various design choices that were made.
In addition, we provide an analysis of data gathered from
TraCI N g, during a period of five months. Our alert data
analysis indicates a plethora of findings: first, many attacks
target protocols that are considered as deprecated, e.g., Tel-
net, are still prominent, while newer protocols, e.g., VOIP,
also begin to experience increased attacks. Second, we ob-
serve large-scale portscans that, as a result of our correlation
analysis, appear to target a wide range of IP addresses.
We would like to thank ISLAB from the National Center
for Scientific Research“Demokritos” (Greece), as well as the
Malaysian Research and Education Network (MYREN) for
their support during the honeypot deployment phase.
[1] P. Baecher, M. Koetter, T. Holz, M. Dornseif, and
F. Freiling. The nepenthes platform: An efficient
approach to collect malware. In Recent Advances in
Intrusion Detection, pages 165–184. Springer, 2006.
[2] M. Carvalho, J. Demott, R. Ford, and W. David.
Heartbleed 101. Security & Privacy, IEEE,
12(4):63–67, 2014.
[3] S. Cheung. Securing collaborative intrusion detection
systems. IEEE Security and Privacy, 9(6):36–42, 2011.
[4] Z. Durumeric, E. Wustrow, and J. A. Halderman.
ZMap: Fast Internet-wide Scanning and Its Security
Applications. In Proceedings of the 22nd USENIX
Security Symposium, pages 605–619, 2013.
[5] H. T. Elshoush and I. M. Osman. Alert correlation in
collaborative intelligent intrusion detection
systems—A survey. Applied Soft Computing,
11(7):4349–4365, Oct. 2011.
[6] M. Haklay and P. Weber. OpenStreetMap:
User-Generated Street Maps. Pervasive Computing.
IEEE Pervasive Computing, 7(4):12–18, 2008.
[7] S. Katti, B. Krishnamurthy, and D. Katabi.
Collaborating against common enemies. In 5th ACM
SIGCOMM Conference on Internet Measurement -
IMC, New York, New York, USA, 2005. ACM Press.
[8] G. Kelly and D. Gan. Analysis of Attacks Using a
Honeypot. In International Cybercrime, Security and
Digital Forensics Conference. Springer, 2011.
[9] I. Koniaris, G. Papadimitriou, P. Nicopolitidis, and
M. Obaidat. Honeypots deployment for the analysis
and visualization of malware activity and malicious
connections. In International Conference on
Communications (ICC), pages 1819–1824. IEEE, 2014.
[10] G. F. Lyon. Nmap Network Scanning: The Official
Nmap Project Guide to Network Discovery and
Security Scanning. Insecure, 2009.
[11] K. Ohno, H. Ko, and K. Koizumi. IPMatrix : An
Effective Visualization Framework for Cyber Threat
Monitoring. In Proceedings of the Ninth International
Conference on Information Visualisation, 2005.
[12] S. Shin and G. Gu. Conficker and beyond: a
large-scale empirical study. In 26th Annual Computer
Security Applications Conference, pages 151–160,
[13] Y. Shinoda, K. Ikai, and M. Itoh. Vulnerabilities of
passive internet threat monitors. In 14th USENIX
Security Symposium, pages 209–224, 2005.
[14] V. Shmatikov and M.-H. Wang. Security against
probe-response attacks in collaborative intrusion
detection. In Workshop on Large scale attack defense -
LSAD, pages 129–136, New York, New York, USA,
2007. ACM.
[15] T. Sochor and M. Zuzcak. Study of internet threats
and attack methods using honeypots and honeynets.
In Computer Networks, pages 118–127. Springer, 2014.
[16] L. Spitzner. Honeypots : Catching the Insider Threat.
In Computer Security Applications Conference,pages
170–179. IEEE, 2003.
[17] S. Tilkov and S. Vinoski. Node. js: Using javascript to
build high-performance network programs. IEEE
Internet Computing, 14(6):0080–83, 2010.
[18] E. Vasilomanolakis, S. Karuppayah, M. Fischer,
M. M¨
auser, M. Plasoianu, L. Pandikow, and
W. Pfeiffer. This Network is Infected : HosTaGe - a
Low-Interaction Honeypot for Mobile Devices. In
Security and privacy in smartphones & mobile devices,
pages 43–48. ACM, 2013.
[19] E. Vasilomanolakis, S. Karuppayah, M. M¨
and M. Fischer. HosTaGe: a Mobile Honeypot for
Collaborative Defense. In 7th International Conference
on Security of Information and Networks (SIN).
ACM, 2014.
[20] E. Vasilomanolakis, S. Karuppayah, M. M¨
and M. Fischer. Taxonomy and Survey of
Collaborative Intrusion Detection. ACM Computing
Surveys, 47(4):33, 2015.
[21] M. Voznak, J. Safarik, and F. Rezac. Threat
Prevention and Intrusion Detection in VoIP
Infrastructures. International Journal of Mathematics
and Computers in Simulation, 7(1), 2013.
... Similarly, Lallie et al. [14] revealed the absence of standardization, ambiguous semantics, and inadequacy of scientific approach towards the visualization design based on cognitive theories, concluding that many AMTs have not undergone an effective design process [14]. Ikuomenisan and Morgan [59] outlined rare implementations of customized visualization techniques (Hilbercurve for honeypot data analysis [65], honeypot driven cyberincident monitor [66], bipartite graph visualization applied to IDS alerts [67], visualization of actionable knowledge for DRDoS mitigation [68]) as a positive development for pattern discovery and perceptual experience and called for further research in the field. Lallie et al. [14] noted that ineffective design leads to cognitively inefficient systems and attributed the fragmentation of efforts to the immaturity of the research field. ...
Full-text available
Cybersecurity research demands continuous monitoring of the dynamic threat landscape to detect novel attacks. Researchers and security professionals often deploy honeypot networks to intercept and examine real attack data. However, due to the volume and variety of the collected data, it is very challenging for security analysts to investigate the attacks, compare their characteristics and infer their potential connections. To this end, we propose a novel graph-based cyberattack model for storing, analyzing, and visualizing honeynet-captured attacks as the main contribution of our work. Our model enables attack graph analysis and presents the attack data analogous to the Cyber Kill Chain framework to enable intuitive visualizations. We construct the attack graph by decomposing the intercepted attacks into a set of unique entities (represented as nodes) and actions (represented as edges) and merge them into a global attack graph. We develop a user-centric, interactive attack analysis and visualization tool that leverages the proposed model to aid the heuristic cyberattack investigation. We describe the design and technical implementation of the developed model and visual-interactive tool in detail. Finally, we demonstrate the developed tools and validate the model in an analysis of real-world attack data captured on our own distributed honeypot platform. We use the attack model and (sub)graph visualizations to depict attack topologies, identify recurring attackers, and quantify detected malware types. We also leverage graph data science algorithms to uncover and rank malware distribution networks, reveal hidden links between the attackers, and cluster the attack entities to identify potential botnets.
... Their presented work is a thoughtful discussion of the lessons learned, both from a design rational perspective as well as from the analysis of data gathered during a five month deployment period. Furthermore, they show that even with a relatively small number of deployed sensors, it is possible to detect correlated attacks that target multiple sensors [6]. Amit D. Lakhani, Dr. Kenneth G. Paterson et al. present a work that focuses on the data anomaly detection challenge in honeypots. ...
Conference Paper
Full-text available
With increasing number of data thefts courtesy of new and complex attack mechanisms being used everyday, declaring the internet as unsafe would be the understatement of the century. For current security experts the scenario is equivalent to an endless cat-and-mouse game across a constantly changing landscape. Hence relying on firewalls and anti-virus softwares is like trying to fight a modern, well-equipped army using sticks and stones. All that an attacker needs to successfully breach our system is the right social networking or the right malware used like a packing or encoding technique that our tools won't detect. Therefore it is the need of the hour to shift our focus beyond edge defense, which largely involves validating the tools, and move towards identification of a breach followed by an appropriate response. This is achieved by implementing an ethereal network which is an end-to-end host and network approach that can actually scale as well as provide true breach detection. The objective is not just blocking; it is significant time reduction. When mundane methods involving firewalls and antiviruses fail, we need to determine what happened and respond. Any industry report uses the term weeks, months, and even years to determine the time of response, which is not good enough. Our goal is to bring it down to hours. We are talking about dramatic time reduction to improve our response, hence an effective breach detection approach is mandatory. A MHN (Modern Honey Network) with a honeypot system has been used to make management and deployment easier and to secure the honeypots. We have used various honeypots such as Glastopf, Dionaea honeypots, Kippo. The dubious activity will be recorded and the attacks details detected in MHN server. The final part of our research is reconnaissance. Since it can be awfully complicated we simplify the process by having our main focus on reconnaissance. Because if a malware or an insider threat breaks into something, they don't know what they now have access to. This makes them feel the need to do reconnaissance. So, focusing on that behaviour provides us a simple way to determine that we have some unusual activity-whether it is an IOT device that has been compromised or whatever it may be, that has breached our network. Finally we deploy MHN, deploy Dionaea, Kippo, Snort honeypots and Splunk integration for analyzing the captured attacks which reveals the service port under attack and the source IP address of the attacker.
Full-text available
Increasingly, cyber security personnel are using cyber deception defense techniques to deal with network intrusions. However, traditional cyber deception techniques (such as honeypots and honeynets) are easily detected by attackers, thus leading to failure. Therefore, we propose a cyber deception defense method based on the signal game to improve the effectiveness of the defense. More specifically, first, we propose a moving target defense (MTD) enhanced cyber deception defense mechanism. Then, on the basis of the in-depth analysis of network attack and defense scenarios, a signal game model is constructed to describe the network attack and defense process, and a multistage attack and defense game equilibrium solution method is designed to guide the selection of the optimal deception defense strategy. Meanwhile, considering the actual network attack and defense, we quantify the game revenue based on a probabilistic model. The experimental results show that the defense method proposed in this paper could guide the defender to implement the optimal defense strategy and achieve a better defense effect.
In today’s world, cyber-attacks are becoming highly complicated. The hacker intends to expose sensitive information or potentially change the operation of the targeted machine. Cybersecurity has become a major bottleneck to the on-demand service’s growth since it is widely accessible to hackers for any type of attack. Traditional or existing intrusion detection systems is proving unreliable due to heavy traffic and its dynamic nature. A honeypot is a device that exposes a server or network that has vulnerabilities to the internet and collects attack information by monitoring and researching the techniques used by attackers. In this paper, we setup an effective active protection architecture by integrating the usage of Docker container-based technologies with an enhanced honeynet-based IDS. T-Pot platform will be used to host a honeynet of different honeypots in the real-time AWS cloud environment. The development of this honeynet methodology is essential to recover threat identification and securing the cloud environment. Moreover, the experiment results reveal that this defending mechanism may detect and log an attacker’s behavior which can expose the new attack techniques and even zero-day exploits.KeywordsCyber securityIntrusion detection systemHoneynetAWS cloudDocker
In this article, we propose a novel method that aims to improve upon existing moving-target defences by making them unpredictably reactive using probabilistic decision-making. We postulate that unpredictability can improve network defences in two key capacities: (1) by re-configuring the network in direct response to detected threats, tailored to the current threat and a security posture, and (2) by deceiving adversaries using pseudo-random decision-making (selected from a set of acceptable set of responses), potentially leading to adversary delay and failure. Decisions are performed automatically, based on reported events (e.g., Intrusion Detection System (IDS) alerts), security posture, mission processes, and states of assets. Using this codified form of situational awareness, our system can respond differently to threats each time attacker activity is observed, acting as a barrier to further attacker activities. We demonstrate feasibility with both anomaly- and misuse-based detection alerts, for a historical dataset (playback), and a real-time network simulation where asset-to-mission mappings are known. Our findings suggest that unpredictability yields promise as a new approach to deception in laboratory settings. Further research will be necessary to explore unpredictability in production environments.
Due to the nature of cybersecurity data science (CSDS) as a novel field emerging in the midst of rapid technological change, there is a gap in CSDS-focused organizational research. Challenges operationalizing CSDS solutions lead to a call for an increased theoretical focus on organizational problem-solving research. To address this gap, CSDS fits the profile of an organizational problem that is “relatively new or fairly complex,” necessitating an effort to “clarify the relevant background and the reasons for the problem” (Doorewaard and Verschuren 2010).
Honeypots act as an easy target for attackers but it is actually a “decoy” in which attacker is trapped. It is a defensive technique which lures the attacker into performing some illicit operations on it and subsequently using it to trace the activities of attacker, generating signatures and protecting the real system. In this article, a recent survey on Honeypots is presented, its deployment in smartphone scenarios, its usage to curb Distributed Denial of Service attacks in variegated frameworks including Cloud environments, copious datasets and open source. Also described are the types Honeypots available, their various security problems, and existing solutions. Furthermore, there is light shed on disparate issues and the challenges in the existing solutions and scope of further research.
Full-text available
The dependency of our society on networked computers has become frightening: In the economy, all-digital networks have turned from facilitators to drivers; as cyber-physical systems are coming of age, computer networks are now becoming the central nervous systems of our physical world—even of highly critical infrastructures such as the power grid. At the same time, the 24/7 availability and correct functioning of networked computers has become much more threatened: The number of sophisticated and highly tailored attacks on IT systems has significantly increased. Intrusion Detection Systems (IDSs) are a key component of the corresponding defense measures; they have been extensively studied and utilized in the past. Since conventional IDSs are not scalable to big company networks and beyond, nor to massively parallel attacks, Collaborative IDSs (CIDSs) have emerged. They consist of several monitoring components that collect and exchange data. Depending on the specific CIDS architecture, central or distributed analysis components mine the gathered data to identify attacks. Resulting alerts are correlated among multiple monitors in order to create a holistic view of the network monitored. This article first determines relevant requirements for CIDSs; it then differentiates distinct building blocks as a basis for introducing a CIDS design space and for discussing it with respect to requirements. Based on this design space, attacks that evade CIDSs and attacks on the availability of the CIDSs themselves are discussed. The entire framework of requirements, building blocks, and attacks as introduced is then used for a comprehensive analysis of the state of the art in collaborative intrusion detection, including a detailed survey and comparison of specific CIDS approaches.
Conference Paper
Full-text available
The continuous growth of the number of cyber attacks along with the massive increase of mobile devices creates a highly heterogeneous landscape in terms of security challenges. We argue that in order for security researchers to cope with both the massive amount and the complexity of attacks, a more pro-active approach has to be taken into account. In addition, distributed attacks that are carried out by interconnected attackers require a collaborative defense. Diverging from traditional security defenses, honeypots are systems whose value lies on in being attacked and compromised. In this paper, we extend the idea of HosTaGe, i.e., a low interaction honeypot for mobile devices. Our system is specifically designed in a user-centric manner and runs out-of-the-box in the Android operating system. We present the design rational and discuss the different attack surfaces that HosTaGe is able to handle. The main contribution of this paper is the introduction of the collaborative capabilities of HosTaGe.
Conference Paper
Full-text available
A Honeypot is a software based security device, deployed to attract hackers by displaying services and open ports which are potentially vulnerable. While the attackers are diverted, their activities can then be monitored and ana-lysed to identify current attack methods and trends. A low-interaction Honeypot called Dionaea was chosen for this project because it can simulate services while preventing an attacker from gaining full control. Results were collected over the six week period of the experiment. The logged information of the observed attacks was analysed and compared with current vulnerabilities, the locations where the attacks were originating from and the time of day at the originating site. A profile of individual attackers can then be built to gain an insight into the current attack trends in order to improve network defences.
Conference Paper
Full-text available
In recent years, the number of attacks on mobile devices has increased rapidly. Users connect to a wireless network without knowledge of its trustworthiness. They are not aware of whether the network is secure or infected with malware that propagates within, actively. As no system can be seen as totally secure this also applies to mobile devices’ operating systems. Hence, a second line of defense is required. In traditional networks such a defense in depth is usually provided by intrusion detection systems and dynamic firewalls. However, these mechanisms cannot be applied easily to mobile environments and to resource constrained devices. Another defense mechanism already known from traditional networks are honeypots, which pretend to be an attractive target in order to lure malware and attackers. As a honeypot has no productive use, each attempt to access it can be interpreted as an attack. Hence, they can provide a first indication on malware spreading within a network. As they do not demand high CPU or memory requirements, they are also applicable to resource constrained devices like smartphones or tablets. In this paper we present the idea of Honeypots-To-Go, i.e., portable honeypots on mobile devices that aim on the fast detection of malicious networks and and at the same time boost the security awareness of users. Moreover, to demonstrate the feasibility of this proposal we present our prototype HosTaGe, a low-interaction honeypot implemented for the Android OS. We present some initial results regarding the performance of this application as well as its ability to detect attacks in a realistic environment.
Full-text available
Passive Internet monitoring is a powerful tool for mea- suring and characterizing interesting network activity like worms or distributed denial of service attacks. By employing statistical analysis on the captured network traffic, Internet threat monitors gain valuable insight into the nature of Internet threats. In the past, these monitors have been successfully used not only to detect DoS at- tacks or worm outbreaks but also to monitor worm prop- agation trends and other malicious activities on the Inter- net. Today, passive Internet threat monitors are widely recognized as an important technology for detecting and understanding anomalies on the Internet in a macro- scopic way. Unfortunately, monitors that publish their results on the Internet provide a feedback loop that can be used by adversaries to deduce a monitor's sensor locations. Knowledge of a monitor's sensor location can severely reduce its functionality as the captured data may have been tampered with and can no longer be trusted. This paper describes algorithms for detecting which address spaces an Internet threat monitor listens to and presents empirical evidences that they are successful in locating the sensor positions of monitors deployed on the Inter- net. We also present solutions to make passive Internet threat monitors "harder to detect".
The paper aims at gathering information about attacks from real internet infrastructure and their analysis. For this purpose, we prepared a set of honeypots monitoring various aspects of nowadays VoIP infrastructure, from emulating an end point device through SIP proxy to SSH terminal emulation. All these application called honeypots bring valuable data about hacker's activity with no threat to the running system. Grouping single honeypots in one cloud solution enables to gather more data on hacker activities and to provide results with higher information value. Analysis of a honeypot data is crucial for further improvement of existing security mechanisms in VoIP networks. The paper describes each honeypot used, brings an analysis of observed malicious activity and a design of the honeypot cloud concept.
Conference Paper
Honeypots are systems aimed at deceiving threat agents. In most of the cases the latter are cyber attackers with financial motivations, and malicious software with the ability to launch automated attacks. Honeypots are usually deployed as either production systems or as research units to study the methods employed by attackers. In this paper we present the results of two distinct research honeypots. The first acted as a malware collector, a device usually deployed in order to capture self-propagating malware and monitor their activity. The second acted as a decoy server, dropping but logging every malicious connection attempt. Both of these systems have remained online for a lengthy period of time to study the aforementioned malicious activity. During this assessment it was shown that human attackers and malicious software are constantly attacking servers, trying to break into systems or spread across networks. It was also shown that the usage of honeypots for malware monitoring and attack logging can be very effective and provide valuable data. Lastly, we present an open source visualization tool which was developed to help security professionals and researchers during the analysis and conclusion drawing phases, for use with one of the systems fielded in our study.
Conference Paper
The number of threats from the Internet has been growing in the recent period and every user or administrator should protect against them. For choosing the most suitable protection the detailed information about threats are required. Honeypots and honeynets are effective tools for obtaining details about current and recent threats. The article gives an introduction into honeypots and honeynets and shows some interesting results from initial 3-months period of the implementation of a small honeynet made of 3 Dionaea and one Kippo low-interaction honeypots. Basic conclusions regarding the amount of currently actively spread malware and their type are formulated.
Described by some as the worst vulnerability since e-commerce began on the Internet, one word sums up what this Basic Training column is all about: Heartbleed. Although we don't necessarily agree with such hyperbole (although it really was pretty bad!), the media furor around the Heartbleed vulnerability was incredible and crossed over from security mailing lists to the national press with remarkable speed. Here, the authors take a look at this vulnerability in OpenSSL and outline how it was fixed. Perhaps more important, they also step back and look at the issue more broadly. Why was the Heartbleed vulnerability missed for so long?
Conference Paper
Internet-wide network scanning has numerous security applications, including exposing new vulnerabilities and tracking the adoption of defensive mechanisms, but probing the entire public address space with existing tools is both difficult and slow. We introduce ZMap, a modular, open-source network scanner specifically architected to perform Internet-wide scans and capable of surveying the entire IPv4 address space in under 45 minutes from user space on a single machine, approaching the theoretical maximum speed of gigabit Ethernet. We present the scanner architecture, experimentally characterize its performance and accuracy, and explore the security implications of high speed Internet-scale network surveys, both offensive and defensive. We also discuss best practices for good Internet citizenship when performing Internet-wide surveys, informed by our own experiences conducting a long-term research survey over the past year.