{"id":6327,"date":"2017-01-23T15:50:22","date_gmt":"2017-01-23T23:50:22","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/01\/23\/news-165\/"},"modified":"2017-01-23T15:50:22","modified_gmt":"2017-01-23T23:50:22","slug":"news-165","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/01\/23\/news-165\/","title":{"rendered":"Reverse engineering DUBNIUM \u2013Stage 2 payload analysis"},"content":{"rendered":"

Recently, we\u00a0blogged about the basic functionality and features of the DUBNIUM advanced persistent threat (APT) activity group Stage 1 binary and Adobe Flash exploit used during the December 2015 incident (Part 1<\/a>, Part 2<\/a>).<\/p>\n

In this blog, we will go through the overall infection chain structure and the Stage 2 executable details. Stage 2 executables are the core of this activity groups\u2019 operation, as it is the final payload delivered to possible targets that matches its profile.<\/p>\n

Infection chain overview<\/h1>\n

The picture below shows the overall infection chain we analyzed.<\/p>\n

\"Flow<\/a><\/p>\n

Figure 1: Infection chain overview<\/em><\/p>\n

 <\/p>\n

In most cases, the daily operation of the DUBNIUM APT depends on social engineering through spear-phishing. They are observed to mainly rely on an .LNK<\/em> file that has an icon that looks like a Microsoft Word file. If the victim clicks the file thinking it\u2019s a Microsoft Office Word file, it downloads a simple dropper that will download and execute next stage binary \u2013 which in this case, has the file name of kernelol21.exe<\/em>.<\/p>\n

The Stage 1 binary extensively checks-up on the system for the existence of security products or usual analysis tools for the reverse engineers or security analysts. It will pass the client\u2019s IP address, hostname, MAC address, software profile information, and locale information to the download server. When the server thinks that the client matches profile for possible prospect, the next stage dropper will be downloaded.<\/p>\n

 <\/p>\n

Stage 0: Social Engineering vs. Exploits<\/h2>\n

In our previous blogs we described the Adobe Flash Exploit the malware recently used. In this blog we want to provide a brief overview of the social engineering method DUBNIUM uses for its daily infection operations. The activity group uses the .LNK<\/em> file with an icon image of a Word document as one of its social engineering methods.<\/p>\n

\"Shortcut<\/a><\/p>\n

Figure 2<\/em>: Shortcut icon disguised as Word document<\/em><\/p>\n

 <\/p>\n

The shortcut contains commands to download and execute the next level executable or script. Unsuspecting victims will double click this icon and will be unknowingly launching a PowerShell command.<\/p>\n

\"The<\/a><\/p>\n

Figure 3: The commands in the shortcut<\/em><\/p>\n

 <\/p>\n

For example, the following shows the script that downloads a binary and executes it on the target system using PowerShell.<\/p>\n

\"PowerShell<\/a><\/p>\n

Figure 4: PowerShell script for downloading and execution of next stage binary<\/em><\/p>\n

 <\/p>\n

To make the attack more benign, the dropper drops an Office Word document and displays it on the screen. One of the samples we saw had content similar to the following screenshot:<\/p>\n

\"Fake<\/a><\/p>\n

Figure 5: Fake document contents – North Korean style language and mentions on North Korean leaders with New year\u2019s celebration<\/em><\/p>\n

 <\/p>\n

Stage 2 infection process<\/h1>\n

Acquiring a Stage 2 binary is very difficult for the analysts because the download server is very selective upon the infection targets. The main direction of the infection strategy is not to infect as many as it can, instead it focuses on infecting targets that matches the desired profile, and avoids detection from security products. One very interesting fact is that the command and control (C2) server we have been observing didn\u2019t go down for months. Overall security product coverage on Stage 2 executables is very poor, and so the strategy with this activity group (with a very selective Stage 2 infection) appears to have been effective.<\/p>\n

The following diagram shows the transition from Stage 1 to Stage 2 through the downloaded binary.<\/p>\n

\"Stage<\/a><\/p>\n

Figure 6: Stage 1 to 2 transition<\/em><\/p>\n

 <\/p>\n

The dropped binary (Dropper PE module) is never written to disk and directly injected to a new process created. In this case plasrv.exe<\/em> is used, but the process name can actually vary each time. The dropper PE module will drop kbkernelolUpd.dll<\/em> and kernelol21.exe<\/em> (which happens to have the same name as the Stage 1 binary \u2013 but different contents). The dropper PE module will look for usual system processes, for example dwm.exe<\/em> in this case, and will inject kbkernelolUpd.dll<\/em>.<\/p>\n

This is the main C2 client that will communicate with the C2 server and process downloaded commands. It performs the extra work of creating a process of usual Windows binary under systems folder and injecting the kernelol21.exe<\/em> binary into it. This is a process persistency module, which will re-inject kbkernelolUpd.dll<\/em> if the process is killed for some reason. The kbkernelolUpd.dll<\/em> module also constantly monitors the existence of the kernelol21.exe<\/em> injected process and will re-launch and re-inject the module if the infected host process is killed. This makes a process persistency loop.<\/p>\n

The following screenshot shows the typical process tree when the Stage 2 infection happens. The dwm.exe<\/em> and cipher.exe<\/em> processes are infected with kbkernelolUpd.dll <\/em>and kernelol21.exe.<\/em><\/p>\n

\"Typical<\/a><\/p>\n

Figure 7 Typical process list with Stage 2 infection<\/em><\/p>\n

 <\/p>\n

The persistency of whole infection is carried by the Windows logon key shown in the following picture.<\/p>\n

\"kernelol21.exe<\/a><\/p>\n

Figure 8 kernelol21.exe load key<\/em><\/p>\n

 <\/p>\n

The following table shows the infection targets used for each stage. All infection target process files are default Windows executables under the system32<\/em> folder.<\/p>\n\n\n\n\n\n\n
Components<\/strong><\/td>\nInjection targets<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n
Stage 1 dropper PE module<\/td>\n\n
    \n
  • plasrv.exe<\/em><\/li>\n
  • wksprt.exe<\/em><\/li>\n
  • raserver.exe<\/em><\/li>\n
  • mshta.exe<\/em><\/li>\n
  • taskhost.exe<\/em><\/li>\n
  • dwm.exe<\/em><\/li>\n
  • sdiagnhost.exe<\/em><\/li>\n
  • winrshost.exe<\/em><\/li>\n
  • wsmprovhost.exe<\/em><\/li>\n<\/ul>\n<\/td>\n
Creates new process<\/td>\n<\/tr>\n
Stage 2 kbkernelolUpd.dll<\/em><\/td>\n\n
    \n
  • dwm.exe<\/em><\/li>\n
  • wuauclt.exe<\/em><\/li>\n
  • ctfmon.exe<\/em><\/li>\n
  • wscntfy.exe<\/em><\/li>\n<\/ul>\n<\/td>\n
Injects into existing process<\/p>\n

If the process is killed, svchost.exe<\/em> will be created by stage kernelol21.exe<\/em>.<\/td>\n<\/tr>\n

Stage 2 kernelol21.exe<\/em><\/td>\n\n
    \n
  • cipher.exe<\/em><\/li>\n
  • gpupdate.exe<\/em><\/li>\n
  • services.exe<\/em><\/li>\n
  • sppsvc.exe<\/em><\/li>\n
  • winrshost.exe<\/em><\/li>\n<\/ul>\n<\/td>\n
Creates new process<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Table 1<\/em>: DUBNIUM infection targets<\/em><\/p>\n

 <\/p>\n

Process image replacement technique<\/h1>\n

When the main C2 client module, kbkernelolUpd.dll,<\/em> is injected, it uses LoadLibrary<\/em> call that is initiated through CreateRemoteThread<\/em> API. This is a very typical technique used by many malware.<\/p>\n

\"Injected<\/a><\/p>\n

Figure 9: Injected LoadLibrary code<\/em><\/p>\n

 <\/p>\n

But, for dropper PE module in Stage 1 and kernelol21.exe<\/em> injection in Stage 2, it uses a process image replacement technique. It creates the usual Windows process, injects the PE module to this process, fabricates PEB information and modifies startup code to achieve process injection.<\/p>\n

 <\/p>\n

Writing PE Image<\/h2>\n

The technique starts with creating a process from the executable under Windows system folder. Table 1 shows each target processes the injection will be made into, depending on the stage and the binary. The process is created as suspended and modifications will be performed on the image. The first step is injecting the infection PE image upon the process. It uses WriteProcessMemory<\/em> APIs.<\/p>\n

Figure 10 shows the code that injects the PE header, and Figure 11 shows the memory of the target process where the PE header is injected.<\/p>\n

\"Injecting<\/a><\/p>\n

Figure 10<\/em>: Injecting PE header<\/em><\/p>\n

 <\/p>\n

\"PE<\/a><\/p>\n

Figure 11<\/em> PE header written on target process<\/em><\/p>\n

 <\/p>\n

After the injection of PE header, it will go through each section of the source PE image and inject them one by one to the target process memory space.<\/p>\n

\"PE<\/a><\/p>\n

Figure 12: PE section injection<\/em><\/p>\n

 <\/p>\n

The injected PE module has dependencies on the hardcoded base and section addresses. If VirtualAlloc<\/em> function upon the desired base or section addresses fails, the whole injection process will fail.<\/p>\n

 <\/p>\n

Acquiring context and PEB information<\/h2>\n

The next step of infection is using GetThreadContext<\/em> API to retrieve current context of the target process.<\/p>\n

\"GetThreadContext\"<\/a><\/p>\n

Figure 13: GetThreadContext<\/em><\/p>\n

 <\/p>\n

One of the thread contexts retrieved is shown in the following image.<\/p>\n

\"Retrieved<\/a><\/p>\n

Figure 14: Retrieved Context<\/em><\/p>\n

 <\/p>\n

When the process is started as suspended, the ebx<\/em> register is initialized with the pointer to PEB structure. The following shows the original PEB data from the target process. The ImageBaseAddress<\/em> member is at offset of +8 and the value is 0x00e0000 in this case. This is the image base of the main module of the target process.<\/p>\n

\"Original<\/a><\/p>\n

Figure 15: Original PEB structure<\/em><\/p>\n

 <\/p>\n

After retrieving the PEB.ImageBaseAddress<\/em> from the target process (Figure 16), it will replace it with the base address of the injected module (Figure 17).<\/p>\n

\"Reading<\/a><\/p>\n

Figure 16<\/em>: Reading PEB.ImageBaseAddress<\/em><\/p>\n

\"Overwriting<\/a><\/p>\n

Figure 17<\/em>: Overwriting PEB.ImageBaseAddress<\/em><\/p>\n

 <\/p>\n

The PEB.ImageBaseAddress<\/em> of the target process is replaced, as in the following figure, to point to the base address of the injected PE module.<\/p>\n

\"Overwritten<\/a><\/p>\n

Figure 18: Overwritten PEB.ImageBaseAddress<\/em><\/p>\n

 <\/p>\n

Overwriting wmainCRTStartup<\/h2>\n

 <\/p>\n

After overwriting PEB.ImageBaseAddress to an injected module\u2019s base address, the next step is patching wmainCRTStartup<\/em> code from the original main module.<\/p>\n

\"wmainCRTStartup<\/a><\/p>\n

Figure 19: wmainCRTStartup patch code<\/em><\/p>\n

 <\/p>\n

The following code shows original disassembly from wmainCRTStartup<\/em> code.<\/p>\n

\"Original<\/a><\/p>\n

Figure 20: Original code<\/em><\/p>\n

 <\/p>\n

After patch, it will just jump to the entry code of the injected module located at address of 0x4053d0, which is the entry point of the injected module. When ResumeThread<\/em> is called upon this thread, it will start the main module from the injected module\u2019s entry code.<\/p>\n

\"Patched<\/a><\/p>\n

Figure 21: Patched code<\/em><\/p>\n

 <\/p>\n

Main C2 Client (kbkernelolUpd.dll<\/em>)<\/h1>\n

As kbkernelolUpd.dll<\/em> is the main module of the infection chain, we are going to focus on the analysis of this binary. As we stated before, the detection coverage and information on this specific component is limited in the security industry.<\/p>\n

 <\/p>\n

The string for the C2 server hostname and URI is encoded in a configuration block inside the binary.<\/p>\n

\"C2<\/a><\/p>\n

Figure 22: C2 server string decoding<\/em><\/p>\n

 <\/p>\n

From the following disassembly list, get_command<\/em> uses wininet.dll<\/em> APIs to send basic client information and to retrieve commands from the server. The process_command<\/em> is the routine that will parse message and execute designated commands.<\/p>\n

\"C2<\/a><\/p>\n

Figure 23: C2 command fetch & execution loop<\/em><\/p>\n

 <\/p>\n

Between each contact to the C2 server, there is a timeout. The timeout value is saved inside the encoded configuration block in the binary. For example, the sample we worked on had a 30-minute time out between each contact request to the server.<\/p>\n

\"Sleep<\/a><\/p>\n

Figure 24: Sleep interval between C2 accesses<\/em><\/p>\n

 <\/p>\n

Cryptographic C2 channel and message format<\/h2>\n

The following diagram shows the basic message format of the C2 server payload that is downloaded when the client contacts the server.<\/p>\n

\"Decrypting<\/a><\/p>\n

Figure 25<\/em>: Decrypting C2 message<\/em><\/p>\n

 <\/p>\n

The message from the C2 server can be encoded in various ways. The first byte in the payload is the XOR key that is used to decode following bytes. The encryption type byte indicates what encryption algorithm is used in the code. It has three different encryption schemes (0x50, 0x58, 0x70) supported.<\/p>\n

From our static analysis, 0x58 is for AES 256 encryption algorithm, 0x70 and 0x50 are for 3DES 168 algorithm. If this type is 0x40, no encryption will be used and it looks like 0x50 and 0x58 encryption type is not fully implemented yet. So 0x70 encryption type with 3DES 168 algorithm is the only encryption type that is fully working here.<\/p>\n

The decryption scheme is using an embedded RSA private key with the decryption key embedded in the binary. By calling CryptHashData<\/em> upon the embedded password string and using CryptDeriveKey<\/em>, it will acquire a key to decrypt the encrypted RSA private key. (Figure 26)<\/p>\n

\"Setting<\/a><\/p>\n

Figure 26<\/em>: Setting encryption key<\/em><\/p>\n

 <\/p>\n

This decryption key is used to import 0x258 bytes of private key embedded inside the binary. And this private key is used to decrypt the encrypted key (Key data 02 from Figure 25) passed through the response packet from the C2 server. Next, the IV (Initialization Vector) passed through the response packet is set as a parameter to the key object.<\/p>\n

\"Importing<\/a><\/p>\n

Figure 27: Importing keys and IV<\/em><\/p>\n

 <\/p>\n

Finally, the actual decryption of the payload happens through CryptDecrypt<\/em> API call. The question still remains why the C2 server and the client are using such an overcomplicated encryption scheme.<\/p>\n

\"Decrypting<\/a><\/p>\n

Figure 28: Decrypting message<\/em><\/p>\n

 <\/p>\n

Command processor<\/h2>\n

The C2 command processor looks very typical. It has a simple packet parser for TLV (type, length, value) data structure. The following picture shows the main routine that processes packet length and types. It will call relevant functions for each packet type.<\/p>\n

\"Main<\/a><\/p>\n

Figure 29<\/em>: Main command processor function<\/em><\/p>\n

 <\/p>\n

Each command provides usual functionalities that are typically seen in backdoors. They include registry, file system manipulations, and searching files with specific patterns, and retrieving and transferring them back to the server and gathering network status information.<\/p>\n

Infections statistics<\/h1>\n

The following chart shows the relative prevalence of the threat overall. We included Stage 1 and Stage 2 payload detections in this map.<\/p>\n

\"Bar<\/a><\/p>\n

Figure 30: Infection distribution by countries<\/em><\/p>\n

 <\/p>\n

Most of the infections we saw focused on East Asia\u2014mostly China and Japan. We already described that the Stage 1 dropper collects and sends IP and language locale of the machines it infected to the Stage 2 dropper distribution site. We think this distribution site has a logic to determine whether to drop next payload or not.<\/p>\n

The Stage 1 dropper is also known to collect information on culture-specific software like messengers and security software mainly used in mainland China. If the distribution site doesn\u2019t push back Stage 2 payload, Stage 1 payload doesn\u2019t have any means of persistency at all. This means that with all the cost of infiltrating into the machine, the malware simply gives up the machine if the machine doesn\u2019t fit into its profile. Based upon the actual infection map and the behavior of this Stage 1 dropper, it might be a good indication that the activity group has a good geolocation preference with their targets.<\/p>\n

 <\/p>\n

Conclusion<\/h1>\n

DUBNIUM is a very cautious actor. From the vendor detections for Stage 2 binaries, we can see that there are no serious detections upon them in the industry. This is partially due to the strategy that DUBNIUM employs. It doesn\u2019t try to infect as many machines as possible, instead it will potentially expose important components, like C2 client modules, to unintended targets. The very long lifespan of the domain it controls and uses for C2 operation supports the story.<\/p>\n

Other features with DUBNIUM is that it uses encoding and encryption schemes over the executables and network protocols. Each stage has different styles of encoding and decoding schemes. Some are complicated and some are relatively simple. Stage 1 binaries have a stronger obfuscation and payload encoding scheme than Stage 2 binaries. The C2 server payload has its own format with encrypted message support.<\/p>\n

The other feature with DUBNIUM is that over each stages, it always checks the running environment. It focuses on security products and analyst tools on Stage 1, but it is very cautious on debugging tools on Stage 2 binaries. From Stage 1, it also collects extensive information on the client system including locale, IP and MAC address and they are sent to the Stage 2 distribution site. The distribution site also serves each client once based upon this information. Getting served on the next stage binary is sometimes very challenging as we don\u2019t know the backend algorithm behind to determine whether to serve the next stage binary or not.<\/p>\n

 <\/p>\n

Appendix \u2013 Indicators of Compromise<\/h1>\n

 <\/p>\n

Stage 0<\/h2>\n

Adobe Flash Player Exploit<\/h2>\n

3eda34ed9b5781682bcf7d4ce644a5ee59818e15 SWF File<\/p>\n

 <\/p>\n

LNK<\/h3>\n

25897d6f5c15738203f96ae367d5bf0cefa16f53<\/p>\n

624ac24611ef4f6436fcc4db37a4ceadd421d911<\/p>\n

 <\/p>\n

Droppers<\/h3>\n

09b022ef88b825041b67da9c9a2588e962817f6d<\/p>\n

35847c56e3068a98cff85088005ba1a611b6261f<\/p>\n

7f9ecfc95462b5e01e233b64dcedbcf944e97fca<\/p>\n

aee8d6f39e4286506cee0c849ede01d6f42110cc<\/p>\n

b42ca359fe942456de14283fd2e199113c8789e6<\/p>\n

cad21e4ae48f2f1ba91faa9f875816f83737bcaf<\/p>\n

ebccb1e12c88d838db15957366cee93c079b5a8e<\/p>\n

4627cff4cd90dc47df5c4d53480101bdc1d46720<\/p>\n

 <\/p>\n

Fake documents displayed from droppers<\/h3>\n

24eedf7db025173ef8edc62d50ef940914d5eb8a<\/p>\n

7dd3e0733125a124b61f492e950b28d0e34723d2<\/p>\n

24eedf7db025173ef8edc62d50ef940914d5eb8a<\/p>\n

afca20afba5b3cb2798be02324edacb126d15442<\/p>\n

 <\/p>\n

Stage 1<\/h2>\n

Droppers<\/h3>\n

0ac65c60ad6f23b2b2f208e5ab8be0372371e4b3<\/p>\n

1949a9753df57eec586aeb6b4763f92c0ca6a895<\/p>\n

4627cff4cd90dc47df5c4d53480101bdc1d46720<\/p>\n

561db51eba971ab4afe0a811361e7a678b8f8129<\/p>\n

6e74da35695e7838456f3f719d6eb283d4198735<\/p>\n

8ff7f64356f7577623bf424f601c7fa0f720e5fb<\/p>\n

b8064052f7fed9120dda67ad71dbaf2ac7778f08<\/p>\n

dc3ab3f6af87405d889b6af2557c835d7b7ed588<\/p>\n

 <\/p>\n

Stage 2<\/h2>\n

Dropper<\/h3>\n

2d14f5057a251272a7586afafe2e1e761ed8e6c0<\/p>\n

3d3b60549191c4205c35d3a9656377b82378a047<\/p>\n

 <\/p>\n

kernelol21.exe<\/h3>\n

6ce89ae2f1272e62868440cde00280f055a3a638<\/p>\n

 <\/p>\n

kbkernelolUpd.dll<\/h3>\n

b8ea4b531e120730c26f4720f12ea7e062781012<\/p>\n

0ea2ba966953e94034a9d4609da29fcf11adf2d5<\/p>\n

926ca36a62d0b520c54b6c3ea7b97eb1c2d203a9<\/p>\n

db56f474673233f9b62bef5dbce1be1c74f78625<\/p>\n

 <\/p>\n

UserData<\/h3>\n

147cb0d32f406687b0a9d6b1829fb45414ce0cba<\/p>\n

 <\/p>\n

Acknowledgement: Special thanks to Mathieu Letourneau at MMPC for providing statistical coverage data on the DUBNIUM multi-stage samples and providing insight on the interpretation of the data. Special thanks to HeungSoo David Kang for providing screenshots from the fake Office Word document file.<\/p>\n

 <\/p>\n

Jeong Wook Oh
MMPC<\/em><\/p>\n

 <\/p>\n

https:\/\/blogs.technet.microsoft.com\/mmpc\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Recently, we\u00a0blogged about the basic functionality and features of the DUBNIUM advanced persistent threat (APT) activity group Stage 1 binary and Adobe Flash exploit used during the December 2015 incident (Part 1, Part 2). In this blog, we will go through the overall infection chain structure and the Stage 2 executable details. Stage 2 executables…<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10759,10378],"tags":[10922,10864,10760,10923,10924,10925,10926],"class_list":["post-6327","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-security","tag-advanced-persistent-threat","tag-advanced-persistent-threats","tag-antimalware-research-for-it-pros-and-enthusiasts","tag-dubnium-apt","tag-dubnium-infection-chain","tag-dubnium-payload","tag-microsoft-threat-intelligence"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/6327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=6327"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/6327\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=6327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=6327"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=6327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}