{"id":1292,"date":"2016-05-24T18:30:30","date_gmt":"2016-05-24T18:30:30","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=13911"},"modified":"2023-06-06T23:55:23","modified_gmt":"2023-06-06T23:55:23","slug":"new-wekby-attacks-use-dns-requests-as-command-and-control-mechanism","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2016\/05\/24\/new-wekby-attacks-use-dns-requests-as-command-and-control-mechanism\/","title":{"rendered":"New Wekby Attacks Use DNS Requests As Command and Control Mechanism"},"content":{"rendered":"

This post is also available in: \u65e5\u672c\u8a9e<\/span> (<\/span>Japanese)<\/span><\/span><\/a><\/span><\/p>\n

We have observed an attack led by the APT group Wekby targeting a US-based organization in recent weeks. Wekby is a group that has been active for a number of years, targeting various industries such as healthcare, telecommunications, aerospace, defense, and high tech. The group is known to leverage recently released exploits very shortly after those exploits are available, such as in the case of HackingTeam\u2019s Flash zero-day exploit<\/a>.<\/p>\n

The malware used by the Wekby group has ties to the HTTPBrowser<\/a> malware family, and uses DNS requests as a command and control mechanism. Additionally, it uses various obfuscation techniques to thwart researchers during analysis. Based on metadata seen in the discussed samples, Palo Alto Networks has named this malware family \u2018pisloader\u2019.<\/span><\/p>\n

Infrastructure<\/h3>\n

The pisloader malware family was delivered via HTTP from the following URL. At the time of writing, this URL was still active.<\/p>\n

http:\/\/globalprint-us[.]com\/proxy_plugin.exe <\/em><\/p>\n

Other samples hosted on this domain include the following:<\/p>\n

http:\/\/globalprint-us[.]com\/proxy_web_plugin.exe <\/em><\/p>\n

MD5:<\/strong> E4968C8060EA017B5E5756C16B80B012
SHA256:<\/strong> 8FFBB7A80EFA9EE79E996ABDE7A95CF8DC6F9A41F9026672A8DBD95539FEA82A
Size:<\/strong> 126976 Bytes
Compile Time:<\/strong> 2016-04-28 00:38:46 UTC<\/p>\n

This discovered file was found to be an instance of the common Poison Ivy malware family with the following configuration data:<\/p>\n

Command and Control Address:<\/strong> intranetwabcam[.]com
Command and Control Port:<\/strong> 80
Password:<\/strong> admin
Mutex:<\/strong> )!VoqA.I5<\/p>\n

The domains witnessed in this attack were all registered very shortly prior to being used. The following domains have been witnessed in this attack:<\/p>\n

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

Additionally, the following IP resolutions have been observed.<\/p>\n

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

Initial Dropper<\/h3>\n

The following sample was discovered initially and is referenced in the subsequent analysis:<\/p>\n

MD5:<\/strong> E8D58AA76DD97536AC225949A2767E05
SHA256:<\/strong> DA3261C332E72E4C1641CA0DE439AF280E064B224D950817A11922A8078B11F1
Size:<\/strong> 126976 Bytes
Compile Time:<\/strong> 2016-04-27 14:37:34 UTC<\/p>\n

This particular file has the following metadata properties. The references to \u2018pisload2\u2019 led to the naming of this malware family.<\/p>\n

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

Figure 1 pisloader dropper metadata<\/em><\/p>\n

The initial dropper contains very simple code that is responsible for setting persistence via the Run registry key, and dropping and executing an embedded Windows executable. Limited obfuscation was encountered, where the authors split up strings into smaller sub-strings and used \u2018strcpy\u2019 and \u2018strcat\u2019 calls to re-build them prior to use. They also used this same technique to generate garbage strings that are never used. This is likely to deter detection and analysis of the sample. The following decompiled code demonstrates this. Comments have been added to show the fully-generated strings.<\/p>\n

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

Figure 2 pisloader dropper building strings and setting persistence<\/em><\/p>\n

In the above decompiled code, we see that the pisloader is generating the following string, which eventually is called to set the Run registry key.<\/p>\n

cmd.exe \/c reg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run \/v lsm \/t reg_sz \/d “%appdata%\\lsm.exe” \/f<\/em><\/p>\n

This particular command will set the HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\lsm registry key with a value of \u201c%appdata%\\lsm.exe\u201d. After this key is set, the malware proceeds to decrypt a two blobs of data with a single-byte XOR key of 0x54. The resulting data is written to the %appdata%\\lsm.exe file path.<\/p>\n

After this file is written, the malware executes the newly written lsm.exe file, which contains the pisloader payload.<\/p>\n

Payload<\/h3>\n

The following sample was discovered and is referenced in the subsequent analysis:<\/p>\n

MD5:<\/strong> 07B9B62FB3B1C068837C188FEFBD5DE9
SHA256:<\/strong> 456FFFC256422AD667CA023D694494881BAED1496A3067485D56ECC8FEFBFAEB
Size:<\/strong> 102400 Bytes
Compile Timestamp:<\/strong> 2016-04-27 13:39:02 UTC<\/p>\n

The payload is heavily obfuscated using a return-oriented programming (ROP) technique, as well as a number of garbage assembly instructions. In the example below, code highlighted in red essentially serves no purpose other than to deter reverse-engineering of the sample. This code can be treated as garbage and ignored. The entirety of the function is highlighted in green, where two function offsets are pushed to the stack, followed by a return instruction. This return instruction will point code execution first at the null function, which in turn will point code execution to the \u2018next_function\u2019. This technique is used throughout the runtime of the payload, making static analysis difficult.<\/p>\n

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

Figure 3 Obfuscated code witnessed in pisloader<\/em><\/p>\n

The malware is actually quite simplistic once the obfuscation and garbage code is ignored. It will begin by generating a random 10-byte alpha-numeric header. The remaining data is base32-encoded, with padding removed. This data will be used to populate a subdomain that will be used in a subsequent DNS request for a TXT record.<\/p>\n

The use of DNS as a C2 protocol has historically not been widely adopted by malware authors. Notable exceptions include the following:<\/p>\n

The use of DNS as a C2 allows pisloader to bypass certain security products that may not be inspecting this traffic correctly.<\/p>\n

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

Figure 4 DNS query for TXT record by malware<\/em><\/p>\n

The pisloader sample will send a beacon periodically that is composed of a random 4-byte uppercase string that is used as the payload. An example of this can be found below:<\/p>\n

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

Figure 5 pisloader DNS beacon request<\/em><\/p>\n

The malware expects various aspects of the DNS responses to be set in a specific way, or else pisloader will ignore the DNS reply. The following DNS flags must be set. Should any additional flags be set, the response will be ignored.<\/p>\n