Trusted Computing vs.

Advanced Persistent
Threats: Can a defender win this game?
Nikos Virvilis, Dimitris Gritzalis, Theodoros Apostolopoulos

Information Security and Critical Infrastructure Protection Research Laboratory

Dept. of Informatics, Athens University of Economics & Business (AUEB)
76 Patission Ave., Athens, GR-10434 Greece
{nvir, dgrit, tca}@aueb.gr

Abstract: As both the number and the complexity of cyber- evitable due to the advanced offensive capabilities of the at-
attacks continuously increase, it is becoming evident that tradi- tacker.
tional security mechanisms have limited success in detecting
However, we believe that the above mentioned malware
sophisticated threats. Stuxnet, Duqu, Flame, Red October and,
has been correctly labeled as APT for two main reasons: a).
more recently, Miniduke, have troubled the security communi-
It was used against sensitive state, military and industrial or-
ty due to their severe complexity and their ability to evade de-
ganizations in targeted attacks and has even been developed
tection - in some cases for several years, while exfiltrating giga-
for a unique target (e.g. Stuxnet), and b). It makes use of ad-
bytes of data or sabotaging critical infrastructures. The signifi-
vanced exploitation and evasion techniques, the majority of
cant technical and financial resources needed for orchestrating
which were unknown (zero-day) to the security community.
such complex attacks are a clear indication that perpetrators
are well organized and, likely, working under a state umbrella. Our contribution in this paper lies with: a). the technical
In this paper we perform a technical analysis of these advanced comparison of the malware, based on our own analysis (fo-
persistent threats, highlighting particular characteristics and cusing on behavioral/dynamic analysis of the samples in a
identifying common patterns and techniques. We also focus on controlled environment), as well as on published technical
the issues that enabled the malware to evade detection from a reports, and b). the identification of common attack patterns
wide range of security solutions and propose technical counter- in the samples, in an effort to identify why current security
measures for strengthening our defenses against similar th- solutions failed to detect those threats, and propose effective
reats. countermeasures for strengthening our defenses against si-
milar threats.
Keywords: Advanced Persistent Threat, Duqu, Stuxnet, Fla-
me, Red October, MiniDuke, Trusted Computing The paper is organized as follows: Section 2 – Related
work. Section 3 – Technical analysis of the malware, fol-
I. INTRODUCTION lowed by the presentation of common characteristics in Sec-
In the last two years or so, we have witnessed an impres- tion 4. In section 5, we describe out test environment and e-
sive change in the complexity of malware. Stuxnet, Duqu, valuate the effectiveness of specific countermeasures against
Flame, Red October and MiniDuke are examples of highly the malware samples, followed by our conclusions and fur-
sophisticated malware (Advanced Persistent Threats - APT), ther work in Section 6.
the development of which required skillful individuals with
expertise in multiple technology fields, as well as significant II. RELATED WORK
financial resources [1]. The term APT is frequently misused, In [2], the authors present a high level overview of Stux-
offering an easy excuse for companies which suffer a securi- net’s architecture. They point on the significant effort requi-
ty incident, as they can support that although following best red in developing such malware, as well as on the fact that
practices (which is rarely the case) that the incident was in- such attack would not be possible to succeed without insider
knowledge and support from a large team of experts. IBM fered with Industrial Control Systems (ICS), which were
[3], Symantec [4] and ESET [5] presented a detailed techni- configured by Programmable Logic Controllers (PLC), and
cal analysis of the malware and its modules. In [6-7], the more specifically Windows systems using Siemens Step-7
authors presented a detailed technical analysis of Duqu mal- software. After infecting such systems, Stuxnet would re-
ware, highlighting the similarities in terms of architecture program the PLC to make the centrifuges operate at speeds
and techniques used, with Stuxnet. They also developed a outside acceptable limits, causing their malfunction and e-
set of tools for detecting Duqu variants, which although ef- ventually destruction. Stuxnet was completely autonomous -
fective, are only applicable for the specific malware sample. a “fire and forget weapon” in military jargon and as a result,
A small number of technical reports have been published for there was very limited window for programming or logical
Flame [8, 9] analyzing its major components. Only prelimi- errors from the attacker’s side.
nary online reports are available for Red October campaign,
In order to develop such a complex threat, the team be-
offering a high level technical view of the malware and its
hind Stuxnet should have at minimum: a) access to a test en-
modules [10]. MiniDuke was discovered in February 2013
vironment with all relevant ICS, PLC, centrifuges and sup-
and early technical analysis revealed it’s very unique archi-
porting equipment - ideally an exact replica of the Natanz
tecture, a combination of zero-day sandbox evading exploits
infrastructure, b) experts for installing, configuring and ope-
and pure assembly coding [11-12]. Based on our literature
rating such specialized equipment, and c) a team of highly
review, no specific models/solutions have been proposed for
skilled programmers and security researchers for the devel-
addressing such threats. Only a few technical countermeasu-
opment of zero-day exploits used for infection of the targets
res have been published for the detection of APT [13]. They
(or access to a private exploit repository). Based on these re-
focus on the identification of fast-flux DNS domains and
quirements, it is logical to assume that the team behind
signature matching. As none of the malware samples were
Stuxnet was state-sponsored [2]. An interesting develop-
using fast-flux to hide their command and control (C&C) in-
ment on Stuxnet’s case happened recently, where an older
frastructure and transmitted network traffic was encrypted/-
sample was identified, named as Stuxnet 0.5 [23]. Prelimi-
obfuscated, such countermeasures would have limited suc-
nary research revealed that it had been active since 2005,
cess discovering those threats. This paper is the sequel of
supporting a subset of Stuxnet’s functionality and following
our short paper [14], which includes the technical analysis
a different technique for controlling the centrifuges, which
of Miniduke and the evaluation of the proposed counter-
was abandoned due to limited success in damaging them.
measures.
Trusted Computing has been proposed as a robust soluti- Initial infection and propagation.
on against widespread malware (worms, trojan horses) [15- The initial infection method has not been identified, but
17] however, it still faces significant shortcomings which li- taking into account that PLC systems are usually not conne-
mit its adoption [18]. Furthermore, as of today and to the cted to the internet (and most of the time not even connected
best of our knowledge there has not been any research on to a network at all), it could be due to the use of an infected
the potential benefits of Trusted Computing against Advanc- removable drive. This is a realistic assumption, as Stuxnet
ed Persistent Threats. actually infected removable drives. Stuxnet was able to sp-
read, using multiple propagation methods: Once an infected
Finally, in the last few years we have witnessed an im-
USB drive was connected to a windows system, Stuxnet
pressive rise in the complexity of smartphone malware [19].
would auto-execute requiring no user interaction, making
The “bring your own device (BYOD)” trend, which has be-
use of a zero-day vulnerability (MS10-046, although older
en endorsed by organizations due to the significant cost sav-
versions of Stuxnet used a modified autorun.inf technique).
ings it offers, has turned smartphones into a high value tar-
Also, it would try to exploit any network accessible win-
get. Exploitation of such devices can give attackers direct
dows systems using the Windows Server Service (MS08-
access to the organization IT infrastructure and due to the li-
067) or Print Spooler Zero-Day (MS10-061) vulnerabilities
mited security mechanisms available on such platforms they
and perform privilege escalation using MS10-073 and MS10
are an easy target [20-21].
-092.
III. TECHNICAL ANALYSIS Apart from the first vulnerability, the rest were unknown
A. Stuxnet to the security community (0-day). This means that Stux-
Stuxnet was the first of the four highly complex malware net’s team had either developed those exploits internally, or
that got detected and its earliest sample dates back to June had access to a private exploit repository. Other propagation
2009. Stuxnet’s speculated purpose was to sabotage the Ira- methods include copying itself to accessible network shares
nian Nuclear Program and more specifically Natanz urani- and the infection of WinCC database server using a hard-
um enrichment plant, something which has succeeded by coded database password.
causing physical damage to the infrastructure and as a result Finally, Stuxnet infected Step 7 project files, which - if
slowing down the program by four years [22]. Stuxnet inter- copied in another system and opened - would infect it.
When Stuxnet managed to gain access to its target systems - on its own. Nevertheless, attackers could use an infected
a Windows System with Siemens Step-7 PLC - it would re-- system as a stepping stone, for manually exploiting and in-
program the PLC, thus making the centrifuges operate outsi- fecting other systems on the same network.
de their limits and eventually destroy them.
Command and Control Servers.
Command and Control Servers. A small number of C&C Servers running CentOS Linux
Stuxnet was mainly a “fire and forget” malware. Howe- were identified. The malware connected to these servers
ver three C&C Servers have been identified, where the mal- over ports 80/TCP and 443/TCP, and used a custom C&C
ware was trying to connect to (assuming there was internet protocol. More specifically, for port 443/TCP a custom en-
access), to send basic information about the infected system. crypted protocol was used. For traffic destined to port 80/
TCP, Duqu used steganography, by encoding and attaching
the transferred data to JPEG image files.

