As tensions rise between North Korea and the United States, Secretary of Homeland Security, John Kelly, proclaimed North Korea currently is a more probable cyber threat than a kinetic threat. Given North Korea’s inclination to use digital weapons over the past few years, this is not a controversial statement, but it should not be assumed that this is a matter simply contained to the governments. If past behavior is any indication, should North Korea opt for a digital response, the private sector, not the public sector, may be disproportionately targeted.

Abridged Summary of North Korean Digital Behavior

The Sony attack is perhaps the most well-known public attribution of a North Korean digital attack, and more specifically the hacking group Lazarus. In late 2014, a combination of targeted spear phishing - including scraping social networks and password reuse of even those with low-level privileges -  and technical vulnerabilities resulted in significant reputational as well as financial losses for Sony. For many, Sony served as an inflection point, manifesting the real-world and existential impact a digital attack can have on a corporation. A 2015 60 Minutes segment summarized this perceived inflection point triggered by the Sony attack, noting,“you don't have to be a superpower to inflict damage on U.S. corporations.”

In addition to the Sony attack, North Korth has also been blamed for digital attacks targeting South Korean corporations, including media and financial institutions. South Korea also has blamed North Korea for an attack on the energy sector, including nuclear reactors run by the Korea Hydro and Nuclear Power Co, again often using large-scale phishing campaigns targeting thousands of employees to gain access. North Korea has also been accused of digital attacks targeting defense and high-tech companies in both South Korea and Japan.

More recently, North Korea has been linked to the 2016 digital attacks targeting the SWIFT payment system, which resulted in an $81 million heist from the Bangladesh Central Bank. Some of the code used in the Bangladesh heist appears to have been repurposed from the Sony attack. It is currently believed that the attackers gained access using stolen credentials, again demonstrating the various fileless attack vectors increasingly employed.  Recently, several North Korean banks, which were already blacklisted by United Nations sanctions, have been banned from the SWIFT system as well.

Diversifying the Economy and Targets

Pyongyang continues to be impacted by international sanctions and the limitations of a centrally planned economy, forcing the government to diversify tactics and revenue streams. Digital attacks are an efficient revenue stream and means to achieve strategic objectives against larger powers. The group most-frequently associated with North Korean high profile attacks, Lazarus, is affiliated with North Korea’s elite hacking group, Bureau 121. Largely believed to be located in China, the size of Bureau 121 is not certain, but may be comprised of 1800 specialists according to one defector, while others estimate the overall size of North Korea’s hacking groups to closer to 6800, with a revenue of $860 million prior to the SWIFT heist.

They also have global reach. In addition to targeting the United States and South Korea, North Korea is also targeting institutions in eighteen different countries, largely in developing economies across the globe. However, while globally North Korea remains focused on the banking system, within the United States and South Korea the target set is much broader, focusing on media companies, financial institutions, and critical infrastructure.

Geopolitical Spillover

State-sponsored and affiliated attacks are increasingly targeting the private sector and thanks to both social and technical vulnerabilities, are likely to successfully compromise networks. While missiles and nuclear capabilities have understandably garnered the most attention in the rising tensions between the United States and North Korea, it would be myopic to overlook the potential impact of digital attacks.

Past behavior strongly indicates North Korea’s propensity to employ digital weapons given the asymmetric advantages and their growing expertise. The recent initial reports speculating that the North Korean missile test failed due to sabotage by the United States is only amplifying the situation. With the regime increasingly cornered by an existential threat, North Korea may well lean on past success and ratchet up targeted digital attacks at a range of corporations as tensions persist with the United States.

Advanced exploitation is moving away from ROP-based code-reuse attacks. Over the last two years, there has been a flurry of papers related to one novel code-reuse attack, Counterfeit Object-Oriented Programming (COOP). COOP represents a state of the art attack targeting forward-edge control-flow integrity (CFI), and caught our attention in 2016 as we were integrating our CFI solution (HA-CFI) into our endpoint product. COOP largely remains in academia, and has yet to show up in exploit kits. This may be because attackers migrate towards a path of least resistance. In the case of Microsoft Edge on Windows 10 Anniversary Update, protected by Control Flow Guard (CFG), that path of least resistance is the absence of backward-edge CFI. But what happens when Return Flow Guard (RFG) emerges and the attacker can no longer rely on corrupting a return address on the stack? 

We were curious to evaluate COOP against modern CFI implementations.  This not only is a useful exercise to keep us on top of cutting-edge research in academia and the hacking community, but it also allows us to measure the effectiveness, alter the design, or generally improve upon our own mitigations when necessary. This first of our two-part blog series covers our adventures evaluating COOP function-reuse attacks against Microsoft’s CFG and later our own HA-CFI. 

Microsoft Control Flow Guard

There have been a number of papers, blogs, and conference talks already discussing Microsoft’s Control Flow Guard (CFG) at length. Trail of Bits does an excellent job of comparing Clang CFI and Microsoft CFG in two recent posts. The first post focuses on Clang, the second emphasizes Microsoft’s implementation of CFI, while additional research provides further detail on the implementation of CFG. 

Bypassing CFG has also been a popular subject at security conferences the past few years. Before we cite some notable bypasses it is first important to note that CFI can be further broken down into two types: forward-edge and backward-edge.

• Forward-Edge CFI: Protects indirect CALL or JMP sites. Forward-edge CFI solutions include Microsoft CFG and Endgame’s HA-CFI.
• Backward-Edge CFI: Protects RET instructions. Backward-edge CFI solutions would include Microsoft Return Flow Guard, components of Endgame’s DBI exploit prevention, as well as other ROP detections including Intel’s CET. 

This categorization helps delineate what CFG is designed to protect – indirect call sites – and what it’s not meant to protect – the return stack. For instance, a recent POC ended up in exploit kits targeting Edge using a R/W primitive to modify a return address on the stack. This is not applicable to CFG, and should not be considered a weakness of CFG. If anything, it demonstrates CFG successfully pushing attackers to hijack control flow somewhere other than at indirect call sites. Examples that actually demonstrate flaws or limitations of CFG include: leveraging unprotected call sites, remapping read-only memory regions containing CFG code pointers and changing them to point to code that always passes a check, a race condition with the JIT encoder in Chakra, and using memory-based indirect calls. COOP or function-reuse attacks in general are an acknowledged limitation for some CFI implementations and noted as out-of-scope for Microsoft’s bypass bounty due to “limitations of coarse-grained CFI”. That said, we are not aware of any public domain POCs that demonstrate COOP to specifically attack CFG hardened binaries.  

CFG adds a __guard_fids_table to each protected DLL, composed of a list of RVAs of valid or sensitive targets for indirect call sites within the binary. An address is used as an index into a CFG bitmap, where bits can be toggled depending upon whether the address should be a valid destination. An API also exists to modify this bitmap, for example, to support JIT encoded pages: kernelbase!SetProcessValidCallTargets which invokes ntdll!SetInformationVirtualMemory before making the syscall to update the bitmap.

A new enhancement to CFG in Windows 10 Creators Update enables suppression of exports. In other words, exported functions can now be marked as invalid target addresses for CFG protected call sites. The implementation of this requires using a second bit for each address within the CFGBitmap, as well as a flags byte in the __guard_fids_table for each RVA entry when building the initial per process bitmap. 

For 64-bit systems, bits 9-63 of the address are used as an index to retrieve a qword from the CFG bitmap, and bits 3-10 of the address are used (modulo 64) to access a specific bit within the qword. With export suppression, the CFG permissions for a given address are represented by two bits in the CFG bitmap. Additionally, __guard_dispatch_icall_fptr in most DLLs is now set to point to ntdll!LdrpDispatchUserCallTargetES where a valid call target must omit ‘01’ from the CFG bitmap. 

Implementing this new export suppression feature becomes a bit complicated when you factor in dynamically resolving symbols, since using GetProcAddress implies subsequent code may invoke the return value as a function pointer. Control Flow Guard handles this by changing the corresponding two-bit entry in the CFG bitmap from ‘10’ (export suppressed) to ‘01’ (valid call site) as long as the entry was not previously marked as sensitive or not marked valid at all (e.g. VirtualProtect, SetProcessValidCallTargets, etc.). As a result, some exports will begin as invalid indirect call targets on process creation, but eventually become a valid call target due to code at runtime. This is important to remember later in our discussion. For reference, a sample call stack when this occurs looks as follows:

00 nt!NtSetInformationVirtualMemory

01 nt!setjmpex

02 ntdll!NtSetInformationVirtualMemory

03 ntdll!RtlpGuardGrantSuppressedCallAccess

04 ntdll!RtlGuardGrantSuppressedCallAccess

05 ntdll!LdrGetProcedureAddressForCaller

06 KERNELBASE!GetProcAddress

07 USER32!InitializeImmEntryTable

COOP Essentials

Schuster et al. identified counterfeit object-oriented programming (COOP) as a potential weakness to CFI implementations. The attack sequences together and reuses existing virtual functions in order to execute code while passing all forward-edge CFI checks along the way. In a similar manner to ROP, the result is a sequence of small valid functions that individually perform minimal computation (e.g. load a value into RDX), but when pieced together perform some larger task. A fundamental component of COOP is to leverage a main loop function, which might iterate over a linked-list or array of objects, invoking a virtual method on each object. The attacker is then able to piece together “counterfeit” objects in memory, in some cases overlapping the objects, such that the main loop will call valid virtual functions of the attacker’s choosing in a controlled order. Schuster et al. demonstrated the approach with COOP payloads targeting Internet Explorer 10 on Windows 7 32-bit and 64-bit, and Firefox on Linux 64-bit. The research was later extended, demonstrating that recursion or functions with many indirect call invocations could also be used instead of a loop, and extended yet again into targeting the Objective-C runtime. 

This prior research is extremely interesting and novel. We wanted to apply the concept to some modern CFI implementations to assess: a) the difficulty of crafting a COOP payload in a hardened browser; b) whether we could bypass CFG and HA-CFI; and c) whether we could improve our CFI to detect COOP style attacks. 

Our Target

Our primary target for COOP was Microsoft Edge on Windows 10, as it represents a fully hardened CFG application, and allows us to prepare our COOP payload in memory using JavaScript. While vulnerabilities are always of interest to our team, for this effort we focus on the hijack of control flow with CFI in place, and make the following assumptions as an attacker:

1. An arbitrary read-write primitive is obtained from JavaScript.
2. Hardcoded offsets are allowed, as dynamically finding gadgets at run-time is out of scope for this particular effort.
3. All of Microsoft’s latest mitigations in Creators update are enabled (e.g. ACG, CIG, CFG with export suppression).
4. The attacker must not bypass or avoid CFG in any way other than using COOP.

For our initial research, we leveraged a POC from Theori for Microsoft Edge on Windows 10 Anniversary update (OS build 14393.953). However, we designed our payload with Creators update mitigations in mind, and validated our final working COOP payload on Windows 10 Creators update (OS build 15063.138) with export suppression enabled.

An ideal POC would execute some attacker shellcode or launch an application. A classic code execution model for an attacker is to map some controlled data in memory as +X, and then jump to shellcode in that newly modified +X region. However, our real goal is to generate COOP payloads that execute something meaningful while protected by forward-edge CFI. Such a payload provides data points with which we can test and refine our own CFI algorithms. Further, attacking Arbitrary Code Guard (ACG) or the child process policy in Edge is slightly out of scope. We decided an acceptable end goal for our research on Windows 10 Creators Update was to use COOP to effectively disable CFG, opening up the ability to then jump or call any arbitrary location within a DLL. We thus ended up with two primary COOP payloads:

1. For Windows 10 Anniversary Update, and a lack of ACG, our payload maps data we control as executable, and then jumps into that region of controlled shellcode after disabling CFG.
2. For Windows 10 Creators Update, our end goal was to simply disarm CFG. 

Finding COOP Gadgets

Following the blueprint left by Schuster et al., our first order of business was to agree upon a terminology for the various components of COOP. The academic papers refer to each reused function as a virtual function gadget or vfgadget, and when describing each specific type of vfgadget an abbreviation is used such as ML-G for a main loop vfgadget. We opted to name each type of gadget in a more informal way. Terms you find in the remaining post are defined here:

• Looper: the main loop gadget critical to executing complex COOP payloads (ML-G in paper)
• Invoker: a vfgadget which invokes a function pointer (INV-G in paper)
• Arg Populator: a virtual function which preps an argument, either loading a value into a register (LOAD-R64-G in paper), or moving the stack pointer and/or loading values on the stack (MOVE-SP-G in paper)

Similar to the paper, we wrote scripts to help us identify vfgadgets in a given binary. We utilized IDA Python, and logic helped us find loopers, invokers, and argument populators. In our research, we found that a practical approach to COOP is to chain together and execute a small number of vfgadgets at a time, before returning to JavaScript, repeating the process through additional COOP payloads as needed. For this reason, we did not find it necessary to lift binary code to IR for our purposes. However, to piece together an extremely large COOP payload, such as running a C2 socket thread all via reused code, it may require lifting to IR in order to piece together the desired assembly. For each subtype of vfgadget, we defined a list of rules that we used while conducting a search within two of the more fruitful binaries in Edge (chakra.dll and edgehtml.dll). A few of these rules for a looper vfgadget include:

1. Function present on __guard_fids_table
2. Contain a loop with exactly 1 indirect call taking 0 arguments
3. Loop must not clobber argument registers

Of all the classes of vfgadgets, the search for loopers was the most time consuming. Many potential loopers have some restrictions that make it hard to work with. Our hunt for invokers turned up not only vfgadgets for invoking function pointers, but also many vfgadgets that can very quickly and easily populate up to six arguments at once all from a single counterfeit object. For this reason, there are shortcuts available for COOP when attempting to invoke a single API, which completely avoid requiring a loop or recursion, unless a return value is needed.  Numerous register populators were found for all argument registers on x64. It is worth mentioning that a number of the original vfgadgets proposed in the Schuster et al. COOP paper from mshtml can still be found in edgehtml. However, we added a requirement to our effort to avoid reusing any of these and instead find all new vfgadgets for our COOP payloads. 

COOP Payloads

By triggering COOP from a scripting language, we can actually move some complex tasking out of COOP, since chaining together everything at once can get complicated. We can use JavaScript to our advantage and repeatedly invoke miniature COOP payload sequences. This allows us to move things like arithmetic and conditional operations back to JavaScript, and leave the bare essential function reuse to prepping and invoking critical API’s via COOP. Further, we show an example of this methodology including passing return values from COOP back to JavaScript in our Hijack #1 section discussing how to invoke LoadLibrary. 

For brevity, I will only step through one of our simplest payloads. A common theme to all of our payloads is the requirement to invoke VirtualProtect. Since VirtualProtect and the eshims APIs are marked as sensitive and not a valid target for CFG, we have to use a wrapper function in Creators Update. As originally suggested by Thomas Garnier, a number of convenient wrappers can be found in .NET libraries mscoree.dll and mscories.dll such as UtilExecutionEngine::ClrVirtualProtect. Because Microsoft’s ACG prevents creating new executable memory, or changing existing executable memory to become writable, an alternate approach is required. Read-only memory can be remapped as writable with VirtualProtect, so I borrow the technique from a BlackHat 2015 presentation, and remap the page containing chakra!__guard_dispatch_icall_fptr as writable, then overwrite the function pointer to point to an arbitrary place in chakra.dll that contains a jmp rax instruction. In fact, there already exists a function in most DLLs, __guard_dispatch_icall_nop, which is exactly that – a single jmp rax instruction. As a result, I can effectively disable CFG since all protected call sites within chakra.dll will immediately just jump to the target address as if it passed all checks. Presumably one could take this a step further to explore function-reuse to attack ACG. To accomplish this mini-chain, the following is required:

1. Load mscoree.dll into the Edge process
2. Invoke ClrVirtualProtect +W on a read-only memory region of chakra.dll
3. Overwrite __guard_dispatch_icall_fptr to always pass check

As seen from the list of vfgadgets above, edgehtml is an important library for COOP. Thus, the first order of business is to leak the base address for edgehtml as well as any other necessary components, such as our counterfeit memory region. This way the payload can contain hardcoded offsets to be rebased at runtime. Using the info leak bug in Theori’s POC, we can obtain all the base addresses we need. 

//OS Build 10.0.14393
var chakraBase = Read64(vtable).sub(0x274C40);
var guard_disp_icall_nop = chakraBase.add(0x273510);
var chakraCFG = chakraBase.add(0x5E2B78); //_guard_dispatch_icall...
var ntdllBase = Read64(chakraCFG).sub(0x95260);

//Find global CDocument object, VTable, and calculate EdgeHtmlBase
var [hi, lo] = PutDataAndGetAddr(document);
CDocPtr = Read64(newLong(lo + 0x30, hi, true));
EdgeHtmlBase = Read64(CDocPtr).sub(0xE80740);

//Rebase our COOP payload
rebaseOffsets(EdgeHtmlBase, chakraBase, ntdllBase, pRebasedCOOP);

Triggering COOP

A key part of using COOP is the initial transition from JavaScript into a looper function. Using our assumed R/W primitive, we can easily hijack a vtable in chakra to point to our looper, but how do we ensure the looper then begins iterating over our counterfeit data? For that answer we need to evaluate the looper, which I chose as CTravelLog::UpdateScreenshotStream: 

Notice in the first block before the loop, the code is retrieving a pointer to a linked list at this + 0x30h. In order to properly kick off the looper, we must both hijack a JavaScript object’s vtable to include the address to our looper, and then place a pointer at object + 0x30 to point to the start of our counterfeit object list. The actual counterfeit object data can be defined and rebased entirely in JavaScript. Also notice the loop is iterating over a list with a next pointer at object + 0x80h. This is important when crafting our counterfeit object stream. Additionally, notice the vtable offset for this indirect call site is +0xF8h. Any fake vtable in our counterfeit objects must all point to the address of the desired function pointer minus 0xF8h, which often will be in the middle of some neighboring vtable. To kickoff our COOP payload, I chose to hijack a JavascriptNativeIntArray object and will specifically override the freeze() and seal() virtual functions as follows. 

var hijackedObj = new Array(0);

[hi, lo] = PutDataAndGetAddr(hijackedObj);

var objAddr = new Long(lo, hi, true);

Write64(objAddr.add(0x30), pRebasedCOOP);

Write64(objAddr, pFakeVTable);

Object.seal(hijackedObj); //Trigger initial looper

Hijack #1: Invoking LoadLibrary

As previously stated, my end goal was bypassing CFG on Edge on Win10 Creators update with export suppression enabled. Looking at the various LoadLibrary calls exported in kernel32 and kernelbase, it turns out loading a new DLL into our process is rather easy even with the latest CFG feature in place. The reason for this is two-fold. First, LoadLibraryExW is actually marked as a valid call target in the __guard_fids_table within kernel32.dll. 

Second, the rest of the LoadLibrary calls within both kernel32 and kernelbase start out as suppressed, but in Edge they eventually become valid call sites. This appears to stem from some delayed loading in MicrosoftEdgeCP!_delayLoadHelper2, which eventually results in GetProcAddr being called on the LoadLibraryX APIs. As foreshadowed earlier, this demonstrates the difficulty of making all function exports invalid call targets. Even if these other LoadLibrary call gates remained suppressed or were only opened temporarily, for our purposes we can just use kernel32!LoadLibraryExW since it’s initialized as a valid target.

