ESET Smart Security v3.0.650.0 serial key or number

BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS

DEPARTMENT OF NETWORKED SYSTEMS AND SERVICES

New Methods for Detecting Malware Infections

and New Attacks against Hardware Virtualization

Ph.D. Dissertation

of

Gábor Pék

Supervisor:

Levente Buttyán, Ph.D.

Opponents:

Herbert Bos, Ph.D.

Vrije Universiteit Amsterdam

László Lengyel, Ph.D.

Budapest University of Technology and Economics

Budapest, Hungary

2015

Alulírott Pék Gábor kijelentem, hogy ezt a doktori értekezét magam készítettem és abban

csak a megadott forrásokat használtam fel. Minden olyan részt, amelyet szó szerint,

vagy azonos tartalomban, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás

megadásával megjelöltem.

I, the undersigned Gábor Pék hereby declare, that this Ph.D. dissertation was made by

myself, and I only used the sources given at the end. Every part that was quoted word-forword,

or was taken over with the same content, I noted explicitly by giving the reference of the

source.

A dolgozat bírálatai és a védésről készült jegyzőkönyv a Budapesti Műszaki és Gazdaságtudományi

Egyetem Villamosmérnöki és Informatikai Karának dékáni hivatalában elérhetőek.

The reviews of the dissertation and the report of the thesis discussion are available at

the Dean’s Office of the Faculty of Electrical Engineering and Informatics of the Budapest

University of Technology and Economics.

Budapest, . . . . . . . . . . . . . . . . . . . . . . . .

Gábor Pék

iii

Abstract

In my dissertation, I address problems in two domains: (i) Detection of unknown malware and (ii) finding

new attacks against hardware virtualization. Accordingly, this dissertation is divided into two parts.

In the first part of the dissertation, I propose Membrane, a memory forensics tool to detect code injection

attacks. Instead of trying to detect the code injection event itself, I focus on the changes it causes on the

paging behavior of the Windows operating system. As my method focuses on the anomalies caused by

code injection in paging events, I am able to detect a wide range of code injection techniques. My results

indicate that on Windows XP we can detect malware behavior with 91-98% success. On Windows 7, a

good detection rate is maintained except for malware injecting into explorer.exe where the success of

detection decreases to 75-86%. My approach can detect stealthy malware attacks, even advanced targeted

attacks using code injection.

Still in the first part, I propose a new system monitoring framework that can serve as an enabler for

automated malware detection on live systems. My approach takes advantage of the increased availability

of hardware assisted virtualization capabilities of modern CPUs, and its basic novelty consists in launching

a hypervisor layer on the live system without stopping and restarting it. This hypervisor runs at a higher

privilege level than the OS itself, thus, it can be used to observe the behavior of the analyzed system in a

transparent manner. For this purpose, I also propose a novel system call tracing method that is designed to

be configurable in terms of transparency and granularity.

In the second part of the dissertation, I shed light on VM related threats and defences by implementing,

testing, and categorizing a wide range of known and unknown attacks based on directly assigned devices. I

executed these attacks on an exhaustive set of VMM configurations to determine their potential impact. My

experiments suggest that most of the previously known attacks are ineffective in current VMM setups. I also

developed an automatic tool, called PTFuzz, to discover hardware-level problems that affect current VMMs.

By using PTFuzz, I found several cases of unexpected hardware behaviour, and a major vulnerability on

Intel platforms that potentially impacts a large set of machines used in the wild. These vulnerabilities

affect unprivileged virtual machines that use a directly assigned device (e.g., network card) and have all

the existing hardware protection mechanisms enabled. Such vulnerabilities allow either an attacker to

generate a host-side interrupt or hardware faults, violating expected isolation properties. These can cause

host software (e.g., VMM) halt as well as they might open the door for practical VMM exploitations. I

believe that my study can help cloud providers and researchers to better understand the limitations of their

current architectures to provide secure hardware virtualization and prepare for future attacks.

At the same time, security practitioners make heavy use of various virtualization techniques to create

sandboxing environments that provide a certain level of isolation between the host and the code being analysed.

However, most of these are easy to be detected and evaded. The introduction of hardware assisted virtualization

(Intel VT and AMD-V) made the creation of novel, out-of-the-guest malware analysis platforms

possible. These allow for a high level of transparency by residing completely outside the guest operating

system being examined, thus conventional in-memory detection scans are ineffective. Furthermore, such analyzers

resolve the shortcomings that stem from inaccurate system emulation, in-guest timings, privileged

operations and so on.

Finally, I introduce novel approaches that make the detection of hardware assisted virtualization platv

forms and out-of-the-guest malware analysis frameworks possible. To demonstrate my concepts, I implemented

an application framework called nEther that is capable of detecting the out-of-the-guest malware

analysis framework Ether [Dinaburg et al., 2008a].

vi

Kivonat

A disszertációmban két problématerülettel foglalkozom: (i) ismeretlen kártékony kódok detekciója és (ii)

új támadások vizsgálata hardver virtualizáció ellen. Ebből adódóan a disszertáció két részre bontható.

Az első részben először egy új memória forenics eszközt javaslok Membrane néven, melynek célja a kód

injekciós támadások detektálása. Ahelyett, hogy a kódinjekció tényét detektálnám, a Windows operációs

rendszerben jelentkező laptábla eseményváltozásokat vizsgálom meg nagy alapossággal. Mivel a laptáblaesemények

által okozott anomáliákra fókuszálok, széles spektrumban lehet detektálni különböző típusú

