Capturing Malware Propagations with Code Injections and Code-Reuse Attacks

Home , Angelos (mythology), Code injection

Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

Capturing Malware Propagations with Code Injections and Code-Reuse Aacks David Korczynski Heng Yin University of Oxford University of California, Riverside University of California, Riverside [email protected] [email protected]

ABSTRACT ght against malware is challenged by two core, albeit opposite, Defending against malware involves analysing large amounts of problems. On the one hand, anti-malware companies receive thou- suspicious samples. To deal with such quantities we rely heavily on sands of samples every day and each of these les must be processed automatic approaches to determine whether a sample is malicious and analysed in order to determine their maliciousness. On the or not. Unfortunately, complete and precise automatic analysis other hand, malicious applications are oen well-designed so- of malware is far from an easy task. is is because malware is ware with dedicated anti-analysis features. is makes accurate oen designed to contain several techniques and countermeasures and automatic analysis of malware a true challenge. In addition to specically to hinder analysis. One of these techniques is for the this, many of the current tools available are constructed for specic malware to propagate through the operating system so as to execute reverse engineering purposes, which makes them less applicable to in the context of benign processes. e malware does this by writing fully automated procedures and more useful for manually-assisted memory to a given process and then proceeds to have this memory analysis tasks. execute. In some cases these propagations are trivial to capture One problem that has particularly challenged the malware re- because they rely on well-known techniques. However, in the cases search community is analysis and detection of malware propaga- where malware deploys novel code injection techniques, rely on tions inside a host system. When malware executes on a host code-reuse aacks and potentially deploy dynamically generated system, it integrates itself to the system using stealthy approaches, code, the problem of capturing a complete and precise view of the oen motivated by evasion and privilege escalation. An important malware execution is non-trivial. part of our defences is to identify these propagation strategies so In this paper we present a unied approach to tracing malware they can be used in host-based intrusion prevention systems (HIPS). propagations inside the host in the context of code injections and A key aspect of malware propagation strategies is the use of code code-reuse aacks. We also present, to the knowledge of the au- injections. In the context of malware, code injection is when the mal- thors, the rst approach to identifying dynamically generated code ware writes code to another processes on the system so as to have based on information-ow analysis. We implement our techniques this code execute. When the malware does this, it eectively exe- in a system called Tartarus and match Tartarus with both synthetic cutes under the context of a legitimate application like white-listed applications and real-world malware. We compare Tartarus to pre- processes that goes undetected by HIPS. In cases where malware vious works and show that our techniques substantially improve relies on well-known techniques to inject the code it is easy for the precision for collecting malware execution traces, and that malware analysis systems to identify the code injection. However, our approach can capture intrinsic characteristics of novel code recent reports have shown that novel code injection techniques injection techniques. can go unidentied by ne-grained malware analysis environments [29, 36] and also bypass modern-day HIPS [27, 45]. is presents KEYWORDS a crucial challenge because false-negatives in both environments mean that malware can operate without detection for a potentially Malware, Taint Analysis, Security, Code Injection long time. Traditional code injection techniques rely on xed API calls 1 INTRODUCTION such as WriteProcessMemory and CreateRemoteread where recent approaches have started adopting exploit-like features such as code- Today, malware remains one of the biggest IT security threats that reuse aacks [2, 27, 29, 45]. is means, instead of writing code to we have to face. Although the last decade has introduced many another process using WriteProcessMemory and creating a thread improvements in our defences and has signicantly raised the bar in the target process with CreateRemoteread, malware will, for for malware authors to be successful, there is still an increasing example, write memory to a global buer, force the target process number of malware incidents reported each year. Presently, the to overwrite its own stack with the memory from the global buer, Permission to make digital or hard copies of all or part of this work for personal or eventually resulting in the target process executing a ROP chain classroom use is granted without fee provided that copies are not made or distributed controlled by the malware. In this way the malware achieves execu- for prot or commercial advantage and that copies bear this notice and the full citation tion in the target process even without explicitly writing memory on the rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permied. To copy otherwise, or republish, to it [27]. to post on servers or to redistribute to lists, requires prior specic permission and/or a e security community has previously investigated automated fee. Request permissions from [email protected]. analysis of malware propagation and code injection. ese works CCS’17, Oct. 30–Nov. 3, 2017, Dallas, TX, USA. © 2017 ACM. ISBN 978-1-4503-4946-8/17/10...$15.00 can be roughly divided in two groups. One group that has been DOI: hp://dx.doi.org/0.1145/3133956.3134099

1691 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

focused on automated approaches to unpacking of malware, and malware code in combination with a model of code-reuse aacks. another group focused on detection and analysis of code-reuse is combination allows Tartarus to follow malware execution in aacks. the whole OS without relying on any API hooking, and also gives Automated approaches to unpacking malware is a well-studied Tartarus the ability to identify where code-reuse aacks occur. area [5, 22, 30, 40]. e main focus point of these approaches is how Tartarus further deploys two novel abstractions upon the malware to uncover and extract dynamically generated code. Code injection execution trace in order to identify dynamically generated code is a natural extension hereof, as we can consider code injections to and code injection techniques. be dynamically generated code across processes. e most recent To the best of our knowledge, Tartarus is the rst malware anal- work on unpacking has indeed investigated this particular prob- ysis system that monitors malware execution based on taint anal- lem [5, 40]. However, the suggested approaches do not address ysis in combination with code-reuse aacks. Tartarus is also the several challenges posed by recent code injections. For example, rst system that captures dynamically generated code based on an Codisasm proposed by Bonfante et al. [5] relies on hooking Cre- information-ow model and also has the abilities to automatically ateRemoteread and CreateRemotereadEx in order to monitor identify code injections and give detailed insights about them. We code execution in a dierent process. is excludes their approach have systematically tested Tartarus against several datasets that from any code injections that do not rely on these two API calls, demonstrate the operational practicality of Tartarus, its relevance of which there are many [2, 27, 29, 45]. Ugarte et al. [40] make against todays’ malware landscape as well as its improvements on eorts into monitoring dynamically generated code via le map- previous work. pings and to shared memory sections. However, these techniques Our main contributions can be listed as follows: only monitor for dynamically generated code explicitly wrien by ‚ We propose a technique for complete malware tracing the malware, and do not consider when malware uses code-reuse based on taint analysis in combination with a model of aacks. Because of this, their approach will not detect malicious code-reuse aacks. code that has been dynamically generated via benign code, of which ‚ We propose a novel technique based on information-ow there has recently been several cases [2, 27, 29, 45]. for identifying dynamically generated code. Similarly to automatic unpacking, automatic detection and anal- ‚ We propose a ne-grained technique as a unied approach ysis of code-reuse aacks has lately received a lot of aention for automatically identifying code injections and also pro- [10, 17, 23, 34]. However, the problem with relying on generic viding detailed insights about them. methods for detecting novel aacks is simply that it is hard, and ‚ We implement our techniques in a practical system called analysis of special cases seems inevitable [10, 16]. In fact, a recent Tartarus and evaluate it thoroughly against several datasets. demonstration of a new code injection was shown to bypass both Our results show that Tartarus works well in operational HIPS and the many exploit-mitigations deployed by Windows [28]. contexts and improves over previous work in several areas. is particular injection technique was adapted by malware not long aer the technique was published [2] . e problem with the 2 MOTIVATION AND BACKGROUND current tools for analysing code-reuse aacks, besides being few in numbers, is that these tools provide a local and limited view on the In this section we illustrate the motivation and background for our injection in respect to the entire malware propagation. is makes work by introducing a running example. We describe each of the them well-suited for aiding reverse engineering but are not well- three techniques: (1) dynamically generated code; (2) code-reuse adapted for complete and automated analysis of entire malware aacks; and (3) code injections, and use our running example to propagations [17, 23, 34]. describe the limitations of previous work. Because of the limitations in previous work and the problems reported by the malware community, there remains to be found a general and accurate solution to automatic analysis of malware 2.1 Motivating example propagations with code injections and code-reuse aacks. Before Our running example is a sample collected from the Gapz malware we proceed, it is natural to consider what is required by such a family and Figure 1 shows the propagation strategy the sample solution. Within the entire malware propagation, the malicious deploys. e entry point of the malware is given by the black circle code oen contains several waves of encrypted code even before within the Malware.exe process. Solid arrows present control-ow, performing any code injection, and potentially aer a given code dashed arrows present data-ow and wave0 are instructions ex- injection as well. ese encrypted waves of code contain the mali- plicitly present in the Malware.exe binary image when rst loaded. cious payload which will be used for analysing the capabilities of When executed, the sample rst deploys one wave of dynamically the malware. We therefore consider a complete solution to auto- generated code (wave1 of Malware.exe). e instructions of this mated analysis of malware propagations to both capture malware wave then overwrite a pointer within the legitimate Windows pro- execution traces across the entire operating system (OS) and also cess explorer.exe using SetWindowsLong and hijacks control of raise the execution trace into abstractions in the shape of code the process with a call to SendNotifyMessage. e execution in waves and code injections. explorer.exe is transferred to a sequence of code-reuse aacks In this paper we describe Tartarus, a system for automatically that are responsible for writing shellcode within explorer.exe. capturing and analysing malware propagations with code injections e code-reuse aacks transfer execution to the newly wrien and code-reuse aacks. Tartarus captures the malware execution shellcode and the shellcode itself writes a new wave of dynamically based on a novel approach that relies on taint analysis of the entire generated code inside explorer.exe. Finally, this wave continues to

1692 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

One of the most popular techniques of this kind is return-oriented Malware.exe programming, described by Shacham [38]. e basic idea is to rely wave0 wave1 4150 2700 on small sequences of code that end in ret instructions. We call instrs instrs such code sequences gadgets. e aack then works by writing an SetWindowsLong address to memory such that whenever the target ret instruction SendNotifyMessage is executed, it will transfer control to the address wrien by the explorer.exe Code- adversary. By combining these gadgets in meaningful ways, the wave2 3567 reuse adversary can achieve complex computation and in most real-world instrs attacks cases even Turing complete computation [6, 8]. In the context of 23 instrs ROP, we call a chain of gadgets a ROP chain.