To get our desired VirtualProtect wrapper loaded into the Edge process, we need to invoke LoadLibraryExW(“mscoree.dll”, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32). We could cut corners here, and leverage one of the aforementioned invokers to populate all of our parameters at once, but instead let’s create a traditional COOP payload using a looper vfgadget to iterate over four counterfeit objects. 

Our first iteration will populate r8d with 0x800. CHTMLEditor::IgnoreGlyphs is a nice vfgadget to populate r8d as seen in the assembly below. Our parameter 0x800 (LOAD_LIBRARY_SEARCH_SYSTEM32) will be loaded from this + 0xD8h. Recall that the next pointer in our counterfeit objects must be at +0x80h. We could create four contiguous counterfeit objects in memory to each be of size greater than 0xD8h, or we could treat the next pointer to be located at the end of our object. I chose the latter.  In this case, we will have an overlapping object so we must be careful that the offset of this + 0xD8 does not interfere with the vfgadget from our second iteration that operates on the second object in memory. The first counterfeit object for populating r8d looks as follows: 

Upon return from this vfgadget, the looper then iterates over our fake linked list and must now invoke another vfgadget this time to populate rdx with a value of 0x0 (NULL). To achieve this I use Tree::ComputedRunTypeEnumLayout::BidiRunBox::RunType(). We can load our value (0x0) from our counterfeit object + 0x28h.

Now that we have populated parameters 2 and 3 for our API call, we need to populate the first argument, a pointer to our ‘mscoree.dll’ string, and then invoke a function pointer to LoadLibraryExW. A perfect invoker vfgadget exists for this purpose, Microsoft::WRL::Details::InvokeHelper::Invoke(). The assembly and corresponding third counterfeit object are as follows: 

Now that LoadLibraryExW has been called, and hopefully mscoree.dll loaded into our process, we need to get the return address back to JavaScript to rebase additional COOP payloads. Both the looper and CFG make use of RAX for the indirect branch target, so we need to find another way to get the virtual address for the newly loaded module back to JavaScript. Fortunately, upon exiting LoadLibraryExW, RDX also contains a copy of the module address. Therefore, we can tack on one final vfgadget to our object list in order to move RDX back into our counterfeit object memory region. For the final iteration of our loop, we will invoke CBindingURLBlockFilter::SetFilterNotify(), which will copy RDX into the address of our current counterfeit object – 0x88h.

The looper then reaches the end of our list, and returns from the hijacked seal() call transferring control back to our JavaScript code. The first COOP payload has completed, mscoree.dll has been loaded into Edge, and we can now retrieve the base address for mscoree from JavaScript in the code snippet below.  

//Retrieve loadlibrary return val from coop region

var mscoreebase = Read64(pRebasedCOOP.add(0x128));

alert("mscoree.dll loaded at: 0x" + mscoreebase.toString(16));

Hijack #2: Invoking VirtualProtect Wrapper

Having successfully completed our first COOP payload, we can now rebase a second COOP payload to invoke ClrVirtualProtect on the read-only memory region that contains chakra!__guard_dispatch_icall_fptr in order to make it writable. Our objective is to call ClrVirtualProtect(this, chakraPageAddress,0x1000,PAGE_READWRITE,pScratchMemory). This time we will demonstrate a COOP payload that does not make use of a loop or recursion by using a single counterfeit object to populate all arguments and invoke a function pointer. We’ll  use the same invoker vfgadget as before, only this time it is primarily used to move a counterfeit object into rcx. 

We hijack the freeze() virtual method from our original JavascriptNativeIntArray to point to Microsoft::WRL::Details::InvokeHelper::Invoke. This vfgadget will move the this pointer based on the address at this + 0x10, and it will treat this+0x18h as a function pointer. Thus, from our R/W primitive in JavaScript, in addition to hijacking the vtable to call this invoker trampoline function, we also need to overwrite the values of the object + 0x10 and + 0x18.

Write64(objAddr.add(0x10), pCOOPMem2);

Write64(objAddr.add(0x18), EdgeHtmlBase.add(0x2DC540));

Object.freeze(objAddr);

Notice that our fake object will load all the required parameters for ClrVirtualProtect, as well as populate the address of ClrVirtualProtect into rax by resolving index +0x100h from another fake vtable. Upon completion, this will map the desired page in chakra.dll to be writable. 

At this point we are done with COOP, and our last step is to actually disarm CFG for chakra.dll. We can pick any arbitrary address in chakra.dll that contains the instruction jmp rax. Once this is identified, we use our write primitive from JavaScript to overwrite the function pointer for chakra!__guard_dispatch_icall_fptr to point to this address. This has the effect of NOPing the CFG validation routine, and allows us to hijack a chakra vtable from JavaScript to jump anywhere. 

//Change chakra CFG pointer to NOP check

Write64(chakraCFG, guard_disp_icall_nop);

//trigger  hijack to 0x4141414141414141

Object.isFrozen(hijackedObj);

As the WinDbg output below illustrates, with CFG now disabled our hijack was successful and the process crashes when trying to jump to the unmapped address 0x4141414141414141. It’s important to point out that we could have made this hijack jump to anywhere in the process address space due to CFG being disabled. By comparison, with CFG in place an exception would have been thrown since 0x4141414141414141 is not valid in the bitmap, and we would have seen the original CFG routine that we swapped out, ntdll!LdrpDispatchUserCallTargetES, in our call stack.

Conclusion

In this post, I discussed COOP, a novel code-reuse attack proposed in academia, and demonstrated how it can be used to attack modern Control-Flow Integrity implementations, such as Microsoft CFG. Overall, COOP is fairly easy to work with, particularly when breaking up payloads into smaller chains. Piecing together vfgadgets is not unlike the exercise of assembling ROP gadgets. Perhaps the most time consuming portion is finding and labeling candidate vfgadgets of various types within your target process space.

Microsoft’s Control Flow Guard is considered a coarse-grained CFI implementation and is thus more vulnerable to function reuse attacks such as described here. By comparison, fine-grained CFI solutions are able to validate call sites beyond just the target address considering elements such as expected VTable type, validating number of arguments, or even argument types, for a given indirect call. A key tradeoff between the two approaches is performance, as introducing too much complexity into a CFI policy can add significant overhead. Nonetheless, mitigating advanced code-reuse attacks is important moving forward as applications become hardened with some form of forward-edge and backward-edge CFI.

To offset some of the limitations of CFG, Microsoft appears to be focused on diversifying its preventions such as protecting critical call gates like VirtualProtect with export suppression in CFG and Arbitrary Code Guard. However, one important takeaway from this post should be the challenges of designing and enforcing mitigations from user-space. As we saw with EMET a couple of years ago, researchers were able to disarm EMET by reusing code inserted by EMET itself. Further, as was originally demonstrated at BlackHat 2015, here we are similarly taking advantage of critical CFG function pointers residing in user-space to alter the behavior of CFG.

By comparison, Endgame’s HA-CFI solution is implemented and enforced entirely from the kernel and uses hardware features that even if vulnerable to function reuse attacks, make it more difficult to tamper with because of the privilege separation. In the second part of this series, I will discuss the COOP adventures with our own HA-CFI and ongoing research, and how our detection logic evolves to account for advanced function reuse attacks.   

Much to the chagrin of the computer security industry, business executives, and people around the world, ransomware had a banner year in 2016. Hospitals, mass transit systems, hotels, and government offices have all fallen victim to widespread ransomware infections that significantly degraded their capabilities and held their data hostage for significant periods of time. In response, the security community continues to commit significant resources to fight this family of threats, and are beginning to produce some promising results. However, despite these investments and advances, ransomware continues to proliferate and evolve at an accelerating rate, bringing in an estimated $1,000,000,000 in 2016.

While it is difficult to fully predict the evolution of ransomware, a review of recent trends in ransomware, malware, and the computer industry as a whole provides useful insights into what the future may hold, and allow us to better prepare for upcoming advances.

What's New in Ransomware?

As we wrote last year when revealing the existence of a new version of TeslaCrypt, ransomware has expanded to a much broader audience than in previous years. Widespread spam campaigns and drive-by downloads facilitated by exploit kits helped attackers initiate an estimated 638 million ransomware attacks in 2016, a significant increase from an estimated 3.8 million attacks in 2015.

Timeline of the Growth of Ransomware 

Operating System Targets

Though Mac and Linux-based ransomware has been spotted in the wild, a vast majority of ransomware is Windows-based, as it is still the dominant operating system for personal computer end users. Ransomware attackers will continue to primarily target Windows until other operating systems catch up in market share, as the case has always been for malware in general. Mobile ransomware is a potential growing threat, but Apple and Google have largely kept it in check by keeping their operating systems regularly updated and reviewing submissions to their respective application stores.

Ransomware targeted against Internet of Things (IoT) devices is another potential area of growth. Most electronic household appliances now have wireless network connectivity. Juicers, weight scales, fridges, and toilets are among the devices that now offer connectivity and, thus, have the potential to be compromised on your home network. While connectivity may seemingly provide valuable extended functionality, these devices further expand your network footprint and may be more vulnerable to exploitation than your laptops and mobile phones.

 The Satis smart toilet released in Japan in 2013 was found to have an insecure default configuration that potentially allowed for remote access to attackers via a Bluetooth mobile app

So, are we all about to be subjected to a wave of ransomware that prevents you from flushing your toilet? Will ransomware disable your thermostat? Will ransomware burn your toast?

The most likely answer to all of these is... possibly. Ransomware has become so prevalent primarily due to its simplicity: attackers just need their payloads to execute on as many hosts as possible. Since most IoT devices tend to run some flavor of Linux and custom software that is optimized for their specific use case, the expected financial gains currently do not appear to justify the work involved to successfully target these devices. These devices also are not easily targeted in the same manner as ransomware attackers tend to distribute their payloads: spear phishing and drive-by downloads. Additionally, these devices do not typically contain the same type of valuable user data that elicits ransom payments from victims. Nevertheless, these devices are not immune to compromise and tend to be less secure than PCs and mobile platforms due to default security configurations as well as the inconvenience of downloading and applying software security updates. The Mirai botnet in particular demonstrated how susceptible to attack IoT devices are across the world.  Once an attacker successfully derives greater monetary value from deploying ransomware to IoT devices instead of utilizing them as part of a botnet, other copycat attacks could subsequently follow. It is an almost certainty that these devices will continue to be compromised and added to even larger botnets and subsequently leveraged in further distributed denial of service (DDoS) attacks.

Motivations

While monetary compensation is the overwhelming driver for ransomware attacks, the RanRan ransomware family that appears to be perpetuated by political dissidents in the Middle East points to attackers with differing motivations becoming more involved in the creation and use of ransomware. Dissidents and hacktivists looking to spread a message could find an audience through ransomware attacks, especially if they are successful and reported in the media.

Though disk wiping malware is typically associated with efforts to sabotage an organization, there have been recent reports of families of this type of malware now being modified to behave like ransomware by encrypting files and soliciting ransom payments from their victims. This combination of financial and destructive objectives puts the attackers in a unique position: they’re passing on the opportunity to outright destroy the data of their purported enemies in favor of making the data temporarily inaccessible in the hopes of procuring a ransom. As is the case with all ransomware attacks, there’s no guarantee that the perpetrators would make good on their promise in the event a ransom payment is actually made.

Technical Advances and Lower Barrier of Entry

Through our research, we have identified six key trends pertaining to ransomware that helped lead to both advances in capabilities by more skilled and experienced developers as well as the proliferation of ransomware through enabling less sophisticated attackers to become involved in its creation and distribution.

Exploit Kits Dropping Ransomware Payloads

Exploit kits have been around for over a decade, but the attackers leveraging them have started to alter their tactics due to the potential for easy and quick profits. Whereas before the ultimate goal for attackers leveraging an exploit kit would likely be to install botnet software and/or remote access tools (RATs) for spying on users and collecting credentials/personally identifiable information (PII), ransomware is being served up as the intended payload for these kits with increasing frequency. For example, in February 2016, the web site of a hospital in Ontario was hacked and subsequently modified to infect users with a variant of TeslaCrypt via the Angler exploit kit.

As new exploit kits continue to pop up and split off from or replace older kits, attackers will likely continue to use ransomware variants as part of their payloads to maintain a steady revenue stream due to their relative lack of sophistication. If attackers must choose between deploying ransomware and collecting/monetizing credentials and PII, they will likely continue to prefer the more straightforward and quicker attack scenario of ransomware versus the more conservative long con.

Ransomware Kits and Ransomware as a Service

The success of exploit kits and malware as a service has led to equivalent ransomware-based offerings sprouting up. Ransomware kits and ransomware as a service offerings provide an even lower barrier of entry for prospective criminal attackers that want to get started in producing and distributing their own ransomware variants. A subset of users of Microsoft Office 365 were infected in June 2016 with a variant of Cerber, a well known ransomware as a service offering. The developers behind these offerings have gone to great lengths in marketing to potential customers on youtube, and even openly host their own sites.

Official web site of The Rainmaker Labs, developers of Philadelphia and Stampado ransomware

The division of labor between the developers of kits and service offerings and ransomware attackers provides a mutually beneficial arrangement: developers continue to churn out more advanced ransomware while attackers focus on targeting new victims without needing to worry about the inner workings of the ransomware they are distributing. Both parties are also able to maintain their own steady revenue streams: sales of the ransomware keep the developers happy while the attackers collect cryptocurrency ransoms from their victims.

Philadelphia is a notorious Ransomware as a Service offering that has been known to target the healthcare industry, among others

As less sophisticated and technical attackers continue to become involved in the distribution of ransomware, kits and service offerings will likely continue to evolve to meet their needs and enable them to target victims and collect ransoms even more quickly.

Open Source/Educational ransomware

Like other areas within the computer security industry, ransomware has seen its fair share of proof of concept/open source projects that have been published for the public, such as:

• AwesomeWare
• CryptoTrooper (inactive)
• EDA2 (inactive)
• Hidden Tear
• Fileless JavaScript POC
• Mabouia (MacOS)
• ShinoLocker
• Sipher

Though these efforts are meant to further research in the field and provide insight into how ransomware works under the hood, attackers have leveraged these projects to produce their own variants. For these attackers, they already have a fully functional codebase, so only minor changes are required to get their own variants up and running. In March 2016, a variant of the EDA2 open source ransomware project infected users via a link posted on a YouTube video. The availability of these projects in open source channels also provides additional camouflage in terms of attribution.

 ShinoLocker Educational Ransomware Demo Video

As security researchers work to devise more advanced methods for detecting and preventing ransomware, more open source ransomware projects will spring up to provide platforms for generating samples for testing and educational purposes. Ransomware attackers will continue to leverage these open source and educational platforms for their own destructive goals for the foreseeable future.

Offline Ransomware

Ransomware variants that do not require an Internet connection to be fully functional are fairly prevalent. These variants do not require any command and control infrastructure, thus lowering the attacker’s footprint on the Internet and within their victims' networks. Also, since offline ransomware does not require any network functionality, their binaries/codebase can be further condensed and potentially appear less malicious to antivirus and endpoint protection detection mechanisms. A variant of the Dharma offline ransomware family was used to attack a horse racing web site based in India in January 2017.

Below are examples of offline ransomware families that the Endgame TRAP unit has observed throughout extensive testing:

• Cancer
• Chimera
• CryptConsole
• CryptoLocker
• CryptoMix
• CryptoShield
• Crysis
• Dharma
• DirtyDecrypt
• DMALocker
• FakeGlobe
• Fantom
• FireCrypt
• Globe
• GlobeImposter
• Gpcode
• Jigsaw
• Kangaroo
• Koovola
• PowerWare
• RansomPlus
• Rokku
• Sage
• Simple Encoder
• Spora
• TeslaCrypt
• Unlock92
• Xlocker
• Xorist
• Zyka

Though standing up ephemeral network infrastructure is easier than it has ever been thanks to an expanding range of cloud-based offerings, offline ransomware will likely continue to increase in prevalence due to the lack of a need for command and control endpoints.

Fileless Attacks

As malware authors devise new and innovative means for circumventing endpoint protection mechanisms, "fileless" malware has seen an uptick in usage due to its ephemeral nature and ease in both development and deployment. It should come as no surprise, then, that fileless ransomware has gained traction recently. PowerWare and RAA are among the more notable examples of fileless ransomware that have appeared since 2016. In March 2016, an unnamed healthcare organization was the target of an unsuccessful spearphishing campaign that employed PowerWare. These ransomware variants are just as capable as those developed in lower level programming languages and distributed as executables, but they are more easily customizable and portable thanks to their scripting language frameworks.

PowerShell, VBA, JavaScript, and other native Windows scripting languages that play key roles (e.g. downloader, dropper, environment detection) in typical fileless attacks also frequently serve the same purpose in setting up both fileless and typical executable-based ransomware attacks. Until they are routinely detected and prevented by a majority of current AV and endpoint protection products, fileless attacks will continue to serve as key components of ransomware attacks.

Raw Disk Ransomware

Though it is not a new threat, ransomware that encrypts, replaces, or degrades individual disk drive sectors (rather than or in addition to individual files) such as the Master Boot Record (MBR) or the Master File Table (MFT) did not see much use until 2016. Most ransomware variants target user documents (e.g. DOC, PDF, XLS) while avoiding system critical executable files (e.g. EXE, DLL, SYS)  to keep the operating system stable and semi-operational. This allows victims to properly assess the damage and subsequently pay their ransom in order to retrieve their files.

 Petya Bootloader Red Screen of Death

With ransomware variants that target disk drive sectors, such pleasantries are not possible. If the startup disk drive is successfully targeted by one of these variants, users will likely be unable to even properly access the operating system, as the ransomware will have replaced the startup routine contained within the MBR with their own custom bootloader. These bootloaders will simply display a ransom note and prevent the user from proceeding further. A variant of the HDDCryptor raw disk ransomware family was used in the attack on the San Francisco Municipal Transportation Agency in late November 2016.

Petya Ransomware Ransom Note and Instructions

The following ransomware families that target raw disk drive sectors all were discovered in 2016:

• HDDCryptor/Mamba (January 2016)

• Petya (March 2016)

• Satana (June 2016)

These types of ransomware variants are potentially much more catastrophic to end users than typical file-based encryption ransomware since they have fewer options for potentially remediating the attack (e.g. volume shadow copies, network or external media-based file backups). Since the operating system has likely been overwritten and encrypted, users are left to assume that none of their files are recoverable. Depending on the success of these variants in soliciting ransom payments from their victims, ransomware attackers may develop advancements in an effort to further infect hard disk drives, the system BIOS, and other low level system components.

Conclusion

Unfortunately, ransomware does not appear to be going away anytime soon. As long as the risk to reward ratio remains in favor of ransomware, we are likely to see continued growth and creativity from its developers and attackers. In order to protect themselves from the effects of ransomware, users are highly encouraged to secure their hosts with a fully featured endpoint security product and maintain regular offline backups of their most important documents that may be susceptible to loss during ransomware attacks.

As for what to expect, there likely will be further developments in ransomware for MacOS, Linux, mobile platforms, and possibly IoT devices. Exploit kits, ransomware kits, ransomware as a service offerings, and open source ransomware will continue to be leveraged by less sophisticated attackers and help them grow their budding criminal enterprises. Fileless ransomware will see more usage as attackers attempt to evade endpoint protection mechanisms. Offline ransomware will continue to be used by attackers wishing to minimize their footprint. And last, but certainly not least, expect to see more advanced ransomware that targets the MBR, MFT, and other raw disk drive sectors. In the coming weeks, I'll have a follow-on post to walk through how the Endgame research team is addressing these advances in ransomware. Stay tuned!

