Archive

Archive for the ‘Advanced persistent threats’ Category

Reverse-engineering DUBNIUM

June 10th, 2016 No comments

DUBNIUM (which shares indicators with what Kaspersky researchers have called DarkHotel) is one of the activity groups that has been very active in recent years, and has many distinctive features.

We located multiple variants of multiple-stage droppers and payloads in the last few months, and although they are not really packed or obfuscated in a conventional way, they use their own methods and tactics of obfuscation and distraction.

In this blog, we will focus on analysis of the first-stage payload of the malware.

As the code is very complicated and twisted in many ways, it is a complex task to reverse-engineer the malware. The complexity of the malware includes linking with unrelated code statically (so that their logic can hide in a big, benign code dump) and excessive use of an in-house encoding scheme. Their bootstrap logic is also hidden in plain sight, such that it might be easy to miss.

Every sub-routine from the malicious code has a “memory cleaner routine” when the logic ends. The memory snapshot of the process will not disclose many more details than the static binary itself.

The malware is also very sneaky and sensitive to dynamic analysis. When it detects the existence of analysis toolsets, the executable file bails out from further execution. Even binary instrumentation tools like PIN or DynamoRio prevent the malware from running. This effectively defeats many automation systems that rely on at least one of the toolsets they check to avoid. Avoiding these toolsets during analysis makes the overall investigation even more complex.

With this blog series, we want to discuss some of the simple techniques and tactics we’ve used to break down the features of DUBNIUM.

We acquired multiple versions of DUBNIUM droppers through our daily operations. They are evolving slowly, but basically their features have not changed over the last few months.

In this blog, we’ll be using sample SHA1: dc3ab3f6af87405d889b6af2557c835d7b7ed588 in our examples and analysis.

Hiding in plain sight

The malware used in a DUBNIUM attack is committed to disguising itself as Secure Shell (SSH) tool. In this instance, it is attempting to look like a certificate generation tool. The file descriptions and other properties of the malware look convincingly legitimate at first glance.

Figure 1: SSH tool disguise

Figure 1: SSH tool disguise

 

When it is run, the program actually dumps out dummy certificate files into the file system and, again, this can be very convincing to an analyst who is initially researching the file.

Figure 2 Create dummy certificate files

Figure 2 Create dummy certificate files

 

The binary is indeed statically linked with OpenSSL library, such that it really does look like an SSH tool. The problem with reverse engineering this sample starts from the fact that it has more than 2,000 functions and most of them are statically linked to OpenSSL code without symbols.

Figure 3: DUBNIUM functions list

Figure 3: DUBNIUM functions list

 

The following is an example of one of these functions – note it even has string references to the source code file name.

Figure 4: Code snippet that is linked from OpenSSL library

Figure 4: Code snippet that is linked from OpenSSL library

 

It can be extremely time-consuming just going through the dump of functions that have no meaning at all in the code – and this is only one of the more simplistic tactics this malware is using.

We can solve this problem using binary similarity calculation. This technique has been around for years for various purposes, and it can be used to detect code that steals copyrighted code from other software.

The technique can be used to find patched code snippets in the software and to find code that was vulnerable for attack. In this instance, we can use the same technique to clean up unnecessary code snippets from our advanced persistent threat (APT) analysis and make a reverse engineer’s life easier.

Many different algorithms exist for binary similarity calculation, but we are going to use one of the simplest approach here. The algorithm will collect the op-code strings of each instruction in the function first (Figure 5). It will then concatenate the whole string and will use a hash algorithm to get the hash out of it. We used the SHA1 hash in this case.

Figure 5: Op code in the instructions

Figure 5: Op code in the instructions

 

Figure 6 shows the Python-style pseudo-code that calculates the hash for a function. Sometimes, the immediate constant operand is a valuable piece of information that can be used to distinguish similar but different functions and it also includes the value in the hash string. It is using our own utility function RetrieveFunctionInstructions which returns a list of op-code and operand values from a designated function.


01 def CalculateFunctionHash(self,func_ea):
02     hash_string=''
03     for (op, operand) in self.RetrieveFunctionInstructions(func_ea):
04            hash_string+=op
05            if len(drefs)==0:
06                  for operand in operands:
07                         if operand.Type==idaapi.o_imm:
08                                hash _string+=('%x' % operand.Value)
09
10     m=hashlib.sha1()
11     m.update(op_string)
12     return m.hexdigest()

Figure 6: Pseudo-code for CalculateFunctionHash

With these hash values calculated for the DUBNIUM binary, we can compare these values with the hash values from the original OpenSSL library. We identified from the compiler-generated meta-data that the version the sample is linked to is openssl-1.0.1l-i386-win. After gathering same hash from the OpenSSL library, we could import symbols for the matched functions. In this way, removed most of the functions from our analysis scope.