wave1 shellcode Code-reuse aacks is not limited to ROP, but are oen lever- 456 instrs 58 instrs aged with a combination of hijacking other types of indirect branch instructions. For example, jump-oriented programming (JOP) ex- plores a similar paradigm to ROP, but focuses on indirect jmp instructions instead of ret instructions [4]. Equally, code-reuse at- Figure 1: Malware propagation of Gapz. tacks can be obtained by hijacking indirect call instructions, and even a mix all three instruction types. Although it is not shown in Figure 1, our motivating sample does indeed hijack both ret and deploy yet another wave of dynamically generated code with a indirect call instructions. substantially larger number of instructions. Although there exist several techniques for identifying code- 2.2 Dynamically generated code reuse aacks [10, 17, 23, 34], these are designed to highlight the use of gadgets and not the overall malware propagation. As can be Nowadays, the majority of malware deploy dynamically generated seen in Figure 1, the code-reuse aacks only play a very local role code. In its simplest terms, dynamically generated code refers to in the malware propagation and does not reveal much about the when an application writes memory at runtime and then proceeds sample’s overall structure. As such, these techniques will not be of to execute this memory. Most oen, malware does this by contain- much use in fully automatic approaches, but rather serve well in ing encrypted code inside its binary image and then decrypts this assisting manual forensics tasks. memory during execution, followed by transferring control to it. Traditionally, dynamically generated code has been associated with the concept of packers. From a simplistic point of view, pack- 2.4 Code injections ers are applications that input a binary and output a new binary Code injection is when a malicious binary writes code to another that will dynamically generate the original binary’s code. e main process and then proceeds to execute this code. e eect of code concern of previous work in unpacking is therefore focused on injections is that execution of the malicious code happens inside a automatic ways to uncover the code dynamically generated in the “legitimate” application. In practice, there are many reasons why packed application. e techniques applied by previous solutions malware use code injections. Two of the most common reasons are are fundamentally very similar. ey keep a set of all the mem- evasion against anti-malware solutions and escalation of process ory writes performed by the malware, and then monitor for each level restrictions. By nature, dynamically generated code and code instruction executed in the malware process whether the bytes injection techniques are closely related. In order to inject code, making up the instruction is an element of this set. the malware writes the code at runtime, making the injected code However, this heuristic is fundamentally limited because it only dynamically generated. monitors code explicitly wrien by the malware. As such, they Traditionally, malware has relied on a common set of approaches do not consider the cases where malware uses benign code to to inject their code. ese approaches rely on well-known API dynamically generate malicious code on its behalf. is limitation calls such as WriteProcessMemory, MapViewOfSection and alike, to is visible in our motivating example where previous approaches place malicious memory in the context of the target process, and to automatically uncovering dynamically generated code would then execute this code using API calls such as CreateRemoteread, only include wave0 and wave1 of the Malware.exe process. is is eueUserAPC and Resumeread. Previous work on automatic because Gapz relies on the code-reuse aacks to write the shellcode, unpacking and automated malware analysis environments there- and the shellcode is then in charge of propagating memory wrien fore rely on hooking these API functions [5, 11] to detect the code by the Malware.exe process into the explorer.exe process. As a injections. result, previous approaches will fail to recognize the code-reuse However, as observed in our motivating example, the malware aacks and all of the malware execution that propagates from this does not rely on WriteProcessMemory or similar API calls to estab- code. lish the code injection. In fact, the malware relies on two rather mundane API functions, SendNotifyMessage and SetWindowsLong. 2.3 Code-reuse attacks Furthermore, the injection technique is application-specic in that To hijack an application’s control-ow, malware can manipulate it relies on constructs specically present in explorer.exe. benign code of the application even without writing any code to It is important to clarify that code injections are not necessarily the application itself. We call this type of aack a code-reuse aack. exploits, and many of them are not intended to escalate privileges

1693 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

from an OS point of view. Rather, these are injection techniques that system as well, and each of these may communicate with each other target OS-specic constructs that allows the malware to execute through the underlying OS. As such, we model the execution envi- code in another process. e code injection is then used for achiev- ronment E as the underlying OS and the other programs running ing evasive behaviours, bypassing white-listed HIPS processes and on the system. several other purposes [28]. Eectively, the number of potential We dene a transition function δE : I ˆ M ˆ C Ñ I ˆ M ˆ C to targets for these code injections is very large, because the malware represent the execution of an instruction in the environment E. It is not necessarily interested in a specic set of privileged processes. denes how execution of an instruction updates the execution state and determines the next instruction to be executed. e trace of 2.5 Observations and objectives instructions obtained by executing program P in execution environ- e combination of dynamically generated code, code-reuse aacks ment E is then dened to be the ordered set T pP,Eq “ pi0,...,il q and code injections allows for complex malicious propagations where i0 “ ϵP and δE pik ,Mk ,Ck q “ pik`1,Mk`1,Ck`1q for 0 ď that pose new challenges for malware analysis systems. Although k ă l. We note here that the execution trace does not explicitly these techniques have been treated individually in the past, they capture what instructions are part of the program, with the excep- have signicant overlap and malware oen use the techniques in tion of i0, but rather all the instructions executed on the system combination. Previous work suers from focusing on one of the including instructions in other processes etc. techniques and are therefore incomplete when the techniques are combined. 3.2 Malware execution trace e objective with Tartarus is to construct a unied approach We now introduce the concept of malware execution trace, which for automatic analysis of malware that combines all of the three describes what instructions of a whole-system execution is part techniques: (1) Dynamically generated code; (2) Code-reuse aacks of the malware execution. Suppose P is a malware program and and (3) Code injections. We achieve this by dividing the objective PA is some malware tracer that aims to collect P’s execution trace. of Tartarus into two main goals: Malware program P is interested in evading analysis and gaining (1) A novel approach to malware execution tracing that is privilege escalation by using dynamically generated code, code- tailored analysis of malware propagations. is requires a reuse aacks and code injections. As such, the execution trace of technique that is general enough to tracing malware even the malware may contain instructions that are not members of the in the context of code injections and code-reuse aacks. program’s memory MP . (2) Techniques for raising the collected execution trace into To monitor the malware across the environment, the malware higher level semantics suitable for fully automatic analysis, monitor PA maintains a shadow memory that allows it to label the namely dynamically generated code and code injections. memory and the CPU registers. is shadow memory is updated Dynamically generated malicious code should be recog- for each instruction in the execution trace. Let S Ď M ˆ C be the nized independent of who wrote the code and code injec- set of all possible shadow memories. We then dene the function tions must be identied even if the injection techniques δA : S ˆI Ñ S to represent the updating of a shadow memory when are unknown prior to analysis. an instruction is executed. We call this the propagation function. e list of shadow memories collected by the malware tracer is 3 SYSTEM-WIDE MALWARE TRACING now dened as the ordered set: STApT pP,Eqq “ ps0,...,sl q where δ ps ,i q “ s for 0 ď k ă l. In this section we present Tartarus’ rst goal of optimizing the A k k k`1 e job of the analyser is to determine for each instruction in completeness and precision of malware execution tracers. We start the execution trace whether the instruction belongs to the malware by presenting a model that allows us to reason precisely about mal- or not. To do this, the analyser uses the predicate Λ : S ˆ I Ñ ware execution tracers and then proceed to present our approach. A ttrue, f alseu. e malware execution trace is now given as the At the end of the section we give a brief discussion on limitations sequence of instructions for which Λ is true and we call Λ the as well as a comparison to previous work. A A inclusion predicate. We dene the malware execution trace formally 3.1 Abstract model of execution environment as follows: We consider execution at the machine instruction level and our Denition 1. Let T pP,Eq be an execution trace and PA a malware model is extended from work done by Dinaburg et al [12]. Since tracer. e malware execution trace is the ordered set an instruction can access memory and CPU registers directly, we ΠA “ pm0,...,md q where: consider a system state as the combination of memory contents ‚ ΠA Ď T pP,Eq; and CPU registers. Let M be the set of all memory states and C ‚Dv |mj “ iv ^ ΛApsv ,iv q for 0 ď j ď d. be the set of all possible CPU register states. We then denote all possible instructions as I, where each instruction can be considered e above denition gives us a starting point from which we a machine recognizable combination of opcode and operands stored can reason about the properties of malware tracers. In particular, at a particular place in memory. for a given malware tracer it highlights the propagation function, A program P is modelled as a tuple (MP , ϵP ) where MP is the δA, together with the inclusion predicate, ΛA, to be the dening memory associated with the program and ϵP is an instruction in parts. Given two malware tracers that are targeted the same ex- MP which denes the entry point of the program. When a program ecution environment, such as X86, we can then make a detailed executes, there are oen many other programs executing on the comparison about the instructions each analyser includes in its

1694 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

malware execution trace. We do this with Tartarus and previous Address Instruction Code-reuse conditions GI work [5, 40]. However, before this comparison is possible, we must I CALL [A] A P T , rAs R T , I R T CALL reg T T T rst introduce our approach and we do this next. I reg P , rregs R , I R I JMP [A] A P T , rAs R T , I R T I JMP reg reg P T , rregs R T , I R T 3.3 Overview of malware execution tracing I RET esp P T , resps R T , I R T Algorithm 1 gives an overview of our approach. For notation, let Table 1: Conditions for identifying GI instructions. irAs denote the address of an instruction and irOs the output of an instruction. e rst step (line 2) is to taint the memory making up the malware, and we describe this in Section 3.4. Next, we execute the malware and continue execution until there is no more taint or 3.4 Initial setting a user-dened timeout occurs. We consider malicious code execution on the basis of tainted mem- For each instruction we check if the memory making up the ory. e only two ways we include instructions in the malware instruction is tainted (line 8) and if so, include it in the malware execution trace is if memory that makes up an instruction is tainted execution trace. If it is not tainted (line 10), we check if the instruc- or the instruction is part of a code-reuse aack. e only way new tion is part of a buer that holds the code-reuse instructions we taint is introduced in the system apart from the initial taint is by need to monitor (line 13). If it is, then we set a temporal variable instructions that are already tainted. e initial taint is therefore indicating if the instruction should be included in the malware seed for the rest of the analysis and will have a large impact on the execution trace, and also remove it from the set of code-reuse to completeness and precision of the analysis. monitor. Next (line 17), we check if the instruction initiates any To ensure completeness, the initial taint must cover all memory code-reuse (Section 3.5). If it does, then we set the temporal vari- that belongs to the malware codebase, and also memory from where able indicating the instruction must be appended to the malware the malware can derive dynamically generated code. If we miss execution trace and also include the code being reused into our any such memory, then there is a possibility the malware uses this code-reuse buer (Section 3.5). Finally, we execute the instruction memory to dynamically generate code and our monitor will miss and propagate taint (line 24). out when this code is executed. On the basis that malware can contain code anywhere in its module we taint the entire module Algorithm 1: Main algorithm of the malware. e tainting occurs when the program has been loaded into memory so as to ensure our tainting happens before Data: Malware execution trace Π, gadgets G. any of the malicious code is executed. Result: (input) Malware sample B 1 // Initialisation; 2 T Ð init taintpBq; // Taint set 3.5 Code-reuse identication 3 TG ÐH; In Section 2.3 we introduced the dierent types of code-reuse at- 4 // Begin full system instrumentation; tacks. e similarity between the techniques is that an indirect 5 i Ð f irst instr pq; branch instruction in benign code redirects execution to other be- 6 while T ‰H do nign code, and the value that determines the destination is con- 7 // is the instruction tainted?; trolled by the adversary. e dierence between the techniques is 8 if irAs P T then then the instruction used i.e. whether it is a ret, jmp or call in- ^ 9 Π Ð Π xiy; struction. Because of this similarity, we consider code reuse aacks 10 else on a more abstract level. Formally, we dene code reuse aacks as 11 // code-reuse handling pairs pGI, GCq where GC is the reused code (gadget code) and GI 12 // is it in the gadget buer? is the instruction that initiates the branch to the reused code (gadget 13 if i P TG then initiator). When malware reuses code as part of their control-ow, 14 append “ true; GI is the trigger that allows the malware to use GC for its own 15 TG Ð TGztiu; purposes. 16 // does it initiate code-reuse?; We identify GI instructions as dynamic instructions made up of 17 if initiates code reusepi, Pq then non-tainted memory that branches to non-tainted memory, but the 18 append “ true memory that determines the destination of the branch is tainted. 19 TG Ð get code reusedpi, TGq e particular execution paern we capture with this denition is 20 G Ð TG Y G malware that creates a control-ow by chaining two benign code 21 if append “ true then regions (non-tainted code) together by overwriting the address ^ 22 Π Ð Π i determining the branch destinations and not the code itself. Table