At least as early as February, France’s intelligence agency warned that Russia aimed to influence the presidential elections in favor of Front National candidate, Marine LePen. Throughout the spring, there already were indications of bots and false amplifiers spreading disinformation about Emmanuel Macron. Election watchers braced for some sort of data dump to dramatically influence the election. But it never came. Then, just 48 hours prior to the election, and just an hour before France’s media outage, Macron’s campaign reported a 9GB breach, with Russia as the main suspect. While this cyber attack has garnered the most attention, it is important to highlight that data breaches are just one component of Russia’s multi-pronged information security strategy. Information operations comprise more than just a cyber attack, and equating the two has been detrimental to defenses and response strategies. A brief summary of the influence operations targeting Macron’s campaign in the lead up to the French elections, and the data dump this weekend, provides a useful case study as targeted cyber attacks and influence operations threaten to destablize democracies across the globe.

Information Operations != A Hack

Influencing an election and hacking a campaign can be similar but different, and this difference is important as it impacts how organizations prepare their defenses. Definitions could add great clarity, and are essential well beyond wonky semantic debates on the Hill. Facebook’s recent paper on information operations is a very useful starting point, and defines (page 5) information operations as, “Actions taken by governments or organized non-state actors to distort domestic or foreign political sentiment, most frequently to achieve a strategic and/or geopolitical outcome. These operations can use a combination of methods, such as false news, disinformation, or networks of fake accounts (false amplifiers) aimed at manipulating public opinion.”  The only reference to hacking is account hacking, and the authors avoid semantic laziness by providing the concrete parameters of the various aspects of influence operations, additionally defining false news, false amplifiers, and disinformation. With its large role as a social media platform, Facebook is in a unique position to help provide clarity to a broader audience, which is desperately needed.

Facebook’s taxonomy is also fairly consistent with the U.S. military doctrine, which views cyberspace as a domain within the information environment, and cyberspace operations are just one of many information-related capabilities to achieve the desired objective. Cyberspace increasingly is the medium in which information operations occurs. When it comes to cyber attacks, the National Institute for Standards and Technology defines a cyber attack as, “An attack, via cyberspace, targeting an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information.” These are useful distinctions when looking at the nuanced and varied objectives of adversaries.

Information operations are multi-faceted efforts to influence, and similarly attackers possess a range of objectives when conducting cyber attacks. At times they are mutually exclusive, such as when IP theft occurs for espionage (cyber attack, but not an information operation), or when bots spread disinformation (information operation without a cyber attack). Since the United States presidential election, there continues to be a constant flow of reports and articles decrying election hacking. Most of these reports conflate information operations and cyber attacks. There has yet to be evidence of tampering of any voting devices, but there were the infamous compromises of DNC and DCCC emails, which does constitute a cyber attack. Most also agree that Russia did attempt to influence the US presidential election, just as they had done previously elsewhere, as part of an information operations campaign.

Unfortunately, when discussing current events, these semantic nuances are lumped together for simplicity, confounding a broad range of information operations activities as ‘hack’. This not only perpetuates theoretical underdevelopment within the community, but it hinders advancements in defenses and incident response planning. It also impacts policies, which in the United States at least, are often several decades old and could greatly benefit from modernization.

Modus Operandi for Information Operations

How do the various aspects of information operations work together and what role do cyber attacks play? The French election provides a useful heuristic to explore some of the key aspects of multi-faceted information operations campaigns, such as those linked to Russia.

Cyber Attacks

For months prior to the election, Macron had been accusing Russia of attempting to compromise his campaign, but never provided evidence. Understanding that his pro-EU stance made him a likely target of Russian information operations, Macron’s campaign took information security seriously and remained on high alert. In late April, a Trend Micro report described how a Russian group (they dub Pawn Storm, aka APT 28, Fancy Bear and several other alias) created fake websites to harvest credentials. Macron’s digital chief confirmed the attempted intrusions, but also that they were thwarted. Just over a week later, and within hours of the election, Macron’s campaign confirmed a massive breach of internal communications. Targeted attacks such as this for data exfiltration, destruction, or a number of other objectives are only increasing.

Bots as False Amplifiers

For information operations, the computer attacks alone are generally not sufficient if they do not reach a broad audience. By one estimate, over this past weekend, 40% of #MacronGate tweets were produced by 5% of the accounts. #MacronLeaks reached 47,000 retweets in the first three hours following news of the hack. This amplification online helped move the meme from the United States to France, which, by law, was entering a moratorium on commentary on the French election. Even before the hack, Macron was targeted by social bots. The Digital Forensic Research Lab articulated how Russia was using bots as false amplifiers against the Macron campaign, greatly expanding the reach of the French-language version of Russian state-sponsored news outlets Sputnik and Russia Today. According to their analysis, this amplification is not an anomaly, but has persisted for at least six months.

False News & Disinformation

Disinformation campaigns are nothing new. However, thanks to bots, social media, and the apparent appeal of clickbait, false news and disinformation are reaching a broader audience and finding more success in today’s tech and social environment. For instance, Sputnik’s French-language version, under the auspices of fair reporting, repeatedly published biased reporting against Macron or in favor of LePen. RT and Sputnik ramped up negative coverage of Macron as the race drew closer, including unsupported allegations against his personal life and portraying him as an agent for the US banks. Finally, following the final presidential debate, Macron filed a lawsuit against the false information presented by LePen during the debate. She failed to provide any evidence, and demonstrates that as the respective parties and their leadership reiterate false information and treat it as a truism, it increasingly becomes accepted.

Preparing for Targeted Attacks

How organizations prepare for and respond to targeted attacks can greatly impact the extent of the damage. Understanding the attacker, and their objectives, is a first step as there are often lessons learned to help inform a baseline defense. For instance, the French broadcasting company, TV5Monde, was almost destroyed in 2015 by a digital attack. First attributed to ISIS, a Russian group (the same APT 28) has been linked to the highly targeted attack that included wiper malware to destroy the company’s systems. Moreover, lessons learned from Russian information operations during the U.S. elections also served as a guidepost as to how they combine cyber attacks, bots and false information. Organizations - especially political campaigns - must be aware that targeted attacks are going to compromise eventually and be prepared to remediate through both technical response as well as public relations (for the private sector) or policy (for the public sector) responses.

With that back drop in mind, the French government and the Macron campaign both remained on heightened alert throughout the election. From suspending overseas electronic voting to Macron’s preemptive warnings that his campaign was under attack, the French public was well-aware of the chances of a data breach, as well as wary of the intent of the attackers. The media also adhered to a blackout, limiting the reporting of the data dump that has been perceived as nothing (to date) out of the ordinary. As for the Macron campaign itself, they were well aware of the spearphishing approach and fake websites established to harvest credentials, and extremely confidential information was not sent via email. As the eleventh hour data dump illustrates, targeted attackers eventually find a way in, and thus remediation must also be in place. This may have even included planting false documents, about which more information is likely to emerge confirming or refuting this speculation.

For campaigns and governments, modernization of outdated policies is essential to tackle the range of cyber attacks and information operations. Following the compromise of emails, the French electoral commission noted that the dissemination of that information is liable to classification as a criminal offense, which also helped contain the information to less respected sources. Current President François Hollande also vowed a response to the attack, but has yet to clarify what that may entail. Macron similarly vowed retaliation, and his foreign policy advisor warned, “We will have a doctrine of retaliation when it comes to Russian cyberattacks or any other kind of attacks." It will be important to keep an eye on how French policy evolves, and if there are lessons learned as Britain and Germany gear up for elections later this year.

Earlier this year, we announced Artemis, Endgame’s chat interface to facilitate and expedite complex analyses and detection and response within networks. Bots have been all the rage over the last few years, but had yet to make a splash in security. On the one hand, tech trends come and go and it is essential to refrain from jumping on the latest fad and avoid forcing the wrong solution onto a specific problem. At the same time, we could see the value in leveraging natural language processing in a conversational interface to reimagine search and discovery. And so we started on our journey into security bots. In this first of two posts, we’ll walk through our research problem and use case, the lessons learned as we dug deep into bot research, and the challenges with implementing a paradigm change in the way analysts and operators are accustomed to interacting with data. I mean we’re talking about a glorified chatbot, right? How hard can this be? Surely it wouldn’t require design discussions with engineering, product, data science, front end, UX, and technical writers...

Our Challenge

As data scientists working in security, we are well aware of the ever-growing data challenges, and the complaints of those analysts who are forced to find creative ways to circumvent the clunkiness of their current toolset. Their current workflow is manually-intensive, and any automation requires scripting or programming knowledge. They needed a way to help automate some of the rote processes, while integrating analytics such as anomaly detection that take too long to be operationally impactful. Often, when analysts are provided tools that help in this area, they either don’t fit the workflow, require learning some kind of proprietary language. In some cases, the tools actually make life harder, not easier, for the analysts.

Even if the automation challenge is overcome, most security teams still lack resources to stay apace of the growing challenges from the data and threat environments. This lack of resources crosses over into three distinct areas - time, money, and personnel. It is no secret that, on average, the time to discovery and detection of an attack lags significantly behind the time it takes for an attacker to achieve his or her objective. Consider the OPM breach, where the attackers had access to US personnel data for over a year before discovery.  Unfortunately, most security teams lack the personnel and funding to shorten this gap.

Finally, while other tech industries have embraced and prioritized user experience for their broad and diverse user base, the security industry continues to make tools for themselves. They generally require a level of expertise that simply exceeds the talent pipeline, which simultaneously also detracts many from entering the field.

It is against this backdrop that we started to explore a solution that addresses these three core challenges security teams encounter:

• Insufficient resources

• Lack of automated tools

• Usability of security platforms

Why Build A Bot?

We explored different ways to augment our users’ ability to tackle these three challenges by focusing on enhancing their ability to discover and remediate alerts. This remains a core pain point, with alert fatigue and false positives impeding their workflow. We wanted a solution that provided analysts an interface to ask questions of their data, automate collection, and bring back only the relevant information from an endpoint. When exploring our solution, we had two primary users to consider: Tier 1 and Tier 3 analysts.

As the graphic above illustrates, even though these individuals work together as a part of a security team, their workflows could not be more different. But maybe, if done correctly, we could augment Tier 1 analysts while providing Tier 3s a non-obtrusive (and even helpful!) interface for their day-to-day. Our solution: An intelligent assistant or a chatbot.

A bot allowed us to build a service that leverages natural language processing to determine user intentions and help automate workflows. By mimicking conversation, we could provide users an interface that allowed them to be as expressive or as curt as they want as they inquire about everything from alerts to endpoint data.

Rule #1 in Bot Design: Manage Expectations

When we pitched the idea to our team we were mindful of tossing around words like Artificial Intelligence. After all, we weren’t building JARVIS from Iron Man and at no point was Scarlett Johansson going to starting talking to SOC analysts about the latest network threats. Moreover, we emphasized that this feature would not be the abrasive hell that was MS Clippy.  Instead we kept it simple. We posited that a simple conversational interface could encourage users to dig deep into endpoint data by eliminating the need for query syntaxes or complex click through user interfaces. It cannot be overstated that managing expectations was paramount to get the project off the ground. Once we were given the go-ahead a bigger question arose… “How are we going to build this thing?”

Challenges with Open Source Bots

The rise of bots and intelligent assistants is largely due to an increase in Bot Development Kits or BDKs. Companies like Wit.ai (acquired by Facebook), API.ai (acquired by Google) and Chatfuel provide a simple UI for the development of closed-domain, rule-based, goal-oriented bots where no real programming skills are required to successfully launch a bot. In addition, Microsoft and Amazon have released their own dev kits to allow users to quickly get an app integrated into their platforms. These various kits are treasure troves of knowledge on how best to build a bot to suit your needs. We would have loved to use any single one of them, but we were trying to provide a bot within our EDR Platform to interact with complex endpoint data, using a diverse and industry-targeted vocabulary none of these frameworks currently supported.

For instance, large companies have generally focused on building general assistant bots and deploying them on third-party platforms like Slack or Facebook Messenger. Our assistant had to be structured to enable users in a SOC to perform their duties safe and efficiently on our platform, making it impossible to use a third party bot kit service.  The specificity of the security domain meant that we often weren’t working with just translating buttons from a form into a bot.  Instead the entities (an NLP term we’ll dive into in the next post) we extract are often semistructured at best, and the intents are as varied as “find bad things” to “pull memory from this running process with PID 4231”.

After reviewing the current state-of-the-art it was clear we had our work cut out for us. Where and how do we acquire the dialog data necessary to build our bot? How can we account for and properly capture the diversity in vocabulary across the information security domain? How can we build a tool that helps train Tier 1 analysts while preventing Tier 3 analysts from being shackled by rigid, scripted routines. It was on us to figure out what makes a bot tick and then implement it ourselves.

Designing Artemis

The engine for Artemis needed to fulfill certain design goals.  For starters, bot architectures can be rule-based or driven by machine learning, and is primarily dependent on the amount of training data at your disposal. The goal is to produce a dialog tree similar to the one pictured below that is designed to complete a task. Each branch of the tree represents a question a user must answer to progress to the next node or state.

To move toward this functionality, the bot needs to handle missing values for a given intent.  For example a user might like to search for a process by name or PID to find if a specific piece of unwanted software is running on multiple endpoints. The user might write “find processes with the name svchost.exe on all endpoints” or “search processes on all endpoints”.  In the second example, the intent classifier can classify “search processes” as a ‘search_process’ intent and then note that the intent contains an ordered list of required and wanted values. When Artemis is faced with a known intent and a lack of needed values, it simply asks the user to enter the missing value.  Simple, but it works.

In addition to handling missing entities, some intents require multiple values in a single user input, such as username, process and endpoint. Some values a user enters can be recognized by a pattern-matching grammar, but some value types are hard to tell apart from one another.  The best we can hope for here is disambiguation.  So within a certain context “Admin” is likely a user name, but it may also be a file name.  In this case, Artemis will propose one based on context and offer the opportunity to change its interpretation to file name.

Another finer point of implementing dialog systems, explored in detail in this Microsoft Research paper is implicit confirmation.  Once done entering in the query string of the search, the user shouldn’t be forced to tell Artemis to continue to the endpoint selection.  Instead, Artemis must implicitly confirm the query string choice and move the user towards the endpoint selection and execution of the operation. Although this may seem obvious, early draft designs of Artemis left the user in limbo. After entering one entity, the bot would reply that it “got it” but then wouldn’t move to the next.

This is why our development occurred so closer with both practitioners and our user experience team to ensure we account for as many of these ‘gotchas’ as possible. We took the wide-range of subject matter expertise at Endgame: incident responders, hunters, designers, and malware analysts, and built custom workflows and recommendations on what to do next during an investigation.

Next Steps

Having explored the state-of-the-art in bots, properly scoped our requirements, and integrated subject matter and design expertise, we were ready to finally throw some data science at it and make Artemis a reality. But before we could provide anything useful, we first had to teach Artemis to understand what the end user typed in the window. No. Easy. Task. In our next post, we’ll get into the technical details of our natural language processing (NLP) approach, including the basic tenets of NLP that are relevant to bots and the necessity to coordinate with user experience designers to truly address our user’s key pain points. Combining user-centric design with our natural language understanding pipeline proved to be the essential factor in delivering cutting edge data science capabilities within our user-friendly platform.

Three of the most prominent attack trends in cybersecurity converged today: ransomware attacks, data dumps of nation-state offensive capabilities, and an emergence of the healthcare industry as a leading victim of cyber attacks. The confluence of these trends resulted in a wide-scale ransomware attack that to date has already hit over 70,000 computers in almost 100 countries. These numbers are likely to grow. Most notably, sixteen hospitals in the United Kingdom were locked down today, disrupting or cancelling the majority of services.  The ransomware also impacted several large companies in Spain, including Telefonica, but did not disrupt customer service as it was limited to their internal network.

The attack deployed an exploit called Eternal Blue, which exploits a known Windows vulnerability that was secured in March 2017 by MS17-010. This was recently released in a Shadow Brokers data dump. While it is not yet known who is behind this ransomware attack, it is indicative of the increasing (usually inadvertent) ‘tech transfer’ of nation-state capabilities to other groups. Given the ongoing impact of this ransomware attack, we immediately tested our platform against it. Let’s walk through some details of the ransomware, our layered prevention approach, and how 2017 already seems to be overshadowing 2016 with the continued sophistication and reach of ransomware.

Layered Prevention

This WCry ransomware (aka several names, including WanaCryptor and WannaCry), responsible for today’s widespread attack provides a harsh lesson in properly securing systems.  This is a two part problem: lack of proper patching and the continued use of old, insecure versions of Windows, especially in critical infrastructure.  The exposure of so many systems to the MS17-010 vulnerability has enabled this ransomware to propagate rapidly.  Patches should have been applied when the patch was released and especially when it became clear that the Shadow Brokers exploit was mitigated by the patch.   But, some couldn’t patch.  Microsoft, for perfectly reasonable business reasons, no longer supports legacy OS versions, most notably XP.  Sadly, these versions are still in production on millions of computers globally.  Microsoft took the unusual (and necessary) step of providing a patch against MS17-010 the evening this attack broke out.  Organizations who didn’t or couldn’t patch before should be urgently scrambling to patch now.  

As this ransomware attack demonstrates, patch management too often is insufficient.  This occurs for numerous reasons, including concerns over disruption to business processes, difficulty maintaining an accurate inventory of assets, or, as mentioned above, a perceived or real need to keep legacy systems in production. Because of this, defenses must be in place which can reliably and consistently block a wide range of attacks, including those which can take advantage of a new vulnerability and spread rapidly such as this one. A layered prevention approach protects enterprises from ransomware and other forms of targeted attacks.  Organizations need effective defenses against exploitation, malware and fileless attacks, and malicious behaviors all operating in parallel.  In addition, these layers must be effective in detecting never-before-seen attacks.  As we’ve seen time and time again, signature-based defenses can’t compete against motivated and sophisticated attackers. This reality forms the foundation of Endgame’s zero-breach tolerance approach to defending customer networks.  

Preventing the Attack

Traditional signature-based AVs are generally ineffective against novel, emergent attacks such as this one.  Financially-motivated attackers know this and operate accordingly. The WCry dropper file (24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c) was not broadly detected by antivirus programs the morning of May 12 when the outbreak began to spread.  This surely played a role in its “success” from the view of the adversary.  

However, Endgame’s MalwareScore™, and its machine-learning based approach to detection, can stop this attack in its tracks. With MalwareScore™, prevention is in place with no prior knowledge of the WCry malware itself, protecting customers at the outset of the attack. Always wary of exaggerated claims about how AI and machine learning can solve every security problem in the industry, we know machine-learning itself is not a silver bullet. But when applied correctly, it is a powerful tool for the defender to battle widespread attacks such as today’s ransomware attack.

Why does machine learning do better in detecting new, never-before-seen malware? Machine learning is better at generalizing at scale than humans. Computers are very good at finding small distinguishing patterns across millions of malware samples and then recognizing those patterns in unknown samples. These patterns are analogous to human-derived signatures, except that they apply to far more samples than a signature for a particular sample, allowing a classifier to better predict new malware. As the image below demonstrates, MalwareScore™ successfully detected WCry. Endgame’s core engine is available in VirusTotal if you want to test it out for yourself.

Malware Prevention End User Popup Notification for the WCry dropper