injekciós eljárásokat. Az eredmények Windows XP operációs rendszer esetén 91-98%-os pontosságot mutatnak,

míg Windows 7 rendszereknél még a legzajosabb folyamatok esetén is (pl.: explorer. exe) 75-

86% a detekciós pontosság. Az eljárásomnak köszönhetően lehetséges ilyen típusú rejtőzködő kártékony

kódokat detektálni, még ha célzott támadásból vett kampányról is van szó.

Ezt követően egy új rendszer-monitorozó eszközt javaslok, amely automatikus malware detekciót tesz

lehetővé éles gépek esetén. A megközelítésem a modern CPU-kban elérhető hardverrel támogatott virtualizációs

eljárást használja ki, illetve azt a tényt, hogy ezáltal lehetőség van egy hypervisort telepíteni a futó

operációs rendszer alá anélkül, hogy le kéne a gépet állítani, vagy újra kéne azt indítani. Ez a hypervisor

magasabb privilégium szinten fut, mint az operációs rendszer maga. Ennek köszönhetően a rendszert transzparensebben

lehet megfigyelni, mint más módszerekkel. Ebből a célból javaslok továbbá egy új rendszermonitorozó

eljárást, melyet a transzparencia és az elemzési granularitás mentén lehet finomhangolni.

A disszertáció második részében rávilágítok a VM-ekhez kapcsolódó fenyegetésekre és védelmi megoldásokra

azáltal, hogy a közvetlen eszközcsatolással kapcsolatos támadások széles skáláját tervezem meg,

implementálom le és kategorizálom. Ezeket a támadásokat sok különböző VMM konfigurációval teszteltem,

hogy kiderítsem a tényleges hatásukat. A vizsgálataim megmutatták, hogy a futtatott támadások egy jó

része tulajdonképpen hatástalan a mai VMM beállítások mellett. Kifejlesztettem azonban egy automatikus

eszközt, amit PTFuzz-nak neveztem el, hogy hardver szintű, VMM-hez kapcsolódó problémákat fedezzek

fel. A PTFuzz segítségével számos váratlan hardverviselkedést, továbbá egy Intel platformhoz köthető

komoly sérülékenységet találtam, mely rengeteg Intel chipsetre és ezáltal gépre hatással van a mai napig.

Ez a sérülékenység minden olyan nem privilegizált virtuális gépet érint, mely közvetlen eszközcsatolással

rendelkezik minden létező hardveres biztonsági védelem mellett. Egy támadó a sérülékenység segítségével

hosztoldali interrupt-ot vagy hardver hibát tud generálni megsértve ezáltal az elvárt izolációs működést. Ez

előbbi elméleti szinten tényleges virtualizációs kitörést is lehetővé tehet, míg a második a hoszt szoftver

(pl.: VMM) teljes leállását idézheti elő. Hiszem, hogy a tanulmányom segít a felhő szolgáltatóknak és kutatóknak

jobban megérteni a jelenlegi architektúra korlátait, hogy biztonságos hardver virtualizációs platformot

hozzanak létre és felkészüljenek jövőbeli támadásokra.

Ugyanakkor a biztonsági szakértők nagy mértékben támaszkodnak a különböző virtualizációs technikákra,

hogy sandboxing környezeteket hozzanak létre, melyek valamilyen szintű izolációt biztosítanak a

hoszt és az analizált kód között. Azonban ezek nagy részét nagyon könnyű detektálni és kikerülni. A hardverrel

támogatott virtualizáció bevezetése (Intel VT és AMD-V) lehetővé tette az újszerű, vendégkörnyezeten

kívüli kártékony kód analízis platformok létrehozását. Ezek magas transzparenciát biztosítanak, és vendég

operációs rendszeren kívül helyezkednek el teljes mértékben, így hatástalanítva a hagyományos memóriavii

szintű ellenőrző eljárásokat. Ezen analizátorok továbbá megoldják a pontatlan rendszer emulációból, vendég

környezeten belüli időzítésből és a privilegizált műveletek használatából adódó hiányosságokat.

Az utolsó bekezdésben ezért egy új megközelítést mutatok be, amely lehetővé teszi a hardverrel támogatott

virtualizációs környezetek és a vendég környezeten kívüli analízis keretrendszerek detektálását. Az épzelésem

demonstrálása céljából, egy alkalmazás keretrendszert implementáltam nEther néven, mely képes detektálni

az Ether nevű, vendég környezeten kívüli analízis rendszert.

viii

Acknowledgement

First of all, I would like to express my gratitude to my supervisor, Professor Levente Buttyán, Ph.D., Head

of the CrySyS Laboratory, Budapest University of Technology and Economics. He gave me guidance in

selecting problems to work on, helped in elaborating the problems, and pushed me to publish the results.

All these three steps were needed to finish this thesis.

I am also grateful to the current and former members, and students of the CrySyS Laboratory: Boldizsár

Bencsáth, Márk Félegyházi, Tamás Holczer, Áron Lászka, Vinh Thong Ta, Gábor Gulyás, Máté Horváth,

Zsombor Lázár, Zoltán Várnagy, Gábor Molnár, Gábor Ács-Kurucz, Olivér Pintér, Zsolt Hornyák, Máté

Bene, András Gazdag, and Szabolcs Váradi for the illuminating discussions on different technical problems

that I encountered during my research. They also provided a pleasant atmosphere which was a pleasure to

work in. Special thank goes to Márk Félegyházi for his advices and suggestions in the topic of the detection

of code injection attacks.