23 append “ f alse 1 illustrates the specic rules we use to determine if an instruction is a GI. 24 pi, T q Ð updatepi, T q; When a GI instruction has been identied, we proceed to de- 25 return pΠ, Gq termine GC. Previous literature on exploit mitigation has tested several ways on how to dene GC and there is no denitive best solution. e diculty occurs because GC can in practice include

1695 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

an arbitrary number of instructions and arbitrary structure, and Algorithm 2: update can vary between small gadgets and entire functions. To this date, Data: Instruction i, taint set T . we monitor if the destination of GI is a function, and if so, con- Result: Taint set T sider the GI to be a function call inside the malware execution 1 // Initialisation; trace. If the destination is not a function, then we include GI in the 2 T Ð propagate taintpi, T q; execution trace as well as the instructions of the rst basic block at 3 inext Ð exec instr piq; GI’s destination. 4 if irAs P T then When a pair pGI, GCq has been identied we must include 5 for o P irOs do them in the malware execution trace. However, the gadget is only a 6 T Ð T Y tou; one-time execution so we can’t taint the instructions as we do with 7 return pinext , T q; regular malware code. Instead, we append the GI instruction to the malware execution trace as we observe it, and all the instructions of the GC basic block is put into a buer. Instructions in the buer are then included in the execution trace only the rst time they are Previous work on automatic unpacking updates the shadow mem- executed right aer the GI instruction execution. In this way we ory with any memory wrien by instructions already inside of the ensure only including the gadgets at the specic instance where shadow memory. By contrast, our approach updates the shadow the malware makes use of it. memory based on our taint propagation and any output of instruc- We notice here that there is one exception to the rule, which tions that are in the shadow memory. As such, our updates to the is when we observe a chain of code-reuse aacks where the last shadow memory includes the same as those of previous work but hijacked indirect branch branches to tainted memory. is is seen also propagations of shadow memory performed by instructions in code injection techniques where a chain of code-reuse aacks is that are not part of the shadow memory itself. Furthermore, pre- used by the malware to transfer execution to shellcode. In this case, vious work on automatic unpacking only includes instruction in the last hijacked indirect branch will eectively transfer execution the execution trace if the memory making up the instructions are to tainted memory, which means it does not satisfy the conditions part of the shadow memory. By contrast, our approach includes infor a code-reuse aack. To circumvent not including this hijacked struction in the execution trace if they are either part of the shadow indirect branch in the malware execution trace, if we observe a memory or code-reuse aacks. As such, our approach also includes chain of code-reuse aacks followed by another hijacked indirect the same and more instructions in the malware execution trace. branch that transfers execution to tainted memory, then we also is is easy to show formally and in Appendix A we give a formal include this hijacked indirect branch in the malware execution trace treatment that shows we indeed capture the same instructions and as a code-reuse aack. also more, compared to previous work. In this section, we have shown how Tartarus achieves one of its two purposes, namely a general approach to malware execu- 3.6 Propagation function tion tracing in the context of dynamically generated code, code In Section 3.2 we describe that one of the key aspects of a malware injections and code-reuse aacks. We now proceed to consider execution tracer is the propagation function. e propagation func- how Tartarus achieves its second goal of raising the execution into tion is in charge of updating the shadow memory. e core part higher-level semantics. of our propagation function is dened by our update algorithm, shown in Algorithm 2. We rst apply taint propagation for a given 4 CODE WAVES instruction, done by the propagate taint function. In practice, we e rst abstraction we propose on the malware execution trace is do this with a bitwise tainting and do not rely on pointer tainting. a novel approach to identify dynamically generated code. e goal Because our implementation is based on the DECAF [21] platform of uncovering dynamically generated code is to identify whenever we taint directly on the QEMU tcg instructions [3]. e taint prop- memory that was wrien during runtime is also executed. e agation rules and the soundness and precision of them are veried approach by previous work is to divide the malware execution into by Lok et al. here [43]. code waves such that each code wave consists of memory explicitly When the taint propagation has been done, we continue to ex- wrien by the previous code wave [5, 24, 40] ([40] uses the termi- ecute (emulate) the instruction. If the instruction just executed is nology layers instead of code waves). However, we cannot rely on part of the tainted memory then we also taint the output of the this approach because it can not identify malicious code that was instruction. We do this because some malware generates dynami- dynamically generated via benign code, i.e. the malware triggered cally generated code without the code explicitly originating from benign code to do the writing of the dynamically generated code. its own memory. It is for example possible for malware to read Instead, Tartarus takes a dierent approach and raises the malware benign code and modify this to suit its own needs and our running execution trace into dynamically generated code waves indepen- example of the Gapz malware employs this type of behaviour. dent of who wrote the code, but on the basis that the wrien code must originate from the malware. We model dynamically generated code on a process-level basis 3.7 Comparison to previous work and consider the rst code wave to be the malware module when e denition of malware execution trace given in Denition 1 rst loaded into memory. To identify code waves we use a per- allows us to rigorously compare Tartarus to previous works [5, 40]. process shadow table that is a memory snapshot taken at one point

1696 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

of the tainted memory in some process, and each shadow table log. e procedure consists of the following three steps: (1) from corresponds to one code wave. When a malicious instruction exe- the malware execution trace, identify where control-ow goes from cutes, we can then map the bytes making up the instruction with one process to another and arrange such ndings into transition the bytes of the shadow table. If we observe any inconsistencies pairs; (2) nd any code-reuse aacks involved in the transition; (3) with the shadow table and the currently executing instruction, we perform backward dependency analysis on these two components can conclude this instruction is part of a new wave of dynamically and generate a code injection graph; In this section, we detail each generated code. of these steps. Because the shadow table is composed of tainted memory and tainted memory is propagated through both benign and malicious instructions, then we eectively dene dynamically generated code 5.1 Transition model independent of who wrote the code. However, since the tainted e transition model captures when the malware execution ows code originates from the malware itself, then we can eectively from one process to another. is type of ow is composed of an declare the dynamically generated code to be dynamically gener- initiator instruction in the source process and a target instruction ated malicious code. ese are the two aspects that separate our in the destination process. Together the initiator and target in- technique from previous work and allows our technique to be more struction make up a transition pair. Identifying the transition pairs general. e ability to identify dynamically generated code in this is not trivial because the instructions in the malware execution way is vital for identifying dynamically generated code across pro- trace are ordered according to when they were observed in a single cesses because in most cases memory wrien from one process cored execution environment, and not necessarily the control ow to another is not done by the instructions explicitly part of the of the malware execution. In practice, this problem of misalign- malware but rather by some OS provided APIs or features. ment between control-ow and observation time occurs because In practice a shadow table is a hashtable where each key is an of asynchronous procedure calls, parallel execution and context address in virtual memory and the corresponding value is the byte switches. located at that address when the pair was inserted into the hashtable. Previous works have handled the problem of identifying tran- Whenever a tainted instruction is executed we have one of four sition pairs with two dierent solutions. Ugarte et al. [40] create possible cases: a transition pair whenever a thread context switch occurs. We (1) the instruction is inside a process that does not have a have found that in practice this approach is inaccurate because it shadow table assigned; generates too many transition pairs. e reason for this is that a (2) the instruction is inside a process with a shadow table context-switch does not reect a control-ow transition from the assigned, but the address of the instruction is not in the process or thread being switched out to the one being switched in. shadow table; Bonfante et al. [5] hook a set of function calls which are known (3) the instruction is inside a process with a shadow table to initiate execution in remote processes. Although this approach and the address of the instruction is inside the shadow works well in practice when the injection techniques are known, table, but the memory in shadow table is not similar to the it lacks generality because it cannot identify unknown code injec- instruction executed; tions. (4) the instruction is inside a process that has a shadow ta- Our approach is instead to rst identify all target instructions in ble and the address of the instruction is in the shadow a general manner independent of function hooking, and then trace table, and the memory in the shadow table is similar to the backwards in order to identify the initiator instruction. In com- current instruction. parison to an approach that rst identies the initiator instruction and then the target instruction, our approach is able to identify the In all cases but (4), we consider the instruction to be entrypoint target instruction independently of the initiator instruction exactly of a new code wave. Further, cases 1-3 each indicate a high-level because we rely on taint for tracing the malware execution. When feature of the new code wave. In case (1) we have an instance of we trace backwards to identify the initiator instruction, we then code injection, in case (2) we simply have a new code wave and in use function hooking to identify if the injection matches an already case (3) we have a new code wave that has overwrien memory in known injection technique, and if it does not we then deploy a a previous code wave. general heuristic to identify the initiator instruction. When an entrypoint of a new code wave is discovered, Tartarus To identify target instructions we monitor for malware code rst clears the shadow table of the given process, and if a shadow execution inside processes where the malware has previously not table does not already exist Tartarus simply initiates one. Next, the executed. When we observe this behaviour, we know (1) this is the entire process memory is scanned and every byte that is tainted is rst instruction in a given code wave and (2) injection of code has put in the new shadow table. Aer the scanning, the shadow table occurred because this is the rst time malware code is executed in contains the current code wave of the process under execution. the process. We label each of these instructions as target instructions. We note here that we only declare an instruction a target 5 CODE INJECTIONS instruction if it is not a code-reuse aack. e second abstraction that we propose is to identify code injec- When a target instruction has been found, we proceed to nd tions in the malware execution trace, and also extract essential the corresponding initiator. During execution we monitor all API insights about these by performing semantics-aware dependency calls done by instructions in the malware execution trace. is analysis on the malware execution trace and the taint propagation includes obfuscated calls such as push X; rol [esp], Y; ret.

1697 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