However, no malware detection capability is perfect.  If anyone tells you they will detect all current and future malware through machine learning alone, they are lying.  This is why layered preventions are important.  So what if this particular dropper or follow-on files don’t get stopped by your malware defenses?   

If allowed to run, the dropper will write multiple files to disk and execute the ransomware encryptor functionality under two separate contexts: one as a child process to a command shell running under services.exe and another as a child process of the dropper under Windows Explorer.

WCry Dropper Process Tree

WCry Service Process Tree

On systems where malware prevention is not enabled, or if a variant emerged which is in the 1% of malware not detected by MalwareScore™, Endgame’s ransomware protection feature is in place to stop ransomware attacks.  This feature, which we will describe in detail in an upcoming post, monitors dozens of aspects of all system processes in real-time.  Very shortly after ransomware activity kicks off, threads associated with the ransomware activity are suspended, protecting critical data on customer machines.

We tested this on a machine protected by Endgame with MalwareScore™ prevention turned off.  As expected, our ransomware prevention feature detects the malicious activity immediately after it begins.  Critical data on these systems is protected.

Ransomware Protection End User Popup Notification for WCry

Conclusion

Over the following days and weeks, we are likely to better grasp the extent and impact of WCry, which has spread outside of Europe and into Asia as of this writing. These kinds of targeted and widespread attacks can be very lucrative, and until that changes, they are likely to become more common as well.  Layered behavioral preventions are necessary to stop these ransomware attacks, and modern attacks in general which are increasingly targeted.  They are especially necessary to stop the sort of attack we see unfold today within the UK NHS and elsewhere.  This particular attack has been enabled by an unfortunate proliferation of suspected nation-state level capabilities combined with poor patching practices.  As this worm propagation continues, keep in mind that the payload of this attack is preventable with the right defenses.  

Note: This was updated on May 13th. At this time, the ransomware has propagated to almost 100 countries, including 45 hospitals in the UK alone.

As we discussed Friday when this outbreak began, the WCry or WanaCrypt0r ransomware spread quickly across Europe and Asia, impacting almost 100 countries and disrupting or closing 45 hospitals in the UK. As the ransomware continued to propagate, I got my hands on a sample and quickly began analyzing the malware. This post will walk through my findings and provide a technical overview of the strain of WCry ransomware which caused the massive impact on Friday.  Many have done great work analyzing this malware in action and helping contain its spread, and I hope my comprehensive static analysis will provide a good overall picture of this particular ransomware variant on top of that.

The Note

With estimates over 100,000 computers impacted globally thus far, many people received unwelcome notes Friday similar to those below demanding a fee to decrypt their files. Notes like these are unfortunately all too common and typical of today’s ransomware.  While the notes promise to return the data, it’s not guaranteed that paying the ransom will return data safe and sound, but if it gets this far and adequate backups are not in place, it may be the only recourse the victim has.  No one ever wants to see one of these.

Ransom Note

Ransom Note Desktop Background

Where to Begin?

There has been a lot of discussion about the method of propagation and the overall impact of this ransomware, but what does this ransomware actually do from start to finish?  That is the question I’ll answer in this post.

To begin, we accessed the malware by grabbing it (SHA256 24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c/MD5 Db349b97c37d22f5ea1d1841e3c89eb4 ) from VirusTotal. See the appendix  for a  summary of the files dropped with the malware.

Dropper Malware Details

MD5: Db349b97c37d22f5ea1d1841e3c89eb4 

Dropped EXE Details

MD5: 84c82835a5d21bbcf75a61706d8ab549

The WCry Execution Flow

The WCry ransomware follows a flow similar to that of other ransomware as it damages a machine.  The high level flow is as follows:  It begins with an initial beacon, other researchers have already reported is basically a killswitch function.  If it makes it past that step, then it looks to exploit the ETERNALBLUE/MS17-010 vulnerability and propagate to other hosts.  WCry then goes to work doing damage to the system, first laying the foundations for doing the damage and getting paid for recovery, and once that’s done, WCry starts encrypting files on the system.  See the diagram below for an overview of how this malware works.  I’ll walk through each of these steps in more detail below.  

As the graphic illustrates, the malware inflicts damage by executing a series of tasks. I’ll walk through each of these tasks, which are numbered below. Each first level of the outline corresponds to that step in the execution flow graphic.

Initial infection and propagation

1. Beacon to hxxp://www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com. Successful connection will cause the malware to quit.  Note that other researchers have reported seeing strains since Friday which have an alternate killswitch URL.  

2. Run the resource Exe as a new service

    a. If Command line args as “-m security”

        1. OpenSCmanager

        2. Create a new service called "Microsoft Security Center (2.0) Service”; “mssecsvc2.0" as mssecsvc.exe

        3. StartService

        4. Load Resource “tasksche.exe”

        5. Save as C:\\WINDOWS\\tasksche.exe

        6. Move C:\\WINDOWS\\tasksche.exe to C:\\WINDOWS\\qeriuwjhrf

    b. Else Propagate via SMB ETERNAL BLUE / DOUBLE PULSAR Exploit

        1. OpenSCManager

        2. Access service “mssecsvc2.0"

        3. Change Service Config

        4. Start Service Crtl Dispatcher (Run SMB Exploit)

            a. Run thread containing the Payload transfer

Setting up the payload

            b. GetAdaptersInfo to get IPs

            c. New thread to propagate the payload

Payload Delivery

                1. Get TCP Socket for Port 445 (Server Message Block/SMB)
                2. Connect to SMB Socket and get SMB tree_id

                    a. SMB_COM_NEGOTIATE
                    b. Get Tree: ipc_share = "\\\\#{ip}\\IPC$” and SMB_COM_TREE_CONNECT_ANDX
                    c. SMB_COM_TRANSACTION

Example Pseudocode: The screenshot above is from the Metasploit Framework's implementation created after the Shadow Broker's leaks and recent weaponized exploit from RiskSense-Ops.

                3. Run smb ms17-010 Exploit function
                    a. do_smb_ms17_010_probe(tree_id)

                        1. Setup SMB_TRANS_PKT

                    b. If vulnerable, do_smb_doublepulsar_probe(tree_id)
                        1. Prepare Base64 Payload in Memory
                        2. Setup SMBv1 Echo Packet
                        3. make_smb_trans2_doublepulsar

                            a. Setup SMB_TRANS2_PKT (See Appendix)
                        4. if code == 0x51: Successful payload
                    c. Execute Payload Shellcode (See Appendix)

If code == 0x51 - successful payload!!!

    c. After Service execution

        1. Gets the computer name
        2. Randomizes string
        3. Get command line args and Checks for switch “/i”

Preparation for Ransomware Activity

3. Extract ZIp and Prep Tor and Bitcoin Info:

    a. Extract resource zip file XIA with hardcoded password “WNcry@2ol7”
    b. Get c.wnry, which includes the Tor configuration used by the malware used by the malware
    c. Extract the configuration from c.wnry to get the Tor browser and onion sites to be used for communication and onion sites to be used for communication:

gx7ekbenv2riucmf.onion;

57g7spgrzlojinas.onion;

xxlvbrloxvriy2c5.onion;

76jdd2ir2embyv47.onion;

cwwnhwhlz52maqm7.onion;

hxxps://dist[.]torproject[.]org/torbrowser/6.5.1/tor-win32-0.2.9.10.zip

    d. Load Bitcoin wallets which have been previously set up by the attackers for payment for file restoration and update c.wnry

“13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94”

“12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw"

“115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn"

4. Hide Extract Zip Directory and Modify Security Descriptors

    a. Create process: Runs command to hide current directory: "attrib +h . “
    b. Runs command: icacls . /grant Everyone:F /T /C /Q.  This grants all users full access to files in the current directory and all directories below.

5. Prep Encryption Public Key, AES Key, Decrypt the DLL

    a. Load exports with getprocaddress: CreateFileW, WriteFile, ReadFile, MoveFileW, MoveFileExW, DeleteFileW, CloseHandle
    b. Set up Encryption Keys

        1. SetUp Cypto function exports: CryptGenKey, CryptDecrypt, CryptEncrypt, CryptDestroyKey, CryptImportKey, CryptAcquireContextA
        2. Get RSA_AES Cryptographic Provider
        3. CryptImportKey import the hard coded public key

BOOL WINAPI CryptImportKey(

 _In_  HCRYPTPROV hProv,

 _In_  BYTE *pbData,

 _In_  DWORD dwDataLen, 1172B 2048 bit RSA key (See Appendix)

 _In_  HCRYPTKEY  hPubKey,

 _In_  DWORD dwFlags,

 _Out_ HCRYPTKEY  *phKey

);

        3. Parse t.wnry to get AES key used to decrypt the DLL key used to decrypt the DLL
            a. WANACRY! Length 8
            b. Read Length 100h = Encrypted AES Key
            c. Read 4h = 04 00 00 00
            d. Read 8h DLL Length = 00 00 01 00 00 00 00 00
            e. Decrypt Encrypted AES Key with Public Key
            f. Read encrypted DLL length 1000h
            g. Decrypt DLL with custom AES-128-CBC algorithm with 16B AES Key (See Appendix)
        4. Get Native System Info and GetProcessHeap

        5. Put EncryptedData In Heap Location
        6. Change the protection of that memory location.

Encrypted DLL Details

96de5f0587f7201b9f5f16ba2e374f80

Spoofed information the decrypted DLL’s VERSIONINFO resource

6. Run DLL Export at function TaskStart

7. Creates Encryption Keys to be used by the user file encryption routine

a. Create Encryption Key by Encrypting the user’’s private key with the ransomware public key and stored in  “%08X.eky” (See Appendix)
b. Also tries to access “%08X.dky” for the received Decryption key

8. Creates Mutex for all threads: Global\\MsWinZonesCacheCounterMutexW

a. Other researchers have noted that if this mutex is present, the malware will not start, offering another way to defend against this malware.

9. Creates a new thread pointing to the setup that starts encrypting files

a. Generates AES Keys to encrypt files using CryptGenKey

Encryption routine

10. Creates a new thread to overwrite files on disk

a. Generate a key
b. Generate Data Buffers for each file
c. Call thread for function StartAddress to begin writing encrypting file contents
d. Tack on extension ".WNCRYT”

11. Run new process taskdl.exe in a new thread

12. Set Up the Decrypter Persistence:

a. Read Configuration File
b. Finds the location of @WanaDecryptor@.exe
c. Create process "taskse.exe @WanaDecryptor@.exe”
d. Set persistence key to run itself on reboot HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
e. CheckTokenMembership, GetComputerName Info
f. Run: cmd.exe /c reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” /v "<rand>" /t REG_SZ /d “\"tasksche.exe\"" /f
g. Looks for “f.wnry" (what this is for is not clear in my analysis)

@WanaDecryptor@.exe Details

MD5: 7bf2b57f2a205768755c07f238fb32cc

Spoofed information the decrypted DLL’s VERSIONINFO resource 

13. Runs: @WanaDecryptor@.exe fi

a. Reads config file for Tor Client
b. Runs Tor Client.  Note that I did not drill into the communications deeply during this analysis.  It’s basically connecting to the .onion sites listed above to allow for user payment and tracking. 

14. Creates @WanaDecryptor@.exe persistence and backup

a. Creates lnk file @WanaDecryptor@.exe.lnk via batch script