I would also like to thank for our joint efforts and publications to Andrea Lanzi, Davide Balzarotti, Abhinav

Srivastava, Aurélien Francillon, and Christopher Neumann. Special thank goes to Mariano Graziano,

Jan Beulich, Rafal Wojtczuk, the Intel PSIRT team, Olivér Pintér, Pipacs from the PaX team, and Hunger for

technical discussions. Additional thanks to Csaba Krasznay from HP Hungary for providing extra machines

for certain experiments.

The financial support from the SysSec Project and the European Union Seventh Framework Programme

for my internships at Eurecom, France and TU Wien, Austria is also acknowledged.

I am also thankful for Herbert Bos and László Lengyel for their reviews and precious comments on the

first version of the dissertation.

Last but not least my thanks go to my financée Barbara, who continuously supported me during my PhD

studies. I know sometimes it was not easy.

ix

Contents

1 Introduction 1

1.1 Motivation and Background to Detect Unknown Malware . . . . . . . . . . . . . . . . . . 1

1.2 Motivation and Background on Hardware Virtualization Attacks . . . . . . . . . . . . . . 3

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Malware Detection 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Limitations of code signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Signature based scanning vs. anomaly detection . . . . . . . . . . . . . . . . . . . 6

2.1.3 Information asymmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 Information sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.5 Advanced use of cryptographic techniques . . . . . . . . . . . . . . . . . . . . . 7

2.1.6 Manual detection of Duqu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.7 Manual detection of Flame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.8 Freely available rootkit detection tools and their comparison . . . . . . . . . . . . 11

2.2 Membrane: Detecting Malware Code Injection by Paging Event Analysis . . . . . . . . . 15

2.2.1 Background and related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 System details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.3 Towards the Automated Detection of Unknown Malware on Live Systems . . . . . . . . . 42

2.3.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.3.2 On-the-fly virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.3.3 Proposed system call tracing method for x64 . . . . . . . . . . . . . . . . . . . . 45

2.3.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.3.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3 Hardware Virtualization Attacks 53

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.1 Overview of virtualizaiton concepts . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.2 Adversary model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2 On the Feasibility of Software Attacks on Commodity Virtual

Machine Monitors via Direct Device Assignment . . . . . . . . . . . . . . . . . . . . . . 59

3.2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.2 Setup and test configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.2.3 Device memory collision attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2.4 Unauthorized memory access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xi

CONTENTS

3.2.5 Interrupt attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.2.6 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.2.7 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.3 nEther: In-guest Detection of Out-of-the-Guest Malware

Analyzers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3.2 Proposed Feature Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.3.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4 Conclusion 87

4.1 New Methods for Detecting Unknown Malware Infections . . . . . . . . . . . . . . . . . 87

4.2 New Attacks against Hardware Virtualization . . . . . . . . . . . . . . . . . . . . . . . . 88

A Appendix 89

B Appendix 91

xii

List of Figures

2.1 Cardinality of different paging events in services.exe, winlogon.exe and explorer.exe on a

clean and a Flame-infected 32-bit Windows 7 system. . . . . . . . . . . . . . . . . . . . . 20

2.2 Execution and test environment for Membrane . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Valid x86 Hardware PTEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5 x86 software PTE pointing to a page in a pagefile . . . . . . . . . . . . . . . . . . . . . . 30

2.6 Gini index of our restored features under Windows XP. We used features with smaller index

than the mean of all feature indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7 A decision tree used by the random forest classifier. Clearly, when the cardinality of Copyon-write

(Cw) paging events in a given process is higher than a threshold (i.e., x), it is

classified to be malicious. Otherwise, we examine the cardinality of Zero PTE events and

decide in accordance with its threshold (i.e., y). When the number of Zero PTE events is

higher than the decision threshold y, we examine Valid Prototype events also. . . . . . . . 31

2.8 Recorded numer of paging events in explorer.exe running in our WinXP environment.

Each dot on horizontal lines shows the number of paging event in a given snapshot. The first

horizontal line shows the points of 54 clean executions, thus only legitimate applications

were installed when memory snapshots were taken. All the other horizontal lines, represent

13 different code injector malware from 10 different families. The vertical straight line

corresponds to the median of clean executions, while the dashed lines depict the standard

deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9 Evaluating targeted samples injecting into explorer.exe with features Zero, Demand

Zero (Dz), Accessed (A) and Writable (W) in Win7 1. . . . . . . . . . . . . . . . . . . . 35

2.10 Evaluating multiple samples from different malware families injecting into services.exe

with features Zero, Demand Zero (Dz), Accessed (A) and Writable (W) in Win7 1. . . . . 35

2.11 Evaluating different code injection methods on explorer.exe and services.exe

with features Zero, Demand Zero (Dz), Valid prototype (Vp), Accessed (A) and Writable

(W) in Win7 1. The injection methods are based on: (i) CreateRemoteThread, (ii)

SetThreadContext and (iii) QueueUserAPC. . . . . . . . . . . . . . . . . . . . . . 40

2.12 Extending New Blue Pill with monitoring capabilities. . . . . . . . . . . . . . . . . . . . 45

2.13 Algorithm for handling invalid opcode exceptions. . . . . . . . . . . . . . . . . . . . . . 46

2.14 Algorithm for handling debug exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.15 64-bit Windows 7 data structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.16 Statistics of CPU performance test for the unmonitored and monitored system. The bars

show the mean value for the corresponding CPU operations in collaboration with their standard