We then keep a subset of these calls in a set F, with all the calls to PID Address Instruction functions that we know possibly initiate execution in a remote con- 4d0 9b3b00 call SendNotifyMessage text e.g. CreateRemoteThread, ResumeThread, CreateProcess, 5f0 1001b4b call [eax] ; KiUserAPCDispatcher QueuseUserAPC. When a target instruction is observed, we rst 5f0 1001b59 call [eax + 8] 5f0 1022599 std check if there is an element e P F that initiates execution of this 5f0 102259a ret code. If there is, then we declare the element e as the initiator of 5f0 1001b6e call [eax + 4] the code injection. In is important to note here that the hooking is 5f0 7c9ee5be mov ecx, 0x94 only used to identify the injection initiator and not to identify that a 5f0 7c9ee5c3 rep movsd code injection has happened. Our approach to identifying whether 5f0 7c9ee5c5 pop edi a code injection has happened is completely independent of our 5f0 7c9ee5c6 xor eax, eax use of hooking. However, if there is no such element, then we have 5f0 7c9ee5c8 pop esi a code injection that relies on an unknown method for injecting the 5f0 7c9ee5c9 pop edi code. In this case, we trace back in the malware execution trace to 5f0 7c9ee5ca ret the rst instruction that branches to something outside of the mal- 5f0 77ec5b26 cld ware memory (such as calling a function in a dynamically loaded 5f0 77ec5b27 ret 5f0 101179c pop eax module) and is a non-gadget related instruction. is instruction is 5f0 101179d ret initiator then identied as the . 5f0 7c9015f8 alloca probe 5f0 7c90160c ret 5f0 7c802213 WriteProcessMemory 5.2 Injection mechanics 5f0 7c802298 ret When the initiator and the target instruction pair has been found, 5f0 101179c pop eax we continue to identify if there is any code-reuse in-between them 5f0 101179d ret that are of importance to the injection. Specically, we consider 5f0 1002080 jmp eax each code injection as a sequence of instructions xinitiator,R,G,targety 5f0 77ef48c0 mov ebp, esp where R is a sequence of instructions with pid not equal to the pid of target and G is a sequence of instructions that are all code-reuse Figure 2: Key components of Gapz code injection. pairs and have pid to be the same as the pid of target. Both R and G may be empty sequences. We call G the catalyst and the tuple lea edi, [esp + 0x10] (initiator,catalyst,target) the key components of the code injection. pop eax e key components of the code injection make up the control ow call eax of the code injection: initiator Ñ catalyst Ñ target. Figure 2 shows the key components of the code injection collected by Tartarus when matched with the Gapz malware sample. Figure 3: Code of KiUserAPCDispatcher. e initiator instruction here is the instruction call SendNotifyMessage at address 9b3b00 in the malware process. is call triggers three indirect call gadgets, that then transfer control to 6 ROP gadgets. of the malware execution trace or (2) the instruction propagating e target instruction is mov ebp, esp at address 77ef48c0. memory propagates memory from a code wave dierent than the To identify code injections that purely rely on code-reuse aacks code wave of which the target instruction belong. and not any target instruction, such as the malware proposed by Vogl et al. [41], we also identify a code injection if we observe a 6 IMPLEMENTATION code-reuse sequence of longer than 10 gadgets. We have implemented the techniques described in the previous e key components give valuable insight into a code injection sections into a practical system called Tartarus. Our implementation and the instructions that are part of it. However, on their own, the consists of three main parts: (i) a dynamic analysis component that key components give lile insight into how the malware established executes a given sample in our sandbox; (ii) a component that does these components. To give insight about this we construct the code analysis on the output of our dynamic analysis and (iii) a manager injection graph. A code injection graph describes the control-ow of component that wraps around the two other components to allow the code injection and the propagation of tainted memory involved for analysis of large sample sets. in the code injection. e nodes of the graph are either instructions e dynamic analysis component emulates the malware execu- in the malware execution trace or taint-propagation instructions. tion and is built on top of DECAF [21]. It is in charge of capturing e edges in the graph therefore show either control-ow or taint- the malware execution trace described in Section 3 and identifying ow. In practice we also annotate the nodes with several descriptive code waves described in Section 4. In addition, it performs several elements such as the modules and functions they are part of. supporting tasks such as dumping memory of code waves, construct To construct the code injection graph we analyse the taint- the pair-wise execution order of instructions inside each code wave, propagation history of the tainted memory in the catalyst and collect obfuscated library calls (like those described in Section 5.1) the target. Specically, we trace backwards on the instructions that and dump taint-logging information. e second component takes have propagated the tainted memory until one of two conditions as input the output of our dynamic analysis component and identi- is satised: (1) the instruction propagating tainted memory is part es and analyses code injections. It also reconstructs control-ow

1698 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

within each code wave based on disassembly of the code wave’s Tartarus CO CS memory dumps and the pair-wise execution order of instructions Samples # num CRI CRI CI CI CI in the code wave. Based on the code waves and the code injections (A) PowerLoader 1 1 1 0 0 this component then generates a system-wide control-ow graph (A) PowerLoaderEx 1 1 1 0 0 that shows the propagation strategy deployed by the malware. An (A) AtomBombing 1 1 1 0 0 important aspect to note here is that our implementation will dis- (A) Codeless 1 1 1 0 0 card malware execution inside a process if this process only has 10 (A) WPM, CRT 1 0 1 1 1 or less instructions executed inside of it. (A) WPM, STC, RT 1 0 1 0 1 e dynamic analysis component does not need to log the entire (A) WPM, QAPC 1 0 1 0 0 execution trace. is is because the pair-wise execution order of (A) MVS, STC, RT 1 0 1 0 1 instructions gives us information to reconstruct control-ow within (A) MVS, CRT 1 0 1 1 1 each code wave, and identication and analyses of code injections (A) MVS, QAPC 1 0 1 0 0 only require API calls, code-reuse aacks and taint-logging infor- (B) CryptoWall 4 [1] 4 0 4 0 4 mation. Additionally, for each code injection we can construct the (B) Gapz [36] 4 3 4 1 1 injection mechanics even without the taint-log because we don’t (B) Ramnit [35] 12 0 12 4 7 need to backtrack on the taint propagations. We only need the (B) Tinba [25] 8 0 8 8 8 taint-logging information to derive the entire code injection graph. Total 38 7 38 15 24 As such, Tartarus comes with two seings, one that produces the Table 2: Evaluation with code injecting binaries. taint-log and one that does not. e one that does not produces #CRI = Code-reuse injection, #CI = Code Injection, minimal outputs (a few MB) from the dynamic analysis where taint #Codeless = Modied version of Atombombing that logs can become several (1-5) GBs for a large malware sample. In relies purely on code-reuse aacks. total, Tartarus consists of about 9000 lines of C code and 3500 lines #WPM = WriteProcessMemory, #CRT = CreateRemoteread, of Python. #STC = SetreadContext, #RT = Resumeread, #QAPC = eueUserAPC/NteueUserAPC, #MVS = 7 EVALUATION MapViewOfSection, #CO = Codisasm, #CS = CuckooSandbox. To verify the eectiveness of Tartarus, we have evaluated it against a set of benchmark applications comprising synthetic applications and real-world malware. In Section 7.1 we experimentally validate Tartarus CO CS the correctness of Taturatus by matching it with applications where samples # num CI CI CI we have ground-truth. en in Section 7.2 we compare Tartarus (C) WCET [19] 11 0 0 0 with previous works and our results show that Tartarus is more Table 3: Evaluation with non code-injecting binaries. precise by nding code injections in more applications. In Section 7.3 we perform in-depth analysis on two case studies, demonstrating that Tartarus is able to capture malware propagations, dynamically generated and code injections, and also give valuable insights about code into other processes. e benchmarks collected are all from the three. In Section 7.4 we present a study on the performance of the WCET benchmark suite [19]. Tartarus relative to malware samples in our experiments, and nally e rst ve columns of Table 2 show the results of matching in Section 7.5 we report observations from matching Tartarus with Tartarus with the samples from set A and B. As can be seen, Tartarus 934 recently collected PE les from online malware repositories. correctly identies code injection in all of the code injecting binaries, and also identies when code-reuse aacks are part of the code injection techniques. 7.1 Experimental validation of correctness Given that our technique relies on taint to capture malware In our rst experiment we empirically evaluate the correctness of execution, it is imperative that the taint does not explode. Tartarus Tartarus. To do this, we match Tartarus with applications where nds no code injecting binaries when matched with our data set we know if the applications perform code injections or not. In C, as shown in the rst three columns of Table 3. However, these total, Tartarus is evaluated against three data sets comprising 49 samples are fairly simple and do not behave in any complex system- applications. interactive behaviours. To measure the number of false positives e rst set, A, is composed of several code injection techniques Tartarus produces in contexts where the samples use a lot of system that are publicly documented. Four of these techniques include activities we match for each malware sample in dataset B the code code-reuse aacks and six of them do not. e second set, B, is com- injections as identied by Tartarus with those identied in the posed of a set of malware samples from 4 malware families where anti-malware companies’ reports. anti-malware companies have documented that these malware sam- In [25] CSIS and Trend Micro reports that Tinba injects into ples inject code into other processes. We have only selected les winver.exe, explorer.exe, svchost.exe, refox.exe and iexplore.exe. In from reports where hashsums are given for the malware samples 6 of the 8 samples we analysed, Tartarus found injections into to ensure we select correct samples. e third set, C, is composed winver.exe, explorer.exe, refox.exe and chrome.exe. In 1 of the 2 of benchmark applications where we are sure they do not inject other samples Tartarus found injections into winver.exe, explorer.exe,

1699 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