Figure 7: OpenSSL functions

Figure 7: OpenSSL functions

(This blog is continued on the next page)

Digging deep for PLATINUM

There is no shortage of headlines about cybercriminals launching large-scale attacks against organizations. For us, the activity groups that pose the most danger are the ones who selectively target organizations and desire to stay undetected, protect their investment, and maximize their ROI. That’s what motivated us – the Windows Defender Advanced Threat Hunting team, known as hunters – when we recently discovered a novel technique being used by one such activity group.

We have code named this group PLATINUM, following our internal practice of assigning rogue actors chemical element names. Based on our investigations, we know PLATINUM has been active since 2009 and primarily targets governmental organizations, defense institutes, intelligence agencies, and telecommunication providers in South and Southeast Asia. The group has gone to great lengths to develop covert techniques that allow them to conduct cyber-espionage campaigns for years without being detected.

Uncovering these kinds of techniques is true detective work, and finding them in the wild is a challenge, but with the wealth of anonymized information we can utilize from over 1 billion Windows devices, a broad spectrum of services, Microsoft’s intelligent security graph as well as advanced analytics and machine algorithms to surface suspicious behaviors, Microsoft is in the best position to do so.

Digging up the nugget

Through our advanced and persistent hunting, we discovered PLATINUM is using hotpatching as a technique to attempt to cloak a backdoor they use. Using hotpatching in the malicious context has been theorized [1], [2], but has not been observed in the wild before. Finding such techniques is a focus of the Microsoft APT hunter team, and we want to provide some brief insights on how the team dug up this PLATINUM “nugget”.

In the first part of this methodology, a hunter carves out some rough data sets from existing information and data that can be further analyzed. This could be based on rough heuristics, such as looking for files with high entropy, that were first observed recently, and that are confined to a geographic region that fits the profile of the activity group being investigated.

Carving the data still yields large data sets that can’t be manually analyzed, and advanced threat analytics can help in sorting through the data for meaningful information in the second step. Graph inferences through the Microsoft intelligent security graph can bubble pieces of information to the top of the queue for a hunter to choose from. In the PLATINUM investigation, we identified 31 files.

Lastly, the hunter works directly with the resulting set. During this stage of the PLATINUM investigation, a hunter found a file with unusual string (“.hotp1”). The hunter’s experience and intuition drove him to dig deeper. In this case, that further investigation led us to the malicious use of hotpatching by this activity group and the “nugget” was uncovered.

Deconstructing the attack

So what is hotpatching? Hotpatching is a previously supported OS feature for installing updates without having to reboot or restart a process. It requires administrator-level permissions, and at a high level, a hotpatcher can transparently apply patches to executables and DLLs in actively running processes.

Using hotpatching in a malicious context is a technique that can be used to avoid being detected, as many antimalware solutions monitor non-system processes for regular injection methods, such as CreateRemoteThread. Hotpatching originally shipped with Windows Server 2003 and was used to ship 10 patches to Windows Server 2003. Windows 10, our most secure operating system ever, is not susceptible to this and many other techniques and attack vectors.

What this means in practical terms is that PLATINUM was able to abuse this feature to hide their backdoor from the behavioral sensors of many host security products. We first observed a sample employing the hotpatching technique on a machine in Malaysia. This allowed PLATINUM to gain persistent access to the networks of companies it targeted and victimized over a long period without being detected.

Thwarting the bad guys

The Microsoft APT hunter team actively tracks activity groups like PLATINUM. We proactively identify these groups and the techniques they use and work to address vulnerabilities and implement security mitigations. The team builds detections and threat intelligence that are utilized by many of our products and services. Beta users of Windows Defender ATP can take advantage of this additional layer of protection and intelligence for a broad set of activity groups.

We’ve included a more technical exploration of  our research and detection of the hotpatching technique in the remainder of this blog.

You can also see a closer look at the PLATINUM activity group in our report PLATINUM: Targeted attacks in South and Southeast Asia. Windows Defender Advanced Threat Protection beta and preview users can also find the report, along with other APT activity group reports, in the Windows Defender ATP portal.

We continue to dig for PLATINUM.

The Windows Defender Advanced Threat Hunting Team

Hotpatching – a case study

We first observed the sample (Sample1) that is capable of utilizing hotpatching on a machine in Malaysia (which matches the general target profile of PLATINUM) on January 28, 2016 . The portable executable (PE) timestamp, which can be arbitrarily set by the adversary, dates back to August 9, 2015, while the unpacked version contains a PE timestamp for November 26, 2015.