@echo off
echo SET ow = WScript.CreateObject("WScript.Shell")> m.vbs
echo SET om = ow.CreateShortcut(“@WanaDecryptor@.exe.lnk")>> m.vbs
echo om.TargetPath = "@WanaDecryptor@.exe">> m.vbs
echo om.Save>> m.vbs
cscript.exe  //nologo m.vbs
del m.vbs

b. Write to <randominteger>.bat

1. Execute batch script
2. Delete: del /a %%0

15. Creates Ransom Notes @Please_Read_Me@.txt from “r.wnry"
16. Encrypts files, kills /database and email server-related processes if they are running

a. Capture UserName
b. Get Drive Type
c. Runs:

taskkill.exe /f /im Microsoft.Exchange.*

taskkill.exe /f /im MSExchange*

taskkill.exe /f /im sqlserver.exe

taskkill.exe /f /im sqlwriter.exe

taskkill.exe /f /im mysqld.exe

d. Check Free Disk Space
e. Loops through files and encrypts (see appendix for the targeted extensions) and encrypts (See Appendix for the targeted extensions)

17. Runs: @WanaDecryptor@.exe co

a. Writes to .res file compiled by the time decrypted

b. Writes to .res file compiled by the time decrypted

c. Run Tor service: taskhsvc.exe TaskData\Tor\taskhsvc.exe

18. Runs: cmd.exe /c start /b @WanaDecryptor@.exe vs

a. Deletes the volume shadow copies with the command: Cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete &  bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet with the command: Cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete &  bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

Conclusion

Despite its ability to propagate so quickly, the ransomware activities taken by this malware are not particularly interesting or novel.  As I demonstrated in this malware, the killswitch in the execution flow provided a unique opportunity to slow down the ransomware. As security researcher MalwareTech discovered, and Talos described in detail, this malware was programmed to bail out upon a successful connection to that server, which stops the malware altogether.  We should all thank MalwareTech for setting up the sinkhole, which caused this outbreak to slow sooner than it otherwise would have.  

This malware is easy to modify.  As mentioned above, other researchers are already finding variants in the wild.  If you’re running Windows and haven’t patched yet, now’s the time to do it. And while you’re at it, go test your backups to build some confidence that you won’t be forced to choose between paying up or losing data should the worst happen to you or your organization.

Appendix

Summary of Files

Zip File (b576ada...31) Contents

Extensions to encrypt

.doc,.docx,.docb,.docm,.dot,.dotm,.dotx,.xls,.xlsx,.xlsm,.xlsb,.xlw,.xlt,.xlm,.xlc,.xltx,.xltm,.ppt,.pptx,.pptm,.pot,.pps,.ppsm,.ppsx,.ppam,.potx,.potm,.pst,.ost,.msg,.eml,.edb,.vsd,.vsdx,.txt,.csv,.rtf,.123,.wks,.wk1,.pdf,.dwg,.onetoc2,.snt,.hwp,.602,.sxi,.sti,.sldx,.sldm,.sldm,.vdi,.vmdk,.vmx,.gpg,.aes,.ARC,.PAQ,.bz2,.tbk,.bak,.tar,.tgz,.gz,.7z,.rar,.zip,.backup,.iso,.vcd,.jpeg,.jpg,.bmp,.png,.gif,.raw,.cgm,.tif,.tiff,.nef,.psd,.ai,.svg,.djvu,.m4u,.m3u,.mid,.wma,.flv,.3g2,.mkv,.3gp,.mp4,.mov,.avi,.asf,.mpeg,.vob,.mpg,.wmv,.fla,.swf,.wav,.mp3,.sh,.class,.jar,.java,.rb,.asp,.php,.jsp,.brd,.sch,.dch,.dip,.pl,.vb,.vbs,.ps1,.bat,.cmd,.js,.asm,.h,.pas,.cpp,.c,.cs,.suo,.sln,.ldf,.mdf,.ibd,.myi,.myd,.frm,.odb,.dbf,.db,.mdb,.accdb,.sql,.sqlitedb,.sqlite3,.asc,.lay6,.lay,.mml,.sxm,.otg,.odg,.uop,.std,.sxd,.otp,.odp,.wb2,.slk,.dif,.stc,.sxc,.ots,.ods,.3dm,.max,.3ds,.uot,.stw,.sxw,.ott,.odt,.pem,.p12,.csr,.crt,.key,.pfx,.der 

Public RSA2 Key to Decrypt AES Key (Converted to Base64 for Display)

BwIAAACkAABSU0EyAAgAAAEAAQBDK00rBJwK2Z8e2l/tMqnv4c4aUPQV51F77LAnVgVYtPaDybZ3W4BhGByrFNVq/TtwnRM/LiET8eev4/urbkNxJW0dUtYFXxMnniiJ9sqQkwpoxN6Cm6rCggKxGGABYxu8cY2+ZIhe1Q1swZzJATaJyYA3jx2JZ08MsTxhCToCXbhO9YgKn4wKht+R/s2fo6AT0y0wd9HwqNerluVIljcDaWSXBlwnUIyRdmeFOmxqslkSCmHyoe6oJMjksRFt1sz3j0xesFWEgW1gRYQP/N/5J6VSyVsGKKPedAPWx3Jm3L6kHv8glu1RhADMnDZk8oVNzzZg3ciw8ZHbeguD7s/vGdcS2q6G2fkOvgKvePNbSb4MmK+1X9aKTAVIZJxA4Rz5PMTkQggtsriK5gtt35PMNOhIMJNd340usz015GYwrYvnID3gydlsNkt5uWTNvF4kSNSIkBw9F05lDOz7GyvsXMMG1mw52Gx+I59Ar0BhtPux9oLNoSa4jcg4j5QDTvu77Bde3Ub35/vfJSGtNb2bHbUBP06wILcjNnmBKTze4nbX5h+f6i2lxGqqQDANzP5Y6Ykoy9fknHu5UBenMSE7tJHzhKa9ngPK6c3uTSsp+gIP5yyuML2FzC0TgxJT0/NBTvUj1s5fQc2BfDvwSYG47o01PLrsksfuzyRjAfNK9Nnai+LApKV/2o88UBnswjNaj+57WumDepb9lEtpUJrSNNEJYUWWfdgSXqiuesAmpW/W5WSTAxOjKW0DJPfCielGRnKrVNzYx3UPLRMx522IoT6hLb7/25TRvW3jwlXHyvsrYzEXl0KRkyHdUyUdZMmVZNm1ep+jyuIPGWbkBLVNb10zdhzpIHFLIuBVXpFWVJQ8Njv9/qFi0N/TbpWL4ZbOT3x4OCteXxuMk4BabSNvbfcZiPGMPVIb2Ku01KCIDaz7evrCNcSnqVBiSqyYmzDhWTdRDG0odKwR2XA4LDXTuNnxt0+hNDaLKWE5NQBw3nPl1Ry7XrhgtnBJhXllRnqUgdbMEgWEQ0Bt/HdVjkX4PbmHp4nSWSjOFppT3J2Ck62xPLmmLaqdQ+zifcoyL08tXy5YOHcuKxsK+v55WoDhjSNnQP/T05V6FL6TG/jvN8LuyL9ZPJxdJbZE/2ub6bT9WYW68ToBBfE+Yg1/H+KBl2ZjkCC7lrTPRMd8fn0lLjE1iyoYq9JByTKqS8rvKB2/KpwcNgJrAg+n7RDAoNrPCXJZW8Y8+RV/qiIAcuClXHkGbmI1M4lWq1/x/ZNiToEePfwFaaQvURviyA6mhqK/naScs9yJs+Ow8Ndg1mzeaR7JsAKFltc1hjYWW+YF4fkL7SWA4AoExZZdNGxM8ODHt4qQPJiiepLqUekF7H08yc2qtmaz20jPfftt3QS5G5eevuFYZv3pcKz5/7YjF/3wNQxBOjiaLz8WKuipczB8OMnEfsZopHj+bQAoTjOH5bbJxT3sDpID6xWbOHO/D8F7WolR8Zdx9dXKRJ+H5901bcAfzVuTwQAO8aklyPboi8c=

AES Decrypted Key for Decrypting the DLL

BE E1 9B 98 D2 E5 B1 22 11 CE 21 1E EC B1 3D E6

Extracting Encrypted AES Key and Encrypted DLL from t.wrny

Hard Coded Public Key to Encrypt User Private Key (Converted to Base64 for Display)

BgIAAACkAABSU0ExAAgAAAEAAQB1l0w7hEbeLCr0lahdwM1t2tfUkh4TgjRqcI2PfPcEklV/8aInsp5BrJCAkRiTwrF7rSvz/6/bK1G+HaMn46dXCFq+wR32BPgcvluxZ/vkyNp1AHCxF3AkbAljdKxLCh1xrn+uZbjFhnnFfp+YYExSuSliyyMp7TGRdHt7CyYb8n1nv9p6QNryYU2UpX2tWWutnqM6OcZbbp/Suza19dJl9Sww2MEXva8oAJYgRqctYgMM19B1oAsH6tQfyujZTts48iZ1yxKmiHCb4eoy3PhxclBB5heBaCdCjt/l3qFy2Tv75Z0wEWmSzWAr4tVGPCjPnTBK9625+w+R/i6+GPHO

Dll Decrypt Private Key (Converted to Base64 for Display)

BgIAAACkAABSU0ExAAgAAAEAAQBDK00rBJwK2Z8e2l/tMqnv4c4aUPQV51F77LAnVgVYtPaDybZ3W4BhGByrFNVq/TtwnRM/LiET8eev4/urbkNxJW0dUtYFXxMnniiJ9sqQkwpoxN6Cm6rCggKxGGABYxu8cY2+ZIhe1Q1swZzJATaJyYA3jx2JZ08MsTxhCToCXbhO9YgKn4wKht+R/s2fo6AT0y0wd9HwqNerluVIljcDaWSXBlwnUIyRdmeFOmxqslkSCmHyoe6oJMjksRFt1sz3j0xesFWEgW1gRYQP/N/5J6VSyVsGKKPedAPWx3Jm3L6kHv8glu1RhADMnDZk8oVNzzZg3ciw8ZHbeguD7s/v

Other Files

Struct for SMB_TRANS2_PKT

Screenshot of Shellcode in SMB1 Trans2 Packet Body

I’ve spent nearly every moment of the past few years thinking about how to stop cyber attacks.

And this is the first time I’ve been truly alarmed.

Friday’s ransomware attacks that infected over 150 countries — most notably shutting down hospitals all over England — proved that a cyber attack can determine whether someone lives or dies.

Access to information is power, and if a cyber attack prevents hospitals from accessing records or life-saving care, the consequences are dire.

Many of us in the security industry have anticipated these dangers for a long time, but yesterday made our worst fears a reality.

The ransomware strain, known as WannaCry (or WanaCrypt0r and WCry and WCrypt), was deployed by unknown cyber criminals who used an exploit allegedly written by the NSA. This exploit was one of many uncovered and dumped for public use last month by the Shadow Brokers hacking group, widely believed to be connected to the Russian government.

Microsoft released a patch for the vulnerability in March, but clearly many organizations haven’t patched or are running older, unsupported versions of Windows.

We could spend the next days debating the nuances of why organizations, especially those in critical infrastructure, didn’t patch the vulnerability in time or why they run insecure software for critical functions. Each organization bears responsibility in their security failures.

But the more pressing issue is how so-called hacktivists, or in this case probably state-sponsored operators, are impacting our everyday lives and what we can do to stop them.

So far, the Shadow Brokers have claimed their behavior was virtuous — they were acting as hacktivists simply sharing what they say are NSA cyber capabilities with the public. What the Shadow Brokers’ exact motivations are for exposing a powerful cyber operations toolkit will be close to impossible to discern definitively, but the negative impact to the safety and security of the world has been made clear. They doubled down yesterday, notifying the world that they plan to release more allegedly NSA-developed capabilities on a monthly basis starting in June, including capabilities for Windows 10.  

Leaking the information that the Shadow Brokers had widely cannot reasonably be called innocent hacktivism.

If the toolkit leak actually was intended as altruistic hacktivism, it was reckless at best. If the leak was something more, it only validates concerns over the alarming trend of information warfare (both information leaks and exploits) and what this means for our collective future.

Groups like Shadow Brokers — whether operating solely to spread information or for something more nefarious — are directly contributing to the weaponization of information that can cause physical harm like we saw this week.

To be clear, I am not suggesting that the Shadow Brokers built and launched this ransomware worm. 

This attack fits the recent trend of criminal enterprises leveraging these now freely available capabilities with the M.O. of hacking and selling stolen information or launching ransomware attacks, a booming business for the attackers (ransomware alone took in an estimated $1 billion last year).

This tech transfer of nation-state capabilities only amplifies the Wild West of cybersecurity, where new weapons are being built every day and very few rules exist to govern actions or prosecute anyone who steps too far. Friday’s ransomware attack demonstrates how these issues actually impact matters of life and death.

So what can be done?

The scary thing is, individuals can implement all the best information security practices like strong passwords, two factor authentication, and encryption, but if large organizations fail to secure their systems, you can be in grave danger.

The proliferation of nation-state exploits and malware are making these kinds of attacks much more accessible to a broad range of criminal and state-associated groups. This means we’re only just beginning to realize the detrimental impact they will have, especially since there seems to be little consequences for the groups conducting this dangerous behavior.

Organizations must wake up to the modern realities of these attacks, assume they’re a target, and prepare accordingly. That means no longer viewing security as a check-the-box compliance exercise. Organizations must proactively and vigorously review their current security methods and ask themselves not if but when an attacker will get in, and whether they have the people, processes, and technology in place to combat it.

Attackers will continue to steal and deploy digital weapons against critical infrastructure so long as they see relatively little risk to their actions. I hope that the impact of this attack on human life will awaken us to the gravity of this issue. In other words, it’s time for everyone to be alarmed.

This piece was originally published in Business Insider.

Last week, WannaCry left its mark across the globe, affecting hundreds of thousands of machines in over 100 countries. While it certainly has been more widespread than previous ransomware, WannaCry is just the latest example of the growing prevalence of ransomware. As I explained in a previous post, ransomware is now a billion dollar industry, and is only growing in popularity among attackers due to the risk calculus and profitable business model.

Although WannaCry included fairly unsophisticated ransomware, it leveraged the Eternal Blue SMBv1 exploit from the Shadow Brokers data dump to propagate to other hosts. It is important to catch these kinds of attacks as early as possible in the attack chain, but what happens when those steps are circumvented by extremely customized and sophisticated techniques? This is why a layered approach to detection and prevention is necessary. While Endgame's layered protection approach ensures that we have the means to prevent and detect threats throughout multiple steps of the attack chain, there needs to be an additional line of defense in the event that ransomware or other destructive malware manages to be invoked on a host. Endgame ransomware protection provides that capability.

Approach

The core functionality of ransomware often is different compared to other malware. Ransomware attackers have a very straightforward mission: make files inaccessible and collect ransom payments from the affected users in order to restore access.  Therefore, the code can be as simple as modifying files and providing recovery capabilities.   It often does not contain large amounts of, or any, code for network communications with a command and control server, evading endpoint defenses, persistence mechanisms, or user surveillance capabilities, all of which are common attributes of other types of malware.  Because of this, simple ransomware often gets through other endpoint protection mechanisms.  This, combined with the enormous impact of a ransomware campaign, means that defenders require specialized capabilities to detect and block ransomware activity on a host at runtime before critical data is lost.

Endgame has provided customers with ransomware protection in our endpoint agent, and will continually enhance this feature going forward. Our approach to solving this problem at runtime involves many pieces operating in parallel.  I will discuss three of these in this post:  

• File operations
• Shannon entropy
• Anomaly scores

File operations will drive analysis of file data and metadata, Shannon entropy is utilized to make key observations regarding the file content in a mathematical context, and anomaly scores are derived from file entropy and a variety of other measurements and characteristics. These concepts combine to provide introspection into each active process and allows us to detect ransomware activity.

File Operations and Anomaly Scores

The first building block is to gain visibility on activities on the filesystem. While a Windows host is active, files are constantly being created, modified, and read in the background. These file operations contain a wealth of information that can serve as the foundation for any ransomware detection capability, but the number of operations that may occur in a minute can be in the tens or even hundreds of thousands. In the face of this deluge of data, filtering plays a crucial role in separating the signal from the noise.

Our filtering approach is based around the following three pieces of data:

• Operation
• Process
• Anomaly scores

If we were to analyze a file every single time one is opened, closed, read, or modified, that would result in an overwhelming amount of redundant analysis. When it comes to ransomware, though, we are primarily concerned with whether a file has been modified. For the sake of data simplification, we group file modifications by the following high level operations:

• Create
• Write
• Rename
• Delete

Once we're limited to those four file operations, we attribute each incoming file operation to a single process. Since we are attempting to distinguish ransomware activity on a per-process basis, we need the means to analyze each relevant operation and how it relates to the process by which it was invoked. This grouping will help us maintain metrics on processes over time and quickly determine anomalous activity as it begins to occur.

Each file that is modified by a particular process, along with the process itself, is assessed a score that reflects the level of anomalous characteristics that were discovered through analysis. The effect that each characteristic has on the anomaly score will vary depending on how abnormal the characteristic is when compared to a particular baseline. This weighted score is based along a scale, with more anomalous attributes being weighted higher. The scale is derived from a combination of applied mathematics along with domain expertise honed through thorough manual and automated analysis of ransomware samples. 

Several metrics are taken into account when compiling anomaly scores

Finally, the affected filepath provides several key data points that can be used to filter out and group file operations:

• Directory
• File extension
• File name

Certain file directories might typically see higher volumes of data modifications than others. In these cases, we can opt for less rigorous analysis of these directories to avoid overtaxing our detector. There are also other directories that are only typically modified by one or more specific processes with a certain level of privileged access, so any processes modifying these directories that do not fit within the normal range would immediately appear to be anomalous.

Depending on the extension of the file that has been modified, a particular operation may be viewed as more or less relevant. For instance, consider a file with a known temporary file extension compared to a Word document file. Both files will be analyzed in the same manner, but a higher weight will be factored into any anomaly score calculations for operations relating to the Word document as opposed to those pertaining to the file with the temporary extension.

The number of unique file extensions, the number of files per unique file extension, and the specific file extensions that are modified all factor into the anomaly score for each process. A process that modifies several files across extensions that are known to be typically targeted by ransomware would generally be viewed as more anomalous than a process that modifies mostly temporary or helper files avoided by ransomware.

Shannon Entropy

While I could write a long-winded description of Shannon entropy and how it relates to file contents, I'd rather recommend this excellent write-up by Lance Mueller of ForensicKB instead. In short, entropy is a measure of the randomness of a specified set of data. The more random the data is, the higher its resulting entropy will be when it is calculated. Low-to-middle entropy data tends to contain only a subset of the 256 possible byte values (0x0 - 0xFF), while high entropy data contains byte values that span the entire range. This can be extrapolated to presume that typical file types (e.g. XML, HTML, TXT) will generally have lower entropy values than binary file types (e.g. EXE, DLL, MSI), among others. 

High entropy Disney television show

So, how can entropy be used to help detect ransomware? For individual file types / extensions, we can devise expected entropy ranges based on manual inspection of the file specification as well as calculating the average entropy for a sufficiently large set of sample files. Since typical encryption algorithms produce high entropy output, we're interested in files that have been modified or created and now possess high entropy values that exceed their predetermined range (based on their file type). Also, if the average entropy of the files being modified by a given process is higher than the expected average entropy based off of their file types, this can be reasonably assessed as an even stronger indicator of potentially anomalous activity than that of a single file exceeding its typical entropy range.

Take for instance an XML file. XML files typically consist of text data that is represented by bytes within the ASCII range (0x0 - 0x7F), though they do not use the full extent of the characters within that range. As 8.0 bits / byte is the highest possible entropy value and 0.0 bits / byte is the lowest possible entropy value, we should generally expect XML files to fall somewhere within the middle range of possible entropy values due to its relatively limited usage of byte values.

Sample XML file (Entropy - 5.212 bits / byte)

Now, when that same file is run through an encryption algorithm (AES-256 in CBC mode in this instance), we can see that the contents become scrambled and incoherent, and no discernible words in English are readable.

XML file after AES-256 (CBC Mode) encryption (Entropy - 7.918 bits / byte)

It should come as no surprise, then, that the entropy value has significantly increased from 5.212 to 7.918. For a file type such as XML, the encrypted entropy value far exceeds its expected range and is much closer to being perfectly random than a normal file of its type should be, which would come across as very anomalous to our protection feature.

Detection of high entropy is not a complete solution.  Compressed data must be handled. It tends to possess high entropy, so the acceptable entropy range for certain file types needs to be adjusted. This makes it difficult to tell the difference between compressed data and encrypted data. While Monte Carlo pi approximation, chi square distribution, and other calculations may help distinguish between encrypted and compressed content, the additional overhead introduced by these calculations may cause unacceptable slowdown when processing thousands of files per minute. 

Another issue is that there are also ransomware variants that employ encryption routines which produce much lower entropy data than typical encryption algorithms, so a file lacking high entropy is not definitively an indicator that it is likely benign. Other approaches are needed to deal with this case, which are beyond the scope of this post.

Entropy is not the be-all, end-all measurement that can affirm whether or not a file contains encrypted content, but it provides a very useful window through which we can gather further evidence of processes that may be modifying files in an abnormal manner.

Additional Screening

Each file operation will be subjected to further proprietary anomaly screening beyond filepath and entropy analysis, which results in modifications to the file anomaly score. The additional data that is yielded, when combined with the results of filepath and entropy analysis, provides an extensive overview of a given file operation and allows for immediate detection of anomalous behavior. Various approaches were tested and integrated into our scoring throughout our research, leading to the scoring system in the product today.

Analysis underway...

How It All Comes Together

As each file operation passes through our ransomware-detecting Rube Goldberg machine, all necessary data associated with the affected file will be extracted and analyzed, and a minimal amount of data summarizing the operation is maintained for posterity. The file's anomaly score will then be logged and added to the process anomaly score.

Artistic Representation of Detection Algorithm

In the event that the process anomaly score meets or exceeds a predetermined threshold, the process will be suspended immediately. A pop-up dialog will alert the user to the suspended ransomware activity and provide them with the option to terminate or resume the offending process.

Ransomware Protection Popup Dialog

Since our ransomware protection feature is driven by analyzing file operations at a high level, it will work irrespective of the type of process. Whether the process originates from a .NET binary, fileless malware (Powershell, JavaScript, VBScript), or a standard executable, Endgame ransomware protection will be able to track all operations needed to quickly determine whether anomalous activity has occurred on a system. Our solution does not interfere with normal system and application operation and introduces minimal CPU and memory overhead.  We also handle all of this with a very low false positive rate.  Earlier variants of our scoring algorithm sometimes experienced false positives with software compilation, filesystem cleanup utilities, and other applications which create or destroy a very large number of files in a short period of time.  A large amount of tuning was required to maintain a very low FP rate for customers.    

Case Study: WannaCry

When WannaCry began grabbing headlines earlier in May, as we detailed, our research team immediately obtained the dropper and the core encryptor binary (tasksche.exe) in order to perform offline testing against our ransomware protection feature. The embedded video below walks through launching the encryptor on a virtual machine with ransomware protection enabled.

Endgame Ransomware Protection at Work

Endgame ransomware protection detects the presence of ransomware activity on the machine quickly after the encryptor launched and before thousands or even hundreds of files could be encrypted. The speed with which the ransomware is detected and mitigated protects against critical data loss, expediting the return to business as usual. An alert containing detailed process activity data is also generated and sent back to the Endgame sensor management platform, allowing for further triage of the ransomware and the workflow which resulted in it being invoked on the system. In addition to MalwareScore™, Endgame ransomware protection serves as another line of defense against extensive critical data loss caused ransomware such as WannaCry.

Conclusion

As long as ransomware remains a profitable criminal venture, attackers will continue to pursue new means to compromise networks and deploy ransomware. Just like other forms of malware, ransomware can be stopped at various points along the attack chain. However, given the customization of techniques, and persistence of targeted attackers, it is essential to be able to provide an additional line of defense. Endgame’s ransomware protection provides this, integrating detection techniques based on filepaths, entropy, and our own proprietary algorithms to protect against the broad range of ransomware in the wild today. As the WannaCry example demonstrates, our ransomware protection is effective at stopping well known but also emergent strains of ransomware.  

Following the horrific attack in London this weekend, Prime Minister Teresa May’s response reinforced the tight interplay between virtual and physical security.  May outlined four key changes for counter-terrorism strategy, two of which focus uniquely on the cyber domain. May’s response has already been criticized as a push to drive terrorists offline. While she certainly seeks to limit physical safe spaces (e.g. ISIS in Iraq in Syria) and virtual safe spaces, her comments pertaining to international regulations have received more scrutiny. In light of last year’s Investigatory Powers Bill, which expanded UK surveillance capabilities, it is understandable that any references to regulation may raise eye brows. However, she frames these changes within an international agreements framework, eluding once more to the growing push for international norms to counter malicious use of the internet, and the need to modernize policy to counter modern threats.

When it comes to removing virtual safe spaces for violent ideologies, she notes:

“Second, we cannot allow this ideology the safe space it needs to breed. Yet that is precisely what the internet, and the big companies that provide internet-based services provide.  We need to work with allied democratic governments to reach international agreements that regulate cyberspace to prevent the spread of extremist and terrorism planning. And we need to do everything we can at home to reduce the risks of extremism online.”

This reference to international agreements reflects the growing push by countries across the globe, as well as multi-national corporations, to foster a norms-based approach to establishing rules of the road when it comes to cyberspace. While she limits the inclusion to democracies, as discussions at the UN Group of Governmental Experts (UN GEE) demonstrate, there are certain commonalities that can reach across regime type and could help begin to chip away at establishing mutually agreed upon behavior. These baseline norms can then help governments coordinate and more effectively respond to activities that occur outside of those rules of the road, including information sharing to address online extremism. While norms certainly aren’t a silver bullet, May’s reference to international agreements highlights the role that digital norms as well as more formal global cooperation can have both on cybersecurity as well as counter-terrorism.

May also indirectly calls out the role of social media platforms for allowing extremist ideology a safe space. She brings to the forefront a conversation which has been growing in the United States and elsewhere in Europe, especially when seeking to balance free speech with personal safety and privacy. Twitter’s censorship has reached oral arguments at the Supreme Court, while the leak of Facebook’s content policy has been criticized in how it handles various forms of abusive or extremist content. This policy surfaced following the French election, when Facebook took down 30,000 accounts they deemed fake for spreading misinformation or deceptive content. Facebook also has been vocal in shaping the discussion around information operations and already has a policy in place to investigate terrorist content. Google also has been vocal in its efforts to combat online illicit activity, ranging from a global anti-phishing campaign to combating fake news. These social media platforms have commented on May’s remarks, arguing that many of her recommended changes are already in place.

This back-and-forth between the government and large tech companies is indicative of the need for policy modernization, one that balances security, privacy and free speech. May’s fourth point acknowledged this current policy shortcoming, noting, “as the nature of the threat we face becomes more complex, more fragmented, more hidden, especially online, the strategy needs to keep up.” The UK is not the only country lagging in policy modernization to counter the realities of the digital age. In the US, the thirty-year old Computer Fraud and Abuse Act remains the foundational policy, while there is increasingly vocal demand for a coherent cybersecurity strategy from some members of Congress, such as Senator John McCain. Technology has dramatically outpaced policy, but hopefully there are glimmers of progress as many realize that innovation must occur not just in technology, but in the policy realm as well.

The UN GGE meets later in June to finalize a framework for internalizing and operationalizing a set of digital norms. At that time, we may learn details about the UK’s position on the establishment of international agreements. While the UN GGE formulates a voluntary framework, these voluntary forms of cooperation often establish the foundation for more formalized international agreements. With the rise of censorship globally, many are understandably concerned that May is heading down a more restrictive path. However, over the last year there has been a major shift from both the tech companies and those in government to find solutions that balance security and privacy. This is no easy feat, but one that is essential as the virtual world increasingly impacts political, economic, social, and physical stability across the globe.

Threat Hunters are charged with the difficult task of sifting through vast sources of diverse data to pinpoint adversarial activity at any stage in the attack lifecycle. To be successful, hunters must continually hone their subject matter expertise on the latest attacker techniques and detection methods. Memory resident malware, which presents itself in many forms, is an attacker technique that has existed for over a decade. The popularity of memory resident malware has steadily increased over time, possibly resulting from the proliferation of code and knowledge of in memory techniques. More likely, its popularity reflects the success of memory-based techniques to evade detection by security products and practitioners. Once limited to advanced adversaries, memory resident techniques are now commonplace for all levels of adversary sophistication. I will examine the most common of these memory based attacker techniques, and walk through our team’s research to craft a scalable, low noise approach to hunting for adversaries that are hiding in memory.

Attacker Techniques

Before I address memory hunting methods to detect adversaries in your network, it is helpful to understand the common forms of memory resident malware. These techniques include shellcode injection, reflective DLL injection, memory module, process and module hollowing, and Gargoyle (ROP/APC).

Shellcode Injection

Shellcode injection is the most basic in-memory technique and has also been around the longest. The basic ‘recipe’ for shellcode injection is a four step process. These steps are: 1) open a target process (OpenProcess); 2) allocate a chunk of memory in the process (VirtualAllocEx); 3) write the shellcode payload to the newly allocated section (WriteProcessMemory); and 4) create a new thread in the remote process to execute the shellcode (CreateRemoteThread). The venerable Poison Ivy malware uses this technique, which is a big reason why so many APT groups were drawn to it over the years.