svchost.exe, refox.exe and chrome.exe and nally in the last sample system and API call granularity [11]. It contains many techniques Tartarus found injections into 20 processes on the system. We for automatically following malware in case of code injections. Both picked 2 samples of the rst 6 to conrm that the malware indeed Codisasm and CuckooSandbox follow malware based on function injects into chrome.exe, and we also manually analysed the last hooking and heuristics about known injection techniques. sample to verify that the sample injects into all processes on the e results of executing our sample set A and B in Codisasm and system for which it has privileges. CuckooSandbox is shown in column 6 and 7 of Table 2. As can be In [36] researchers from eset report that Gapz injects code into seen Tartarus outperformed both CuckooSandbox and Codisasm the Windows process explorer.exe and also uses code-reuse aacks. by a large margin. CuckooSandbox detected code injection in 24 Tartarus found code injections into explorer.exe in 3 of the 4 sam- samples and Codisasm in 15 samples of the 38 applications. ples we analysed and code-reuse aacks in all 3 of these. In two In comparison to Cuckoo Sandbox, the rst thing we noticed of these samples Tartarus captured explorer.exe to be the only pro- is that Cuckoo Sandbox fails on all four synthetic injection tech- cess where injection occurred, where in the other one Tartarus niques that rely on code-reuse aacks. Furthermore, Cuckoo fails captured code injections into explorer.exe but also svchost.exe and to observe code injection in 3 of the Gapz malware samples and 5 winlogon.exe. is sample contained about 3800 unique instructions of the Ramnit malware samples. e sample from the Gapz family inside explorer.exe and only 22 and 138 unique instructions within that Cuckoo correctly identied as containing code injection was svchost.exe and winlogon.exe, respectively. e last sample exhibited the sample without code-reuse aacks as described above. e use no code-reuse aacks and injected code into svchost.exe rather than of ResumeThread was accurately reported by both Tartarus and explorer.exe. We veried manually that this malware does indeed Cuckoo Sandbox. inject code into svchost.exe and relies on CreateProcessInternalW e second thing we notice when comparing to Cuckoo is that and Resumeread functions, and no code-reuse aacks, to perform Cuckoo failed to correctly identify code injections via remote proce- the injection. dure calls. We believe this is because many remote procedure calls In [35] researchers from Symantec report that Ramnit injects do not constitute code injections. erefore Cuckoo cannot create code into IEXPLORE.EXE and svchost.exe. In 9 out of the 12 Ram- a hook and label each remote procedure call an injection because nit samples Tartarus found injections into IEXPLORE.EXE and sv- it will produce many false positives. Tartarus does not run into chost.exe. In the remaining three samples, Tartarus captured code this problem because tainted code must be be executed for Tartarus injection into IEXPLORE.EXE and svchost.exe but also 25, 20 and 17 to declare that a code injection occurs, and Tartarus can therefore instructions inside of drwtsn32.exe, respectively. identify which remote procedure calls result in a code injection. In [1] researchers from Cisco report that CryptoWall 4 injects It may seem Tartarus should identify a code reuse aack for the into svchost.exe and explorer.exe. In all four samples of CryptoWall remote procedure calls because an indirect branch in the target 4.0 in our data set we observed malware execution in these two process transfers execution to a value set by the process sending processes. In two of the samples svchost.exe and explorer.exe were the remote procedure call. However, in our cases, the destination of the only processes of which injection occurred. In the two other the indirect branch is tainted code so the conditions for a code-reuse samples, Tartarus also captured 20 and 17 instructions inside vssas- aack, as described in Section 3.5, are not satised. Furthermore, mind.exe, respectively. it is important to note here that even in the case where a remote procedure call is performed, and not to tainted memory, then we will still not declare it as a code injection because only 1 code-reuse 7.2 Comparative evaluation aack will be observed. As such, it does not satisfy the conditions To assess the quality of our results, we put Tartarus in context with for a code injection described in Section 5 because there is no target other approaches. Our second experiment, presented in this section, instruction nor a chain of code-reuse aacks. compares our solution with two approaches that are state-of-the Codisasm found code injections in 15 of the 36 samples. In par- art in malware analysis. We specically compare our tool with a ticular, Codisasm found code injections in both of the synthetic recent malware disassembler, Codisasm [5], and a coarse-grained samples that relied on CreateRemoteread. Because we don’t have malware analysis platform, namely Cuckoo Sandbox. direct access to their system, but rather through a web interface, Codisasm relies on both static and dynamic analysis and is aimed it is dicult to assess the specic cause of limitations in the other at disassembling binaries with self-modifying code and overlapping samples. For several samples we would get get error messages back instructions. e tool is built on top of PIN and hooks two API calls from the server that either an unknown malfunction occurred or CreateRemoteThread and CreateRemoteThreadEx to follow the the timeout occurred because the system had crashed or wasn’t able malware propagation. Although Codisasm is designed as a malware to produce any traces. However, we consider the limitations to be a disassembler, it relies on capturing an instruction-level execution result of two properties: one conceptual and one in the implementa- trace of the malware to perform the disassembly. It furthermore tion. In terms of conceptual limitation, Codisasm follows malware identies dynamically generated code by monitoring for execution propagation based on monitoring calls to CreateRemoteThread of memory that is explicitly wrien by the malware, as described and CreateRemoteThreadEx. However, there are many techniques in Section 4. As such, Tartarus and Codisasm both capture the that do not use either of these API functions to inject code. Notably execution trace and dynamically generated code, although with only 2 out of 10 injection techniques in data set A makes use of two dierent approaches, and this is the reason we select it as a CreateRemoteThread. From an implementation point of view, the comparative benchmark. CuckooSandbox is a malware analysis tool dynamic analysis component of Codisasm relies on PIN. PIN is a that is heavily used in industry and deploys a malware analyser with process-level dynamic binary instrumentation framework and has

1700 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

AtomBombing.exe Malware.exe NteueAPCread wave wave 0 1 CALL [ebp-0xc] . .. 4150 2700 instrs instrs

SetWindowsLong explorer.exe SendNotifyMessage ZwSetreadContext RPCDispatcher . .. explorer.exe . .. Code- CALL eax wave2 3567 reuse ZwAllocateVirtualMemory instrs attacks 23 instrs . .. memcpy ret . .. ret wave1 wave0 456 instrs 58 instrs wave0 mov eax, edi ret ...

Figure 4: Malware propagation of Gapz. Figure 6: AtomBombing caught by Tartarus with hook on NteueAPCread. previously been reported to be unreliable when instrumenting malware. For example, it fails instrumentation in case of code injection to be overwrien with whatever esi points to. We can therefore into processes with multiple active threads [18]. easily conclude the stack is being overwrien with the memory pointed to by esi, hinting strongly towards a set of indirect call 7.3 Detailed analysis instructions being hijacked to allow for a ROP aack. Before we To demonstrate the precision of our approach and its ability to proceed, it is important to note here that the malware execution give insights about code injection techniques we present in this trace is subset of all the instructions executed. When the third section two detailed case studies of Tartarus. e rst case study is gadget is executed there has in fact been several push instructions from a Gapz malware sample and the second case is from a recently between the rst and the third gadget, resulting in a larger distance published code injection technique called AtomBombing. between esp and edi than 0x14 as can be thought from looking at Gapz malware. Figure 4 shows a high-level view of the system- the malware execution trace. However, these are not part of the wide CFG produced by Tartarus when matched with a sample from malware execution trace and is therefore not shown by Tartarus. the Gapz malware family. e solid arrows represent control-ow, Investigating the code injection graph, we observe that Tartarus the dashed arrow represent data-ow and the black circle is the correctly identies SendNotifyMessage as the code execution ini- entry point. tiator and SetWindowsLong as a function responsible for data-ow e malware rst decrypts itself with a single wave of self- in the overwrien addresses in the code-reuse aacks. Further anal- modifying code and then proceeds to inject code into explorer.exe. ysis reveals that the ROP chain uses WriteProcessMemory to over- Because Tartarus has identied an injection catalyst, we know there write memory inside the process of explorer.exe and then pro- are code-reuse aacks involved in the injection. Furthermore, the ceeds to transfer execution to the rst wave inside explorer.exe. injection transfers control to a rather small code wave of only 58 in- Investigating the complete code injection graph, shown in Appen- structions. is suggests that the malware uses a code-reuse aack dix A, we see with minimal eort that the code-reuse aacks does to leverage shellcode execution inside of explorer.exe, and this in fact turn into a ROP chain and also that the return addresses is indeed the case. e key components identied by Tartarus are were overwrien by the rep movsd instruction. shown in Figure 2, and Figure 5 shows a part of the code injection AtomBombing. Recently, researchers discovered a new injec- graph for the three rst gadgets in the key components. Rounded tion technique called AtomBombing [27], which uses code-reuse boxes are control-ow and squared boxes are taint-propagating aacks to avoid using standard API calls for code injection. e nodes. e rounded boxes shows the code-reuse initiator and also technique was rst presented October 2016 and only four months the gadget itself. later researchers discovered a new 64-bit version of the Dridex Investigating the key components, we observe the rst code- malware that had adopted AtomBombing into its arsenal [2]. reuse aack is a call to KiUserAPCDispatcher, and the code of AtomBombing abuses the global atom table in Windows to share this function is shown in the boom of Figure 3. is gadget puts memory between processes and undocumented asynchronous pro- the value of esp + 0x10 into edi and the second gadget executes cedure calls to force the injectee application to call various functions the instruction std which will cause the direction ag to be set. on behalf of the injecting process. Specically, the injecting process e third gadget, initiated by the instruction at 1001b4b, executes writes a ROP chain and shellcode onto the global atom table us- the two instructions: mov ecx, 0x94 followed by rep movsd, ing GlobalAddAtom. e injecter then uses NtQueueApcThread to eectively causing 0x94 bytes to be copied from esi to edi. Because force the injectee process to call GlobalGetAtomName such that the the direction ag is set, edi and esi will be decreased by one aer ROP chain and shellcode is stored inside the target process. To in- every mov instruction. Recall that edi was set to esp + 0x10 by the voke execution, the injecter again uses NtQueueApcThread to force rst gadget, which means that the memory at the top of the stack the injectee to call SetThreadContext to navigate eip and esp. eip

1701 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

mov [esi + 0x80], eax mov [esi + 0x94], eax 0xa40, wave1 0xa40, wave1 [eax] chaser Call SendNotifyMessage 0x9b373d 9b3748

1001b4b Call [eax] eax chaser [esi] chaser KiUserAPCDispatcher push [ebp + 0x10] push eax 0xa40 1001b59 Call [eax + 8] . .. esi chaser eax chaser 0xa40, wave1 0x7e42c2a4 mov eax, [esi] std Kernel 0x9b3aee User32.dll ret SetWindowsLong [eax + 8] chaser 1001b6e Call [eax + 4] eax chaser mov ecx, 0x94 mov [esi + 0x9c], eax mov [esi + 0x94], eax rep movsd 0xa40, wave1 0xa40, wave1 pop edi 0x9b3765 0x9b3748 xor eax, eax [eax+4] chaser pop esi pop edi

Figure 5: Code injection graph for the rst three gadgets in Gapz code injection. e graph shows that in all three call gadgets the value tainting eax was propagated through SetWindowsLong in the host process.

AtomBombing.exe In Figure 7, we show the AtomBombing injection caught by Tar- ExitProcess tarus when there are no hooks on NtQueueApcThread. In this case, . .. CALL ds:ExitProcess Tartarus catches the exact same code injection except for the initiator instruction which in this case is a call to ExitProcess. e reason

explorer.exe this happens is because NteueAPCread is an asynchronous

ZwSetreadContext RPCDispatcher procedure call, which means that the last API call in the injector ...... CALL eax process at the time the injection happens inside explorer.exe is not NteueAPCread because execution has continued inside the ZwAllocateVirtualMemory injector process itself. is clearly shows the use of hooks in our . .. memcpy ret . .. technique, namely to capture the right initiator instruction and not ret to identify whether an injection has occurred or not. wave0 mov eax, edi ret ... 7.4 Performance evaluation e performance of Tartarus has a large impact on the applications of the tool. Because we specically use Tartarus for malware Figure 7: AtomBombing caught by Tartarus analysis, we measure the performance of Tartarus relative to the without any hooks. malware samples in our data set. For a performance measurement specically about DECAF, we refer to the original DECAF paper [21]. To put the performance of Tartarus in perspective, we measure how fast Tartarus identies the instructions that are part of the is set to ZwAllocateVirtualMemory which is the rst code-reuse system-wide CFG, i.e. unique instructions in the malware execution aack in the target process, and esp is set to point to the begin- trace, during execution of the samples. ning of the ROP chain. As such, AtomBombing achieves code We selected one sample from each of the malware families in execution with a combination of calls to NtQueueApcThread and our B data set and ran them for 1100 seconds inside Tartarus. e GlobalAddAtom in the injecter process. samples shared very similar behaviours to the other samples in When Tartarus is matched with AtomBombing, Tartarus nds their respective families, so each sample represents well the overall the code injection shown in Figure 6. Tartarus captures the code in- malware family. Our experiments were performed on a laptop jection exactly, seeing that a call to NtQueueApcThread in the host with an i7 ad Core 2.5 GHz processor and 16 GB of ram and process results in the target process calling SetThreadContext. three instances of the dynamic analysis environment were run e ret instruction inside ZwAllocateVirtualMemory is the rst simultaneously, meaning 3 samples were analysed approximately ROP gadget in the injection. is ROP gadget transfers execution to every 1100 seconds on a standard laptop. We used a Windows XP memcpy and the return instruction of memcpy transfers execution to SP3 image. Our experiments were performed with our taint-logging a simple ROP gadget consisting of only a ret instruction. is gad- turned o, meaning Tartarus is able to identify code waves and gets is there because the ROP chain must catch the dest parameter code injections with their key components, but not the entire code given to memcpy, which is 4 bytes away from the original return injection graph. e results are shown in Figure 8. address. erefore, the third ret instruction executed results in We can see in Figure 8 that the majority of Tinba was captured in transfer of control to the destination of the copied buer. less than 2 minutes, Gapz about 13 minutes, Ramnit about 7 minutes