Rootkit Functionality. Rootkit Functionality.

Stuxnet included rootkit code to hide its binaries on win- Similarly to Stuxnet, Duqu was using a rootkit module to
dows systems and also modified PLC code to present “ac- hide its files.
ceptable” values to the monitoring software although the ac-
tual systems were working above limits. It also used of two Evasion Techniques.
compromised digital certificates to sign its drivers in an ad- Duqu, having a similar list as Stuxnet, would scan for
ditional effort to evade detection [2]. known security products and based on the product and ver-
sion it would inject its payload accordingly, to evade detec-
Evasion Techniques. tion.
It would scan for known endpoint security products and
based on product name and version it would inject its pay- Encryption.
load accordingly, to evade detection. Duqu used AES-CBC for the decryption of executable
code received from the C&C server. Additionally, it used
Encryption. XOR to encrypt the data captured by the key logger module
Stuxnet was using XOR encryption with a static key and to encrypt the configuration file [6].
(0xFF) to decrypt parts of its payload and a 32-byte fixed
key to encode the data it sent to the C&C server, using again C. Flame
a XOR algorithm.
Flame was first detected in May 2012. However, it is be-
lieved that it had been already active for 5-8 years. Flame
B. Duqu was incidentally discovered while researching for another
malware infection [8]. One of the most interesting aspects of
Duqu was detected in September 2011. However, it is be-
this malware is its size, almost 20 megabytes, including all
lieved that it has been active since February 2010 [6]. It has
its modules, which is very uncommon [9]. There are no
significant similarities with Stuxnet, which have led researc-
strong connections between Flame and Stuxnet or Duqu, so
hers to believe that both threats were developed by the same
it is unlikely that Flame was developed by the same team
team, with a different objective [7]: Instead of sabotage, Du-
that developed the other two threats. However, based on the
qu’s objective was espionage. Duqu was a clearly targeted
use of the same exploits and common code/functions, it
malware and according to estimations infected no more than
could be the case that these teams were collaborating and
50 targets worldwide [9]. After initial infection, Duqu re-
had shared source code for at least one module [24]. Flame,
mained active for 36 days before self-destructing, although
like Duqu, was a targeted information stealing malware but
attackers could command it to persist for as long as needed.
significantly more widespread, as it had infected thousands
It included a key logging component which was used to col-
Windows system, mainly in Middle East. It had a key log-
lect sensitive information, such us passwords, which attack-
ging module similar to Duqu, took screenshots, intercepted
ers could use to gain access to other systems on the network.
email messages, used the internal microphone of the compu-
Similarly with Stuxnet, it was a modular malware, which
ter to record conversations and captured information about
made use of compromised certificates to sign its compo-
Bluetooth devices in proximity.
nents and thus be harder to detect.
Initial infection and propagation.
Initial infection and propagation.
Currently, Flame’s initial infection point is not clearly
Microsoft Word files which contained the zero day True
known. However, as it infected USB devices, this is a realis-
Type font parsing vulnerability (CVE-2011-3402) were us-
tic scenario. It did not replicate on its own, but attackers
ed as the initial attack vector. The malware did not replicate
could command it to infect other hosts using a variety of network devices, and recovery of deleted files on removable
techniques: Apart from infecting USB devices, it made use drives.
of two zero-day vulnerabilities (same as Stuxnet) Print Spo-
Moreover, it included key logging/screen capturing func-
oler (MS10-061) and Windows Shell (MS10-046). However
tionality and intercepted outlook’s email messages, calendar
the most impressive propagation technique was the imperso-
and contacts list. As a robust persistence mechanism, Red
nation of a Windows Update Server (WSUS). As all softwa-
October installed a plugin for Office and Adobe reader ap-
re updates are digitally signed, the attackers had to perform
plications. This parsed each opened Office or PDF file and
a complex cryptanalytic attack (chosen prefix collision at-
tried to identify embedded commands (injected by the at-
tack for the MD5 algorithm) against Microsoft's Terminal
tackers) to execute. Using this technique, even if the C&C
Services licensing certificate authority. This attack enabled
servers were taken down, the attackers could email specially
generation of valid digital signatures for Flame modules.
crafted documents to their victims and regain control of
Such advanced cryptanalytic attack required a team of skil-
their systems.
led cryptographers. According to estimations, it has cost
between 200K and 2M USD [1], another indication that
Initial infection and propagation.
such attacks are likely to be state-funded.
Targeted emails containing malicious Word and Excel
documents which exploited known vulnerabilities (CVE-
Command and Control Servers.
2009-3129, CVE-2010-3333 and CVE-2012-0158) were us-
Flame used more than 80 domains as C&C Servers,
ed for infecting the targets.
mostly Ubuntu Linux Servers. The communication was per-
formed over HTTP, HTTPS or SSH. Each malware build was unique for the specific target
and each e-mail was also tailor-made to increase the proba-
Rootkit Functionality. bility of been opened by the victim. Also, a Java exploit
Flame’s rootkit functionality enabled it to hide its net- (CVE-2011-3544) was used for delivering the malicious
work connections. payload.