If you pull up a Poison Ivy sample with x64dbg and set a breakpoint on VirtualAllocEx, you will soon locate the chunk of code responsible for the injection.

In the first image, the push 40 instruction preceding the call to VirtualAllocEx corresponds to page access protection value of PAGE_EXECUTE_READWRITE. In the following screenshot from ProcessHacker of the memory layout of a Poison Ivy implant, you can see it allocates a number of these RWX sections.

Typical code sections are of type ‘Image’ and map to a file on disk. However, these are type ‘Private’ and do not map to a file on disk. They are therefore referred to as unbacked executable sections or floating code. Threads starting from these types of memory regions are anomalous and a good indicator of malicious activity. ProcessHacker can also show you the call stack of the malware threads. There are multiple functions in the call stack which do not map to memory associated with loaded modules.

Reflective DLL Injection

Reflective DLL injection, originally developed by Steven Fewer, is another type of in memory attacker technique. Metasploit’s Meterperter payload was one of the first attempts to fully weaponize the technique, but many malware families use it today. Reflective DLL injection works by creating a DLL that maps itself into memory when executed, instead of relying on the Window’s loader. The injection process is identical to shellcode injection, except the shellcode is replaced with a self-mapping DLL. The self-mapping component added to the DLL is responsible for resolving import addresses, fixing relocations, and calling the DllMain function. Attackers benefit from the ability to code in higher level languages like C/C++ instead of assembly.  

Classic reflective DLL injection, such as that used by Meterpreter, is easy for hunters to find. It leaves large RWX memory sections in the process, even when the meterpreter session is closed. The start of these unbacked executable memory sections contain the full MZ/PE header, as shown in the images below. However, keep in mind that other reflective DLL implementations could wipe the headers and fix the memory leak.

The DLLs loaded in memory also conveniently export a self-describing function called ReflectiveLoader().

Memory Module

Memory module is another memory resident attacker technique. It is similar to Reflective DLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself. Essentially, the memory module loader re-implements the LoadLibrary function, but it works on a buffer in memory instead of a file on disk. The original implementation was designed for mapping in the current process, but updated techniques can map the module into remote processes. Most implementations respect the section permissions of the target DLL and avoid the noisy RWX approach.

NetTraveler is one malware family that uses a memory module style technique. When NetTraveler starts, it unpacks the core functionality and maps it into memory. The page permissions more closely resemble a legitimate DLL, however the memory regions are still private as opposed to image.

The active threads have start addresses at these private regions. The callstack also reveals these malicious sections.

Winnti is yet another malware sample that uses the Memory Module technique. They had a minor slip on the section permissions of the first page, as you can see below.

However, the Winnti sample was notable because the MZ/PE headers in the DLL were erased, making it more difficult to detect.

Process Hollowing

Process hollowing is another technique attackers use to prevent their malware from being detected by security products and hunters. It involves creating a suspended process, unmapping (hollowing) the original executable from the process, allocating and writing a new payload to the process, redirecting the execution of the original thread to the new payload with SetThreadContext, and finally calling ResumeThread to complete. More stealthy variants use Create/Map section APIs to avoid WriteProcessMemory. Others modify the entry point with a jump instead of using SetThreadContext.  

DarkComet is one of many malware families that use process hollowing techniques. Several artifacts can be used to detect process hollowing.  One dead giveaway for this activity is a process being spawned with the CREATE_SUSPENDED flag, as shown in the following screenshot from a DarkComet sample.

Module Overwriting

So far, all techniques discussed have led to the execution of non-image backed code, and were therefore fairly straightforward to detect. Module overwriting, on the other hand, avoids this requirement, making it much more difficult to detect. This technique consists of mapping an unused module into a target process and then overwriting the module with its own payload. Flame was the first widely publicized malware family to use this technique. More recently, Careto and Odinaff malware families have used module overwriting techniques.  Various techniques can be used to reliably detect module overwriting, which involves comparing memory to associated data on disk.

Gargoyle

Gargoyle is a proof of concept technique for memory resident malware that can evade detection from many security products. It accomplishes this feat by laying dormant with read-only page protections. It then periodically wakes up, using an asynchronous procedure call, and executes a ROP chain to mark its payload as executable before jumping to it. After the payload finishes executing, Gargoyle again masks its page permissions and goes back to sleep. One way to detect this attacker technique is to examine threads and user APCs for evidence of ROP chains.

Detecting In-Memory Attacks

Given the proliferation and accessibility of these techniques, security personnel must be vigilant for memory-based attacker techniques and proactively hunt for them on their networks.  However, most products cannot generically detect in-memory attacks at scale, leaving defenders with an enormous gap in their ability to protect against these attacks.  Endgame has done significant research to bring low-noise detection capabilities into our product for each method mentioned above.  

Given the immense size and impact of this detection gap, it is important to raise all boats, not just those of our customers.  For this reason, we collaborated with Jared Atkinson on his powershell tool called Get-InjectedThreads, which implements a relatively low-noise method of detecting in memory threats.  It scans active threads on the system for suspicious start addresses. Hunters leverage it to scan hosts in their networks and quickly identify many memory resident malware techniques. The script works by querying each active thread with the NtQueryInformationThread function to retrieve its start address. The start address is then queried with the VirtualQueryEx function to determine the associated section properties. If the memory region where the thread started is unbacked and executable (i.e. not image type and has execute bit set), then the thread is considered injected. The following screenshot shows a sample detection when run on a system infected with a 9002 RAT sample.

The script will catch a variety of malware families leveraging the shellcode injection, reflective DLL, memory module, and some process hollowing techniques. However, it is no replacement for security products that comprehensively prevent in-memory attacks, such as Endgame. 

Enterprise In-Memory Detection at Scale

Endgame has built detections for each of these techniques (and many more) into our enterprise security platform, offering best in market capabilities to locate in-memory threats.  We do not simply rely on naïve approaches like monitoring well-known system call sequences for process injection, but efficiently analyze memory to find all known evasion capabilities.  This provides our users with thread-level visibility on injected code, as well as sophisticated follow-on actions like examining the injected code and suspending only a malicious injected thread to remediate the threat.  Our platform is effective both in stopping injection as it is happening in real time as well as locating already resident adversaries hiding in memory, locating threats across tens of thousands of hosts in seconds.   

Like any signatureless detection technique, false positives (FPs) are an important consideration. As we researched and implemented our technique-based preventions for each adversary technique described above, we initially encountered FPs at every step of the way.  Handling these correctly in our product is of paramount importance.   

Most FPs are related to security software, Just-In-Time (JIT) compiled code, or DRM protected/packed applications. Security products sometimes inject code to some or all processes on the system to enhance their behavioral detection capabilities. The downside is if the product is sloppy in its methods, it can actually harm the security of the system and make hunting for real in memory threats more difficult. JIT code, another potential area for false positives, generates assembly code at runtime which lives in unbacked or floating memory regions. .NET or Java applications are a couple of examples which use JIT techniques. Fortunately, this type of code is easier to identify and filter than rogue security products. Lastly, applications packed or protected with Digital Rights Management (DRM) schemes should be kept in mind. These applications may decrypt or deobfuscate their core functionality in memory to deter debugging and reverse engineering. However, the same techniques are used by malware to evade detection and deter analysis from security practitioners.

Through careful design decisions and extensive testing, we have managed to achieve very low false positive rates, allowing Endgame users to root out in-memory threats rapidly.  

Conclusion

Adversaries will continue to innovate new techniques to avoid detection and accomplish their objectives. Memory resident techniques are no exception, and have been a thorn in the side of endpoint security defenders for over a decade. Fortunately, by understanding the latest techniques, we can turn the tables and use this knowledge to develop new high fidelity detection methods. At Endgame, our comprehensive approach to these attacks have led us to a market leading position for fileless attack detection (adding to our other key technologies). For more on hunting for in-memory attacks, check out our slides from our SANS Threat Hunting and IR Summit presentation.

As attacks become more targeted and unique, it’s critical that security teams are equipped with the tools required to stop attacks before information theft. Even if teams have the right tools, however, they often lack sufficient resources or expertise to decode the massive number of security alerts hitting their screens daily from multiple point products.

This problem is not going away anytime soon: the cybersecurity workforce gap is on track to reach 1.8 million by 2020. While there’s an urgent need for people to solve the talent problem, there’s also an urgent need to solve for the ‘automation’ problem. How do we equip inexperienced analysts with the power to accelerate attack detection and response?

The Answer: Endgame Artemis

You may have read about Endgame’s chatbot Artemis™ before, but if you haven’t, Artemis is an intelligent assistant that automates security analyst actions and guides users of any skill level to detect and respond to attacks through a simple conversational interface. Just as digital assistants like Siri or Alexa proved their ability to give time back to our day by tackling complex tasks, Artemis automatically combs through millions of data points in Endgame’s endpoint protection platform to provide users with definitive answers required to stop attacks faster and earlier than with legacy endpoint products.

We know we’re biased, but we believe that chatbots have the ability to help solve for the talent and automation problems in our industry by dramatically simplifying complex tasks for security teams. We’ve outlined four ways that chatbots are transforming cybersecurity:

Ability to Understand Analyst Language and Intent

Chatbots are powered with natural language processing, a subset of machine learning, that allows them to translate and interpret human language input. Endgame Artemis goes one step further - by pairing natural language understanding (NLU) with security domain expertise to identify analyst intent and guide user workflow. As a result, users of any skill level can ask Artemis simple questions and receive definitive answers without learning complex and proprietary syntax of multiple point products.

Transform a Tier 1 Analyst into a Tier 3 Analyst

Defeating today’s attacks requires analysts to detect malicious behavior across millions of running processes. For inexperienced analysts, this requires them to spend hours - if not days - combing through data and identifying malicious patterns. With Artemis, analysts can ask “what is suspicious in my network today?” and Artemis will digest millions of events across endpoints in seconds and provide the user with malicious activities on the network. Artemis will then guide the user on what to do next to either stop or kill the process. By preemptively suggesting the most urgent information to the user, Artemis empowers less-experienced Tier 1 analysts to behave at the similar level of sophistication as a Tier 3.

Don’t take our word for it, check out this video from one of our customers:

Endgame customer Texas A&M speaks to the power of Artemis

Detecting In-Progress Attacks

Imagine you work for a large enterprise, and you’ve just signed a partnership with a company in the UK that requires you to connect them with your company network. Your CEO has just seen the WannaCry ransomware attack in the news, and wants to ensure that the partner has not been compromised with the attack.

With Artemis, you can ask:

• "Have we seen any ransomware alerts in the past 24 hours?"
• "Do these alerts show up anywhere else on my network?”
• "Have these processes communicated outside my network?

Ability to Adapt Over Time

While we believe that AI-powered chatbots are helping to simplify security operations, we know that it’s not a silver bullet to solving all challenges in the industry. We also know that machine learning models have limitations, which is why Artemis has built-in domain expertise from our team here at Endgame. As our customers continue to use Artemis, the bot will learn and adapt to user needs over time. We’re constantly iterating and improving Artemis to understand context and patterns in language, and look forward to further feedback from the community.

You can see Artemis in action by requesting a demo, meeting our data scientists at a conference, or visiting us Black Hat 2017 at Booth #1360. You can also check out a video on Artemis with Senior Data Scientist Bobby Filar.

Today, Endgame was named a ‘Top Workplace’  by the Washington Post for the second consecutive year. The award is based on a broad survey of people at our company and other companies, and so I'd like to reflect briefly here on why workplace culture matters, and share some of what we've learned about how to build and sustain a good one.

Companies can fail to meet their potential for many reasons -- product shortcomings, poor customer service, sloppy execution, market dynamics beyond their control. But when they succeed, it is almost always because of the people they have attracted -- their grit, mission-focus, collaboration, respect for each other, and excellence.

I’m honored to work with such a  group of people at Endgame. We like to say this is an "elevator assets company," where all we have that matters goes down the elevator at night and goes home. In a talent-driven business, our success depends upon our ability to recruit and retain this kind of team, and then for that group to be much more than only the sum of its parts.

As the company has grown, we’ve tried to keep five things front-and-center with respect to workplace culture and great talent:

Start with Values 

Our company values are integrity, boldness, speed, openness and responsibility. We paint them on the office walls, and I took some heat from our crew for mentioning them in a TV interview. But what really matters is living them -- who do you hire? Who do you promote? Who do you fire? Values are the North Star that allow a team to make choices and move quickly without seeking permission for every decision.

Put the Mission First 

Cybersecurity is among the toughest business and national security challenges of our time. Endgamers believe deeply in our mission to protect the world’s data from attack, and know that our ability to tackle this problem will have profound impact on the world -- how we communicate, transact, learn, and live. The ability to work on an issue that is on the front page of the newspaper every day is something that galvanizes us as a team and inspires us to continue to stay ahead of advanced attackers.

Encourage Professional Growth

Daniel Pink's wonderful book, DRIVE, makes the case that people seek three things in their jobs: mastery, autonomy, and purpose. We don’t view the professional development of mastery as an added perk, but as a necessity. Staying ahead of evolving threats requires a team of people who constantly strive to remain at the top of their field. We encourage employees to participate in the broader community by publishing research, attending classes, or by speaking at conferences. We have a patent incentive system. We have a bias in favor of internal promotions. All these things together reinforce a culture that values learning and achievement, both as individuals and as a team.

Ensure Diversity in Every Sense

The security industry is failing, and we will never succeed in thinking differently without different skill sets, backgrounds and perspectives at the table. So no matter who you are – academics, hackers, public servants, or industry gurus - if you are driven and willing to collaborate, then we have a place for you. More diversity within teams leads to greater innovation, and that’s why we’re committed to hiring a diverse workforce at Endgame. In a hard-fought war for talent, we need to have a workplace where everyone feels welcome and empowered to be his or her best self regardless of gender or race or any other personal characteristic. It's both the right thing to do and a business imperative.

Allow for Workplace Flexibility

We don’t believe in punching time cards, but rather knocking out code and content during your and your team’s optimal work hours. Think like an athlete -- train when you best train, sprint and recover, but be ready to win during your time on the field. We encourage collaboration within and across teams, and try to have our physical space and operating rhythm reflect that. This helps us foster those serendipitous encounters and open communication that allow for innovation.

We're still learning. I'd love to hear ideas and suggestions from others focused on doing this well. To learn more about Endgame, watch our mission video or check out our careers page.

As an industry, security suffers from an inside baseball problem, generally focused on the technical minutiae and failing to translate it to the non-experts. This not only makes security inaccessible to the rest of the population, but it hinders a more holistic perspective on just how quickly the threat landscape is evolving. This strategic perspective is required to ensure both public and private sector organizations are not caught flat-footed with the next compromise. Building off of this challenge, we’ll post a series of articles this summer that address the key tech and policy trends impacting security, and highlight some of our research that integrates the threat landscape, machine learning, and user experience.   

With that in mind, this post kicks off the series by focusing on the dominant technological trends that are altering the digital and geopolitical landscape, illustrating how they impact commercial enterprises and the public sector, and how their convergence contributes to the escalatory nature of attacks. I recently spoke at the Commonwealth Conference on National Defense and Intelligence to a very tech-centric audience, with the main feedback centered on how useful it was to pull the thread through these key cybersecurity trends and articulating their impact. While it may be a review to insiders, to those who don’t spend their day researching the latest attack, this hopefully provides insight into just how quickly the digital threat landscape is evolving both overseas and on the homefront.

Beyond Inside Baseball

How many times do we read about wake-up calls that are anything but? In the last few months, WannaCry and CrashOverride were both hailed as the latest wake-up calls, but if you talk to anyone outside of security, they were quickly cast aside in the twenty-four hour news cycle, or worse, never even registered on the radar. This is problematic, as together they reflect several of the key technological trends which are dramatically restructuring adversarial capabilities and objectives. A look at a few of the driving trends behind recent widescale attacks reveals just how urgent the situation is. To summarize, I’ll discuss the role of bots and automation, innovations in malware (ransomware and wiper malware), and the open source proliferation of advanced cyber weapons which continues to dramatically alter the threat landscape.

Bots and Automation

WannaCry, which I referenced earlier,  is a self-propagating worm, which leverages automation, as do most widespread attacks. A few weeks ago, US-CERT revealed that North Korea was behind a DDoS botnet infrastructure that, since 2009, has targeted a range of victims, exfiltrating data and causing disruption. This use of botnet infrastructure is increasingly prevalent, as we saw with the Mirai botnet in late 2016, which leveraged IoT devices to bring down internet services, including major websites. Bots are not just used for DDoS, but also contribute to malvertising, which often includes browser-hijacking malware. Fireball is a recent example of this and has infected between 40 million and 250 million computers (depending on who you ask). These malicious bots - which also include social bots responsible for amplifying false news and propaganda - comprise roughly 30% of all web traffic. The use of automation doesn’t end with bots and propagating ransomware, but also extends to adversarial machine learning, which is increasingly employed to circumvent security defenses.

Destructive and Demanding Malware

Automation is not the only transformative digital innovation leveraged by adversaries. Once thought of as not much more than a nuisance, malware is now extremely impactful, especially in the form of ransomware or wiper malware, leading to financial losses and destruction. Let’s start with ransomware, which was a billion dollar industry in 2016. While WannaCry is most associated with attacks over a weekend in May, just last week it forced Honda to halt production after the worm shutdown computers.  With the introduction of new variants, and criminals and nation-states employing ransomware with impunity, this number is only expected to rise. SamSam ransomware, which has been around for over a year, successfully demanding ever-higher ransom, as well as today's evolving news on Petya ransomware spreading across Europe, illustrates how attackers continue to push the limits in financial demands and objectives.