deviation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.17 Statistics of Memory performance test for the Unmonitored, Blue-pilled and Monitored system.

The bars show the mean value for the corresponding CPU operations in collaboration

with their standard deviation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xiii

LIST OF FIGURES

3.1 Taxonomy of virtualization concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2 Main types of hardware virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3 System architecture including different types of networks and adversaries . . . . . . . . . 57

3.4 MMIO overlapping attack. An attacker on VM1 sets the MMIO Base Address Register

(BAR) value of a passthrough device (PT device1) to that of another device (PT device 2),

assigned to VM2. As a result of this manipulation, the attacker can get access to the device

memory of PT device 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.5 Intra-guest DMA attack. An attacker, controlling VM1, can read/write arbitrary intra-guest

memory locations by a loopback mode passthrough device (PT device). . . . . . . . . . . 69

3.6 Interrupt generation by PTFuzz. This figure describes two interrupt generation cases indicated

by the numerical and alphabetical paths. On the numerical path, PTfuzz requests

a legitimate MSI (1) by a DMA write operation to the MMIO LAPIC (2) which is first

verified by the DMA remapping engine (DMAR). As a result, a compatibility-format MSI

is generated (3) that is blocked by the interrupt remapping engine (IR). The alphabetical

path, however, shows our unsupported MSI request (a), which the platform detects and

blocks. However, when System Error Reporting is enabled, the platform sets the SERR

status bit on the Memory Controller Hub (MCH) PCI Device (b). As a result, a host-side

Non-maskable Interrupt (NMI) is directly delivered to the physical CPU (c) executing the

privileged VM/host OS/VMM. SERR induced NMIs, however, may cause host software

halt or trigger the host-side NMI handler (d) which opens the door for Guest-to-VMM escapes.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.7 Raising different types of interrupt faults on the KVM host by fuzzing the don’t care (DC)

field of a remappable format MSI address. Note that both the fault reason and the fault index

values (Interrupt Remapping Table Entries - IRTE) are changing on different DC values. . 74

3.8 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

xiv

List of Tables

2.1 Examining the stack trace of a newborn lsass.exe process on a Duqu-infected, 32-bit

Windows XP machine with Process Monitor. . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Comparing the context switch deltas (per 1 second) of benign and Flame-infected 32-

bit Windows XP system processes. Note that we indicate only the average and standard

deviation statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Comparing the number of threads in benign and Flame-infected 32-bit Windows XP system

processes. Note that we indicate only the average and standard deviation statistics. . . . . 9

2.4 Comparing the number of referenced handles in benign and Flame-infected 32-bit Windows

XP system processes. Note that we indicate only the average and standard

deviation statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Unknown function calls in the stack trace of services.exe. . . . . . . . . . . . . . . . 10

2.6 Confusing function calls in services.exe. . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Detecting hidden processes/threads/modules with anti-rootkit tools on our 32-bit Windows

XP machine. Some tools reports malicious process IDs which are indicated by symbols. . 13

2.8 Usermode hook detection by free anti-rootkit tools on Duqu-, and Flame-infected 32-bit

Windows XP machines. Note that concrete process IDs are substituted with symbols. . . . 14

2.9 Machine configurations we used in our malware detection and analysis system. Virtual

machines WinXP, Win7 1 and Win7 2 are running on the ESX1 host machine and are used

for snapshot based malware detection. Win7 3 runs on our Xen installation and used by

Membrane Live. Note that Win7 2 was configured with 1 and 4 GBs of memory for more

complete evaluation. Note that the default setup comes with 1 GB of memory, so the other

case is explicitely mentioned when used. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.10 Comparing the advantages and disadvantages of snapshot and live monitoring based systems 23

2.11 Goodware applications we used for our training and evaluation phases. Standalone applications

are associated with the no Autostart flag. Note that AV software was not installed on

malicious VMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.12 The number of distinct malware samples after each stage in the dataset preparation process.

We started with 9,905 malware samples obtained from various malware feeds. Our prudent

dataset preparation resulted in 194 active malware samples that exhibited code injecting

behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.13 Breakdown of code injector malware families used in our cross-validation and testing phases.

Labels were obtained from VirusTotal and belong the Kaspersky’s classification. The Sample/Family

column shows the number of distinct samples we choose from a given family.

Some families (e.g., Foreign) appear both in the cross-validation and the test-only dataset,

but the evaluated samples are different. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

xv

LIST OF TABLES

2.14 Detecting generic code injecting malware on our WinXP and Win7 1 VMs with different

network connections in explorer.exe. Variable K in the head row determines the different

cross-validation procedures we used. We also calculated the decision accuracy for

our test-only generic dataset by choosing the best classifier from each K cross-validation

iteration. Note that the FPR value cannot be evaluated for our test-only generic dataset as

only malicious samples were tested there. The first column “Internet” indicates the status of

the network connection we used for our evaluation process. Mark indicates no network

connection, and is associated with enabled network connection in accordance with our

previously discussed containment policy. Note that the targeted samples of our test-only

dataset were executed only under Win7 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.15 Baseline ratios for the WinXP, Win7 1, Win7 1c, Win7 2, Win7 2+ execution environments

by analyzing and comparing n = 24 snapshots with Membrane. Baseline ratios for Win7 3c

was recorded and analyzed by Membrane Live by comparing execution traces with n = 400

entries. Ratios for unselected features (i.e., with no or minimal information gain) in given

execution environments are marked with ”-”. . . . . . . . . . . . . . . . . . . . . . . . . 38