1702 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

code injection, where in the Gapz sample more than 20% happens 100 aer the rst code injection.

80 100

60 80 e CFG size 40 60 Relativ 20 Gapz Tinba e CFG size 40 Ramnit 0 CryptoWall Relativ 20 0 5 10 15 20 Time (min) 0

Figure 8: Size of CFG relative to analysis time. 0 0.5 1 1.5 2 Time (min) Total instructions MT instructions Last injection Figure 9: Relative CFG size of Tinba malware with rst wave of Gapz 1.2B 225M 13Min dynamically generated code and code injections marked. TinyBanker 230M 10M 2Min CryptoWall 2.0B 250M 14Min Ramnit 580M 50M 7Min Table 4: Instruction count of malware 100 samples. #MT = Malware execution trace. 80

60 and CryptoWall 4.0 in about about 17 minutes. To put this into e CFG size perspective of the sample sizes, we ran the same experiment with 40 two counters for capturing the number of instructions executed in entire system and the number of instructions in the malware Relativ 20 execution trace. We counted until the last code injection in each of the samples. e instruction counts are shown in Table 4. An interesting aspect of Figure 8 is how clearly it shows that the 0 samples in our dataset work in stages in that the construction of the 0 5 10 15 20 CFG is not linear but more of a step-wise construction. For example, Time (min) the Gapz malware has revealed about 65% of its CFG within the rst 3 minutes, but then continues for 10 with only about 5% more of the CFG constructed. Aer 13 minutes of execution time, Gapz Figure 10: Relative CFG size of Gapz malware with rst wave of nally reveals more of itself and a big leap to about 95% happens. dynamically generated code and code injections marked. To put the construction of the CFG into perspective of dynamically generated code and code injections, Figure 9 and Figure 10 show the CFG construction relative to execution time, with the 7.5 Relevance of approach on recent malware addition of markers for when the rst wave of dynamically gener- We match Tartarus with a recent collection of malware samples to ated code and code injections occurred. e graphs are of a Tinba demonstrate the relevance of our approach. In total, we analyse and a Gapz sample, respectively. Note the Tinba graph is zoomed 934 PE les submied to VirusTotal in April and May of 2017. Each in on the rst 2 minutes of execution time. A triangle shows the sample has at least 40 anti-malware vendors reporting the sample rst wave of dynamically generated code and a circle denotes a malicious. We verify the relevance of our approach by counting code injection. We observe that the majority of the code execu- the number of processes a sample injects into and whether it uses tion happens aer the rst wave of dynamically generated code. code-reuse aacks. We execute each sample for 600 seconds. Namely, in the Tinba case, more than 90% of the malware execution We found that 373 samples inject code into other processes, happens aer the rst wave of dynamically generated code and in which corresponds to 40% of the total malware samples. In contrast, the Gapz sample about 60%. Furthermore, in the Tinba case more a report from PaloAlto Networks on New and Evasive Malware from than 80% of unique instructions in the CFG happens aer the rst 2013 reports that code injection was observed in 13.5% of samples

1703 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

collected in March 2013 [33]. is is an increase of almost three the code wave itself. One potential strategy for solving this problem times in four years. We found that 223 of the samples inject into 4 is a more rened denition of a code-wave, for example something processes or less and in 120 of the samples code-reuse aacks were similar to Ugarte et al. who divides the memory of a code wave used as part of a code injection. In 118 of these cases, only one into unpacking frames. However, this would require us to relax the code-reuse aack was used and in the other two cases a chain of way we identify code injections and may end up producing many two code-reuse aacks were used. We consider this to be a strong false positives in the control-ow graph of the malware. indication that indeed code-injection is increasingly being used, From a practical point of view, a limitation to our approach is but chained code-reuse aacks inside code injections remain rare. that malware can detect the use of dynamic analysis. is problem is shared by any dynamic analysis environment. For example, malware can detect the presence of QEMU and then diverge execution 8 LIMITATIONS AND FUTURE WORK to non-malicious behaviours. We do not perform any activities to In this work our focus is on tracing malware propagations within combat malware that tries to detect the presence of our system. the host and identifying code injections and code waves with a ere exists several approaches to hardening QEMU for malware special aention to the use of code-reuse aacks. In this section analysis which are directly correlated with approaches in which we describe limitations of our approach and some of the remain- malware detects QEMU. If we implement these techniques into ing challenges in the problem space of capturing and describing Tartarus we may harden it for some time, but is not likely to work malware propagations. as a general solution. Conceptually, in order to make it harder for An interesting limitation to our approach is that we only con- the malware to detect that it is running inside an analysis environ- sider malware propagations that happens within a single system ment, one approach is to switch to dynamic analysis environment execution. However, some malware carry propagation strategies that are more transparent in nature. For example, environments that stretch over a system reboot by, for example, dropping a bootkit like Ether [12] that utilize hardware virtualization extensions oer or rootkit which is initialized during system start-up. In fact, the more separation between the analysis environment and the guest Gapz malware is in this category. When Gapz has injected into environment in which the malware is executing. explorer.exe it continues to drop a bootkit and then modify either On a fundamental level, our techniques rely on taint analysis for the master boot record (MBR) or the volume boot record (VBR) capturing malware propagation. As such, our techniques inherit (depending on the version of Gapz). As a result, during the next the limitations of taint analysis for malware analysis, meaning an bootup, the modications to the MBR or VBR will cause the bootkit aacker can deploy information-ow evasive behaviours in order to to be loaded and Gapz will continue execution via the bootkit. Au- avoid analysis by our techniques. Certainly, techniques like multi- tomatic analysis of this part of Gapz requires dynamic analysis to path exploration via symbolic execution can aid in defeating evasive be stretched over the system boot. To the best of our knowledge, behaviours. However, given that we can’t explore the entire state- dynamic analysis of malware has never been done over several space of the vast majority of malware samples, the question we must system boots. erefore, an interesting avenue of further research really solve is how to identify evasive behaviours. When an evasive is to investigate how much more information can be leveraged behaviour is then detected, we can rely on various techniques, with automatically about the malware with such an approach. symbolic execution as one of them, to guide execution down the Another limitation to our approach is the use of our techniques path of interest. For a more general description about limitation to when the guest system is a multiprocessor environment. For ex- taint analysis for malware analysis we refer to Cavallaro et al. [7]. ample, our approach to collecting the malware execution trace described in Algorithm 1 assumes a single-core execution environment. Although we believe the identication of code injections 9 RELATED WORK and code waves can follow very similar strategies to our current Dynamic taint analysis have many applications in automating mal- approach, we have not yet tested Tartarus with a multi-core guest ware analysis tasks and a lot of work has been done in this area. environment. However, we will have many more parallel execution System-wide ne-grained malware analysis with taint information contexts to concern ourselves with and can potentially not rely on was rst proposed in Panorama by Yin et al. [46]. Panorama is the order of the malware execution trace as we do in this work. built on top of QEMU and oers multiple features such as keylog- In this paper we focused on identifying control-ow aspects ger detection and malware tracing based on taint analysis. Indeed between processes based on code injections and code waves within the malware tracing oered by Panorama is the work the comes each process. However, we have not paid a lot of aention to the closest to ours. In the malware execution tracing itself, Tartarus control-ow aspects within each code wave itself. In most cases, diers from Panorama by also considering code-reuse aacks and we can identify a lot of the control-ow within each code wave initially taints more memory than Panorama which only taints the from the instruction execution order in the malware execution trace text section. Panorama deploys no abstractions on the execution and disassembly of the code wave. However, if a malware sample trace itself where Tartarus abstracts the trace into code waves and writes memory to another process and this memory has several code injections that are then used to construct a system-wide CFG. dierent entry points independent of each other, then our approach Finally, the evaluation performed with Panorama is centred around will only recognize one code injection and consider the wrien its keylogger detection, which does not rely on malware tracing memory as one code wave. A more accurate approach would be to via taint, and the evaluation presented in this work is therefore the discover multiple code injections to the same code wave, and use rst evaluation on taint analysis for malware tracing. Other work that information to capture more precisely the control-ow within include Egele et al. who use dynamic taint analysis for spyware

1704 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