Simultaneously, wiper malware - which can cripple computers and destroy data - continues to wreak havoc in some of the most volatile international relationships. CrashOverride, or Industroyer, is the most recent example, and is customized to disrupt power grids. It has been linked to the 2016 power outage in Kiev, which affected 1/5th of the population. This is just the latest example, as Kiev experienced an outage a year earlier, linked to KillDisk, a destructive, wiper malware.  Ukraine is not the only victim, with numerous instances of wiper malware surfacing across the globe, including: Dark Seoul (attributed to North Korea) destroying over 30,000 South Korean government, financial and media computers; Shamoon 2 (attributed to Iran) targeting 15 Saudi government agencies, petrochemical companies, and IT service providers; and Destover (attributed to North Korea) destroying 75% of Sony’s servers. If this wasn’t enough, a few months ago malware with a ransomware component, Stonedrill, was spotted in the wild. It began in the Middle East, and has since spread to Europe. Shortly after, KillDisk was also discovered with a ransomware component.

Open Source Proliferation

These new attacker innovations evolve, and in some cases leverage the open source proliferation of nation-state capabilities that has occurred via data dumps or human error. With these readily accessible and powerful cyber weapons, the asymmetry within the cyber domain is only growing, such that those with limited resources can now achieve an even greater impact. For example, the recent WannaCry ransomware infected over 300,000 machines across 150 countries. It deployed an exploit called EternalBlue, which was recently released in a Shadow Brokers dump. We will likely see more of these, as Shadow Brokers recently announced an exploit-of-the-month subscription model. The Vault 7 dump similarly offers new releases periodically, and together the two dumps reflect the growing accessibility of nation-state digital capabilities within the open source realm.

Recently, a newly discovered attack leverages two Shadow Broker’s exploits, exploiting both unpatched Microsoft servers and can remain undetected in the kernel. There also is a ransomware component, and fears of worse-case scenarios of this attack vector foresee the insertion of destructive malware through the backdoor to attack critical infrastructure. Finally, it’s not just nation-states whose weapons are dumped into the wild, but also commercial entities, expediting the proliferation of these impactful weapons. For example, BlackTech is an espionage group using dumped Hacking Team tools for document and IP theft. What happens when these same tools are employed by terrorist or other criminal groups, or additional nation states, who may or may not comprehend the potential externalities of such an attack? 

Duck and Cover?

By most accounts, we are not ready to respond to these hybrid attacks that are unleashed at a rapidly expanding rate. The old-school, Cold War mentality of state-on-state targeting is obsolete. Even previous attacks which focused on data theft may soon pale in comparison to the brazen objectives of today’s adversaries. From the attribution of WannaCry to North Korea to revelations of the Mexican government targeting lawyers, journalists and media with spyware, to threats to the energy grid and financial systems,  it is well past time for new models, approaches, and policies to address the realities of the modern threat landscape.  

Technological innovation is key to improved defenses, but so too is innovation in our policy and strategy. While duck and cover is the path of least resistance, the risks are too great to leave in the hands of Cold War era strategies that are insufficient for today’s technologies and adversaries. So what can be done? With every high profile breach, there is demand for greater deterrence capabilities and policy changes, but it quickly dissipates within the twenty-four hour news cycle.  It also is extremely difficult, with no easy solutions across a menu of options, but that should only serve to elevate the necessity for a modern approach.

In the next post, I’ll discuss some key tenets that should inform such a framework, including the integration of diplomatic and defensive postures, and reimagining the role of the private sector to progress toward a deterrent framework. It will also require international collaboration, which is increasingly difficult as the latest UN GGE talks demonstrated. Despite these challenges, while the defensive technologies will be key, a path toward better security must also run through a modernized policy framework.

Throughout the day, news spread of a ransomware attack hitting Europe and Russia, before making its way into the United States. By one estimate, it has already impacted tens of thousands computers, including pharmaceutical giant Merck, Russian oil company Rosneft, Danish shipping company AP Moller-Maersk, and a Ukrainian company responsible for monitoring Chernobyl’s radiation system. Today’s ransomware attack follows closely on the heels of the widespread WannaCry ransomware infection, which struck 300,000 machines in May, and just last week debilitated computers at Honda. Given the widespread impact and potential for propagation, we quickly tested the Endgame platform against this latest Petya-like ransomware. Endgame’s layered approach once again proved up to the task, catching and remediating the ransomware before it could inflict damage.

Ransomware - Today’s Hottest Attack Trend

2017 already has proven to be a stellar year for ransomware, and we’re just half-way through it. Experts are divided whether this is a variant of Petya or just Petya-like, and some have recently dubbed it Goldeneye, which is a hybrid of Petya and another ransomware variant, Misha. For the sake of simplicity, we will refer to it as Petya. Despite this nomenclature disagreement, there is general consensus that it has already had a large impact.  

As our ransomware timeline below illustrates, the Petya ransomware variant emerged last year. It is just one of the many new variants of ransomware that continue to shape the threat landscape. Petya overwrites the master boot record (MBR) with a custom bootloader from user space by the DLL and then the system is rebooted. Upon reboot, the custom bootloader that overwrote the MBR is loaded, which will encrypt the MFT and then display the ransom note, demanding $300 in bitcoin (which is proving problematic).

While Petya is similar to WannaCry, there are a few significant differences. With WannaCry, a kill switch was discovered relatively early, helping limit its propagation. There were signs late Tuesday that one was discovered for Petya as well, but it works more as a local inoculation than a global kill switch. The efficacy is also questionable because it is filename dependent.

Despite being spotted in the wild in early 2016, it is not terribly surprising to see Petya reappear. This time around, Petya takes advantage of the EternalBlue exploit released by the Shadow Brokers, similar to WannaCry.  It includes additional propagation methods as well, taking advantage of at least one other ShadowBrokers exploit and leveraging credential harvesting and usage of legitimate administrative tools to move laterally and inflict damage more broadly inside a network.  While many thought WannaCry was yet another wake-up call to companies and governments, the quick diffusion of Petya demonstrates yet another wake-up call that went ignored.

Protecting Against Petya and Beyond

As we’ve discussed in previous posts, Endgame stops ransomware attacks by combining several layered, signatureless preventions including exploit prevention, malware prevention, and a variety of behavioral preventions.  Endgame’s MalwareScore^TM  catches Petya immediately, identifying the malware as malicious. MalwareScore^TM is a machine-learning based approach to detection and has proven highly effective at detecting known and unknown malware. Unlike some other machine learning-based solutions, MalwareScore does not require a cloud connection to be effective, protecting even those critical assets without an internet connection. We also tested Petya against many early versions of our MalwareScore^TM model, and all detect Petya, proving the protective power of our signatureless machine learning approach yet again. With Endgame deployed on a system, Petya is prevented without any prior knowledge of the ransomware variant. This is especially important because there is near certainty that Petya will not be the last, highly impactful ransomware attack. As long as these attacks remain profitable, they will continue.

Despite being highly effective, MalwareScore^TM comprises just one layer of Endgame’s multi-layer approach to protection. We know machine learning is not a silver bullet, and as impactful as ransomware is, there are other forms of malware-less and file-less attacks that require additional protection capabilities. In just a few weeks, our team will be in full force at BSidesLV, Black Hat, and DEF CON, talking about our research and the protection capabilities within our platform. Swing by our Black Hat booth 1360, and attend our conference talks covering everything from prevention to machine learning to the essential role of design and user experience in facilitating the analyst workflow.

Capital One recently hosted the excellent Data Intelligence conference in northern Virginia. As a data scientist working in infosec, it was great to meet so many new people and old friends who were all interested in applying machine learning to diverse fields. I presented an overview of our early research into malware classification titled “Which Model Came Hot and Fresh Out the Kitchen in our Malware Classifier Bake Off?”. We had previously documented this research in our technical blog, which detailed in depth our path toward choosing a machine learning model to use for our endpoint malware classifier, and providing tips for others as they evaluate machine learning models. The results of the bake off gave us a great foundation for building what eventually became MalwareScore^TM. In this talk, I added additional context about data science in security in general, the benefits and drawbacks of running a model bake off, and more information about our conclusions.

In our bake off, the Endgame data science team evaluated many machine learning models to see how well they could power a malware detection capability on customer endpoints. We not only focused on classification performance, but also model size and query time execution to fit within tight memory and CPU constraints. Our data science team members brought their expertise in many models to this bake off, including nearest neighbors, decision tree based models, and even a deep learning model.

In addition, this project allowed our data science team to share knowledge and insights. Having used a Support Vector Machine (SVM) with a Radial Basis Function kernel many years ago to find neutrinos from other galaxies during my graduate research, I thought I knew everything there was to know about them. But during this project, I learned that it’s best to train SVMs differently when your feature count is as high as it was here (>2000 features). This is just one example of how our data science team gained additional knowledge throughout the bake off process, and as a result expanded our own skillsets.

After my talk, most questions focused on the many things we could have done to continue to improve the performance of the models across the board. I had to laugh at some point where my answer was going to once again be “no, we didn’t try that” and explain that at some point the purpose of the bake off had been accomplished. Once we’ve learned from each other and seen some early performance results, it was important for the team to decide on a model and iterate on delivering an actual product. In our case, it was clear that gradient boosted decision trees offered the best combination of detection, size, and performance.  A lot of the audience’s suggestions (identifying problem executables and improving on them, searching for better features, Bayesian hyperparameter optimization) are techniques we have since used to improve and optimize MalwareScore^TM performance, something we do on a nearly continual basis.  

If you’re considering using machine learning to solve a problem at your company or organization, a bake off is a great way to determine which direction you should take or challenge existing assumptions about the best path.  As you design a bake off, make sure to clearly define what you hope to learn from it. Machine learning can be applied to many different domains, and so an unexpected model could be appropriate for your problem area. At the same time, focusing too many resources on a bake off could distract your team from all the other task required before shipping a data product. By defining what questions you need answered from a bake off, you can reduce the chances of it becoming too large of a project.

In the process of recalling our earlier work in order to build this talk, I was reminded how this bake off really served as the ignition for our efforts towards building MalwareScore^TM. We may remix the effort in the coming months to include what our team has learned about training deep learning architectures and will share results if and when they’re available.

In our last post, we highlighted the design challenges we faced creating a chatbot for the security space. While the design considerations pose a significant challenge, equally daunting is building something that actually “understands” the end user. For instance, the banner graphic above demonstrates the wide gap between query language syntax when searching on endpoints and how a human would actually pose the question in reality.

Unfortunately, the computational transition to natural language is not necessarily a ahem... “natural” one. Building something that understands an English form SQL-like language is much simpler than the messy reality required to build a conversational interface. We’ll describe this process of transitioning from strict query syntax toward building a user-friendly interface flexible enough to answer questions. Guided by the user experience research, building a natural language processing pipeline is the essential second component to ensure our chatbot, Artemis, meets the operational needs of users across a range of expertise.

Chatbot

The concept of a chat interface is straightforward. The user is presented a text input window where they can perform a query. Upon entering some text in the window and hitting <enter>, the following actions occur behind the scenes:

1. Text is sent to the bot

2. Bot preprocesses/cleans incoming text

3. Bot determines what the user wants to do

4. Bot extracts important information

5. Bot carries out user action

Easy enough, right? Well, not really. In fact, steps 2-4 are some of the toughest problems in a subfield field of Natural Language Processing (NLP), called Natural Language Understanding (NLU). This field has seen increased attention due to the rise of other mainstream intelligent assistants from companies like Amazon, Microsoft, and Google, as well as chatbots on Facebook Messenger and Slack. In short, NLU attempts to derive a user’s intention by performing semantic and syntactic analysis. Before we dive into our NLU pipeline, let’s first explore the core chatbot components required to successfully build a chatbot.

Utterance

Utterance refers to the words the user sends to the chatbot.  Utterance is a catch-all term that covers whatever the bot might receive, anything from the word “hey” to a multi-sentence paragraph.

Dialog Script

The flowchart in Figure 1  is one example of a dialog script. Dialog scripts provide a template of ideal interaction between bot and user. They are similar to a decision or process tree, and cover the potential range of outcomes and flows within a conversation.

Figure 1 -- Example of a dialog tree

Context

Context represents the current state of a conversation. Each context within an intent has constraints that must be met (e.g. context = search_process_no_query means a user must supply a hash or filename) to proceed. It might include the extracted entities, the intent itself, the history of past user actions, etc. Programmers could consider context the “state” of the dialog.

Action

The action of a chat varies depending on the application.  At its most basic form, action is an API call that is only made when the bot receives the necessary parameters to satisfy a constraint. The Action is a database query using the search term(s) discovered from entity extraction.  In the case of our tool, Artemis, we are trying to get results to the users in an intuitive way which promotes intelligent hunting and effortless hypothesis checking.  The actions driven by Artemis are generally search and discovery, with the final result being an answer in the form of data.  Within the Endgame platform, Artemis allows the user to run efficient distributed search functions with parameters they specify through chat.

Intent

The concept of an intent is intimately tied to actions, but it is the human-facing side of a set of actions.  For example, searching for processes connecting to an IP and searching for IPs that received the most traffic are both ‘network’ intents, but the actions are different enough that the API calls internally are distinct.  The intent could be considered the part that gathers the parameters for the action function, but it also may decide which exact action to call.

Figure 2 -- Foundation of Artemis architecture

Entities

Entities are the final core component of our chatbot, Artemis. Entities can be thought of as the parameters needed to satisfy constraints stated within Intents that ultimately lead to the execution of Actions. For example, in the sentence: “Search processes for the filenames calc.exe;explorer.exe” we would like to perform Named Entity Recognition on the filenames. Unlike a finite list of known pizza toppings or airport codes, the list of possible process names is nearly infinite (well something more like 1.9820064666e+493 on Windows with a Latin-1) so we can’t possibly hardcode all of them. One option is to write (or copy from stack overflow) a regular expression akin to the 86 ascii characters for string lengths 1 to 255 to match filenames. Unfortunately, this would match all of the words in this paragraph as well, so we need the ‘file|filename|process’ tag specifier as well or use a Named Entity Recognizer model which we detail later.

Natural Language Understanding

Although we built the architecture to handle a wide range of use cases, in every data scientist’s life, the inevitable handling of missing data must occur. To handle missing information, we had to improve Artemis’ ability to understand user supplied language. After all, we can only discover missing information after we identify what has already been supplied. We integrated a pipeline similar to what is depicted in Figure 3 to perform the following process:

1. Take a user’s utterance and break apart the sentences into words (Tokenization)

2. Create features from tokenized words (Bag-of-Words -- BoW)

3. Perform Named Entity Recognition (NER) to extract the query parameters

4. Redact the user utterance with entity labels (reduces the vocabulary Artemis needs to model)

5. Extract Bag of Words to use as features against a supervised learning model

6. Make a prediction on user input to determine intent (Intent Classification)

7. Acquire all necessary data to carry out an action in Artemis (Perform Action).

Figure 3 -- Artemis natural language understanding pipeline

Within this pipeline, there are several key components that warrant additional clarification, and are described below.

Tokenizing

Tokenizing refers to the breaking apart of sentences into separate words, often on whitespace. This facilitates the tagging and extraction in the subsequent steps.

POS Tagging

Parts-of-speech tagging is different from named entity recognition in that instead of a proper name like “Windows Filename” we are looking for more universal parts of speech like “noun” or “verb”, etc.  These parts of speech are defined through the grammar of the language, not by the problem domain (in our case: cybersecurity, aka computers).  Many linguists often use tags to facilitate building relevant models.

Figure 4 -- Part-of-speech tagging on a tokenized string

Entity Extraction

Entities are the items which are not parts of speech but are interesting to your domain of research.  For example, in the domain of information security you might want to extract operating systems, IP addresses or CVEs.  They are all generally “nouns” but you can assign more meaning to them by declaring them special entities in your NLP pipeline and either matching them explicitly or training named entity recognizers (NER) to identify what kind of entity they are.  For example, if you have a corpus of text where “the vulnerability CVE-2017-0069” shows up if someone else writes “the vulnerability CVE-2017-0107”, an NER model can predict or infer “CVE-2017-0107” refers to a CVE.  However, a regex may work better in production.

Intent Classification

Intent classification can be thought of as taking a user input and assigning the appropriate category. This process is achieved by training a supervised learning model, which we have explained inpreviousposts. Unlike other intent classifiers, we leverage the entity extractor prior to classifying the user intent so the intent model can see a “redacted” sentence. This redacted sentence removes unique entities (i.e. filename or domain names) and replaces them with a label (i.e. ENT-FILE or ENT-DOMAIN). By performing this step first we can significantly reduce the size of our vocabulary, a core feature in our model. This reduces the overall size of the model and increases the overall speed of a response!

Dependency Parsing

Dependency parsing involves analyzing a sentence based on the sequence of the words and which word comes next.  When shown in graphical form (Figure 5), you can see how each word depends on another and how those links and the words represent parts of speech. For instance, the phrase: “Show me network traffic from 10.0.100 to 10.0.5.10” should be trivial for the intent classifier to correctly predict. After all the bigram “network traffic” is a strong indicator of the intent search_network. Likewise, entity extraction is simple enough since the structure of IP addresses are unique (i.e. all numbers with 3 periods). But for Artemis to return the correct data we must understand the source and the destination IPs. Otherwise, we could return suboptimal results.

Figure 5 -- Visualization of SpaCy’s dependency parser

Conclusion

Behind every successful chatbot, there is a logical, scientifically-driven NLU model. Having walked through the core components that together comprise the data science behind Endgame’s chatbot, Artemis, we hope that some of the mystery behind chatbots is replaced with a better understanding of the depth of research on which it was built. However, as we continue to emphasize, neither a well-designed user experience nor a properly specified NLU approach alone are sufficient to meet the needs of security analysts and operators. NLU and user experience together are required to ensure a chatbot moves beyond hype and provides an operationally essential capability for our customers.

Resources

If you want to learn more about building your own bots and the tools required to pull it off we recommend the following resources:

• http://www.wildml.com/2016/04/deep-learning-for-chatbots-part-1-introduction/
• http://www.wildml.com/2016/07/deep-learning-for-chatbots-2-retrieval-based-model-tensorflow/
• https://stanfy.com/blog/advanced-natural-language-processing-tools-for-bot-makers/
• https://medium.com/lastmile-conversations/do-it-yourself-nlp-for-bot-developers-2e2da2817f3d#.q6xoefkp2
• https://medium.com/the-mission/how-i-turned-my-resume-into-a-bot-and-how-you-can-too-f03847352baa#.d74niojp5
• https://blog.acolyer.org/2016/06/27/on-chatbots/
• https://medium.com/@surmenok/chatbot-architecture-496f5bf820ed#.k0aj6weqk
• https://api.ai/blog/2015/11/09/SlotFilling/
• https://wit.ai/
• https://x.ai/how-to-teach-a-machine-to-understand-us/
• http://www.nltk.org/
• https://spacy.io/
• https://textblob.readthedocs.io/en/dev/
• http://scikit-learn.org/stable/
• https://keras.io/

