Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Side 1 af 25
INVESTIGATION REPORT
HACKERS REMEMBER THE VULNERABILITIES WE FORGET Danish organization hacked five times in two years – Thousands of Danish servers still critically
vulnerable
Side 2 af 25
Contents Summary ..................................................................................... 3
Introduction ................................................................................. 3
Organization hacked five times in two years ..................................... 4
The five compromises: Motives and attack patterns .......................... 5
Thousands of Danish servers critically vulnerable ............................ 10
Recommendations: Defense-in-Depth strategy ............................... 14
Appendix 1: Cyber Kill Chain® model ............................................ 22
Appendix 2: Table 1 (large version) – Patterns of Attack in the
five compromises ........................................................................ 23
Appendix 3: Figure 3 (large version) - Active Vulnerabilities in
Denmark pr. December 2 2019 ..................................................... 24
Appendix 4: Figure 4 (large version) – Vulnerabilities in Denmark
distributed after publication date .................................................. 25
Kastellet 30
2100 København Ø
Telefon: + 45 3332 5580
E-mail: [email protected]
1st edition April 2020.
Side 3 af 25
Purpose This investigation report outlines a specific incident in which a server with a Danish organization was hacked five times in two years due to lack of updates to software containing known vulnerabilities. The outlined incident is far from unique, and this report proposes future
remediation initiatives for authorities and companies. Target readers of this report are IT leaders and technicians.
Summary • A server with a Danish organization was hacked five times between December
2016 and January 2019. • The hackers exploited a known vulnerability which, for the preceding six
years, could have been closed. • In the first hacking incident, the hacker tried to steal computer power for
crypto mining. The hackers involved in the three subsequent incidents did not
use their access for nefarious purposes, while the hacker involved in the last
hacking incident tried to penetrate deeper into the more sensitive parts of the
network. • However, the server was taken offline, preventing the hacker from expanding
their access, and the organization’s anti-virus programme prevented the
crypto miner from functioning. • We assess it less likely that the hackers involved were state sponsored. • Using open sources, we have identified thousands of similar Danish servers
with serious vulnerabilities that have been left unresolved although their
existence was identified years ago.
Introduction Hackers frequently succeed in exploiting older, known vulnerabilities to
compromise Danish authorities and companies, often due to their failure to
implement security updates that have been available for years prior to the
attacks.
In this report, we thus focus on the challenge of older, known vulnerabilities. We
at the Centre for Cyber Security (CFCS) often come across servers with
authorities and companies that hold less sensitive data and which are thus not
covered by the same security measures as the more critical parts of the
organization networks. Even though these servers in themselves may seem like
uninteresting targets, they may act as stepping stone for hackers to access more
sensitive parts of the organization.
This report outlines a specific incident in which a server with a Danish
organization was hacked five times in two years due to a vulnerability, which,
for more than six years, could have been closed with updates.
This report falls into four parts: First, a brief outline of the incident followed by
a more detailed analysis of the hackers’ attack patterns and motives. The third
part illustrates just how easy it is for hackers to identify vulnerable servers in
Denmark using open and readily accessible search engines. The report concludes
with a number of specific suggestions for vulnerability remediation measures that
may help protect authorities and companies against hacking in the future.
Side 4 af 25
Organization hacked five times in two years
In January 2019, a hacker attack against a Danish state set off an alarm in the
CFCS sensor network. CFCS investigations revealed that the server had been
hacked five times in two years with the first compromise dating back to
December 2016. The five compromises were highly likely unlinked, and it is less
likely that they were launched by state-supported hacker groups.
The compromised server was a Windows 2003 server with
an Oracle Application Server installed, whose uses include
generation of internal statistical reports. All five hackers
exploited a vulnerability in this application, more specifically
the CVE-2012-3152, that had been known since 2012 and
which enabled the hackers to upload malicious files directly
on the server over the Internet.
Even though security updates for the application had been
available for more than six years, it had never been
updated. The server had thus been vulnerable at least since
October 2012 – a mere five months after it was installed.
Although the data on the server in itself was not of a nature requiring protection,
one hacker tried to access the more sensitive parts of the network. Another
hacker tried to steal computer power to generate crypto currency, while the
remaining three hackers did not exploit their illegal access to the server.
On recommendation from CFCS, the server was taken offline before the hacker
succeeded in penetrating deeper into the network and the organization’s anti-
virus programme prevented the crypto miner from running. As the hackers
involved in the last three attacks never tried to exploit their access, they may
have been so-called “grey hat hackers”, who were merely out to test whether it
was possible to compromise the server. However, it is also possible that these
hackers compromised the server with the aim of establishing long-term access
that could be resold or exploited at some point in the future.
The vulnerability of the Oracle application was not the server’s only vulnerability
as Microsoft already in 2015 had officially deemed its Windows 2003 server
outdated and stopped providing security updates for the server.
Figure 1 provides an overview of the key events of the incident from the
publication of the vulnerability in 2012 to the last compromise in January 2019,
when we at the CFCS became involved and the server was taken offline.
CFCS sensor network
We conduct regular monitoring of network
traffic to and from authorities and companies
that are connected to our sensor network. We
monitor traffic from state-sponsored and other
particularly advanced actors and provide
assistance in the event of serious hacker
attacks.
Side 5 af 25
Figure 1: Timeline of key events
The five compromises: Motives and attack patterns This part analyses the hackers’ more specific motives and attack patterns. The
analysis is based on an analysis model called the Cyber Kill Chain® model, which
was originally developed by US defence and security group Lockheed Martin. The
model divides cyber attacks into a number of chronological phases from the
hackers’ initial probing for potential victims to the realization of their ultimate
goals – the attack. The original model has seven phases, but in this report we
have chosen to fuse the delivery and exploitation phase to facilitate
understanding. See appendix 1 for a closer introduction to the model.
Despite all five hackers initially exploiting the same vulnerability to compromise
the server, their conduct differed significantly once they had illegally accessed
the server. Chart 1 thus lists differences and similarities in the five compromises
distributed on the six phases of the Cyber Kill Chain® model, which are dealt
with individually below.
Side 6 af 25
Chart 1: Attack patterns of the five compromises
Reconnaissance
It has not been possible to definitely establish how the hackers carried out their
initial reconnaissance. However, it is likely that they found their victims using
one among a range of open search engines that are readily accessible via the
Internet.
One of the most popular search engines is Shodan which continuously scans the
Internet for connected units, indexing them in an open database on its website.
Among the users of Shodan are security experts who use the engine to detect
vulnerabilities in their own organizations, though it is also often used by hackers
to identify vulnerable targets.
Using Shodan or similar services, the hackers have thus been able to identify
Internet-facing servers with Oracle Application Servers installed, enabling them
to generate lists of potential targets.
It is thus likely that the organization’s server was attacked merely because it
featured in one of these open databases of potentially vulnerable servers. In
other words, the compromises were likely opportunistic rather than specifically
directed against the organization.
Side 7 af 25
Weaponization
Once the hackers had identified their target, they prepared the malicious code
intended to exploit the vulnerability in the Oracle Application Server software as
well as different kinds of web shells.
It proved challenging for the hackers to install web
shells on the server that would give them remote
control of the system. To this end, all the hackers
used the vulnerability in the Oracle application
known as CVE-2012-3152. The malicious code and
the applied web shells were freely available for
download from the Internet.
Specifically, the CVE-2012-3152 vulnerability is a security hole in the report
module of the Oracle application that allowed hackers to install web shells directly
on the organization’s server. Below is a brief, anonymized and non-functional
version of the malicious code:
Figure 2: Example of malicious code
The malicious code can be sent directly from an ordinary web browser or terminal
and may ideally be broken into three constituent parts:
1. First, the hackers entered the URL address on the vulnerable server to
facilitate direct communication with the server.
2. Then the hackers specified that they wanted to point their
communication directly to a specific module of the Oracle application
named “Reports Servlet”, abbreviated “rwservlet” under the “reports”
main module. Though the module is designed to generate various
statistical reports, the hackers had discovered that it was possible to
place random files in a specific image storing folder that was to be part
of the report.
3. In the third part of the malicious code, the hackers specified a number
of parameters that imitated a request to generate an ordinary report,
but which in reality downloaded a malicious file from a hacker-controlled
domain:
a. In the “report” parameter, the hackers simulated a request to
generate an ordinary report.
Web shell
A web shell is a small piece of programme code
that can be stored in a file and uploaded on a
web server, providing remote online access.
Web shells thus act as a so-called “Remote
Access Tool” (RAT), enabling hackers to read,
write, change, download or delete files on a
server.
Side 8 af 25
b. In “desformat”, they specified the formatting of the report. In
the above example shown in html format.
c. In “destype”, they specified the type of report that was to be
generated. In the above example an ordinary file.
d. It is particularly in this parameter, “job type”, that the first part
of the vulnerability of the module emerged as the “job type”
parameter makes it possible for reports to incorporate elements
from public websites. This functionality may be useful for
organizations that wish to generate reports based on information
gleaned from the Internet. However, the functionality also
allowed the hackers to refer to websites controlled by the
hackers themselves.
e. In “url parameter”, the hackers could thus enter the specific
hacker-controlled domain from which the report was to draw its
information. The trick was thus to store malicious files on these
hacker-controlled domains; files that were downloaded when
visited by the application.
f. The last parameter, “desname”, was actually designed to specify
the location on the server where the final report was to be saved,
but this feature held the application’s second serious
vulnerability: Normally, applications have built-in security
limitations preventing the saving of files directly on a server.
However, the hackers had discovered that a special folder for
storing of imagery for the reports did not have this security
limitation. By choosing this exact folder as destination, the
hackers were thus able to bypass the normal security limitations
and download random files on the server while the application
merely registered that an ordinary report was being generated.
All hackers were thus able to freely download their web shells
via their controlled domains in JavaServer Pages (jsp) format to
the imagery folder, which could then be executed by visiting this
exact path in a web browser. In the above example, the hacker
saved a jsp file by the name of bad-file.jsp
The hackers were thus able to exploit the legitimate option offered by the Oracle
application to incorporate information from public websites to refer to hacker-
controlled websites. The hackers then downloaded web shells to a special,
unprotected folder on the organization’s server. Authorities and companies using
Oracle Application Servers may profitably examine this special image folder to
detect suspicious files as they may be indicative of a compromise.
We know of incidents in which a state-sponsored hacker group has exploited this
exact vulnerability in its attack against another state.
Delivery and Exploitation
Once the hackers had identified vulnerable targets and prepared the code, they
launched the attack directly on the organization’s server. More specifically,
hacker 1 and 4 delivered the malicious code to the server directly from their own
Side 9 af 25
machines, while hackers 2, 3 and 5 tried to conceal their identities by hiding
behind other compromised servers.
CFCS have traced actor 2 back to a similar Oracle server in Thailand, which has
previously been compromised and is now being used to distribute web shells to
other servers worldwide.
In contrast, actor 3 contacted the vulnerable state server via a web server in
Mauritius, which had likely been compromised during a global campaign known
as Drupalgeddon 2.
Actor 5 also used a compromised external server to hide their identity.
Installation
All hackers exploited the vulnerability to download web shells to the server, thus
succeeding in setting up long-term illegal access to the server from which they
were able to control and upload several malicious files.
The hackers involved in the first four attacks used ordinary web shells, while the
hacker behind the fifth attack had downloaded a more special type of web shell
known as China Chopper. Despite its small size, the China Chopper web shell
offers a full complement of attack features. The China Chopper web shell has
presumably earned its name as it was originally associated with Chinese cyber
criminals, though the use of China Chopper has now extended beyond China.
Having installed web shells on the server, hackers 2 and 4 ceased their attacks,
while hacker 1 merely exploited their access to upload an extra web shell. The
likelihood thus exists that these three hackers were so-called “grey hat hackers”,
whose sole aim was to test whether they could hack the server. Conversely, it is
also possible that the hackers compromised the server with the aim of setting
up a more long-term access to be used at some point in the future or resold.
Hacker 3 uploaded an additional series of malware to the server with a view to
initiating a crypto mining process. The hacker also downloaded a known XMRig-
type crypto miner intended to mine Bitcoins as well as a file
that could continuously be executed to check the status of the
crypto miner, making it highly likely the attack was financially
motivated.
Hacker 5 also installed different types of malware on the
server whose purpose included in-depth reconnaissance of
the server’s settings and networks. This could be an indication
that the hacker tried to penetrate deeper into the more
sensitive parts of the network – possibly because they
discovered that the server belonged to a Danish organization.
Even though this hacker displayed a more sophisticated
approach than the rest of the hackers, it is still less likely that the fifth
compromise was orchestrated by a state-sponsored hacker group.
Crypto mining
Crypto mining is a process in which one or more
computers are tasked with performing very
complicated mathematical calculations that are
subsequently “rewarded” with crypto currency as
the calculations help support the currency’s block
chain. Criminals thus have the incentive to steal
computer power from others to make these
calculations on their behalf.
Side 10 af 25
Command & Control
Hackers 1, 2 and 4 did not exploit their web shells once they had been installed
on the server.
Hacker 3 used a more complex command & control set-up in which a number of
compromised servers in a known botnet continuously accessed the web shell to
check the status of the crypto miner. Once the hacker had set up access to the
server through the web shell, they thus left the running of the crypto miner to
an automated network of compromised servers.
Hacker 5 accessed their China Chopper web shell through the same external
compromised server that was used to send the malicious code.
Actions on Objective
All five hackers managed to compromise the server, obtaining direct control of
the server through the Internet using their web shells.
As mentioned previously, hackers 1, 2 and 4 did not further exploit their access.
Hacker 3 actively attempted to exploit the server’s computer power to generate
Bitcoins for pecuniary reasons, but the server’s anti-virus programme prevented
the crypto miner from running. After just under three months, the botnet stopped
accessing the server, likely because the hacker had found out that the crypto
miner did not work on the server, causing them to abort their attack.
Hacker 5 conducted targeted reconnaissance of the server and its network
settings, likely with a view to penetrating deeper into the more sensitive parts
of the network. The CFCS’s warning about and subsequent disconnection of the
server’s access to the Internet successfully stopped the hacker before they
succeeded in accessing the more sensitive parts of the network.
Thousands of Danish servers critically vulnerable The above incident is merely one among many similar incidents regularly
encountered at the CFCS. Hackers very often exploit older vulnerabilities in their
attacks, and this part of the report deals with the simplicity in identifying the
vulnerable units using open search engines such as Shodan.
A search in the Shodan database carried out in December 2019 returned more
than 750,000 Danish IP addresses on everything from web servers and web
cameras to industrial control systems that are all connected to the Internet. A
host of information is listed for each IP address describing the unit behind the IP
Side 11 af 25
address, including the type of hardware used, the type of software installed on
the unit, location of the unit and, in some cases, ownership of the unit.
However, what makes Shodan and similar services particularly
interesting to hackers is the fact that the results of the search
engines are actively linked to the vulnerabilities that have been
identified on this particular type of unit through time. In other
words, the search engines not only show how to communicate with
different Internet-connected units, they also reveal which
vulnerabilities exist on specific hosts. This transparency has
become a basic condition, not only for the authorities and
companies that try to protect themselves, but also for hackers that
want to compromise them.
However, Shodan has the limitation that it can only scan a smaller
number of the aggregated Danish IP addresses. This limitation is
in part the result of the fact that today most routers, which
constitute the main entrance point to a network, often reject
incoming traffic unless an outgoing connection has already been
established or if the unit, due to its functionality, requires incoming traffic, such
as a web server or a remote-controlled web cam. It follows that by far the
majority of Danish private individuals are not registered in these data bases and
most units require some kind of open and direct channel of communication.
In addition, Shodan’s indexation of vulnerable units must be viewed with some
reservations as it bases itself exclusively on the unit’s software and versions.
Vulnerabilities will typically relate to specific software functions, and the unit’s
indexation as vulnerable or not thus depends on whether these functions are
activated. This is not evident from Shodan’s scan. Consequently, Shodan’s
indication of a vulnerability does not necessarily mean that the unit is in fact
vulnerable; rather, it is an indication that the unit may contain this vulnerability.
Despite these limitations, the search engines are broadly used by hackers, and
Shodan’s data thus provides a good insight into the landscape in which hackers
often navigate when probing for potential victims.
Shodan figures indicate that in early December 2019 there were just under 1,600
different active vulnerabilities in Denmark distributed on the approximately
750,000 indexed Danish units. The vulnerabilities vary depending on the number
of units they each stretch across. In December 2019, CVE-2018-1312 was the
most widespread vulnerability with just below 15,000 potentially vulnerable units
in Denmark. The severity of the vulnerabilities varies, and the individual unit
may contain more than one vulnerability at the same time.
A score system developed by the US National Institute of Standards and
Technology (NIST) is used to assess the severity of the vulnerabilities. NIST has
two score systems, and this report uses version 2.0, since the focus of the report
is older vulnerabilities. This calculation model compares the specific
characteristics of each individual vulnerability, rating them on a scale from 0 to
10, where ratings between 0.0 and 3.9 are considered “low” severity, and those
between 4.0 and 6.9 are classified as “medium” severity. Ratings between 7.0
and 10.0 are considered “high” severity. A number of factors are included in the
calculation of the so-called “CVSS Score”, including the rights the hackers gain
by exploiting the vulnerabilities, attack complexity indicating how easy or difficult
The five most widespread
vulnerabilities in Denmark
CVE-2018-1312 (14.525)
- Insufficient approval
CVE-2017-7679 (12.975)
- Unlimited memory buffer
CVE-2016-8612 (11.272)
- Insufficent input validation
CVE-2016-4975 (10.938)
- Possible change of line in code
CVE-2019-0220 (10.287)
- Possible manipulation of directory in
URL’s
Side 12 af 25
it is to exploit the vulnerability in practice, and the scope of the hackers’ access
to the information stored on the vulnerable unit. For further information on how
the score is calculated visit: nvd.nist[.]gov/vuln-metrics/cvss. Figure 3 illustrates
the close to 1,600 active vulnerabilities in Denmark with an indication of the
severity of the individual vulnerability.
Figure 3: Active vulnerabilities in Denmark as of 2 December 2019
Based on Shodan’s data, the most critical vulnerabilities in Denmark include
those that are located at the top right corner of figure 3 – the vulnerabilities were
found in more than 7,500 potentially vulnerable units and had a CVSS Score of
minimum four, corresponding to “medium” severity. 17 vulnerabilities in total
fell within this quadrant of which 12 were of “medium” severity and five of “high”
severity. In addition, two “critical” vulnerabilities fell just outside the quadrant,
vulnerabilities that existed on more than 6,500 vulnerable units in Denmark and
had a CVSS Score above nine.
The CFCS has issued warnings pertaining to the two mentioned critical
vulnerabilities to its clients and on the CFCS website. The CFCS has also
contacted a number of Internet providers in an effort to directly warn the affected
parties.
From a societal perspective, there is a clear distinction as to whether a vulnerable
device supports critical infrastructure or has functions less vital to society.
Consequently, a vulnerability of “medium” severity in critical infrastructure may
have a much more severe impact on society if the vulnerability is exploited
Side 13 af 25
compared to a vulnerability of “critical” severity in a less vital unit. Nevertheless,
it is noteworthy that Shodan indicates that potentially several thousand Danish-
based units had vulnerabilities of “critical” severity and may potentially become
targets of hacker attacks.
The number of vulnerable units in Denmark depends very much on our capability
to implement essential security updates. The timespan between the public
disclosure of vulnerabilities and the implementation of security updates is crucial
as it determines the amount of time available to hackers for exploitation of
vulnerabilities.
In the incident reviewed in this report, five different hackers exploited a six-year-
old vulnerability, and even though Shodan no longer detects that specific
vulnerability in Danish IP addresses, figure 4 illustrates that the incident is far
from unique. Figure 4 shows the nearly 1,600 different active vulnerabilities
listed according to public disclosure date, illustrating how long it takes before
Danish public authorities and private companies implement key security updates
as well as giving an idea of the number of old vulnerabilities left unresolved in
Denmark.
Figure 4: Vulnerabilities in Denmark broken down by their disclosure dates.
Given that publication of vulnerabilities is often quickly followed by security
patches from the supplier, a dramatic drop in the number of active vulnerabilities
might be expected during the first two months. However, the graph indicates a
different reality as most active vulnerabilities in Denmark are several years old.
Side 14 af 25
Some vulnerabilities date as far back as 1999 and most of them are even also
relatively severe.
As a result, hackers often have several years to plan
and exploit old vulnerabilities before Danish public
authorities and private companies install security
updates. More alarmingly, however, the CFCS is also
registering hackers exploiting vulnerabilities that are
only a few weeks or days old.
In the final part of the report, we introduce a number
of initiatives that may help public authorities and
private companies improve their counter measures in
future.
Recommendations: Defense-in-Depth
strategy By using the Cyber Kill Chain® model in the analysis,
it is possible to learn from the incident illustrated above
and improve cyber security in a structured manner.
Specifically, dividing the attack into individual phases
may help identify some of the security precautions that
might have stopped or mitigated the attack in each
phase of the attack.
Below is listed a number of security measures that public authorities and private
companies may effectively implement to protect themselves against similar
attacks. The initiatives are based on the “defence in depth” concept, which
emphasizes that though victims can never fully protect against a targeted hacker
attack, they may increase the possibility of detecting, countering and mitigating
attacks by placing multiple layers of defence throughout their IT systems. Table
2 provides an overview of the various initiatives in each attack phase, which is
presented separately in the following pages.
Citrix vulnerability left more than thousand
Danish units potentially vulnerable
On December 17 2019 a severe vulnerability in
Citrix networking equipment was made public.
Already on January 10 a guide to hack via the
vulnerability – a so-called proof-of-concept – was
made public. The hackers thereby had more than
a week to exploit the vulnerability with the help
from the guidance, before the supplyer issued the
first security update on January 19. CFCS knows
about several Danish organizations, that in this
period was tried to compromise.
A search in Shodans database when the
vulnerability was made public revealed more than
thousand potentially vulnerable units in
Denmark.
CFCS has issued warnings to identified vulnerable
authorities and companies and has continuously
guided about countermeassures.
Side 15 af 25
Table 2: Cyber security initiatives divided by attack phases
Reconnaissance
Hackers likely identified the server of the organization by using freely available
search engines such as Shodan.
Detect
Use open search engines in your cyber defence
Private companies and public authorities may effectively use the same search
engines that hackers use to identify their own vulnerable Internet-facing devices.
A lot of large organizations, especially large corporate networks, have developed
their own IT infrastructure over several years, making it difficult to maintain the
full overview. These search engines may thus prove useful tools to beat the
hackers at their own game and detect “forgotten” or otherwise vulnerable
systems on private networks before the hackers find them. There are multiple
search engines, but two of the most popular ones are available on the websites
shodan[.]io and censys[.]io. It is also possible to get an it-security company to
scan ones own organization’s systems for vulnerable equipment.
If you find vulnerable equipment in the searches made and is not sure how to
react properly, you can contact CFCS for further guidance on mail or phone
[email protected] eller +45 33 32 55 80.
Side 16 af 25
Deny
Consider isolation of equipment
Not all units need Internet connection to run. In some instances, it is sufficient
that the unit is available on the organization’s internal local network (LAN) with
no Internet connection. As the number of Internet connected units increases, so
does the likelihood of a hacker attack.
In particular, it may prove useful to enclose network equipment from the Internet
if equipment updates are unavailable. Implementation of updates may be
impossible for various reasons and, if that is the case, the best alternative is to
ensure that access to the unit via an online connection is restricted. The issues
associated with outdated systems that are unable to interact with newer
systems, also called “legacy systems”, are further described below under the
paragraph “Patching: Keep your systems updated”.
Limit the access and banner information for search engines
Public authorities and private companies may effectively limit the banner
information obtained by search engines when they perform their scans.
Alternatively, private companies and public authorities may try to prevent the
search engines from indexing their sites. The IP addresses on the scanning
pages’ units may, for instance, be added to their firewall, thus blocking the
scanning. The challenge is that malicious actors try to hide their IP addresses
and are regularly changing them to avoid blocking. The list of blocked IP
addresses must thus be constantly updated, a potentially taxing task that may
not necessarily be worth the effort. For further information on how to map search
engines, go to greynoise[.]io.
Weaponization
The hackers prepared the malicious code that exploited the vulnerability in the
Oracle Application Server software as well as different kinds of web shells, all of
which could be downloaded freely from the Internet.
Detect
Stay updated on new vulnerabilities
Many hackers learn of vulnerabilities on online forums or websites where they
are typically disclosed as part of the distribution of security updates, potentially
inspiring hackers to exploit these vulnerabilities in practice. Thus, organizations
may benefit from joining such online forums where the latest vulnerabilities
related to their own systems are openly disclosed, as it will allow them to stay
updated on popular hacking techniques. Organizations should pay special
attention to vulnerabilities that include relevant Proof of Concept (PoC) code, i.e.
the malicious code is publicly available, including clear instructions on how to use
it in practice.
Side 17 af 25
Delivery & Exploitation
The hackers delivered the malicious code to exploit the vulnerability in the
organization’s server Oracle application – some of the hackers attacked directly
while others used a compromised proxy to hide their identity.
Detect
Network and Host Intrusion Detection Systems – NIDS and HIDS
Intrusion Detection Systems (IDS) is the collective name for two different types
of devices or software applications designed to monitor activity – either network-
based (NIDS) or host-based (HIDS) – for malicious activity and send alerts to
the administrator if suspicious activity is detected. When an activity triggers the
alarm, it must be manually analysed in order to determine whether the network
is actually under attack or it is merely a false positive.
A Network Intrusion Detection System (NIDS) is a network-based system that
monitors and analyses traffic from all devices on the network, looking for
suspicious patterns that may indicate malicious activity. In this connection, it is
crucial that the organization has in-depth knowledge of its normal network traffic
in order to detect potential anomalous network activities. Also, it is vital that the
organization has set up a clear plan of action in case an alert is triggered,
including whether there are available resources to analyse the alerts generated
by the systems, as an alert that is not addressed will have no effect.
Snort is one of the most widely used applications, designed to facilitate
identification of suspicious network traffic. Snort generates alerts according to a
set of rules that establish suspicious activities. The trick is to write Snort rules
that are able to clearly distinguish between legitimate and malicious network
traffic, ultimately reducing the number of false positives that need closer
examination. It is possible to write your own rules or use rules written by others.
These rules are distributed openly in the large online Snort community. Several
Snort rules are designed specifically to spot traffic generated by malicious web
shells.
In principle, Host Intrusion Detection Systems (HIDS) operate in the same way
as NIDS, but instead of detecting malicious traffic on a network, the system runs
on individual hosts and is thus closer to its users. HIDS has the capability to
tailor the ruleset to be very specific to the host system, enabling it to detect
backdoors running on a host, possibly installed via local WIFI or Bluetooth
connections. In addition, the system also detects insider attacks that involve the
use of USB drives. It may prove a daunting task to implement and support host-
based intrusion detection systems, especially within large, complex
organizations.
Similarly, so-called YARA rules may be applied to HIDS, specifically designed to
search for host-based malware codes. Once a certain malware type and the code
behind it has been identified, it will allow you to write YARA rules that will be
able to recognize such specific malware in future.
Side 18 af 25
File integrity checking
File integrity checking is a technology that organizations may use to monitor
critical files for potential changes by constantly generating cryptographic hash
values for individual files, which are subsequently securely saved. Any changes
to the monitored files will result in different hash values, ultimately facilitating
the monitoring of potential changes in critical files.
Deny
Do not use default logon/password
Before deploying new IT systems, all default passwords on hardware or software
components must be changed. It is very easy for hackers to find default
passwords on IT products, as they are usually freely available online. Figure 5
illustrates an example of how hackers share Danish server login information on
Shodan’s website, more specifically a server located in the city of Aarhus with
username “admin” and password “1234”. If the default password is not changed,
the device will be left unprotected against compromise.
Figure 5: Sharing of Danish server login information via Shodan
Patching: Keep your systems updated
One of the key elements in an efficient cyber defence is to keep your systems
updated. If the organization’s server in the specific incident had been updated
with available security updates, the hackers would not have been able to
compromise the server in the way described in this report. However, the setup
of an effective update regime may prove challenging for several reasons.
Firstly, the mapping of digital infrastructure is complex. Most organizations use
an extensive number of IT systems in their daily operations, and technology is
moving fast. It is important to bear in mind, though, that all IT systems and
Internet-facing devices are vulnerable to hacking attacks. It is a challenging
undertaking to maintain an overview of an organization’s dynamic IT landscape
while keeping all systems updated, but nonetheless it is vital to cyber security.
Thus, implementing an IT management system that continuously helps mapping
the entire digital infrastructure of the organization may prove useful.
Secondly, another challenge associated with patching is the unclear division of
responsibilities between the organization and suppliers. Is it the responsibility of
the organization itself or the IT supplier to implement and inform of critical
security updates? The responsibility is not always defined, and as a result, some
IT system updates are neglected. The responsibility for updates of operational
systems, programmes and third party components should thus always be clearly
stipulated in a patch management policy or outlined as contractual demands to
suppliers.
A third challenge associated with patching is the use of so-called ’legacy
systems’. Some organizations are dependent on old, typically customized IT
Side 19 af 25
systems that support critical parts of the organization but are no longer
maintained by the supplier or somehow require significant resources to
continuously update. For this very reason, these legacy systems are a significant
attack vector. If it is impossible to conduct updates or completely get rid of
legacy systems, the organization should focus on isolating them from the
Internet by keeping them in separate network segments. Thus, top executives
of the organization should make an informed decision as to whether they are
prepared to accept the security risk of an unpatched network.
A fourth challenge related to patching is the threat of software supply chain
attacks. Even though it is crucial to quickly implement security updates,
organizations should also focus on the threat of software supply chain attacks.
In a software supply chain attack, attackers target the IT supplier by inserting
malware into updates that are distributed to the supplier’s clients. Consequently,
organizations should only use reliable IT suppliers that maintain a high security
level. Also, some suppliers publish hash values in connection with their security
updates, allowing their clients to crosscheck whether any unauthorized changes
in the update configuration have occurred before implementation is commenced,
as discussed above under the paragraph “File Integrity Checking”.
Network and Host Intrusion Prevention Systems – NIPS and HIPS
Intrusion Prevention System (IPS) is the overall term for two different security
solutions that not only monitor network activity but also prevent suspicious traffic
that match the rules written in the system. The downside is that organizations
are forced to focus more on false positives as these will block legitimate traffic.
These solutions are also available on both network-based systems (NIPS) and
host-based systems (HIPS) and operate under the same principles as the
Intrusion Detection Systems described above.
Firewalls
In addition, firewalls are basic elements in an organization’s cyber security.
Firewalls allow the opening and closing of specific ports and serve to limit the
organization’s inbound and outbound traffic. Also, firewalls may be used to block
certain identified malicious domains or IP addresses. A firewall is typically
installed between the external network (Internet) and the organization’s internal
network but may also run on individual hosts to control inbound and outbound
traffic.
Firewalls are sometimes regarded as the most important piece of security
infrastructure and, at times, even the only security solution providing proper
protection, but it is important to keep in mind that firewalls have limitations.
Hackers often know of the type of traffic allowed to pass through the firewalls,
and it is thus imperative that an organization installs additional security tools to
detect and prevent attacks. Consequently, a firewall is not enough by itself and
should always be used in addition to other security measures as one of the layers
in the “defence in depth” strategy.
Side 20 af 25
Installation
Hackers uploaded both web shells and, in some instances, also additional
malware to the server.
Deny
Antivirus
An updated antivirus programme is an important part of the effort to detect and
prevent threats to hosts. A large share of the traffic – including malicious traffic
– that is sent over the Internet to servers is encrypted, making it difficult for
detection systems to spot it. Thus, it is essential to have an efficient host-based
antivirus system that is able to spot malicious code or programmes that run
directly on the machine once the contents have been decrypted when received
on the server. In the example above, the server’s antivirus programme
generated a number of alerts related to the crypto miner, but unfortunately the
alerts failed to generate responses. Luckily, the organization’s customized
antivirus programme also functioned as HIPS, as the programme actively
stopped the crypto miner from running on the server.
However, antivirus programmes by themselves fail to provide sufficient
protection, as they may not be able to detect web shells. IDS and IPS, including
implementation of, for instance, YARA and Snort rules may thus become a
valuable supplement to antivirus solutions, as mentioned above.
Access control
It is important to limit the number of users that have been given write access to
the server. Access lists specify the users with privileges on the organization’s
different systems. For instance, it is essential to distinguish between ordinary
users and users with administrative privileges.
Command & Control
In order to control the server, the hackers had to access their web shells, thus
creating a command and control connection.
Deny
Prevent suspicious inbound and outbound traffic
Although traffic to these communication connections may be difficult to detect,
some IDS’s may detect malicious activity, including suspicious DNS lookups or
new port openings. Alternatively, private companies and public authorities may
introduce so-called “whitelisting” and “blacklisting”, enabling a network
administrator to register certain websites and applications as trusted or
malicious, enabling the administrator to block or allow the organization’s
ordinary users access to these networks and systems.
Side 21 af 25
Actions on objective
Detect
Logging
Effective logging is the foundation of a top cyber defence. In principle, logging is
important in all attack phases; however, it is included in this phase to illustrate
that detection and analysis of an attack are only possible through effective
logging provided that the hacker has gone through all of the initial phases.
Even though many of the above measures have been implemented, it is still
difficult to completely avoid cyber attacks. Once an organization has been
breached, it is imperative that it has created effective logs that are able to help
analyse the incident. There are multiple challenges connected to logging such as
ensuring that there is sufficient storage capacity to save the extensive amount
of data and that the organization logs the correct data. In addition, organizations
are subject to different legislation regulating the type of data stored and data
storage limitations.
Side 22 af 25
Appendix 1: Cyber Kill Chain® model The Cyber Kill Chain® model provides a framework for analysis and prevention
of cyber attacks. The model was originally developed by US defence and security
group Lockheed Martin. The model is widely used in both public and private
sectors and originally determines seven chronological phases that a hacker goes
through before launching a cyber attack. However, in this report, the delivery
and exploitation phase has been fused into one phase to facilitate understanding.
By identifying what steps an attacker must complete in order to launch a cyber
attack, it is possible to map the attacker’s specific attack pattern and develop
customized security measures to each phase. The six phases included in this
report are as follows:
• Reconnaissance: The hacker plans the attack, making the necessary
research and identifying potential victims, ranging from a random,
vulnerable server to targeted attacks against individuals or organizations of
particular interest.
• Weaponization: The hacker develops malware weapons tailored to the
vulnerabilities of the intended victim discovered during the reconnaissance
phase.
• Delivery and exploitation: The hacker launches the attack, exploiting the
already identified vulnerabilities.
• Installation: Once the hacker has gained unauthorized access, they will
typically be able to install additional tools aimed at ensuring a more long-
term access as well as install other types of tools that may compromise more
specific targets.
• Command & Control: The different tools installed on the victim’s system
will often set up a communication channel through which the attacker
monitors and controls their operations.
• Actions on objective: Once the attacker has completed the five initial
phases, they are able to carry out their original objectives, which may range
from espionage or the prospect of financial gains to downright destruction of
hardware.
Side 23 af 25
Appendix 2: Table 1 (large version) – Patterns of Attack in the five compromises
Side 24 af 25
Appendix 3: Figure 3 (large version) - Active Vulnerabilities in Denmark pr. December 2 2019
Side 25 af 25
Appendix 4: Figure 4 (large version) – Vulnerabilities in Denmark distributed after publication date