detection [13] and Moser et al. who use dynamic taint analysis but does not make any aempt to follow the malware across pro- in combination with linear constraint solvers to explore multiple cesses. Polyunpack detects unpacking behaviour by single-stepping execution paths in malware [32]. Dynamic taint analysis has also an application and matching the program counter to an initial static been explored in Android, most notably by TaintDroid [14] and analysis. DroidScope [44]. Besides automatic approaches to malware anal- Besides related work in the more general scope of malware analysis, dynamic taint analysis has also been proposed as an aid to ysis, memory forensics is an area that also provides solutions to manual reverse engineering tasks. For example, the tool SemTrax the problem of identifying how malware infects a system. For ex- [26], which is no longer being developed, augments debugging with ample, the Gapz malware places shellcode within explorer.exe by dynamic taint analysis and has the ability to visualize various rela- overwriting the function atan inside of ntdll. Code integrity check tionships on tainted data, such as the set of operations performed to verify the provenance of code in memory images is able to iden- on tainted memory. tify that malware overwrote the function by analysing memory In the last decade, full-system dynamic binary analysis platforms images [42]. Volatility [15] is a popular open source project that is have gained a lot of aention from malware analysis researchers. used for digital forensics and indeed there are plugins for volatility As a result, there now exists several multi-purpose systems that are aimed at identifying code injection [31]. e dierence between well-suited for building further analysis tools. We designed Tartarus our approach and that of memory forensics is the forensics analy- on top of DECAF [20] which is the successor of TEMU from the sis relies on a snapshot where our approach is based on analysis BitBlaze project [39]. One of the key features of DECAF is that taint of an execution. is means, if the Gapz would rewrite the atan analysis is performed directly on the QEMU tcg instructions, which function aer having executed its shellcode, such that the atan allows it to perform fast taint analysis during execution. In addition function would contain its original instructions and the snapshot to fast tainting via the tcg instructions, DECAF performs bitwise of the memory image was taken post this rewriting, then forensics taint analysis which gives it a very high level of precision in its taint. on this snapshot would not reveal the overwrien code, whereas PANDA is another platform that allows full-system dynamic binary we would still observe the execution of shellcode. analysis. In comparison to DECAF, PANDA is built around the concept of repeatable reverse engineering. It executes an instance 10 CONCLUSION of QEMU and records all non-deterministic data that goes into the In this paper we concern ourselves with automatic analysis of host- system. With the non-deterministic data recorded, PANDA then based malware propagations. Specically, we divide the problem provides the ability to replay the execution and the actual analysis into to two smaller tasks. First, how to trace malware in a gen- of the execution is performed during replay. e key advantages eral and precise manner in the context of execution across several of this strategy compared to performing analysis directly on the processes and code-reuse aacks. Second, how to raise the col- real execution is that the recording minimally aects the actual lected execution trace into higher-level semantics of dynamically execution in terms of performance, and that analysis can take a step- generated code and code injections. wise fashion. As such, the execution on which analysis is performed To solve these problems we have proposed three techniques and is eectively independent of the computational workload of the implemented them in a system we call Tartarus. Tartarus is a mal- analysis, i.e. analysis is performed on a “fast” full-system emulation, ware analysis environment that traces malware execution based on and, dierent analysis can be performed on the same execution. taint analysis and a model of code-reuse aacks. Tartarus abstracts PANDA supports byte-level taint analysis by raising the QEMU the execution trace into code waves based on an information-ow trace into an LLVM trace. S2E [9] is another platform that also oers model, and also identies and highlights intrinsic characteristics full-system dynamic binary analysis, but, in comparison to DECAF about code injection techniques in the execution trace. Finally, Tar- and PANDA, is focused around augmenting symbolic execution tarus combines these abstractions into a system-wide control-ow to full-system analysis. S2E does this via an x86-to-LLVM QEMU graph. backend that interfaces S2E with the KLEE symbolic execution We test Tartarus in the context of ground-truth applications engine that interprets LLVM instructions. Both DECAF, PANDA and our results show that Tartarus accurately captures malware and S2E provides comprehensible interfaces for writing plugins propagations, even without prior knowledge about them. We show and are all open-source projects. via a comparative evaluation that Tartarus improves capture of roughout the paper we have already mentioned automated malware execution traces over state-of-the-art dynamic analysis unpackers and other tools that give solutions to the problem of tools. We evaluate the performance of Tartarus which ranges from self-modifying code. We have specically focused on Codisasm [5] a few minutes to 15 minutes depending on the complexity of the and Ugarte et al [40]. Other tools include Renovo [22], OmniUn- sample. Finally we demonstrate the relevance of our approach by pack [30], EtherUnpack [12], RePEconstruct [24] and Polyunpack matching Tartarus with a recent malware data set which shows the [37]. All of these tools rely on the heuristic of monitoring explicit number of malware samples that inject code have increased almost write-then-execute paerns. EtherUnpack and Renovo captures three times since 2013. dynamically generated code within a specic process where Omni- Unpack deploys a more coarse-grained approach by monitoring for page-level write-then-execute paerns and suspicious system calls. ACKNOWLEDGMENTS RePEconstruct is a tool based on DynamoRIO that aims at uncover- e authors would like to acknowledge our anonymous reviewers, ing dynamically generated code and identify obfuscated API calls, Pedro Antonino and Julien Vanegue for useful feedback and insight- ful critique. We would also like to thank VirusTotal for providing

1705 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

malware samples and Udi Yavo and Tal Liberman of enSilo for [17] Mariano Graziano, Davide Balzaroi, and Alain Zidouemba. 2016. ROPMEMU: A making their code injection techniques available. Finally we would Framework for the Analysis of Complex Code-Reuse Aacks. In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security (ASIA like to thank Xunchao Hu for helping the rst author with several CCS ’16). ACM, New York, NY, USA, 47–58. hps://doi.org/10.1145/2897845. aspects of DECAF. Work is funded by National Science Foundation 2897894 [18] Pin Yahoo Groups. 2015. Failure to instrument process tree. (2015). hps: Grant #1664315 and DARPA Grant #FA8750-16-C-0044. //groups.yahoo.com/neo/groups/pinheads/conversations/topics/12019 [19] Jan Gustafsson, Adam Bes, Andreas Ermedahl, and Bjorn¨ Lisper. 2010. e Malardalen¨ WCET benchmarks: Past, present and future. In OASIcs-OpenAccess Series in Informatics, Vol. 15. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik. REFERENCES [20] Andrew Henderson, Aravind Prakash, Lok Kwong Yan, Xunchao Hu, Xujiewen [1] Andrea Allievi and Holger Unterbrink. 2015. CryptoWall 4 e Evolution Con- Wang, Rundong Zhou, and Heng Yin. 2014. Make It Work, Make It Right, Make tinues. (2015). It Fast: Building a Platform-neutral Whole-system Dynamic Binary Analysis [2] Magal Baz and Or Safran. 2017. Dridex’s Cold War: Enter AtomBombing. (2017). Platform. In Proceedings of the 2014 International Symposium on Soware Testing [3] Fabrice Bellard. 2005. QEMU, a Fast and Portable Dynamic Translator. In Pro- and Analysis (ISSTA 2014). ACM, New York, NY, USA, 248–258. hps://doi.org/ ceedings of the Annual Conference on USENIX Annual Technical Conference (ATEC 10.1145/2610384.2610407 ’05). USENIX Association, Berkeley, CA, USA, 41–41. hp://dl.acm.org/citation. [21] Andrew Henderson, Lok Kwong Yan, Xunchao Hu, Aravind Prakash, Heng cfm?id=1247360.1247401 Yin, and Stephen McCamant. 2017. DECAF: A Platform-Neutral Whole-System [4] Tyler Bletsch, Xuxian Jiang, Vince W. Freeh, and Zhenkai Liang. 2011. Jump- Dynamic Binary Analysis Platform. IEEE Trans. Sow. Eng. 43, 2 (Feb. 2017), oriented Programming: A New Class of Code-reuse Aack. In Proceedings of 164–184. hps://doi.org/10.1109/TSE.2016.2589242 the 6th ACM Symposium on Information, Computer and Communications Security [22] Min Gyung Kang, Pongsin Poosankam, and Heng Yin. 2007. Renovo: A Hidden (ASIACCS ’11). ACM, New York, NY, USA, 30–40. hps://doi.org/10.1145/1966913. Code Extractor for Packed Executables. In Proceedings of the 2007 ACM Workshop 1966919 on Recurring Malcode (WORM ’07). ACM, New York, NY, USA, 46–53. hps: [5] Guillaume Bonfante, Jose Fernandez, Jean-Yves Marion, Benjamin Rouxel, Fab- //doi.org/10.1145/1314389.1314399 rice Sabatier, and Aurelien´ ierry. 2015. CoDisasm: Medium Scale Con- [23] omas Kiel, Sebastian Vogl, Julian Kirsch, and Claudia Eckert. 2015. Counter- catic Disassembly of Self-Modifying Binaries with Overlapping Instructions. acting Data-Only Malware with Code Pointer Examination. Springer International In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Com- Publishing, Cham, 177–197. hps://doi.org/10.1007/978-3-319-26362-5 9 munications Security (CCS ’15). ACM, New York, NY, USA, 745–756. hps: [24] D. Korczynski. 2016. RePEconstruct: reconstructing binaries with self-modifying //doi.org/10.1145/2810103.2813627 code and import address table destruction. In 2016 11th International Conference [6] Erik Buchanan, Ryan Roemer, Hovav Shacham, and Stefan Savage. 2008. When on Malicious and Unwanted Soware (MALWARE). 1–8. hps://doi.org/10.1109/ Good Instructions Go Bad: Generalizing Return-oriented Programming to RISC. MALWARE.2016.7888727 In Proceedings of the 15th ACM Conference on Computer and Communications [25] Peter Kruse. 2012. W32.Tinba (TinyBanker) e Turkish Incident. (2012). Security (CCS ’08). ACM, New York, NY, USA, 27–38. hps://doi.org/10.1145/ [26] Persistence Labs. 2013. Semtrax. (2013). hp://www.persistencelabs.com/blog 1455770.1455776 [27] Tal Liberman. 2016. AtomBombing: Brand New Code Injection for Windows. [7] Lorenzo Cavallaro, Prateek Saxena, and R. Sekar. 2008. On the Limits of Informa- (2016). tion Flow Techniques for Malware Analysis and Containment. In Proceedings of [28] Tal Liberman. 2017. BSidesSF 2017, AtomBombing: Injecting Code Using Win- the 5th International Conference on Detection of Intrusions and Malware, and Vul- dows’ Atoms. (2017). hps://www.youtube.com/watch?v=9HV69QGiBAU nerability Assessment (DIMVA ’08). Springer-Verlag, Berlin, Heidelberg, 143–163. [29] Wayne Low. 2012. Code injection via return-oriented programming. Virus hps://doi.org/10.1007/978-3-540-70542-0 8 Bulletin (2012). [8] Stephen Checkoway, Ariel J. Feldman, Brian Kantor, J. Alex Halderman, Ed- [30] Lorenzo Martignoni, Mihai Christodorescu, and Somesh Jha. 2007. Omniunpack: ward W. Felten, and Hovav Shacham. 2009. Can DREs Provide Long-lasting Fast, generic, and safe unpacking of malware. In In Proceedings of the Annual Security? e Case of Return-oriented Programming and the AVC Advantage. In Computer Security Applications Conference (ACSAC. Proceedings of the 2009 Conference on Electronic Voting Technology/Workshop on [31] Monnappa22. HollowFind. (). hps://github.com/monnappa22/HollowFind Trustworthy Elections (EVT/WOTE’09). USENIX Association, Berkeley, CA, USA, [32] Andreas Moser, Christopher Kruegel, and Engin Kirda. 2007. Exploring Multiple 6–6. Execution Paths for Malware Analysis. In Proceedings of the 2007 IEEE Symposium [9] Vitaly Chipounov, Volodymyr Kuznetsov, and George Candea. 2012. e S2E on Security and Privacy (SP ’07). IEEE Computer Society, Washington, DC, USA, Platform: Design, Implementation, and Applications. ACM Trans. Comput. Syst. 231–245. hps://doi.org/10.1109/SP.2007.17 30, 1, Article 2 (Feb. 2012), 49 pages. hps://doi.org/10.1145/2110356.2110358 [33] PaloAlto Networks. 2013. e Modern Malware Review. (2013). [10] Lucas Davi, Ahmad-Reza Sadeghi, Daniel Lehmann, and Fabian Monrose. 2014. [34] Michalis Polychronakis and Angelos D. Keromytis. 2011. ROP Payload Detection Stitching the Gadgets: On the Ineectiveness of Coarse-grained Control-ow Using Speculative Code Execution. In Proceedings of the 2011 6th International Integrity Protection. In Proceedings of the 23rd USENIX Conference on Security Conference on Malicious and Unwanted Soware (MALWARE ’11). IEEE Computer Symposium (SEC’14). USENIX Association, Berkeley, CA, USA, 401–416. hp: Society, Washington, DC, USA, 58–65. hps://doi.org/10.1109/MALWARE.2011. //dl.acm.org/citation.cfm?id=2671225.2671251 6112327 [11] Cuckoo developers. 2017. Cuckoo Sandbox. (2017). hps://www.cuckoosandbox. [35] Symantec Security Response. 2015. W32.Ramnit analysis. (2015). org/ [36] Eugene Rodionov and Aleksandr Matrosov. 2016. Mind the Gapz: e Most [12] Artem Dinaburg, Paul Royal, Monirul Sharif, and Wenke Lee. 2008. Ether: Complex Bootkiv Ever Analyzed? (2016). Malware Analysis via Hardware Virtualization Extensions. In Proceedings of the [37] Paul Royal, Mitch Halpin, David Dagon, Robert Edmonds, and Wenke Lee. 2006. 15th ACM Conference on Computer and Communications Security (CCS ’08). ACM, PolyUnpack: Automating the Hidden-Code Extraction of Unpack-Executing New York, NY, USA, 51–62. hps://doi.org/10.1145/1455770.1455779 Malware. In Proceedings of the 22Nd Annual Computer Security Applications [13] Manuel Egele, Christopher Kruegel, Engin Kirda, Heng Yin, and Dawn Song. Conference (ACSAC ’06). IEEE Computer Society, Washington, DC, USA, 289–300. 2007. Dynamic Spyware Analysis. In 2007 USENIX Annual Technical Conference hps://doi.org/10.1109/ACSAC.2006.38 on Proceedings of the USENIX Annual Technical Conference (ATC’07). USENIX [38] Hovav Shacham. 2007. e Geometry of Innocent Flesh on the Bone: Return- Association, Berkeley, CA, USA, Article 18, 14 pages. hp://dl.acm.org/citation. into-libc Without Function Calls (on the x86). In Proceedings of the 14th ACM cfm?id=1364385.1364403 Conference on Computer and Communications Security (CCS ’07). ACM, New York, [14] William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyeon Jung, NY, USA, 552–561. hps://doi.org/10.1145/1315245.1315313 Patrick McDaniel, and Anmol N. Sheth. 2010. TaintDroid: An Information-ow [39] Dawn Song, David Brumley, Heng Yin, Juan Caballero, Ivan Jager, Min Gyung Tracking System for Realtime Privacy Monitoring on Smartphones. In Proceedings Kang, Zhenkai Liang, James Newsome, Pongsin Poosankam, and Prateek Saxena. of the 9th USENIX Conference on Operating Systems Design and Implementation 2008. BitBlaze: A New Approach to Computer Security via Binary Analysis. In (OSDI’10). USENIX Association, Berkeley, CA, USA, 393–407. hp://dl.acm.org/ Proceedings of the 4th International Conference on Information Systems Security citation.cfm?id=1924943.1924971 (ICISS ’08). Springer-Verlag, Berlin, Heidelberg, 1–25. hps://doi.org/10.1007/ [15] Volatility Foundation. Volatility - Open Source Memory Forensics. (). hp: 978-3-540-89862-7 1 //www.volatilityfoundation.org/ [40] Xabier Ugarte-pedrero, Davide Balzaroi, Igor Santos, and Pablo G. Bringas. SoK: [16] Enes Gokta¨ s¸, Elias Athanasopoulos, Michalis Polychronakis, Herbert Bos, and Deep Packer Inspection: A Longitudinal Study of the Complexity of Run-Time Georgios Portokalidis. 2014. Size Does Maer: Why Using Gadget-Chain Packers. (). Length to Prevent Code-Reuse Aacks is Hard. In 23rd USENIX Security [41] Sebastian Vogl, Jonas Pfoh, omas Kiel, and Claudia Eckert. 2014. Persistent Symposium (USENIX Security 14). USENIX Association, San Diego, CA, 417– Data-only Malware: Function Hooks without Code. In Proceedings of the 21th 432. hps://www.usenix.org/conference/usenixsecurity14/technical-sessions/ Annual Network and Distributed System Security Symposium (NDSS). presentation/goktas