Evasion Techniques. Command and Control Servers.

Flame included an extended list of more than 100 securi- More than 60 C&C domains were identified. However
ty products and adopted its strategy accordingly to evade only three hardcoded domains were included in each custom
them. Its binaries were using the .ocx extension as it is often build of the malware. Additionally, none of these domains
not scanned by antivirus engines in real time. were the actual C&C servers, but acted as proxies in order
to hide the real C&C infrastructure, which is currently un-
Encryption. known.
Flame made extensive use of encryption, using substituti-
on ciphers, XOR encryption, and RC4 algorithm to encrypt Rootkit Functionality.
its configuration, modules and captured data. No rootkit component has been identified.

Evasion Techniques.
D. Red October The minimalistic architecture of the malware, having a
Red October was discovered in October 2012. Although basic component responsible for downloading encrypted
it is still under analysis, current findings indicate that it is a- modules and executing them in memory, allowed it to re-
nother targeted malware for information gathering. It is beli- main undetected without having to perform additional evasi-
eved that it has been active since May 2007, targeting diplo- on techniques.
matic, governmental and scientific agencies [10]. Red Octo-
ber does not seem to have common characteristics with any Encryption.
of the other three malware samples. It followed a minimalis- Red October used a custom packer with XOR encryption.
tic architecture, with one main component responsible for The same algorithm was also used for encrypting exfiltrated
connecting to the C&C Servers. When commanded to do so data.
by the attackers, it downloaded and executed specific modu-
les (at least 1000 different modules have been identified) en-
abling it to perform a wide range of tasks [10]. This small D. MiniDuke
footprint was one of the main reasons it managed to evade MiniDuke was discovered on 27 February 2013, but earlier
detection for several years. Some characteristic functionality samples have been identified and date back in June 2011
includes: Stealing of information from Nokia phones and i- [11]. It targeted government bodies in 23 countries, mainly
Phones, SNMP brute forcing in an effort to gain access to in Europe. It had a unique architecture, as it combined mod-
ern exploitation techniques to bypass Adobe’s PDF sand- Rootkit Functionality.
box, and pure assembly coding for its payload [12]. No rootkit functionality has been identified.