Process injection is a widespread defense evasion technique employed often within malware and fileless adversary tradecraft, and entails running custom code within the address space of another process. Process injection improves stealth, and some techniques also achieve persistence. Although there are numerous process injection techniques, in this blog I present ten techniques seen in the wild that run malware code on behalf of another process. I additionally provide screenshots for many of these techniques to facilitate reverse engineering and malware analysis, assisting detection and defense against these common techniques. 

1. Classic DLL Injection Via CreateRemoteThread and LoadLibrary

This technique is one of the most common techniques used to inject malware into another process. The malware writes the path to its malicious dynamic-link library (DLL) in the virtual address space of another process, and ensures the remote process loads it by creating a remote thread in the target process.

The malware first needs to target a process for injection (e.g. svchost.exe). This is usually done by searching through processes by calling a trio of Application Program Interfaces (APIs): CreateToolhelp32Snapshot, Process32First, and Process32Next. CreateToolhelp32Snapshot is an API used for enumerating heap or module states of a specified process or all processes, and it returns a snapshot. Process32First retrieves information about the first process in the snapshot, and then Process32Next is used in a loop to iterate through them. After finding the target process, the malware gets the handle of the target process by calling OpenProcess.

As shown in Figure 1, the malware calls VirtualAllocEx to have a space to write the path to its DLL. The malware then calls WriteProcessMemory to write the path in the allocated memory. Finally, to have the code executed in another process, the malware calls APIs such as CreateRemoteThread, NtCreateThreadEx, or RtlCreateUserThread. The latter two are undocumented. However, the general idea is to pass the address of LoadLibrary to one of these APIs so that a remote process has to execute the DLL on behalf of the malware.

CreateRemoteThread is tracked and flagged by many security products.  Further, it requires a malicious DLL on disk which could be detected.  Considering that attackers are most commonly injecting code to evade defenses, sophisticated attackers probably will not use this approach. The screenshot below displays a malware named Rebhip performing this technique.

Figure 1: Rebhip worm performing a typical DLL injection
Sha256: 07b8f25e7b536f5b6f686c12d04edc37e11347c8acd5c53f98a174723078c365

2. Portable Executable Injection (PE Injection)

Instead of passing the address of the LoadLibrary, malware can copy its malicious code into an existing open process and cause it to execute (either via a small shellcode, or by calling CreateRemoteThread). One advantage of PE injection over the LoadLibrary technique is that the malware does not have to drop a malicious DLL on the disk. Similar to the first technique, the malware allocates memory in a host process (e.g. VirtualAllocEx), and instead of writing a “DLL path” it writes its malicious code by calling WriteProcessMemory. However, the obstacle with this approach is the change of the base address of the copied image. When a malware injects its PE into another process it will have a new base address which is unpredictable, requiring it to dynamically recompute the fixed addresses of its PE. To overcome this, the malware needs to find its relocation table address in the host process, and resolve the absolute addresses of the copied image by looping through its relocation descriptors.

This technique is similar to other techniques, such as reflective DLL injection and memory module, since they do not drop any files to the disk. However, memory module and reflective DLL injection approaches are even stealthier. They do not rely on any extra Windows APIs (e.g., CreateRemoteThread or LoadLibrary), because they load and execute themselves in the memory. Reflective DLL injection works by creating a DLL that maps itself into memory when executed, instead of relying on the Window’s loader. Memory Module is similar to Reflective DLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself. In a previous blog post, these two in memory approaches were discussed extensively.

When analyzing PE injection, it is very common to see loops (usually two “for” loops, one nested in the other), before a call to CreateRemoteThread.  This technique is quite popular among crypters (softwares that encrypt and obfuscate malware). In Figure 2, the sample unit test is taking advantage of this technique. The code has two nested loops to adjust its relocation table that can be seen before the calls to WriteProcessMemory and CreateRemoteThread. The “and 0x0fff” instruction is also another good indicator, showing that the first 12 bits are used to get the offset into the virtual address of the containing relocation block. Now that the malware has recomputed all the necessary addresses, all it needs to do is pass its starting address to CreateRemoteThread and have it executed.

Figure 2: Example structure of the loops for PE injection prior to calls to CreateRemoteThread
Sha256: ce8d7590182db2e51372a4a04d6a0927a65b2640739f9ec01cfd6c143b1110da

3. Process Hollowing (a.k.a Process Replacement and RunPE)

Instead of injecting code into a host program (e.g., DLL injection), malware can perform a technique known as process hollowing. Process hollowing occurs when a malware unmaps (hollows out) the legitimate code from memory of the target process, and overwrites the memory space of the target process (e.g., svchost.exe) with a malicious executable.

The malware first creates a new process to host the malicious code in suspended mode. As shown in Figure 3, this is done by calling CreateProcess and setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004). The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called. Next, the malware needs to swap out the contents of the legitimate file with its malicious payload. This is done by unmapping the memory of the target process by calling either ZwUnmapViewOfSection or NtUnmapViewOfSection. These two APIs basically release all memory pointed to by a section. Now that the memory is unmapped, the loader performs VirtualAllocEx to allocate new memory for the malware, and uses WriteProcessMemory to write each of the malware’s sections to the target process space. The malware calls SetThreadContext to point the entrypoint to a new code section that it has written. At the end, the malware resumes the suspended thread by calling ResumeThread to take the process out of suspended state.

Figure 3: Ransom.Cryak performing process hollowing
Sha256: eae72d803bf67df22526f50fc7ab84d838efb2865c27aef1a61592b1c520d144

4. Thread Execution Hijacking (a.k.a Suspend, Inject, and Resume (SIR))

This technique has some similarities to the process hollowing technique previously discussed. In thread execution hijacking, malware targets an existing thread of a process and avoids any noisy process or thread creations operations. Therefore, during analysis you will probably see calls to CreateToolhelp32Snapshot and Thread32First followed by OpenThread.

After getting a handle to the target thread, the malware puts the thread into suspended mode by calling SuspendThread to perform its injection. The malware calls VirtualAllocEx and WriteProcessMemory to allocate memory and perform the code injection. The code can contain shellcode, the path to the malicious DLL, and the address of LoadLibrary.

Figure 4 illustrates a generic trojan using this technique. In order to hijack the execution of the thread, the malware modifies the EIP register (a register that contains the address of the next instruction) of the targeted thread by calling SetThreadContext. Afterwards, malware resumes the thread to execute the shellcode that it has written to the host process. From the attacker’s perspective, the SIR approach can be problematic because suspending and resuming a thread in the middle of a system call can cause the system to crash. To avoid this, a more sophisticated malware would resume and retry later if the EIP register is within the range of NTDLL.dll.

Figure 4: A generic trojan is performing thread execution hijacking
Sha256:787cbc8a6d1bc58ea169e51e1ad029a637f22560660cc129ab8a099a745bd50e

5. Hook Injection via SetWindowsHookEx

Hooking is a technique used to intercept function calls. Malware can leverage hooking functionality to have their malicious DLL loaded upon an event getting triggered in a specific thread. This is usually done by calling SetWindowsHookEx to install a hook routine into the hook chain. The SetWindowsHookEx function takes four arguments. The first argument is the type of event. The events reflect the range of hook types, and vary from pressing keys on the keyboard (WH_KEYBOARD) to inputs to the mouse (WH_MOUSE), CBT, etc. The second argument is a pointer to the function the malware wants to invoke upon the event execution.The third argument is a module that contains the function. Thus, it is very common to see calls to LoadLibrary and GetProcAddress before calling SetWindowsHookEx. The last argument to this function is the thread with which the hook procedure is to be associated. If this value is set to zero all threads perform the action when the event is triggered. However, malware usually targets one thread for less noise, thus it is also possible to see calls CreateToolhelp32Snapshot and Thread32Next before SetWindowsHookEx to find and target a single thread. Once the DLL is injected, the malware executes its malicious code on behalf of the process that its threadId was passed to SetWindowsHookEx function. In Figure 5, Locky Ransomware implements this technique.

Figure 5: Locky Ransomware using hook injection
Sha256: 5d6ddb8458ee5ab99f3e7d9a21490ff4e5bc9808e18b9e20b6dc2c5b27927ba1

6. Injection and Persistence via Registry Modification (e.g. AppInit_DLLs, AppCertDlls, IFEO)

Appinit_DLL, AppCertDlls, and IFEO (Image File Execution Options) are all registry keys that malware uses for both injection and persistence. The entries are located at the following locations:

   HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls
   HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls
   HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls
   HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options

AppInit_DLLs
Malware can insert the location of their malicious library under the Appinit_Dlls registry key to have another process load their library. Every library under this registry key is loaded into every process that loads User32.dll. User32.dll is a very common library used for storing graphical elements such as dialog boxes. Thus, when a malware modifies this subkey, the majority of processes will load the malicious library. Figure 6 demonstrates the trojan Ginwui relying on this approach for injection and persistence. It simply opens the Appinit_Dlls registry key by calling RegCreateKeyEx, and modifies its values by calling RegSetValueEx.

Figure 6: Ginwui modifying the AppIniti_DLLs registry key
Sha256: 9f10ec2786a10971eddc919a5e87a927c652e1655ddbbae72d376856d30fa27c

AppCertDlls
This approach is very similar to the AppInit_DLLs approach, except that DLLs under this registry key are loaded into every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW, and WinExec.

Image File Execution Options (IFEO)
IFEO is typically used for debugging purposes. Developers can set the “Debugger Value” under this registry key to attach a program to another executable for debugging. Therefore, whenever the executable is launched the program that is attached to it will be launched. To use this feature you can simply give the path to the debugger, and attach it to the executable that you want to analyze. Malware can modify this registry key to inject itself into the target executable. In Figure 7, Diztakun trojan implements this technique by modifying the debugger value of Task Manager.

Figure 7: Diztakun trojan modifying IFEO registry key
Sha256: f0089056fc6a314713077273c5910f878813fa750f801dfca4ae7e9d7578a148

7. APC Injection and AtomBombing

Malware can take advantage of Asynchronous Procedure Calls (APC) to force another thread to execute their custom code by attaching it to the APC Queue of the target thread. Each thread has a queue of APCs which are waiting for execution upon the target thread entering alterable state. A thread enters an alertable state if it calls SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx, or WaitForSingleObjectEx functions. The malware usually looks for any thread that is in an alterable state, and then calls OpenThread and QueueUserAPC to queue an APC to a thread. QueueUserAPC takes three arguments: 1) a handle to the target thread; 2) a pointer to the function that the malware wants to run; 3) and the parameter that is passed to the function pointer. In Figure 8, Amanahe malware first calls OpenThread to acquire a handle of another thread, and then calls QueueUserAPC with LoadLibraryA as the function pointer to inject its malicious DLL into another thread.

AtomBombing is a technique that was first introduced by enSilo research, and then used in Dridex V4. As we discussed in detail in a previous post, the technique also relies on APC injection. However, it uses atom tables for writing into memory of another process.

Figure 8: Almanahe performing APC injection
Sha256: f74399cc0be275376dad23151e3d0c2e2a1c966e6db6a695a05ec1a30551c0ad

8. Extra Window Memory Injection (EWMI) Via SetWindowLong

EWMI relies on injecting into Explorer tray window’s extra window memory, and has been used a few times among malware families such as Gapz and PowerLoader. When registering a window class, an application can specify a number of additional bytes of memory, called extra window memory (EWM). However, there is not much room in EWM. To circumvent this limitation, the malware writes code into a shared section of explorer.exe, and uses SetWindowLong and SendNotifyMessage to have a function pointer to point to the shellcode, and then execute it.

The malware has two options when it comes to writing into a shared section. It can either create a shared section and have it mapped both to itself and to another process (e.g., explorer.exe), or it can simply open a shared section that already exists. The former has the overhead of allocating heap space and calling NTMapViewOfSection in addition to a few other API calls, so the latter approach is used more often. After malware writes its shellcode in a shared section, it uses GetWindowLong and SetWindowLong to access and modify the extra window memory of “Shell_TrayWnd”. GetWindowLong is an API used to retrieve the 32-bit value at the specified offset into the extra window memory of a window class object, and SetWindowLong is used to change values at the specified offset. By doing this, the malware can simply change the offset of a function pointer in the window class, and point it to the shellcode written to the shared section.

Like most other techniques mentioned above, the malware needs to trigger the code that it has written. In previously discussed techniques, malware achieved this by calling APIs such as CreateRemoteThread, QueueUserAPC, or SetThreadContext. With this approach, the malware instead triggers the injected code by calling SendNotifyMessage. Upon execution of SendNotifyMessage, Shell_TrayWnd receives and transfers control to the address pointed to by the value previously set by SetWindowLong. In Figure 9, a malware named PowerLoader uses this technique.

Figure 9: PowerLoader injecting into extra window memory of shell tray window
Sha256: 5e56a3c4d4c304ee6278df0b32afb62bd0dd01e2a9894ad007f4cc5f873ab5cf

9. Injection using Shims

Microsoft provides Shims to developers mainly for backward compatibility. Shims allow developers to apply fixes to their programs without the need of rewriting code. By leveraging shims, developers can tell the operating system how to handle their application. Shims are essentially a way of hooking into APIs and targeting specific executables. Malware can take advantage of shims to target an executable for both persistence and injection. Windows runs the Shim Engine when it loads a binary to check for shimming databases in order to apply the appropriate fixes.

There are many fixes that can be applied, but malware’s favorites are the ones that are somewhat security related (e.g., DisableNX, DisableSEH, InjectDLL, etc). To install a shimming database, malware can deploy various approaches. For example, one common approach is to simply execute sdbinst.exe, and point it to the malicious sdb file. In Figure 10, an adware,  “Search Protect by Conduit”,  uses a shim for persistence and injection. It performs an “InjectDLL” shim into Google Chrome to load vc32loader.dll. There are a few existing tools for analyzing sdb files, but for the analysis of the sdb listed below, I used python-sdb.

Figure10: SDB used by Search Protect for injection purposes
Sha256: 6d5048baf2c3bba85adc9ac5ffd96b21c9a27d76003c4aa657157978d7437a20

10. IAT Hooking and Inline Hooking (a.k.a userland rootkits)

IAT hooking and inline hooking are generally known as userland rootkits. IAT hooking is a technique that malware uses to change the import address table. When a legitimate application calls an API located in a DLL, the replaced function is executed instead of the original one. In contrast, with inline hooking, malware modifies the API function itself. In Figure 11, the malware FinFisher, performs IAT hooking by modifying where the CreateWindowEx points.  

Figure 11: FinFisher performing IAT hooking by changing where CreateWindowEx points to
Sha256: f827c92fbe832db3f09f47fe0dcaafd89b40c7064ab90833a1f418f2d1e75e8e

Conclusion

In this post, I covered ten different techniques that malware uses to hide its activity in another process. In general, malware either directly injects its shellcode into another process or it forces another process to load its malicious library. In Table 1, I have classified the various techniques and provided samples to serve as a reference for observing each injection technique covered in this post. The figures included throughout the post will help the researcher recognize the various techniques when reversing malware.  

Table1: Process injection can be done by directly injecting code into another process, or by forcing a DLL to be loaded into another process

Attackers and researchers regularly discover new techniques to achieve injection and provide stealth. This post detailed ten common and emerging techniques, but there are others, such as COM hijacking. Defenders will never be “done” in their mission to detect and prevent stealthy process injection because adversaries will never stop innovating.

At Endgame, we constantly research advanced stealth techniques and bring protections into our product. We layer capabilities which detect malicious DLLs that load on some persistence (like AppInit DLLs, COM Hijacks, and more), prevent many forms of code injection in real-time via our patented shellcode injection protection, and detect malicious injected payloads running in memory delivered through any of the above techniques through our patent-pending fileless attack detection techniques. This approach allows our platform to be more effective than any other product on the market in protecting against code injection, while also maximizing resiliency against bypass due to emerging code injection techniques.  

Author: David Murray, Chief Business Development Officer, Corvil

The time of solely providing a constant stream of security alerts is over.  It has gone the way of the buggy whip, the mullet, and the virtual moat (firewall) or physical moat as the primary line of defense!  

Unlike the mullet, there is no party in the back for security analysts today.  There is too much for analysts to manage – the most dangerous attacks are too targeted for signature alerts to keep up, the attack surface is too large and constantly changing, and adept cyber-attackers know how to circumvent many known defenses.   In economics terms, the cost to launch a successful cyberattack is falling.  Diversity of techniques, accessibility of technologies and codebase, availability of data for successful phishing and social engineering, and diversity of motivations have all contributed to the increase in supply.   Inversely, the cost of defending against cyberattack is rising and the necessary talent to protect is in short supply.

Way Beyond the Basics

Analysis techniques that automate the discovery of unpatched or unprotected endpoints on the network are necessary, but not sufficient.  Good hygiene always counts as does user education.   However, companies must operate as if in a perpetual state of breach.  Analyzing how machines are communicating with others and correlating user accounts exhibiting risky behaviors that are active on those endpoints, is eminently valuable because it more effectively identifies and prioritizes risk.  Looking deep inside the riskiest machines to hunt for suspicious artifacts and other evidence of never-before-seen attacks techniques is yet another layer of a more effective protection strategy. 

Stepping back and looking at customer needs, what we see is a security analyst workflow that is manual today, and repeated again and again until their brains get numb.  Each step of the workflow answers an additional set of questions about the level of risk -  each step gathers more information and correlates it to help the analyst decide what actions he/she should take.  There are several manual workflows like this depending on infrastructure starting point. 

For example:

1. Endpoint solution detects some new malware variant on the machine
2. Analyst seeks information on origin through various other tools
3. Analyst seeks information on what other machines have been in communication with that host through various other tools
4. Analyst seeks what user accounts have been active on that machine and others, what has been communicated, etc., etc. through various other tools

Streamlining the workflow with automated data collection, analysis, correlation of information across network and endpoint surfaces, and contextual navigation for gaining more information and actioning the findings should help analysts return to business in the front.  This automated analysis can help free security analysts from the endless mire of mundane and time-consuming investigative tasks so they can focus on more complex analysis, protections, and prevention.  As Jamie Butler, CTO of Endgame, puts it “AI should be seen as a multiplier, not a silver bullet.”  While his comment specifically references machine learning approaches, it seems applicable to any set of automated analysis techniques.  Unfortunately, the data and analysis skills needed to understand time-series machine communications to track lateral user movement is totally different from the data and skills needed to hunt for exploits in machine memory or recognizing new endpoint attack tactics.

The domain expertise needed to build and optimize the automation resides in separate organizations. Advanced network communications expertise and endpoint expertise have lived in different worlds – and it has been tough to get either to work with data scientists to create analytics models that are operationally useful and with solution engineers to build platforms capable of doing the analysis at scale.  Hence Corvil’s focus on network analysis/automation and Endgame’s focus on endpoint analysis/automation. 

However, these different innovations in automated analysis must find ways to work together to be effective productivity multipliers for overworked security analysts – and that is what Corvil’s partnership with Endgame is all about.  

Today, we announced a partner and integration that ties together leaders in security analysis and protection for network and endpoint to help ease the burden for security analysts and provide a more effective visibility and protection fabric for customers.

While each organization services customers across many industries, our respective heritage in financial services and defense bring together a wealth of experiences and capabilities that are needed everywhere.   We share a commitment to empower security analysts of any skill level to do more, both extended innovations in the area of machine learning and both having introduced chatbot / virtual assistant capabilities in Endgame Artemis™ and Corvil Cara. 

While we are not advocating a return of the mullet, we are certainly providing an all-business approach to cyber protection and visibility with multipliers to elevate security analysts at all levels.   If that affords analysts a much-needed relief to party, then so much the better!