Content uploaded by George Hatzivasilis
Author content
All content in this area was uploaded by George Hatzivasilis on Mar 25, 2021
Content may be subject to copyright.
Chasing Botnets: A Real Security Incident Investigation
George Hatzivasilis1, 2 [0000-0002-2213-7759] and Martin Kunc3
1 Foundation for Research and Technology, Heraklion, Greece
hatzivas@ics.forth.gr
2 Department of Electrical and Computer Engineering, Hellenic Mediterranean University
(HMU), Heraklion, Greece
hatzivas@hmu.gr
3 CZ.NIC, ZSPO, Praha, Czech Republic
martin.kunc@nic.cz
Abstract. Botnets form a special type of malware that nowadays constitute one
of the biggest threats in cyber-security. Ordinarily, the hacker exploits existing
vulnerabilities to infiltrate the system and install a command-and-control
(C&C) infrastructure. Thereupon, the system is “botnized” and performs the
bot-master’s commands. In most cases, the attacker does not intend to destroy
the compromised assets but to utilize them in order to perform other type of at-
tacks, such as crypto-mining or Denial of Service (DoS) campaigns to targeted
websites. Nevertheless, ransomware or other disruptive attacks can also be
launched at some point and harm the owner of the infected equipment. This pa-
per starts with an overview of botnet cases, attacker’s tactics, and relevant de-
fense mechanisms. Then, we present a real step-by-step digital forensics inves-
tigation on a customer’s bare-metal server in the cloud. The attack was per-
formed in 2020. We describe the storyline from the server’s installation, the in-
fection, the investigation, the proper mitigation actions, as well as, the econom-
ic implication. Finally, we sum-up which were the main mistakes that enable
the attack and propose a silver bulletin for server setup in the cloud.
Keywords: Botnet, Malware, Forensics, Digital Investigation, Attack Tactics,
Miner, DoS, Cloud, OpenStack, Economic Crime.
1 Introduction
For more than a decade now, the battle against botnets has gone more intensive. Mi-
crosoft estimates that around 1% of the recorded computers that execute automatic
updates are infected with malicious software [1]. In a twelve-months period, the ma-
jority of the affected machines are unique, revealing that around 10% of users will
face an infection within the next year.
Defense mechanisms are surveyed in [2], [3], [4], engaging industry and govern-
mental organizations, Internet Service Providers (ISPs), and end-users. The infection
rate is reduced since the beginning of this war, and it seems to be relatively stabilized
[5] since 2009.
2
On the other hand, the financial losses and costs on the global economy are still
significant [6]. Malwares were evolved from highly visible and disruptive at early
2000s (ILOVEYOU, CODE RED, etc.), to stealthy code laying undetectable in the
infected equipment and acting as part of a larger criminal infrastructure
(GAMEOVER ZEUS). Today, cybercrime is structured as a Service Oriented Archi-
tecture (SoA) with malware authors and botnet herders trading their assets in a market
of attack-tools and integrated malicious strategies [7], [8]. The malicious operations
include, among others, crypto-mining, user credentials harvesting, Distributed Denial-
of-Service (DDoS) attacks, financial fraud, ransomware, hosting of phishing sites,
click fraud on advertising networks, spamming, and so on [9].
Ordinarily, the end-users do not bear the whole cost of the botnet scourge, as ISPs
undertaking main mitigation actions with the support of national initiatives (e.g. the
London Action Plan (LAP) [10] which promotes anti-spam and anti-botnet strategies).
Nevertheless, ISPs are not motivated by the market to moderate bot-net operations
and several ISPs try to evade the addable costs [11].
Nonetheless, end-users still play a core role in the overall Internet security [12].
This fact is becoming more-and-more essential with the evolution of the Internet of
Things (IoT) where mobile and personal devices in high numbers have to be safe-
guarded against “botinization” [13], [14], [15], [16]. Marai constitutes an indicative
botnet case that exploited IoT devices [17]. In just six months, the malware infiltrated
in almost 600,000 smart devices (e.g. CCTV cameras with default credentials). On
October 2016, the botnet launched massive DDoS attacks, overwhelming several
high-profile victims and getting unreachable much of the Internet on the US east coast
[18]. While the creators of the Mirai bot were arrested, its techniques and source code
inspired many other actors to build sophisticated IoT botnets, like Tori-bot. There-
upon, the users’ active involvement is considered as a next step towards the safer
Internet and the further decrement of the abovementioned infection ratio [5].
WARDOG functionality [12] as well as the active participation of users is crucial.
Security certification and cyber insurance are also instruments to establish trust and
reduce risk in the provision of a wide spectrum of industries and services ([19], [20],
[21]). Insurance and certification can also enhance the trustworthiness of potential
customers.
This paper presents a real step-by-step digital forensics investigation on a set of
compromised virtual machines in a cloud setting with OpenStack administrating
them. Cloud environments form a popular target for attackers as a successful assault
would be feasible to several machines with the same setting as well. Also, cloud ap-
plications usually provide a specific set of known services and have sufficient compu-
tational/communicational capabilities.
The rest paper is structured as follows: Section 2 overviews the overall concept of
the emerging botnet threats and countermeasures. Section 3 outlines the storyline of
the examined security incident. Section 4 details digital investigation on the compro-
mised server. Section 5 discusses the economic implication for the victim and the
excess usage charges for the cloud services. Section 6 summarizes a proposed silver
bulletin for cloud server set-up. Finally, Section 7 concludes the results of this work.
3
2 Related Works
Nowadays, security experts have managed to neutralize a few botnets and analyze
their underlying features [22], [23]. The generic botnet architecture was initially re-
vealed through the investigation of Torbig [22], with other remarkable studies includ-
ing the analysis of Botters [8] and Conficker [23]. Surveys for botnet attacks, mali-
cious tools, and countermeasures are documented in [2], [4], [9], [24], and [25]. Fur-
thermore, several botnets target specific application domains, like social media [26]
and the banking sector [27]. Legal aspects of botnet mitigation are examined in [28].
2.1 Botnet Infrastructure
Typically, botnets are defined as networks of compromised end-hosts, known as bots
or zombies. The whole infrastructure is controlled by one or more persons, called bot-
master/s. The botnet recruits vulnerable hosts across the Internet via various methods
which are exploited by different malware types (e.g. default system configurations,
social engineering, software flaws, etc.). The infected bots establish a Command and
Control (C&C) mechanism between them, to get instructions from the bot-master and
coordinate malicious campaigns. The core C&C operations:
1. Support monitoring and recovery by the bot-master
2. Offer robust network connectivity
3. Constrains the exposure of the malicious network which is visible to individu-
al bot
4. Provide individual control traffic dispersion and encryption.
Therefore, the bot-master sends commands to the bot armies through the C&C in-
frastructure. Usually, the hacker builds intermediate bot layers, known as handlers.
Handlers forward the bot-master’s instructions to other bots which they are control-
ling directly. The commands will eventually reach the end-bots, which are actually
performing the attacks. Henceforth, the bot-master’s real identity and location are
concealed and he/she evades the law authorities.
The C&C channels can work across various (logical) networks and use several
communication techniques. Botnet administration includes a set of tools and systems
which ordinarily install malicious software and control the victim through the Internet
Relay Chat (IRC). Nevertheless, the attacker can change the communication ap-
proach, with many botnets nowadays providing more than one protocol to harden
their detection.
2.2 Attacks
Usually, botnets are utilized for DDoS attack campaigns on targeted applications,
networks, and/or the Web in general. The current trends include the execution of
DDoS operations at the application layer. These are still remaining among the most
difficult cases to defend online, especially for web servers.
The typical attack strategy launches HTTP/S flooding traffic which is sent from the
end-bots to the victim. The campaign presupposes an adequate number of bots which
are exhausting the victim’s bandwidth, and thus, constraining the access of legitimate
4
users.
As the involved end-bots do not require any response from the victim, they can
transmit requests with spoofed (false) IPs. Thus, bots attack the victim with several
fake IPs and their true IP addresses are hidden. The deployed defense mechanisms,
such as black-listed IPs in firewalls or other network monitoring modules, are over-
come as the bots keep altering IPs.
Also, the attacker could further conceal the end-bots through a reflectors’ layer and
hit the victim indirectly. Reflectors constitute non-compromised systems which exclu-
sively send replies to requests. The bots make requests towards the reflectors setting
as spoofed IP, the IP address of the victim. Thereafter, the reflectors will answer back
to the victim, executing the actual assault.
Apart of flooding, Slowloris forms another state-of-the-art type of DDoS. The at-
tacker makes several connections to the target and keeps them open with minimum
effort for as long as possible. The assault is effectively launched with less bots than
flooding. Furthermore, the bots devote less resources, and thus, enhance the possibil-
ity of remaining undetected by the owner of the compromised equipment.
Unquestionably, botnets are utilized for a high variety of malicious operations. The
latest cyber threat landscape by ENISA [29] reports actions like spam campaigns and
click frauds, crypto-mining or crypto-jacking, as well as, data breaches, extortion,
and/or ransomware.
The main variation among botnets and to ordinary malwares is the subsistence of
the C&C. Therefore, if we discover the C&C location, the botnet can be traced and
removed. This approach exploits the potential weaknesses of the botnet’s communica-
tion channels. It is relatively more feasible to break down a centralized setting. Thus,
as the detection strategies become more effective, hackers start adopting Peer-to-Peer
(P2P) and hybrid infrastructures. This comes with a cost of higher delay as the inter-
action between the bots and the bot-master passes via many peers before reaching the
target (i.e. HTTP flooding). On the other hand, it provides higher untraceability from
law authorities and botnet’s persecutors.
2.3 Countermeasures
The botnet defense mechanisms can be grouped in three categories. The first category
blocks the botnet’s setup, prevents the infection of secondary victims, and de-
tects/neutralizes the botnet’s handlers. The second category responds to ongoing bot-
net attacks, incorporating countermeasures that detect, prevent, or mitigate the mali-
cious activity at runtime. The third category applies forensics techniques that examine
the botnet characteristics, after a performed attack.
The usual methods for safeguarding systems from getting infected involve anti-
viruses/anti-malwares, firewalls, and patching. Therefore, malicious code is detected
based on digital signatures, behavior and/or heuristic features. Afterwards, it is quar-
antined for further examination or permanent deletion. Valuable information is also
gathered, disclosing the hacker’s strategies. The system’s vulnerabilities are revealed
and the legitimate software/hardware is updated accordingly. These countermeasures
form an integral part of the overall defense. Apart from protecting individual ma-
chines or networks, such functionality is now extended to the cloud [30]-[31].
However, those methods cannot always defend the legitimate assets. For example,
5
anti-viruses only detect malicious patterns which are already known. Thus, an attacker
could test the scanning capabilities of the defense mechanism and perform a policy to
evade detection (e.g. zero-days).
Thereupon, anomaly detection techniques are suggested. The normal system opera-
tion is traced by machine learning modules (e.g. based on fingerprinting, deep learn-
ing, synergetic neural networks, or fuzzy estimators). When a new attack type is
launched, the abnormal activity is noticed and mitigation strategies are performed. So,
DDoS attacks could be tracked by network monitoring components that scan the traf-
fic at runtime [12]. Then, prevention techniques, such as the Moving Target Detection
(MTD) [32], can constrain the malicious side-effects. BotFlex is a state-of-the-art
community-driven tool for network monitoring. Raw data from the inspected net-
working functions, which were performed by the examined machines, are transformed
in high-level events (e.g. download form site, port scan, or other transactions). A de-
duction engine processes this information and discovers symptoms of malicious pat-
terns (modelled as logic rules). However, it needs a vast amount of data which have to
be processed. Therefore, singular value decomposition from the Big Data domain is
applicable here. The high-order data dimensions are decreased, even for encrypted
transactions, and the computational overhead is considerably decreased.
On the other hand, stealthy DDoS campaigns with the attacker combining various
attack patterns instead of a single and easily traced one, could overcome statistical
analysis and anomaly detection. Furthermore, the legitimate entity has to devote suffi-
cient effort to apply and keep up-to-date the defense mechanisms.
Except from these main security controls at the system level, Internet-wide mecha-
nisms are also deployed by ISPs to marshal the networking traffic without the active
involvement of the end-users. While ISPs would not take full responsibility and lock
down every compromised machine, they will at least ensure that they do not serve
traffic containing malicious packets. The main ISP countermeasures include:
1. IP-spoofing: ISPs should not forward traffic with spoofed IP addresses and all
packets containing any RFC 1918 or reserved IP address in the source or des-
tination must be immediately discarded.
2. Filtering: Ingress filtering has to be performed for all the incoming packets to
the ISP’s network. For traffic which is originated from a customer’s site, it
should be validated that the NET_ID field in the source IP address matches the
assigned NET_ID for this specific customer. Egress filtering has to be also
performed to monitor the outgoing traffic to upstream and peer ISPs.
3. Broadcast: Directed IP broadcasts has to be deactivated.
4. High-profile entities: Special attention should be paid for high-profile cus-
tomers and servers.
5. Dissemination: Customers should be educated to protect themselves and en-
hance the security awareness.
In several botnet cases, the compromised machines tend to connect malicious do-
mains or Domain Name System (DNS), which are under the control of the bot-master,
to get and respond to instructions. If the relevant communication patterns to the C&C
are detected by the ISP (e.g. router-based TCP/UDP monitoring, honeypots, etc.), the
communication can be stopped (e.g. blocking malicious domains/IPs, routing and
DNS blacklist).
However, relying on identifying bot communications is not considered viable in
6
the long term. The C&C interactions could be extremely polymorphic and flexible,
using encryption and other masking methods.
Digital forensics are applied throughout these processes to collect juridical arti-
facts. These mainly involve honeypots, network and computer forensics. Still, the
high amounts of affected users/machines, the global coverage of bots, and thus, the
different law authorities from various involved countries, pose significant difficulties
in the prosecution of the wily entities.
3 The Storyline of the Security Incident
The digital investigation concerns a successful attack on a bare-metal server for a
cloud customer in Europe. The server has a quite powerful machine (20 physical/40
logical CPU cores, 192GB RAM, 960GB hard disk, 250TB Bandwidth) where a train-
ing platform would be implemented. In the main machine, it was installed the Open-
Stack framework, which would manage several underlying Virtual Machines (VMs).
There were VMs that performed i) the core functionality of the developed platform
and were deployed once and ii) the training session modules per trainee which would
be deployed dynamically at runtime. The OpenStack installation and the permanent
VMs were deployed first and were affected by the attack. One of the core VMs had
external connection capabilities and acted as a proxy for the rest ones.
Due to lack of time for the delivery of the final product, the platform was exposed
to direct Internet access almost from the beginning in order to speed-up the develop-
ment and testing procedures. This was the main mistake, as: i) server administrators
were not assign from the start, ii) the proper security controls (e.g. HTTPS connec-
tions) were not in place, iii) installed software modules with pre-defined default cre-
dentials (e.g. accounts) and configurations (e.g. ports), and iv) a secure communica-
tion channel was not established with some credentials (i.e. pairs of
username/password) being initially sent via unencrypted emails.
The server and the development started in January 2020 and the malicious behav-
ior begin almost immediately a few days later. At first, the malware compromised the
proxy and then some of the other core VMs behind it. Then, the malware was trying
to spread to other servers within the cloud, by trying SSL connections for ordinary
accounts (e.g. admin, superuser, etc.) with default or weak passwords. The activity
was blocked initially by the cloud provider and then by the customer (e.g. by restrict-
ing outgoing SSL connections). The spreading phase stopped and the botnized server
started DoS attacks to external websites. This activity requires some time to be detect-
ed and was identified via collaborative intrusions detection and early warning systems
between the cloud providers, raising an alarm that they were under attacks. The ac-
countable cloud provider blocked the public IP and Internet connection of the server
for a while. Thereafter, the disruptive activity was stopped and the infected VMs start
exhibiting high CPU and memory usage from crypto-mining.
Finally, it was completed the digital investigation that is detailed in the next section
and the malware was detected and removed. The VMs were set properly under a safe
environment, the security primitives were activated, and the server went online again.
7
4 The Investigation – Incident Report
This was a second incident in about six months. During the first incident, couple of
machines were compromised and abused for DDoS attacks. That was visible as a
significant outgoing traffic which actually resulted in increased cost of the platform.
Higher outgoing traffic can be often expected with highly visited web servers (or
other service providing platform) – which was not our case in that moment. Another
giveaway was that during regular connections i.e. downloading files a reasonable
amount of related incoming traffic is expected – which was not our case. Short packet
capture on outgoing interface clearly showed a high number of outgoing SYN packets
with no reply, as depicted in Fig. 1.
Fig. 1. Snapshot – SYN packets
From there it was just about identifying the compromised machine by the high traf-
fic and the way it communicates with command and control server. The list of active
TCP sessions (i.e. netstat -t) then clearly showed active IRC connection, which is
often used for this. At that time, we decided to go the way of rolling back all the ma-
chines to an uncompromised state and securing SSH by denying authentication with
username and password and allow only public key authentication as is often referred
as best practice.
The second incident was spotted as high CPU load on one of the virtual machines
by a process named mdadmd. Short search led to conclusion that it might be process
coupled with RAID storage. That could have swayed the investigating team into
thinking that it’s a legitimate application that has something to do with the way the
virtual machine is setup. Unfortunately for the process, the list of installed packages
(dpkg -l) proved that no such package is currently installed. From that point it was
clear that the machine was compromised. After checking the other machines, it was
clear that a total number of 6 virtual machines were compromised. The location of the
original binary (/root/.mdadmd/mdadmd) was found via ls -la /proc/x/exe (where x is
pid of the running process) which show the path from which the file was executed.
One of the other indicators of compromise was found in syslog (Fig. 2).
Fig. 2. Snapshot – Syslog
8
XMRig is name of a cryptomining application. That was actually a good sign be-
cause there was high chance it was “just miner” instead of a destructive malware.
Even-though sings of persistence are to a trained eye visible from the syslog. More
information was found when issuing the find command find / -name "mdadmd*".
That resulted in the following output:
/etc/systemd/system/mdadmd.service
/etc/systemd/system/multi-user.target.wants/mdadmd.service
/root/.mdadmd/mdadmd
After clearing the persistence, the only question left to answer was how did the at-
tacker get in. The included syslog output actually refers to a first time the mdadmd
process was started (the same output was then written several times later). Having the
first time help a lot with pinpointing the similar timestamp in authlog. e (Fig. 3).
Fig. 3. Snapshot – Authlog
Log shown that a user superuser logged via tty1 just before the mdadmd was first
run. What was puzzling here was that the tty that was used to login did not point to
SSH. That meant that the attacker used another way to get in. That lead to host ma-
chine being pulled into investigation. Since the host machine authlog and wtmp didn’t
show any discrepancy the next thing to check were open ports and related applica-
tions. The list of open ports (netstat -tulnp) shown that there is a number of open ports
just above 5900. On those ports was a process qemu-system-x86 that was listening.
Since the same process was used for running the virtual machines things began to be
clear. Port 5901 is a default port for VNC which is one of the protocols used for re-
mote desktop. Upon connection to that port a user obtained a terminal where the user
could just provide a username and password a gain access to the machine it belongs
to. Using this an attacker could that bypass the public key restriction posed on the
SSH server configuration and gain access to actually any machine since all have the
maintenance account superuser and same password. The attacker did not even have to
enumerate or randomly discover the IP address of those machines since all ports were
situated one after another (5901, 5902, …).
The next steps were then clear. First block access to those ports, and then change
the compromised password.
Final step was to check the compromised machines on any changes that could have
been made by the attacker. Utility called debsums serves exactly this purpose. It gath-
ers hashes of all system files and compares them with their original counterpart that
comes with the package during installation (Fig. 4).
9
Fig. 4. Snapshot – Debsums
From the output above we can clearly see which files were changed and we can
then manually check if any changes were introduced by the attacker. The only change
that was made by the attacker was enabling hugepages option in the sysctl.conf which
is expected to increase the performance of the miner.
Luckily the attacker did not display any really malicious behavior and the damage
done was easily fixed. There is still speculation on how did the attackers obtained the
quite strong password in the first place. One option is that during the first incident the
attackers could have guessed easier password get access to the system, obtain the
hashes from /etc/shadow and crack them. Other option is they eavesdropped it from
an unencrypted email (the password was at least once transferred in plain text). But
that we will never know.
5 The Economic Implications
This section discusses the economic implications that the attack had to the server
owner. Fig. 5 depicts the bandwidth of the infected server during the period January-
May 2020. The server was hired in January 1st and, as it is visualized, the malicious
activity began a few days later at January 27th. As the server would be used for devel-
opment, it was not secured properly from the start and before being exposed directly
to Internet access. Also, adequate monitoring and auditing procedures had not been
established as well as the involvement of the responsible personnel (e.g. administra-
tors). As the setup of the server and the related services proceeded, the abnormal in-
coming traffic was noticed, the digital investigation analysis was performed as de-
scribed in the previous section, and the attack was mitigated completely at May 18th.
10
Fig. 5. Bandwidth activity of the infected server during the period January to May 2020.
However, as mentioned in the beginning, the server was hired by a cloud provider.
Therefore, it was subject to volume charges (i.e. when traffic exceeded a specified
threshold). The legitimate service was supposed to require a low incoming/outgoing
bandwidth, so the contract included the default traffic and usage thresholds. This had
the implication that when the malicious traffic exceeded by far these thresholds, the
monthly charge was excessively raised. The owner had hired the server for 12 months
(January to December) for around 2,800 euros. The additional charges due to the at-
tack for February alone would be around 7,500 euros. Fortunately, the cloud provider
noticed the extreme charges and the produced traffic, and inform the owner accord-
ingly. It was agreed to purchase an additional package for around 120 euros per
month that would cover the malicious traffic threshold, leaving the owner the oppor-
tunity to fix the problem and continue from then on. Thus, the owner paid an addi-
tional amount of around 1,450 euros to cover the whole contracting period and avoid
the extreme monthly chargers. Furthermore, cyber insurance of digital infrastructure
nowadays could cover such security incidents and reduce the risk for the customer
[19]-[21].
6 Silver Bulletin for Setting a Sever in the Cloud
As a main comment of this investigation is to “secure first, then go public”. It must be
strongly avoided to expose a development server directly to the Internet. One must
first complete the development phase, deploy the relevant security controls and poli-
cies, and then make the service/application public.
Concerning cloud applications, one must also be familiarized and leverage the se-
curity controls that are offered by the cloud provider. Most cloud providers support
IDS functionality, both for their operation, as well as, a panel for the customers. Also,
a customer must enable the provided early-notification functionality and set low-
traffic (or other) thresholds.
Other technical best practices for secure server configuration include:
Apply server-hardening techniques
─ update and upgrade the utilized packages and the operating system
─ remove unnecessary packages
─ verify that no accounts have empty passwords
─ disable USB devices
─ secure any Apache server running in this machine
─ examine which services start at boot time in order to verify that there are no ma-
licious services starting with booting and running in the background
─ delete all world-writable files
─ configure iptables to block common attacks, like SYN flooding and spoofing
─ secure configuration of SSH
─ disable telnet
11
─ secure configuration of sysctl to prevent the main flooding attacks and IP spoof-
ing
─ lock user accounts after some failed login attempts
─ use netstat and check for hidden open ports
─ set root permissions for the core system files
─ install security software and scan for rootkits, viruses, malware, etc.
Use strong passwords
Do not send passwords unencrypted
─ Extra point: When sending encrypted passwords (i.e. in zip file) distribute pass-
word for the zip file across another channel (i.e. phone)
─ Extra point: Even if password is securely transferred, force the user to change it
─ Extra point: Do not share accounts ("admin", "superuser", etc.)
─ Extra point: Deny root login
Allow only ssh-key-based login for ssh
Set all firewalls defaults to deny and only allow ports that are required and justified
─ Never let ports like VNC, SQL, RDP (in case of Windows) be accessible from
Internet
o SSH, HTTP/S are justifiable
─ Set up such default firewall on all machines
Document all internet accessible ports and monitor version of the software running
there for vulnerabilities and patches
─ Have that document updated, private, but easily accessible.
─ Conduct regular port scans to verify
If compromised, change all passwords that could have been affected
─ i.e. in case of root level compromise, change all user passwords after rollback
Extra points for:
Monitoring of authentication logs
Check traffic – especially outgoing (only updates are expected and they are easy to
rule out)
─ Look for IRC connections (highly suspicious, nicely visible)
7 Conclusions
This study presented on overview of current botnization threats and relevant counter-
measures, as well as, a step-by-step digital forensics analysis for a real attack case on
a customer server in the cloud. The core mistake that lead to the infection was the fact
that the server was immediately exposed to direct Internet access, once it was deliv-
ered by the cloud provider. It took several days for the administration team to set the
full security controls, while in the meantime the server had been compromised. The
rapid infection of the server reveals that the cloud infrastructures have become of
great importance for attackers, who seem to be aware of the relevant public IP ranges
and monitor them. This is also reasonable as cloud applications usually provide a
specific set of known services (i.e. OpenStack) and acquire sufficient computation-
12
al/communicational resources. Moreover, a successful assault would be feasible to
several machines with the same setting. The investigated botnet was eventually de-
tected and mitigated. However, as the security monitoring procedures were not in
place from the beginning, the attacks were ongoing for several weeks. This has an
economic side-effect as well, in contrast to the usual botnet cases on machines which
are fully-owned by the legitimate party. As the cloud services are subject to volume
charges (e.g. with threshold for bandwidth consumption) a DoS attack from a com-
promised node would cause excessive charges for the related customer. This is an
issue both for the users – who must be aware and put cyber-security as a high priority;
and the cloud providers – who must install early notification mechanisms for raising
charges to protect their customers. The study ends with a proposed bulletin for setting
up a server in cloud environments.
8 Acknowledgements
This work has received funding from the European Union Horizon’s 2020 research
and innovation programme under the grant agreements No. 786890 (THREAT-
ARREST) and No. 830927 (CONCORDIA).
References
1. Microsoft, ‘Microsoft security intelligence report,’ Microsoft, vols. 9-17, 2010-2014.
2. S. T. Zargar, J. Joshi and D. Tipper, ‘A survey of defense mechanisms against Distributed
Denial of Service (DDoS) flooding attacks,’ IEEE Communications Surveys & Tutorials,
IEEE, vol. 15, issue 4, pp. 2046-2069, March 28, 2013.
3. S. Liu, ‘Surviving distributed Denial-of-Service attacks,’ IT Professional, IEEE, vol. 11,
issue 5, pp. 51-53, 29 September, 2009.
4. S. M. Specht and R. B. Lee, ‘Distributed Denial of Service: taxonomies of attacks, tools
and countermeasures,’ 17th International Conference on Parallel and Distributed Compu-
ting Systems (ICPADS), San Francisco, CA, USA, pp. 543-550, September 15-17, 2004.
5. H. Asghari, M. J. G. van Eeten and J. M. Bauer, ‘Economics of fighting botnets: lessons
from a decade of mitigation,’ IEEE Security & Privacy, IEEE, vol. 13, issue 5, pp. 16-23,
October 28, 2015.
6. A. K. Sood, S. Zeadally and R. J. Enbody, ‘An empirical study of HTTP-based financial
botnets,’ IEEE Transactions on Dependable and Secure Computing, IEEE, vol. 13, issue 2,
pp. 236-251, March-April 1, 2016.
7. T. Moore, R. Clayton and R. Anderson, ‘The economics of online crime,’ The Journal of
Economic Perspectives, vol. 23, no. 3, pp. 3-20, 2009.
8. J. J. C. de Santanna, R. M. van Rijswijk, R. J. Hofstede, A. Sperotto, M. Wierbosch, L. Z.
Granville and A. Pras, ‘Booters – an analysis of DDoS-as-a-Service attacks,’ IFIP/IEEE
International Symposium on Integrated Network Management (IM), IFIP/IEEE, Ottawa,
Canada, pp. 243-251, May 11-15, 2015.
9. S. Khattak, N. R. Ramay, K. R. Khan, A. A. Syed and S. A. Khayam, ‘A taxonomy of bot-
net behavior, detection, and defense,’ IEEE Communications Surveys & Tutorials, IEEE,
vol. 16, issue 2, pp. 898-924, October 2, 2014.
13
10. I. Brown and C. Marsden, ‘Co-regulating Internet security: The London Action Plan,’ Ac-
ademic Symposium on Global Internet Governance Academic Network (GigaNet), SSRN,
Rio de Janeiro, Brazil, pp. 1-18, November 11, 2007.
11. A. Garcia and B. Horowitz, ‘The potential for underinvestment in Internet security: impli-
cations for regulatory policy,’ Journal of Regulatory Economics, Springer, vol. 31, issue 1,
pp. 37-55. February, 2007.
12. Hatzivasilis, G., Soultatos, O., Chatziadam, P., Fysarakis, K., Askoxylakis, I., Ioannidis,
S., Alexandris, G., Katos, V., Spanoudakis, G.: WARDOG: Awareness detection watch-
dog for Botnet infection on the host device”, IEEE Transactions on Sustainable Computing
– Special Issue on Sustainable Information and Forensic Computing, IEEE, vol. 4, pp. 1-
15, May 2019.
13. J. Habibi, D. Midi, A. Mudgerikar and E. Bertino, ‘Heimdall: mitigating the Internet of In-
secure Things,’ IEEE Internet of Things Journal, IEEE, vol. 4, issue 4, pp. 968-978, May
17, 2017.
14. Z. Lu, W. Wang and C. Wang, ‘On the evolution and impact of mobile botnets in wireless
networks,’ IEEE Transactions on Mobile Computing, IEEE, vol. 15, issue 9, pp. 2304-
2316, September 1, 2016.
15. A. Karim, S. A. A. Shah, R. B. Salleh, M. Arif, R. M. Noor and S. Shamshirband, ‘Mobile
botnet attacks – an emerging threat: classification, review and open issues,’ KSII Transac-
tions on Internet and Information Systems, TIIS, vol. 9, no. 4, pp. 1471-1492, April 30,
2015.
16. P. Traynor, M. Lin, M. Ongtang, V. Rao, T. Jaeger, P. Mc Daniel and T. L. Porta, ‘On cel-
lular botnets: measuring the impact of malicious devices on a cellular network core,’ 16th
ACM Conference on Computer and Communications Security (CSS), ACM, Chicago, Illi-
nois, USA, pp. 223-234, November 9-13, 2009.
17. M. Antonakakis et al., ‘Understanding the Mirai botnet,’ 26th Usenix Security Symposium
(SS), Vancouver, BC, Canada, pp. 1093-1110, August 16-18, 2017.
18. J. Fruhlinger, ‘The Mirai botnet explained: how teen scammers and CCTV cameras almost
brought down the Internet,’ CSO Online, article 3258748,
https://www.csoonline.com/article/3258748/security/the-mirai-botnet-explained-how-teen-
scammers-and-cctv-cameras-almost-brought-down-the-internet.html, March 9, 2018.
19. W. Pritchett, “Insurtech 10: Trends for 2019,” The Digital Insurer, KPMG, pp. 1-36,
March, 2019.
20. G. Hatzivasilis, P. Chatziadam, N. E. Petroulakis, M. Mangini, C. Kloukinas, A.
Yautsiukhin, M. Antoniou, D. G. Katehakis, M. Panayiotou, ‘Cyber Insurance of Infor-
mation Systems,’ 24t h IEEE International Workshop on Computer Aided Modeling and
Design of Communication Links and Networks (CAMAD 2019), IEEE, Limassol, Cyprus,
11-13 September, pp. 1-7, 2019.
21. G. Hatzivasilis, P. Chatziadam, A. Miaoudakis, E. Lakka, S. Ioannidis, A. Alessio, M.
Smyrlis, G. Spanoudakis, A. Yautsiukhin, M. Antoniou, N. Stathiakis, ‘Towards the Insur-
ance of Healthcare Systems,’ 1st Model-driven Simulation and Training Environments for
Cybersecurity (MSTEC), ESORICS, Springer, LNCS, vol. 11981, pp. 185-198, Luxem-
bourg, 27 September, 2019.
22. B. Stone-Gross, M. Cova, B. Gilbert, R. Kemmerer, C. Kruegel and G. Vigna, ‘Analysis of
a botnet takeover,’ IEEE Security & Privacy, IEEE, vol. 9, issue 1, pp. 64-72, September
2, 2010.
23. S. Shin, G. Gu, N. Reddy and C. P. Lee, ‘A large-scale empirical study of Conflicker,’
IEEE Transactions on Information Forensics and Security, IEEE, vol. 7, issue 2, pp. 676-
690, April 1, 2012.
14
24. A. M. Konovalov, I. V. Kotenko and A. V. Shorov, ‘Simulation-based study of botnets and
defense mechanisms against them,’ Journal of Computer and Systems Sciences Interna-
tional, Springer, vol. 52, no. 1, pp. 43-65, January 2013.
25. Y. Bekeneva, N. Shipilov, K, Borisenko, and A. Shorov, “Simulation of DDoS-attacks and
protection mechanisms against them,” IEEE NW Russia Young Researchers in Electrical
and Electronic Engineering Conference (ElConRusNW), IEEE, St. Petersburg, Russia, pp.
49-55, February 2-4, 2015.
26. Y. Dong, J. Dai, and X. Sun, “A Mobile Botnet That Meets Up at Twitter,” Security and
Privacy in Communication Networks (SecureComm), Singapore, August 8-10, Springer,
LNICST, vol. 255, pp. 3-21, 2018.
27. L. Ling, Z. Gao, M. A. Silas, I. Lee, and E. A le Doeuff, “An AI-based, Multi-stage detec-
tion system of banking botnets,” 32nd Conference on Neural Information Processing Sys-
tems (NIPS), pp. 1-9, Montréal, Canada, 2019.
28. G. Grant, “Botnet Mitigation and International Law,” Columbia Journal of Transnational
Law, Elsevier, vol. 58, pp. 189-231, 2019.
29. Andreas Sfakianakis, Christos Douligeris, Louis Marinos, Marco Lourenço, and Omid
Raghimi, ‘ENISA Threat Landscape Report 2018,’ ENISA, pp. 1-139, January 2019.
30. G. Hatzivasilis, K. Fysarakis, I. Askoxylakis, A. Bilanakos, ‘CloudNet Anti-Malware En-
gine: GPU-Accelerated Network Monitoring for Cloud Services,’ International Workshop
on Information & Operational Technology (IT & OT) Security Systems (IOSec), Herakli-
on, Crete, Greece, Springer, LNCS, 11398, pp. 122-133, 13 September, 2018.
31. I. Papaefstathiou, A. Bilanakos, K. Fysarakis, G. Hatzivasilis, C. Manifavas, ‘An efficient
anti-malware intrusion detection system implementation, exploiting GPUs,’ International
Conference on Advanced Technology & Sciences (ICAT 2014), Antalya, Turkey, pp. 1-9,
12-15 August, 2014.
32. G. Hatzivasilis, N. Papadakis, I. Hatzakis, S. Ioannidis, G. Vardakis, ‘AI-driven composi-
tion and security validation of an IoT ecosystem,’ Applied Sciences – Special Issue on
Smart City and Multi-Agent Systems, MDPI Open Access Journal, vol. 10, issue 14, arti-
cle 4862, pp. 1-31, August 2020.
33. G. Berger-Sabbatel and A. Duda, “Four Years of Botnet Hunting: An Assessment,” Mul-
timedia Communications, Services and Security (MCSS), Krakow, Poland, June 11-12,
Springer, CCIS, vol. 429, pp 29-42, 2014.
34. E. Cooke, F. Jahanian and D. Mc Pherson, ‘The zombie roundup: understanding, detecting,
and disrupting botnets,’ Usenix Workshop on Steps to Reducing Unwanted Traffic on the
Internet (SRUTI), Cambridge, MA, USA, pp. 1-6, July 7, 2005.