Initial infection and propagation. Evasion Techniques.

MiniDuke spread over email, using malicious, well-crafted MiniDuke’s first stage, written completely in assembly lan-
PDF files. The PDF files contained code which triggered a guage, contained a list of security related processes (debug-
vulnerability in Abobe Reader versions 9, 10 and 11, by- gers, disassemblers, file system monitoring software, etc).
passing the sandbox and executing the malware’s payload Upon detection of any of these processes, it would remain at
on the victim’s system idle state, not performing any malicious actions. Newer
samples would also wait for user interaction (e.g. mouse
Command and Control Servers. movement) before decrypting and executing the payload to
The malware used a sophisticated, layered technique for lo- thwart automated malware analysis. Finally, after initial
cating the C&C servers. Initially (first stage) it connected to execution the malware would generate a new copy of itself -
specific Twitter accounts controlled by the attackers, which that was encrypted using a key derived from the computer’s
contained the encrypted URL’s of the C&C servers. If Twit- hardware configuration - and replace the original executa-
ter was not accessible (e.g. twitter accounts had been block- ble. As a result, the malware would only be able to decrypt
ed) the malware would use Google Search to find the en- correctly under this particular system, making analysis of
crypted C&C servers by searching for specific unique the sample on a different system significantly challenging.
strings. Upon locating the servers, the malware received ad-
ditional malicious payload (second stage), obfuscated as Encryption.
GIF images, which in turn would download a larger backdo- MiniDuke was making heavy use of encryption. Each pay-
or (third stage) enabling the attackers to control the infected load was specially built for each victim and was decrypted
system. A large number of C&C servers have been identifi- based on a key generated by the CPU, Drive and Computer
ed, however all of them have been legitimate web sites, name of the victim. Additional layers of XOR and ROL ob-
compromised by the attackers. fuscation were also used.

TABLE I – ADVANCED PERSISTENT THREATS COMPARISON

Stuxnet Duqu Flame Red October Mini Duke

Active since June 2009 (2005) Nov. 2010 May 2012 (2006) May 2007 June 2011