2.16 Injecting DLL into a process by using ➊ VirtualAllocEx, ➋ WriteProcessMemory,

➌ CreateRemoteThread and ➍ LoadLibrary WinAPI functions. Note that the correspoding

kernel functions of VirtualAllocEx and WriteProcessMemory are executed

also in the context of the target process. In this way, Windows guarantees that no

address space violation occurs between the originator and target processes when loading the

new DLL. Note that the start address (sa) parameter of CreateRemoteThread means

the start address of operation when the new thread is created. While the HW PTE column

indicates the hardware PTE bits being set when the corresponding kernel function is called,

the SW PTE column refers to the software PTE subtype used to handle invalid pages. Similarly,

column PPTE and VAD entry is associated with the status of Prototype PTEs and

VAD entries. While the upper part of the table refers to the memory region allocated for

the name of the DLL, the lower part indicates table entry changes for the memory region

allocated for the DLL itself. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.17 Compering paging event cardinalities between different injected malware functionalities

(i.e., ➊ Keylogger, ➋ Data exfiltration, ➌ Registry operations) and the clean execution of

Windows 7 (i.e., Win7 1c) for winlogon.exe. Column WinAPI calls highlights some of

the key WinAPI functions we called in a given functionality. All the functionalities were

injected into the target process by using CreateRemoteThread detailed in Table 2.16. 41

2.18 Counting the number of page faults and invalid opcode exceptions being raised under native

operation on two CPU cores. The examined time interval is 2.5 minutes, and the statistics

are calculated from samples with 12 elements. . . . . . . . . . . . . . . . . . . . . . . . 48

2.19 Results of Passmark CPU performance test for the unmonitored, blue-pilled and monitored

system. The first column lists the operations executed by the test, while the numbers show

the mean and standard deviation of execution times. . . . . . . . . . . . . . . . . . . . . 49

2.20 Results of Passmark Memory performance test for the Unmonitored, Blue-Pilled and Monitored

system. The first column lists the operations executed by the test, while the numbers

show the mean and standard deviation of execution times. . . . . . . . . . . . . . . . . . 50

3.1 This table shows vertically the possible targets that can be compromised by an adversary

with access privileges enumerated horizontally. Note that the type of attack (BB - black box,

GGB - guest grey box, IGB - infrastructure grey box, WB - white box) that an adversary

can launch is remarked after each access privilege. Possible attack targets are indicated by

symbols as follows: guest OS (g); intra-guest (g); host OS (h); intra-host (h); virtual

machine monitor (vmm); management intarface (mi); communication, management and

storage networks (n). Cells contain references to practical examples. . . . . . . . . . . . . 60

xvi

LIST OF TABLES

3.2 Test Configurations from the perspective of certain features (i.e., ➊ VT-d DMA Remapping,

➋ VT-d Dom0 DMA passthrough, ➌ VT-d interrupt remapping, ➍ Direct Configuration

Space Access, ➎ x2APIC mode on the Host). The table shows both the default and test

configurations in our Xen 4.2 and KVM 3.5 setup on an Intel Core (Quad) i5-2500 CPU

3,30 GHz CPU and Q67 motherboard chipset. While the Default Values column is placed

only for comparison purposes, the Our Xen Setup and Our KVM Setup columns summarize

those configurations we tested our attacks on. For example, the HVM-4 configuration on

Xen means that all the hardware protection features were enabled in this configuration, but

we did not give direct configuration space access to the passthrough device being attached

to the Xen guest VM. The sign NA, refers to a cell that cannot be evaluated in the given

configuration.

*Direct PIO access to device configuration memory was granted explicitly. . . . . . . . . 64

3.3 Overview of the results of the attacks implemented in our study. These attacks are performed

by: ➊ PCI/PCIe configuration space access (PIO), ➋ PCIe configuration space access

(MMIO), ➌ I/O port overlapping (PIO), ➍ I/O memory overlapping (MMIO), ➎ Unauthorized

MMIO memory region access, ➏ DMA and ➐ NMI

* The attack was previously confirmed as h, g⇒h, and g⇒vmm against an old version of

Xen. ** The attack was previously confirmed as h⇒vmm, against an old version of Xen

without DMA remapping hardware. *** KVM detects the port overlapping and kills the

guest. The state of CPU registers is also dumped in the Host OS. . . . . . . . . . . . . . . 66

3.4 The number of updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

B.1 Paging entries we restored for feature creation. . . . . . . . . . . . . . . . . . . . . . . . 91

xvii

Chapter 1

Introduction

1.1 Motivation and Background to Detect Unknown Malware

In June 2010, the Stuxnet malware [Falliere et al., 2011] marked the start of a new era in the arms-race

in cyber security. First time in history, a targeted cyber attack was discovered that aimed at physically

destroying part of an industrial infrastructure. Reportedly, Stuxnet was not the first targeted attack against

industrial systems [Byres, 2010], but the first one to receive worldwide attention due to its unique purpose

as a cyber weapon.

It turned out that Stuxnet was not the single example of its kind. Thanks to the increasing attention, the

shared knowledge and growing efforts of the malware research community, several new targeted threats that

are related to Stuxnet in some way have been discovered. In October 2011, I participated in the discovery

and analyis of Duqu, a malware with striking similarities to Stuxnet, but apparently with a different objective.

Indeed, Duqu does not aim at causing physical damage, but it is an information collecting malware

used for cyber espionage.

More precisely, in September 2011, a company from Europe approached us (i.e., CrySyS Lab in Budapest,

Hungary) to help them in the investigation of a security incident that occurred in their IT system.