1706 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

[42] Andrew White, Bradley Schatz, and Ernest Foo. 2013. Integrity verication of Tartarus updates the shadow memory based on the taint propa- user space code. Digital Investigation (2013). gation functionTP and also all output by instructions in the shadow [43] Lok Yan and Heng Yin. 2017. SoK: On the Soundness and Precision of Dynamic Taint Analysis. (2017). hp://www.cs.ucr.edu/„heng/teaching/ memory. As such, the malware analyser Tartarus PA,TA denes δA cs260-winter2017/formaltaint.pdf as follows [44] Lok Kwong Yan and Heng Yin. 2012. DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis. In TPpi,sq Y irOs if irAs P s Proceedings of the 21st USENIX Conference on Security Symposium (Security’12). δA,TAps,iq “ s Y tTA where tTA “ USENIX Association, Berkeley, CA, USA, 29–29. hp://dl.acm.org/citation.cfm? #TPpi,sq otherwise id=2362793.2362822 [45] Udi Yavo and Tomer Bion. 2015. Injection on Steroids: Code-less Code Injections Furthermore, Tartarus includes in the malware execution trace and 0-Day Techniques. (2015). any instruction part of the shadow memory or part of a code-reuse [46] Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, and Engin Kirda. aack, given by theCR function, and therefore denes ΛA as follows 2007. Panorama: Capturing System-wide Information Flow for Malware De- tection and Analysis. In Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS ’07). ACM, New York, NY, USA, 116–127. true, if irAs P s _ CRpi,sq hps://doi.org/10.1145/1315245.1315261 ΛA,TAps,iq “ #f alse, otherwise A FORMAL COMPARISON TO PREVIOUS We now show shat the malware execution trace collected by previous work is indeed a subset of the malware execution trace WORK collected by Tartarus. e denition of malware execution trace given in Denition 1 allows us to formally compare Tartarus to previous works [5, 40]. Theorem A.1. Let PA,UB and PA,TA be the malware tracer de- Before we make the comparison, however, we need to give a few ned above and T pP,Eq be some execution trace. Furthermore, let more denitions. First, for a given instruction, let irW s denote the STUB pT pP,Eqq “ psu,0,... su,l q and STTApT pP,Eqq “ pst,0,...,st,l q memory it writes, irAs the instruction address and irOs the output of be the respective shadow memory sets. Given that su,0 = st,0, we have the instruction. We have that irW s Ď irOs and for convenience that that there is no element i P T pP,Eq such that i P ΠUB ^ i R ΠTA. irAs Ď irW s Ď irOs Ď S. Second, let the function TP : S ˆ i Ñ Proof. We prove by contradiction that there is no element i P S represent the taint propagation function, and CR : S ˆ i Ñ T pP,Eq such that i P ΠUB ^ i R ΠTA. ttrue, f alseu be the predicate that identies code-reuse. We rst show that each element in the shadow memories col- We now proceed to formally dene the malware analysers of pre- lected by PA,UB is a subset of the corresponding element in the vious work [5, 40] and the approach by Tartarus, and then continue shadow memories collected by PA,TA. We have that su,0 “ st,0 to show malware execution trace collected by previous work is a and therefore su,0 Ď st,0. From the denitions of δA,UB and δA,TA, subtrace of the one collected by Tartarus. Both [5, 40] propose the we then have have tUB Ď tTA and therefore δA,UB psu,0,i0q Ď malware analyser PA,UB that updates the shadow memory with δA,TApst,0,i0q. Because δA is a monotonic increasing function, we any memory wrien by instructions already in the shadow memory, then have that @su,i P STUB pT pP,Eqq|su,i Ď st,i . As such, each as such they dene δA as follows: element in the shadow memories collected by PA,UB is a subset of the corresponding element in the shadow memories collected by irW s, if irAs P s PA,TA. δA,UB ps,iq “ s Y tUB where tUB “ Assume there exist an element m such that m P Π ^ m R #H, otherwise A,UB ΠA,TA. is means there exists an element i P T pP,Eq such that Furthermore, in the malware execution trace they only include ΛA,UB psu,j ,iq is true and ΛA,TApst,j ,iq is false. From the deni- instructions that are part of the shadow memory, and therefore tions of ΛA,UB and ΛA,TA, this is only possible if su,j contains an dened Λ as follows: A element that is not in st,j . We have shown above that this is not true, if irAs P s the case, and the proof is done. ΛA,UB ps,iq “ f alse, otherwise # B CODE INJECTION GRAPH OF GAPZ SAMPLE.

1707 Session H2: Code Reuse Attacks CCS’17, October 30-November 3, 2017, Dallas, TX, USA

mov [esi + 0x94], eax 0xa40 [eax] chaser Call SendNotifyMessage 9b3748

1001b4b Call [eax] eax chaser KiUserAPCDispatcher rep movsd mov edx, [ebp + 0x10] 0x804de7f4 0xbf834abf eax chaser 1001b59 Call [eax + 8] ntoskrnl.exe win32k.sys mov eax, [esi] std ret esi chaser

push [ebp + 0x10] push [ebp + 0x10] mov [ecx], edx mov esi, eax 1001b6e Call [eax + 4] 0x7e42c285 0xbf834b15 0xbf834ac4 0x1001b3e eax chaser mov ecx, 0x94 ntoskrnl.exe win32k.sys win32k.sys explorer.exe rep movsd [eax + 8] chaser pop edi xor eax, eax push [ebp + 0x10] pop esi mov eax, [esi + eax + 0xa4] 0x7e42c2a4 pop edi 0x7e418894 User32.dll explorer.exe SetWindowsLong [eax+4] chaser

mov [esi + 0x9c], eax mov [esi + 0x94], eax 0xa40 0xa40 0x9b3765 0x9b3748 push eax 0xa40, wave1 0x9b3aee mov [esi + 0x64], eax 0x9b3799 7c9ee5ca ret wave1 cld Malware.exe

mov [esi+0x70], eax 0x9b37b7 77ec5b27 ret wave1 pop eax Malware.exe

mov [esi + 0x78], eax 0x9b384a 101179d ret wave1 alloca probe Malware.exe

mov [esi + 0x7c], eax rep movsd 7c90160c ret 0x9b3824 7c9ee5c3 mov eax, [eax] push eax WriteProcessMemory Malware.exe explorer.exe

mov [esi + 0x10], eax 0x9b3830 7c802298 ret wave1 pop eax Malware.exe

mov [esi + 0x2c], eax 101179d ret 0x9b384a jmp eax Malware.exe

rep movsb rep movsd rep movsd 0x9b39a1 System System 0x77ef48c0 mov ebp, esp wave1 0x805758ad 0x80575907 0x77ef48c0 chaser Malware.exe

1708