Detected June 2010 Sept. 2011 May 2012 Oct. 2012 Feb. 2013

PE Type DLL OCX EXE EXE

MS Excel /
Initial infection Unknown MS Word Unknown PDF
Word, Java

Removable drives,
Replication Manual replication only
network

Rootkit module Yes No

Key logging No Yes No

Evasion Yes No Yes

XOR, RC4, Unique per victim,

Encryption XOR XOR, AES-CBC XOR
Substitution XOR, ROL

Target Sabotage Information gathering

could have enabled the malware to evade detection by com-

IV. COMMON MALWARE CHARACTERISTICS AND monly used security technologies:
POTENTIAL REASONS FOR DETECTION FAILURE

Based upon our technical analysis, we have identified A. Targeted operating system and architecture.
common malware characteristics, such as: similar techniqu- All samples were targeting 32-bit versions of Windows.
es, attack paths and functionality. Focusing on these charac- Interestingly enough, none of the malware would execute on
teristics, we highlight in the sequel the potential issues that 64-bit systems. The additional security mechanisms that are
available on the 64-bit versions of windows (especially win- All malware communicated over ports 80/TCP, 443/TCP
dows 7 and newer) complicate significantly the exploitation, or 22/TCP, as egress traffic destined to such ports is frequ-
especially when malware targets kernel components [25]. ently allowed to pass through network access control mecha-
However, based on the fact that attackers had access to valid nisms. The communication protocols were HTTP, HTTPS
certificates (Stuxnet, Duqu) that they could use to sign the and SSH. However, additional layers of encryption/obfusca-
64-bit components of their malware (thus allowed to execute tion and compression were also used. Malware’s success to
in kernel space), we consider that the main reason that the communicate back to the C&C infrastructure highlights the
malware targeted 32-bit systems was, that the majority of fact that most of the victims had very relaxed internet access
the victims were using this architecture. restrictions in place (if any) - a worrying finding, taking into
account the sensitive nature of the targeted organizations.
B. Initial attack vectors.
Duqu and Red October both used malicious Word and E. Network IDS and endpoint antivirus products.
Excel documents for infecting their targets, while MiniDuke Stuxnet, Flame, Duqu and MiniDuke were designed to
exploited Adobe’s PDF Reader. For Stuxnet and Flame the detect and evade Antivirus Software, using multiple techni-
initial infection method has not been identified, however in- ques. Moreover, Flame, Duqu, Red October and MiniDuke
fection through removable drives or spearfishing attacks, is encrypted or obfuscated their network traffic, to and from
the most likely scenario. Microsoft since the release of Offi- the C&C servers, so as to “pass under the radar” of Network
ce 2010 Suite, has introduced “protected view” [26], a sand- Intrusion Detection Systems (NIDS). As a result, the level of
box feature for opening office documents received from un- protection offered by both Antivirus and NIPS products a-
trusted sources - such as downloaded from internet or recei- gainst advanced threats has received strong criticism, after
ved as an email attachment. By default, all new files are o- they failed to identify such threats - even when they had be-
pened in protected mode, thus any potentially malicious en active for several months/years [27]. The shortcomings of
payload would have to face the additional barrier of escap- such systems, mainly due to the strong reliance on pattern
ing the sandbox. matching (signature based detection) are well known to the
research community for long [28-29], nevertheless, they are
Further analysis proved that none of the Office vulnerabi-
most common (if not the only one) set of tools that defen-
lities was able to escape the sandbox. Thus, we have to assu-
ders have.
me that victims who got infected were running outdated ver-
sions of MS Office and potentially other third party software
F. Use of Encryption / Obfuscation.
(Java, etc.) and/or had disabled the security features offered
All samples relied strongly on XOR “encryption” to deter
by newer versions of the software. This was not the case for
detection and complicate malware analysis (packing), as
MiniDuke, which was able to exploit all versions of Adobe
well as for protecting the configuration file(s) and transmit-
Reader and at the same time evade the sandbox.
ted traffic. Additionally Duqu and Flame also used AES and
RC4 algorithms, respectively. The use of encryption in a
C. Command execution and escalation of privileges.
program cannot be categorized as malicious on its own,
All malware made use of exploits for command execution
however it is a useful indication during behavioral analysis
or privileged escalation, the vast majority of which were un-
of potentially malicious files.
known to the security community (0-day). Exploitation of
zero day vulnerabilities against the Operating System is pro-
G. Exploitation of digital signatures.
bably the most challenging problem to address. As long as
Stuxnet and Duqu binaries were digitally signed using
these vulnerabilities remain unknown to the vendor, all af-
compromised digital certificates. Thus, these samples would
fected systems will be vulnerable. Even when security pat-
manage to infect hardened systems, where only digitally sig-
ches addressing these vulnerabilities had been released, still
ned binaries were allowed to execute. Similarly, Flame ex-
a large number of systems continued to get infected, high-
ploited the collision resistance of MD5 hash function to per-
lighting the lack of patch management procedures, even in
form the same task, and replicated through the WSUS Servi-
sensitive environments
ce.
D. Network Access. Based on these findings, allowing execution of binaries
based on the existence of valid digital signatures cannot be
considered an effective defense on its own. This is particu- ing the VM’s in a clean state), but this time we activated the
larly important for Antivirus and HIPS solutions, which tend Windows firewall (blocking all ingress ports) on the VMs.
to avoid real-time analysis of signed binaries for performan- As expected, traffic from the infected VM was blocked and
ce reasons. thus Stuxnet failed to propagate.
V. COUNTERMEASURES C. Whitelisting: Furthermore, as all malware had to con-
nect back to a C&C server for receiving commands or exfilt-
Due to the complexity of those threats and the multiple
rating data, strict internet access policies and granular traffic
attack paths, a wide range of security countermeasures and
inspection of both incoming and outgoing data, are required.
hardening procedures are necessary to enable a multi-layer-
Instead of following a blacklist approach which would inevi-
ed, robust defense. In order to test the effectiveness of each
tably fail to block all malicious traffic, a relaxed whitelist
proposed countermeasure in the section, we created the fol-
approach can be a much more secure alternative for use, in
lowing environment: Each sample was executed in a Win-
sensitive organizations. Depending on the risk appetite of
dows XP SP3 32bit virtual machine with Office 2007 SP1,
the organization, the whitelist could even include the most
while all registry, file system and network connections were
common (non-work related) websites that users are visiting.
monitored. The virtual machine was given a private IP ad-
This would completely block any malicious connection at-
dress in the same range where other three additional virtual
tempts to C&C servers, unless attackers were able to exploit
machines were located (Windows XP SP2 32bit, Windows
any whitelisted services/systems and set their C&C infras-
XP SP3 32bit and Windows XP SP2 64bit), all vanilla in-
tructure there.
stallations. The default gateway of all VM’s was pointing to
a Linux box, which acted as a gateway/proxy and captured For this test we configured our Linux gateway to allow
all network traffic. outgoing traffic to the Alexa top 100 web sites [31]. Then
we executed each sample on the victim VM, monitoring the
A. Patch Management: Patch management, for both Op-
network traffic. As the C&C domains have long been taken
erating System and third party applications, is the first line
down, we were not expecting a successful connection to any
of defense. Although it will have limited effect on the miti-
C&C server, however our test was to prove that all malware
gation of zero-day vulnerabilities, it will stop further exploi-
specific domains that samples tried to connect to, were
tation of new systems when the vulnerabilities are discov-
blocked by the firewall as there were not in the white list.
ered and addressed by the vendor. As expected, all malware
samples failed to infect our test system when the corre- D. Dynamic content execution: Focusing on the client
sponding vulnerabilities were patched. side exploitation mechanisms, it is evident that the majority
of end-user exploitation techniques (e.g. Malicious Office,
B. Network Segregation: Strong internal network access
PDF documents) required dynamic content execution for
controls and monitoring are also crucial. In the majority of
triggering the vulnerabilities. Filtering mechanisms at the
cases, multiple systems had to be exploited until the objec-
network ingress points could filter dynamic content in in-
tive of an attack was met (e.g. data exfiltration or sabotage).
coming traffic (e.g. Javascript from PDF and html files, ma-
One of the most effective techniques that could severely
cro’s from Office files) thus protecting against a wide range
block the ability of the malware to spread internally is the i-
of exploitation mechanisms [30].
solation between the workstations. This could be achieved
by the use of network or host based firewalls, configured to For the test we installed Microsoft Office 2010 on our
allow workstations to only connect to specific server sys- test VM (as the protected view feature is supported from
tems, based on their role/business requirements (e.g. Active version 2010 and later). Then we opened two malicious
directory, Mail, Web/Proxy Server). word files containing Duqu and Red October samples. When
the malicious documents were copied locally e.g. copied
Although attackers could focus on exploiting the servers,
from a USB device, Protected View was not activated and
servers tend to be more closely monitored and hardened than
thus did not provide any protection against the malicious fi-
workstations, raising the bar for attackers. As Stuxnet was
les. In addition as Duqu’s exploit was not Office Specific
the only sample that would self-propagate, we executed it in
but exploited then Win32k TrueType font parsing engine
the test VM, while monitoring all traffic to the VM network.
and thus even with protected view enabled, the system was
After a short period of time the two 32bit Windows VM’s
infected. However Protected View did block the infection
were also infected. We repeated the experiment (after restor-
from Red October when the malicious word file exploiting negative impact on user experience (due to the additional li-
the CVE-2010-3333 vulnerability was executed from a net- mitations) are blocking their adoption.
work location.
Based on the fact that traditional security solutions, have
E. Trusted Computing: A secure computing base by limit- failed repeatedly to address the APT problem and organiza-
ing and controlling the software that is allowed to be instal- tions are reluctant to adopt high maintenance solutions/-
led and executed on a system, would significantly reduce the countermeasures, we need to shift our focus on more robust
impact of APT attacks. Although the limitations have been and transparent solutions. We consider that a Trusted Com-
extensively discussed [18], we should take into account that puting Base can be an invaluable tool in addressing this
the majority of APT attacks target sensitive organizations- multi-dimensional problem.
/critical infrastructures. We believe that in such environ-
Our future research will take into account, build upon and
ments, the benefits introduced by a TCB significantly over-
exploit our earlier publications record on fighting malware
come the shortcomings.
[32-36] and will focus on the design of a generic TCB archi-
VI. CONCLUSION tecture, which could be implemented in security-critical con-
texts/infrastructures, with a foreseen limited impact on the
It is evident that use of widely accepted best practices/-
business operations and user experience.
countermeasures such as the ones presented in the previous
section, would have reduced the impact of such malware.
Unfortunately, it seems that even in critical infrastructures,
only a small subset of such protection mechanisms was en-
forced. The required resources, technical expertise and the
[9]. Kaspersky Labs. [Online] 28 May 2012 [Cited: 01 January
2013]
REFERENCES http://www.securelist.com/en/blog?weblogid=208193522
[1]. Fisher, D.: Threatpost. [Online] 15 June 2012 [Cited: 01 02 [10]. Kaspersky Labs. "Red October" Diplomatic Cyber Attacks
2013] https://threatpost.com/en_us/blogs/what-have-we- Investigation. [Online] 14 01 2013 [Cited: 15 01 2013]
learned-flame-malware-061512 http://www.securelist.com/en/analysis/204792262/Red_Octo
[2]. Chen, T., Abu-Nimeh, S.: 2011. Lessons from Stuxnet. ber_Diplomatic_Cyber_Attacks_Investigation
Computer 44, 4 (April 2011), 91-93. [11]. Tivadar, M., Balazs, B., Istrate, C., A closer look at Mini-
http://dx.doi.org/10.1109/MC.2011.115 duke. [Online] [Cited: 20 05 2013] http://labs. bitdefend-
[3]. Larimer, J.: An inside look at Stuxnet, IBM, 2010. er.com/wp-content/uploads/downloads/2013/04/ MiniDuke_
Paper_Final.pdf
[4]. Falliere, N., Murchu, L., Chien, E., W32.Stuxnet Dossier,
Symantec, February 2011. [12]. Raiu, C., Soumenkov, I., Baumgartner, K., Kamluk V., “The
MiniDuke Mystery” [Online] [Cited: 10 05 2013]
[5]. Matrosov, A., Rodionov, E., Harley, D., Malcho, J., Stuxnet
https://www.securelist.com/en/downloads/vlpdfs/themystery
Under the Microscope, ESET, 2011.
ofthepdf0-dayassemblermicrobackdoor.pdf
[6]. Symantec, W32.Duqu - The precursor to the next Stuxnet,
[13]. Binde, E., McRee, R., O'Connor, T., “Assessing Outbound
Symantec, 2011.
Traffic to Uncover Advanced Persistent Threat”, SANS Insti-
[7]. Bencsath, B., Pek, G., Buttyan, L., Felegyhazi, M., “Duqu: tute. Online] 2011 [Cited: 21 12 2012] http://www.sans.edu/
Analysis, detection, and lessons learned”, in Proc. of the 2nd student-files/projects/JWP-Binde-McRee-OConnor.pdf
ACM European Workshop on System Security, 2012.
[14]. Virvilis N., Gritzalis D., “The Big Four - What we did wrong
[8]. Bencsath, B., Pek G., Buttyan L., Felegyhazi M., “The Cous- in protecting critical ICT infrastructures from Advanced Per-
ins of Stuxnet: Duqu, Flame, and Gauss”, in Proc. of Future sistent Threat detection?”, in Proc. of the 8th International
Internet, 2012. Conference on Availability, Reliability & Security, pp. 248-
254, IEEE, 2013.
[15]. Gajek, S., “Compartmented security for browsers - or how to [27]. Schneier, B., www.schneier.com. [Online] 19 June 2012.
thwart a phisher with trusted computing”, in Proc. of the 2nd [Cited: 6 February 2013.] http://www.schneier.com
International Conference on Availability, Reliability and Se- /blog/archives/2012/06/the_failure_of_3.html.
curity, p. 120-127, 2007
[28]. Cohen, F., Computer Viruses, ASP Press, 1986.
[16]. Kuhlmann, D., Landfermann, R., Ramasamy, H., Schunter,
[29]. Denault, M., Gritzalis, D., Karagiannis, D., Spirakis, P.,
M., Ramunno, G., Vernizzi, D., “An open trusted computing
“Intrusion detection: Evaluation and performance issues of
architecture - Secure virtual machines enabling user-defined
the SECURENET system”, Computers & Security, vol. 13,
policy enforcement”, Web Page: http://www. opentc.net/acti
no. 6, pp. 495-508, 1994.
vities/otc_HighLevelOverview/OTC, 2006.
[30]. Lagadec P., "Diode réseau et ExeFilter: 2 projects pour des
[17]. Litty, L., Lie, D., “Manitou: a layer-below approach to fight-
interconnexions sécurisées", in Proc. of SSTIC06, pp. 1-15,
ing malware”, in Proc. of the 1st Workshop on architectural
2006.
and system support for improving software dependability, pp.
6-11, ACM, 2006. [31]. Alexa Top Sites - http://www.alexa.com/topsites