The company allowed us to share information about the root cause behind the incident, which happens to

be a malware that was previously unknown. When we discovered this malware during the investigation of

the incident, we gave it the name Duqu, because it has an infostealer component that creates files in the

infected system with filenames starting with the string “∼DQ”.

Since our discovery, Duqu has become widely known and was covered by the media, mainly due to

its striking similarity to the infamous Stuxnet worm in terms of design philosophy, internal structure and

mechanisms, implementation details, and the estimated amount of effort needed to create it. However, no

paper has discussed this malware in the scientific community so far. Yet, we believe it is important to discuss

Duqu within the scientific community too, because the success of malware codes like Duqu and Stuxnet is

due to the inefficiency of our current defense mechanisms. Designing efficient security mechanisms against

targeted attacks requires a joint effort of researchers, industry and policymakers.

Our main contribution related to Duqu is threefold:

1. Discovery: First of all, we discovered and named Duqu, and we performed its first analysis. The main

outcome of our analysis was that Duqu is extremely similar to the Stuxnet worm in its design and

implementation, but there are also obvious differences between them stemming from their different

objectives. These findings have later been confirmed by others, and led many to believe that Duqu

was probably created by the same people who developed Stuxnet, but with a different purpose: unlike

Stuxnet that infected PLCs and maliciously controlled uranium centrifuges, Duqu is an information

stealer rootkit targeting MS Windows based PCs. We dumped our analysis results in a confidential

report that we shared only with a small set of mainstream anti-virus vendors and security experts.

We also shared with them the Duqu samples that we had, such that they can repeat and extend our

1

1. INTRODUCTION

analysis. In a very short amount of time, Symantec confirmed our findings, extended our analysis,

and published the first public Duqu report [Symantec Security Response, 2011] on October 18, 2011.

A reduced and anonymized version of our initial analysis appeared in the Symantec report as an

appendix. A few days later our lab has been identified as the source of the anonymized appendix 1

based on some cryptographic hash values computed from some Duqu components and placed on the

personal blog site of one of us for monitoring purposes 2 .

2. Dropper: Once the Duqu samples have been shared among the anti-virus vendors, they updated

their products such that they could detect Duqu. This was an important step, but a key element was

still missing: no one knew how Duqu infects the first computer in a network. Our second main

contribution was that we identified the dropper of Duqu, which was an MS Word document with a

zero-day kernel exploit in it. To prove that it is a zero-day exploit, we opened the dropper file on

a fully patched system, and observed how Duqu installs itself. However, the difficulty was that the

installation does not start immediately, only if the computer is idle for 10 minutes and some other

conditions hold. It took us some time to find all these conditions. We immediately notified Symantec

and Microsoft about our findings including the conditions for successful installation. We also helped

Symantec to re-produce the installation of Duqu from the dropper in their analysis environment, such

that they can confirm our results. Symantec then produced an anonymized dropper file with a proofof-concept

exploit code, and that was shared with Microsoft and others such that they can take the

necessary steps for fixing the problem. In effect, the exploit took advantage of an unknown bug in

the handling of embedded fonts in the Windows kernel; this bug was fixed by Microsoft in December

2011.

3. Detection: After the analysis it was clear to us that Duqu generated anomalies in the infected systems

that could have been rather easy to spot. Yet, Duqu was not detected by any anti-virus product at the

time. Based on the lessons learnt, we developed a Duqu detector toolkit and made it available under

an open source license for free 3 . Our toolkit consists of simple heuristic tools, which are individual

programs that can be run on a system to look for a certain type of anomaly, such as PNF files without

corresponding INF files, and drivers with too large entropy (which suggests that the file is obfuscated).

The open source license allows users to check the precise operation of the detector and to create their

own executables with their trusted compilers. This allows for the usage of our Duqu detector toolkit

in critical infrastructures, where commercial anti-virus products may not be used due to lack of trust

in their vendors. As a heuristic tool, our detector may generate false positive alarms, but we believe

that in critical infrastructures, it is affordable to invest some time in filtering false positives, and this

additional effort is preferred to missing a real attack. The positive side is that our heuristic tools may

detect as yet unknown variants of Duqu, or even Stuxnet, and they may also detect remains of a past

infection. Our Duqu detector has been downloaded from more than 12000 distinct IP addresses from

all around the world.

More details about Duqu can be found in our full technical report [Bencsáth et al., 2011]. As expected,

Stuxnet and Duqu were not unique in their purpose, and since they came to light, more targeted malware

attacks have been discovered. In May 2012, I participated in an international collaboration to investigate

a recent threat called Flame (which at that time we named sKyWIper). Flame is another informationcollecting

malware built on a platform different from that of Stuxnet and Duqu. Yet, researchers found

identical code segments in an early Stuxnet variant and Flame, making us believe that Flame belongs to the

same cyber espionage operation and it is indeed member of the Stuxnet family. Flame received worldwide

attention of security researchers and practitioners due to its advanced spreading techniques based on masquerading

as a proxy for Windows Update [Symantec Security Response, 2012]. Also, Flame was quite

unusual as a malware in the sense that it was an order of magnitude larger than typical malware samples

(both for generic and targeted attacks). Our analysis of Flame served as a starting point for further technical

investigations.

Another information collection malware, called Gauss [Kaspersky Lab, 2012], surfaced in June 2012,

and yet again made headlines. Gauss appears to be based on the Flame platform, but it possesses a very