It is a DLL that runs as a service and serves as an injector component of a backdoor. Interestingly, this sample not only supported the hotpatching technique described in this post, but was able to apply more common code-injection techniques, including the following, into common Windows processes (primarily targeting winlogon.exe, lsass.exe and svchost.exe):

  • CreateRemoteThread
  • NtQueueApcThread to run an APC in a thread in the target process
  • RtlCreatUserThread
  • NtCreateThreadEx

Hotpatching technique

For hotpatching, the sample goes through the following steps:

  1. It patches the loader with a proper hotpatch to treat injected DLLs with execute page permissions. This step is required for DLLs loaded from memory (in an attempt to further conceal the malicious code).
  2. The backdoor is injected into svchost using the hotpatch API.

Patching the loader is done by creating a section named “knowndllsmstbl.dll”. This DLL does not reside on-disk, but is rather treated as a cached DLL by the session manager.

It then proceeds to write a PE file within that section. The PE file will have one section (“.hotp1 “) with the hotpatch header structure. This structure contains all the information necessary to perform the patching of the function “ntdll!LdrpMapViewOfSection” used by the loader, such that the loader will treat created sections as PAGE_EXECUTE_READWRITE instead of PAGE_READWRITE. The patch is successfully applied by invoking NtSetSystemInformation.

The malware builds the information describing the first patch

Figure 1: The malware builds the information describing the first patch

 

The highlighted "push 4" is patched to "push 0x40", meaning that the parameter for the following API call NtMapViewOfSection is changed from PAGE_READWRITE to PAGE_EXECUTE_READWRITE.

Figure 2: The highlighted “push 4″ is patched to “push 0x40″, meaning that the parameter for the following API call NtMapViewOfSection is changed from PAGE_READWRITE to PAGE_EXECUTE_READWRITE.

Now that the memory permission issue has been solved, the injector can proceed with injecting the malicious DLL into svchost. Again, it creates a (now executable) section named “knowndllsfgrps.dll” and invokes NtSetSystemInformation, causing the final payload to be loaded and executed within the target process (svchost).

Trying to hide the payload using hotpatching also falls in line with the last functional insights we have on the sample. It seems to have an expiry date of January 15, 2017 – at that point in time, the DLL will no longer perform the injection, but rather execute another PLATINUM implant:

C:program filesWindows JournalTemplatesCpljnwmon.exe –ua

This implant may be related to an uninstall routine. Note that we observed the sample last on the machine on September 3, 2015, which may indicate PLATINUM pulled the trigger earlier.

 


 

[1] http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sotirov.pdf

[2] https://www.yumpu.com/en/document/view/14255220/alexsyscan13

Digging deep for PLATINUM

There is no shortage of headlines about cybercriminals launching large-scale attacks against organizations. For us, the activity groups that pose the most danger are the ones who selectively target organizations and desire to stay undetected, protect their investment, and maximize their ROI. That’s what motivated us – the Windows Defender Advanced Threat Hunting team, known as hunters – when we recently discovered a novel technique being used by one such activity group.

We have code named this group PLATINUM, following our internal practice of assigning rogue actors chemical element names. Based on our investigations, we know PLATINUM has been active since 2009 and primarily targets governmental organizations, defense institutes, intelligence agencies, and telecommunication providers in South and Southeast Asia. The group has gone to great lengths to develop covert techniques that allow them to conduct cyber-espionage campaigns for years without being detected.

Uncovering these kinds of techniques is true detective work, and finding them in the wild is a challenge, but with the wealth of anonymized information we can utilize from over 1 billion Windows devices, a broad spectrum of services, Microsoft’s intelligent security graph as well as advanced analytics and machine algorithms to surface suspicious behaviors, Microsoft is in the best position to do so.

Digging up the nugget

Through our advanced and persistent hunting, we discovered PLATINUM is using hotpatching as a technique to attempt to cloak a backdoor they use. Using hotpatching in the malicious context has been theorized [1], [2], but has not been observed in the wild before. Finding such techniques is a focus of the Microsoft APT hunter team, and we want to provide some brief insights on how the team dug up this PLATINUM “nugget”.

In the first part of this methodology, a hunter carves out some rough data sets from existing information and data that can be further analyzed. This could be based on rough heuristics, such as looking for files with high entropy, that were first observed recently, and that are confined to a geographic region that fits the profile of the activity group being investigated.

Carving the data still yields large data sets that can’t be manually analyzed, and advanced threat analytics can help in sorting through the data for meaningful information in the second step. Graph inferences through the Microsoft intelligent security graph can bubble pieces of information to the top of the queue for a hunter to choose from. In the PLATINUM investigation, we identified 31 files.

Lastly, the hunter works directly with the resulting set. During this stage of the PLATINUM investigation, a hunter found a file with unusual string (“.hotp1”). The hunter’s experience and intuition drove him to dig deeper. In this case, that further investigation led us to the malicious use of hotpatching by this activity group and the “nugget” was uncovered.