[18]. Oppliger, R., Rytz, R., “Does trusted computing remedy com- [32]. Doumas, A., Mavroudakis, K., Gritzalis, D., Katsikas, S.,
puter security problems?”, Security & Privacy, IEEE, 3(2), “Design of a neural network for recognition and classifica-
16-19, 2005. tion of computer viruses”, Computers & Security, vol. 14, no.
5, pp. 435-448, October 1995.
[19]. Mylonas, A., Tsoumas, B., Dritsas, S., Gritzalis, D.,
“Smartphone security evaluation: The malware attack case”, [33]. Gritzalis, D., "Enhancing security and improving interopera-
in Proc. of the 8th International Conference on Security and bility in healthcare information systems", Informatics for
Cryptography, pp. 25-36, SciTekPress, 2011. Health and Social Care, vol. 23, no. 4, pp. 309-324, 1998.

[20]. Mylonas, A., Dritsas, S., Tsoumas, B., Gritzalis, D., “On the [34]. Kandias, M., Mylonas, A., Virvilis, N., Theoharidou, M.,
feasibility of malware attacks in smartphone platforms”, Se- Gritzalis, D., “An Insider Threat Prediction Model”, in Proc.
curity and Cryptography, pp. 217-232, Springer (CCIS-314), of the 7th International Conference on Trust, Privacy, and Se-
2012. curity in Digital Business, pp. 26-37, Springer (LNCS 6264),
2010.
[21]. Gritzalis, D., “Embedding privacy in IT applications devel-
opment”, Information Management & Computer Security, [35]. Katsikas, S., Spyrou, T., Gritzalis, D., Darzentas, J., "Model
vol. 12, no. 1, pp. 8-26, 2004. for network behaviour under viral attack", Computer Com-
munications, vol. 19, no. 2, pp. 124-132, 1996.
[22]. Lemos, R., Infoworld. [Online] 19 January 2011 [Cited: 02
February 2013] http://www.infoworld.com/t/malware/stux [36]. Katsikas, S., Gritzalis, D., Spirakis, P., “Attack Modeling in
net-attack-more-effective-bombs-888 Open Network Environments”, in Proc. of the 2nd Communi-
cations and Multimedia Security Conference, pp. 268-277,
[23]. Symantec, Stuxnet 0.5: The missing link, Symantec, 2013.
Chapman & Hall, 1997.
[24]. Kaspersky Labs. [Online] 11 June 2012. [Cited: 3 February
2013.] http://www.kaspersky.com/about/news/virus/2012/Re
source_207_Kaspersky_Lab_Research_Proves_that_ Stuxnet
_and_Flame_Developers_are_Connected
[25]. Field, S., An introduction to kernel patch protection. [Online]
12 August 2006. [Cited: 08 February 2013.]
http://blogs.msdn.com/b/
[26]. Microsoft: [Online] [Cited: 11 02 2013.]
http://office.microsoft.com/en-001/excel-help/what-is-
protected-view-HA010355931.aspx.