1 http://www.symantec.com/connect/blogs/duqu-status-update-1 2 We placed these hashes on the blog site

to see if there is anybody looking for them. 3 http://www.crysys.hu/duqudetector.html

2

1. INTRODUCTION

unique feature: it has an encrypted module, called Gödel, which can only be decrypted on its target system(s).

As a consequence, the research community is still clueless about the purpose and operation of

this module, and hence, Gauss’ true mission. We did not participate in the first analysis of Gauss, but for

completeness, we implemented an on-line detector service 4 to test computers for Gauss infection.

A common characteristic of Stuxnet, Duqu, Flame, and Gauss is that they have all been active for an

extended period before they were actually discovered. This stealthiness is achieved by carefully avoiding

the generation of visible anomalies. Yet, as we show in Sections 2.1.6 and 2.1.7, Duqu and Flame (and hence

most probably Stuxnet and Gauss too) do generate anomalies that could have been detected by a vigilant

system administrator by manual inspection of systems or by using available rootkit detector tools. The fact

that this did not happen shows that computers are usually poorly administered in practice, and regular sanity

checks are very rare even in special environments, not to mention an average office environment.

Note that the discovery and analysis of Duqu, as well as the design of the Duqu Detector Toolkit and the

lessons learned from the Duqu incident have been published in our earlier paper [Bencsáth et al., 2012a].

This paper contains significantly more material, including the analysis of Flame, the overview on Gauss,

more lessons we learned since the Duqu incident, and the experiments on the detection of Duqu and Flame

manually and with available tools.

1.2 Motivation and Background on Hardware Virtualization Attacks

While the advantages of virtualization are pretty much clear to everyone, one must also be aware of the fact

that it gives rise to a number of security issues. Some of those issues exist in traditional computing environments

as well, but they need to be addressed with special care in virtualized environments, while some other

issues are specific to virtualization, and hence, require novel solutions. One such example is multitenancy,

which allows for cross-platform information flow between customers hiring virtual machines over the same

physical host [Ristenpart et al., 2009] in an IaaS cloud. Other issues entitle adversaries to execute arbitrary

out-of-the-guest code either locally [Wojtczuk et al., 2008] or remotely [Shelton, 2005] without owning the

required access rights. Virtualized storage systems also have special security requirements [Dwiendi, 2003;

Dwiendi, 2004; Dwiendi, 2005] to keep our data secure. Due to the increasing popularity of using virtualization

technologies, it is important to discuss these security issues, and hence, raise the awareness of the

potential users of virtualized services and infrastructures.

As it turns out, the number of reported vulnerabilities and attacks on different virtualization platforms

is quite large, so we structured the presentation of those based on their target in our survey paper [Pék et

al., 2013]. Hence, we introduce vulnerabilities and attacks targeting the guest, the host OS, the hypervisor

layer, the management interfaces, and the different networks within a virtual infrastructure. The detailed

discussion of vulnerabilities and attacks is preceded by the definition of an adversary model and a short

overview on virtualization detection and identification techniques.

To the best of my knowledge, my work is the first that discusses security issues in hardware virtualization

with this level of details. Moreover, the adversary model and the structuring of the attack vectors are

original contributions. I believe that they are sufficiently general to be used to classify not only existing but

also future vulnerabilities and attacks in virtualized environments.

One of the lessons that one can learn from this survey is that the number of reported vulnerabilities and

attacks on different virtualization platforms is already quite large, and it is expected to further increase in

the future due to the increasing complexity of and additional services in those platforms. Given the increasing

popularity of using virtualization technologies, and in particular, the proliferation of cloud computing

services, it is important to be aware of these security issues, and to address them in an appropriate way.

This requires better understanding and continuous research in this domain. In particular, we identify

the need for developing security tools tailored for discovering vulnerabilities, as well as for detecting or

preventing attacks in virtualized environments. Some inspiration may be provided by how security issues

are addressed in traditional computing systems, but they must be adapted to the specific properties of virtualized

systems; in addition, some issues are very specific to virtualized environments, and hence need

new solutions. For instance, the impact of an attack on a hypervisor can be very serious, because it affects

multiple guest operating systems and the services running on top of those.

4 http://gauss.crysys.hu/

3

1. INTRODUCTION

Therefore, vendors of virtualized platforms should pay special attention to the security of their products,

system administrators should pay special attention to careful operation and maintenance of virtual

infrastructures, and researchers should develop effective tools to detect and contain such attacks.

1.3 Contributions

In my dissertation, I aim at answering various system security questions which still raise hot debates among

field experts. First and foremost, the detection of unknown malware has been studied over many years, however,

targeted attacks seems to successfully exploit existing preventive and reactive solutions. Interestingly,

most of these attacks still use well-known, traditional methods to hide their presence. One such method is

the injection of hostile code into benign system processes. As it has been demonstrated by recent targeted

campaigns (e.g., Flame), the way of injection can be exotic enough to evade signature based approaches

and various heuristics. At the same time, deploying such detection/analysis solutions into production environments

is not trivial to perform in every cases as machines need to be restarted. In critical infrastructures,

for example, neither interruption of operation nor installing arbitrary software on the system are allowed.

To address these problems, in the first part of my dissertation, I introduce a novel memory forensics

Office 2010 Full Torrent > http://shorl.com/jugrariladraji

Office 2010 Full Torrent, Codes For Rinse My Music

c5bee480b0