Deconstructing the attack

So what is hotpatching? Hotpatching is a previously supported OS feature for installing updates without having to reboot or restart a process. It requires administrator-level permissions, and at a high level, a hotpatcher can transparently apply patches to executables and DLLs in actively running processes.

Using hotpatching in a malicious context is a technique that can be used to avoid being detected, as many antimalware solutions monitor non-system processes for regular injection methods, such as CreateRemoteThread. Hotpatching originally shipped with Windows Server 2003 and was used to ship 10 patches to Windows Server 2003. Windows 10, our most secure operating system ever, is not susceptible to this and many other techniques and attack vectors.

What this means in practical terms is that PLATINUM was able to abuse this feature to hide their backdoor from the behavioral sensors of many host security products. We first observed a sample employing the hotpatching technique on a machine in Malaysia. This allowed PLATINUM to gain persistent access to the networks of companies it targeted and victimized over a long period without being detected.

Thwarting the bad guys

The Microsoft APT hunter team actively tracks activity groups like PLATINUM. We proactively identify these groups and the techniques they use and work to address vulnerabilities and implement security mitigations. The team builds detections and threat intelligence that are utilized by many of our products and services. Beta users of Windows Defender ATP can take advantage of this additional layer of protection and intelligence for a broad set of activity groups.

We’ve included a more technical exploration of  our research and detection of the hotpatching technique in the remainder of this blog.

You can also see a closer look at the PLATINUM activity group in our report PLATINUM: Targeted attacks in South and Southeast Asia. Windows Defender Advanced Threat Protection beta and preview users can also find the report, along with other APT activity group reports, in the Windows Defender ATP portal.

We continue to dig for PLATINUM.

The Windows Defender Advanced Threat Hunting Team

Hotpatching – a case study

We first observed the sample (Sample1) that is capable of utilizing hotpatching on a machine in Malaysia (which matches the general target profile of PLATINUM) on January 28, 2016 . The portable executable (PE) timestamp, which can be arbitrarily set by the adversary, dates back to August 9, 2015, while the unpacked version contains a PE timestamp for November 26, 2015.

It is a DLL that runs as a service and serves as an injector component of a backdoor. Interestingly, this sample not only supported the hotpatching technique described in this post, but was able to apply more common code-injection techniques, including the following, into common Windows processes (primarily targeting winlogon.exe, lsass.exe and svchost.exe):

  • CreateRemoteThread
  • NtQueueApcThread to run an APC in a thread in the target process
  • RtlCreatUserThread
  • NtCreateThreadEx

Hotpatching technique

For hotpatching, the sample goes through the following steps:

  1. It patches the loader with a proper hotpatch to treat injected DLLs with execute page permissions. This step is required for DLLs loaded from memory (in an attempt to further conceal the malicious code).
  2. The backdoor is injected into svchost using the hotpatch API.

Patching the loader is done by creating a section named “knowndllsmstbl.dll”. This DLL does not reside on-disk, but is rather treated as a cached DLL by the session manager.

It then proceeds to write a PE file within that section. The PE file will have one section (“.hotp1 “) with the hotpatch header structure. This structure contains all the information necessary to perform the patching of the function “ntdll!LdrpMapViewOfSection” used by the loader, such that the loader will treat created sections as PAGE_EXECUTE_READWRITE instead of PAGE_READWRITE. The patch is successfully applied by invoking NtSetSystemInformation.

The malware builds the information describing the first patch

Figure 1: The malware builds the information describing the first patch

 

The highlighted "push 4" is patched to "push 0x40", meaning that the parameter for the following API call NtMapViewOfSection is changed from PAGE_READWRITE to PAGE_EXECUTE_READWRITE.

Figure 2: The highlighted “push 4″ is patched to “push 0x40″, meaning that the parameter for the following API call NtMapViewOfSection is changed from PAGE_READWRITE to PAGE_EXECUTE_READWRITE.

Now that the memory permission issue has been solved, the injector can proceed with injecting the malicious DLL into svchost. Again, it creates a (now executable) section named “knowndllsfgrps.dll” and invokes NtSetSystemInformation, causing the final payload to be loaded and executed within the target process (svchost).

Trying to hide the payload using hotpatching also falls in line with the last functional insights we have on the sample. It seems to have an expiry date of January 15, 2017 – at that point in time, the DLL will no longer perform the injection, but rather execute another PLATINUM implant:

C:program filesWindows JournalTemplatesCpljnwmon.exe –ua

This implant may be related to an uninstall routine. Note that we observed the sample last on the machine on September 3, 2015, which may indicate PLATINUM pulled the trigger earlier.

 


 

[1] http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sotirov.pdf

[2] https://www.yumpu.com/en/document/view/14255220/alexsyscan13