(LogOut/Change),You,are,commenting,using,your,Google+,account.,Install,Microsoft,Office,2010,Click,onMicrosoft.Office.Pro.2010.exe,to,start,installing.,DownloadWinRAR,,(32-bit),,Take,,full,,control,,over,,RAR,,and,,ZIP,,archives,,,along,,with,,unpa.,,This,service,pack,includes,previously,unreleased,fixes,that,were,made,specifically,for,this,service,pack.,,,read,,more,,+,,User,,Reviews,,+,,Current,,Version,,5.0,,out,,of,,1,,votes,,5,,star,,1,,4,,star,,0,,3,,star,,0,,2,,star,,0,,1,,star,,0,,All,,Versions,,5.0,,out,,of,,1,,votes,,5,,star,,1,,4,,star,,0,,3,,star,,0,,2,,star,,0,,1,,star,,0,,My,,rating,,0,,stars,,Write,,review,,Results,,1–1,,of,,1,,1,,5,,stars,,"hmmmm.",,November,,15,,,2011,,,,By,,togas007,,2011-11-15,,20:25:36,,,,By,,togas007,,,,Version:,,Microsoft,,Office,,2010,,Service,,Pack,,1,,(32-Bit),,1.0,,Pros??????????????????????,,Cons,,Summarylagi,,di,,coba,,bisa,,gak,,ya,,di,,pake,,Reply,,to,,this,,review,,Was,,this,,review,,helpful?,,(0),,,,(0),,,,Report,,this,,post,,Email,,this,,post,,Permalink,,to,,this,,post,,Results,,1–1,,of,,1,,1,,Please,,Wait,,Add,,Your,,Review,,Login,,or,,create,,an,,account,,to,,post,,a,,review.,,It,,,is,,,a,,,new,,,kind,,,of,,,MS,,,Office,,,2010,,,Pro,,,Plus.,,,Close,,,,,,see,,,all,,,reviews,,,+,,,Full,,,Specifications+,,,General,,,Publisher,,,Microsoft,,,Publisher,,,web,,,site,,,Release,,,Date,,,June,,,27,,,,2011,,,Date,,,Added,,,June,,,27,,,,2011,,,Version,,,1.0,,,Category,,,Category,,,Utilities,,,&,,,Operating,,,Systems,,,Subcategory,,,Operating,,,Systems,,,&,,,Updates,,,Operating,,,Systems,,,Operating,,,Systems,,,Windows,,,XP/2003/Vista/7,,,Additional,,,Requirements,,,Microsoft,,,Office,,,2010,,,32-Bit,,,Edition,,,and,,,Windows,,,Installer,,,3.1,,,Download,,,Information,,,File,,,Size,,,361.,,,DownloadMiniTool,Partition,Wizard,Free,Edition,Move,,resize,,copy,,explore,,and,recover,hard,disk,drive,par.,

..,,,,,Microsoft,,Word,,2010,,,,Microsoft,,Excel,,2010,,,,Microsoft,,Outlook,,2010,,,,Microsoft,,PowerPoint,,2010,,,,Microsoft,,OneNote,,2010,,,,Microsoft,,Access,,2010,,,,Microsoft,,InfoPath,,2010,,,,Microsoft,,Publisher,,2010,,,,Microsoft,,Project,,2010,,,,Microsoft,,SharePoint,,Designer,,2010,,,,Microsoft,,SharePoint,,Workspace,,2010,,,,Microsoft,,Visio,,2010,,================,,FileSize,,:,,750,,Mb,,Language,,:,,English,,Crack,,inf:,,n/a,,================,,Download,,Free:,,================,,[INSTALL,,NOTES],,================,,1.,,Once,reported,,our,staff,will,be,notified,and,the,comment,will,be,reviewed.,Crack,,Microsoft,,Office,,2010,,You,,must,,turn,,off,,all,,antivirus,,softwares,,to,,avoidFailed,,to,,start,,error.,,Now,You,must,Download,MS,Toolkit,Activator,for,MSOffice,Professional,Plus,2010.,The,,,interface,,,of,,,application,,,is,,,completely,,,changed,,,,it,,,is,,,modernized,,,and,,,practically,,,reminds,,,in,,,no,,,way,,,to,,,the,,,previous,,,versions.In,,,a,,,few,,,minutes,,,the,,,software,,,will,,,be,,,installed,,,on,,,your,,,computer,,,,without,,,any,,,questions,,,or,,,other,,,things,,,that,,,slow,,,down,,,the,,,installation.,,,Search,Maher,Zain,,Number,One,For,Me,March,2015,M,T,W,T,F,S,S,,Jul,,Jul,,1,2345678,9101112131415,16171819202122,23242526272829,3031,,Recent,Posts,WhatsApp,Plus,v3.10,MOD,Apk,is,Here!,(Size:,23.33MB),,,2015,,,10,,:,,,Microsoft,Office,Proffesional,Plus,2010,FullActivated,ARGENTINA,VS,NETHERLANDS,IN,WORLD,CUP,2014,SEMI-FINALHIGHLIGHTS,My,InstagramThere,was,an,error,retrieving,images,from,Instagram.,Thank,,,You,,,for,,,Submitting,,,an,,,Update,,,to,,,Your,,,Review,,,,!,,,Note,,,that,,,your,,,submission,,,may,,,not,,,appear,,,immediately,,,on,,,our,,,site.,,,

gta vice city cutscene audio
16 21 guns m4a
Zulu_Winter_-_Language_[2012].zip
Alms7f_Mrtla_Wmgwda_Kamla
Opel Globaltis Version 32 B 2011 03 Multilanguage Keygen