CryptoClippy Speaks Portuguese

This post is also available in: 日本語 (Japanese)

Executive Summary

Unit 42 recently discovered a malware campaign targeting Portuguese speakers, which aims to redirect cryptocurrency away from legitimate users’ wallets and into wallets controlled by threat actors instead. To do this, the campaign uses a type of malware known as a cryptocurrency clipper, which monitors the victim’s clipboard for signs that a cryptocurrency wallet address is being copied.

The malware, which we call CryptoClippy, seeks to replace the user’s actual wallet address with the threat actor’s, causing the user to inadvertently send cryptocurrency to the threat actor. Unit 42 Managed Threat Hunting found victims across manufacturing, IT services, and real estate industries, though they likely impacted the personal wallet addresses of someone using their work machine.

To deliver the malware to users’ computers, threat actors in this campaign used both Google Ads and traffic distribution systems (TDS) to redirect victims to malicious domains that are impersonating the legitimate WhatsApp Web application. They use this to ensure victims are real users, and also that they’re Portuguese speakers. For users who are sent to malicious domains, the threat attempts to trick them into downloading malicious files, including either .zip or .exe files, that lead to the final payload.

Palo Alto Networks customers receive protections against this campaign through Cortex XDR. The Advanced URL Filtering and DNS Security cloud-delivered security services for the Next-Generation Firewall identify domains associated with the CryptoClippy campaign as malicious.

What Are Cryptocurrency Clippers?

Cryptocurrency malware aims to redirect cryptocurrency funds away from legitimate users’ wallets and into wallets that are controlled by the threat actor. When a computer is infected with a cryptocurrency clipper, the malware continually examines the victim’s clipboard to see if they have copied a cryptocurrency wallet address. The idea behind this is that if a person copies a wallet address to the clipboard, it indicates they might be in the process of transferring cryptocurrency from one wallet to another.

The clipper malware uses regular expressions (regexes) to identify what type of cryptocurrency the address pertains to. It then replaces the clipboard entry with a visually similar but adversary-controlled wallet address for the appropriate cryptocurrency. Later, when the victim pastes the address from the clipboard to conduct a transaction, they actually are sending cryptocurrency directly to the threat actor.

Since wallet addresses typically are very long – sometimes exceeding 40 alphanumeric characters – many people will not notice this change in address. This contributes to the effectiveness of clipper malware.

CryptoClippy Overview

Unit 42 Managed Threat Hunting found victims across manufacturing, IT services, and real estate industries. This threat does not target specific industries, and the devices impacted were hit opportunistically.

A CryptoClippy infection begins with SEO poisoning, so that when a person searches for “WhatsApp Web,” the result leads them to a threat actor-controlled domain. Once there, victims are prompted to download a .zip file that contains a .lnk file, which is composed of malicious scripts. These scripts set off a chain of events that installs the clipper malware. This threat then monitors the victim’s clipboard activity for bitcoin transactions, such that their valid crypto wallet address will be replaced with one controlled by the threat actor.

The variant of CryptoClippy we investigated has a variety of additional capabilities to help the threat actor accomplish their crypto stealing activities. This includes being able to establish a Remote Desktop Protocol (RDP) backdoor through execution of an RC4-encrypted PowerShell script.

This script contains elements of Windows Management Instrumentation (WMI), terminal service registry manipulation, icacls, net commands and log clearing. These allow the attackers to maintain access outside the in-memory payload.

In addition, the variant also has functionality related to targeting Ethereum and bitcoin cryptocurrency wallets. This is not surprising, given the growing popularity of digital currencies in Latin America.

At the time of writing this post, the actor controlled wallets show recent activity. The bitcoin address has shown evidence of receiving 0.039954 BTC, which roughly equals $982.83. This bitcoin (BTC) balance came from four different BTC transactions. The Ethereum (ETH) address shows evidence of having received funds as well, with 0.110915556631181819 ETH (roughly equal to $186.32) being sent from three different ETH addresses.

The threat actors in this campaign employed a multi-stage approach to try to bypass signature- and heuristic-based security engines. This approach included obfuscation techniques to evade detection, including using obfuscated PowerShell scripts and encoded payloads.

The current low detection rate of this malware highlights this approach's effectiveness, as only a handful of vendors appear to be detecting this malware in VirusTotal. The vendors that do detect this have assigned generic names to this malware.

Infection Chain for CryptoClippy

The infection flow for CryptoClippy starts with delivering an initial .zip file that contains a .lnk file that is composed of an obfuscated PowerShell command line script. Once the .lnk file is double-clicked by the victim, the PowerShell script will be executed, which will download the second stage and several obfuscated/encrypted payloads (as discussed later in Stage 1 - Loader).

When the second stage PowerShell script is executed, it deobfuscates/decrypts the CryptoClippy loader and executes it. The loader will then inject its stealer component into svchost.exe.

CryptoClippy will set up user-mode event based hooks and a callback function into clipboard APIs to replace the victim’s Ethereum/bitcoin crypto wallet with the actor’s crypto wallet, when it is copied to the clipboard. It also contains functionality to communicate with C2 servers.

Figure 1 shows the attack diagram for CryptoClippy.

Delivery via Malvertising

We’ve observed this malware campaign leveraging Google Ads and TDS. First the threat actor used Google Search ads that appeared in search results when users search for “WhatsApp Web.” This allowed them to trick victims into opening and downloading their malicious compressed .zip file. After being alerted to the issue in early 2022, Google implemented additional protections and the company says its systems have improved at detecting and preventing renewed attack attempts.

In addition, threat actors used TDS to filter victims and bots on the malicious landing page. The TDS filters exclude bots and internet crawlers by using various criteria to determine if a client device is a real user and also a Portuguese speaker.

First, the TDS checks if the connecting device is coming from a virtual private network (VPN) IP address. Using a VPN can make it difficult for the attacker to determine the location and characteristics of the victim's device, and can also make it more difficult to deliver malicious content.

Next, the TDS makes user agent checks. The user agent is a string of text that a web browser sends to a website to identify itself and its capabilities. By checking the user agent of the client device, the TDS determines if the preferred browser language is Portuguese by checking the Accept-Language header. The TDS can also check for other information such as device type, operating system, browser version and geolocation.

Finally, the TDS follows the Hypertext Transfer Protocol (HTTP) GET header criteria. The HTTP GET header is a request message sent by a web browser to a server to retrieve a resource. The header can contain various information, such as the requested URL, the user agent, the Accept-Language header and the referer header. Checking the criteria in the HTTP GET header is another way the TDS can determine if the preferred language for the browser is Portuguese

If the TDS determines that the connection does not meet the above criteria, the victim is redirected to a different landing page (shown in Figure 2) and prompted to click on "Continuar para o WhatsApp Web" ("Continue to WhatsApp Web" in Portuguese). This will redirect to the legitimate WhatsApp Web domain without any further malicious activity, effectively avoiding detection by the victim and security software.

However, if the TDS determines that the connection does meet the above criteria, the victim is redirected to the malicious landing page where they are prompted to download the malicious .zip file (shown in Figures 3 and 4).

This site disguises itself as the official WhatsApp Web site, offering WhatsApp Desktop. Downloading this file from mydigitalrevival[.]com resulted in the initial infection — WhatsApp.zip (shown in Figure 4).

When a victim successfully loaded the malicious webpage and downloaded the offered .zip file, it contained a .lnk file, as shown in Figure 5.

For more technical details on the .lnk file, please see Infection via LNK File.

Following the execution of the .lnk file, Unit 42 researchers observed the following files downloaded to C:\Users\<USERNAME>\AppData\Roaming\Ricoly:

• Ricoly.bat
• Ricoly.ps1
• Two obfuscated encrypted files (ps, sc)
• One obfuscated encrypted auxiliary config file (pf)

The first PowerShell script loader Ricoly.ps1 is launched and executed by the Ricoly.bat batch file. The Ricoly.ps1 script's purpose is to decrypt the second-stage obfuscated/encrypted script ps. More in-depth information about these loader files can be found in Stage 1 - Loader and Stage 2 - Loader.

The functionality of the second stage PowerShell script ps is to act as a reflective PE loader. The ps file will target an encrypted EXE file named sc that is written to the file system. The sc file is reflectively loaded and eventually functions as the main loader for CryptoClippy.

Main CryptoClippy Executable

After the execution of the .lnk file and the two subsequent PowerShell scripts, the CryptoClippy operation consists of an executable loader and the main CryptoClippy executable. The loader for CryptoClippy is a 64-bit EXE file, where the main stealer EXE file is embedded inside of the .data section. The loader uses syscalls and appears to overlap with SysWhispers2 implementation for execution.

SysWhispers2 is a stealthier implementation for code execution, which is used to bypass inspection of user-mode APIs. This bypass is possible because user-mode APIs are typically used by applications, including introspection by AV/EDR products, through user-mode hooks.

The main executable for CryptoClippy is written in C and it is statically compiled with the Transport Layer Security (TLS) library Mbed-TLS. The main feature of the executable includes its own algorithm for name generation (i.e., the file path, mutex and event object). For more in-depth information on this algorithm, see Folder Name and Mutex String Generator.

The main executable also makes extensive use of a local auxiliary file called pf, which contains an encrypted certificate. CryptoClippy uses its own algorithm to deobfuscate the character lookup table from the auxiliary file to build the plaintext certificate from pointers to values in the lookup table.

This threat also uses two different RC4 keys for various string decryption functions. The string decryption routine will use a structure built in memory for the index location into the structure, string offset and string size. These strings are related to object names, domains, crypto wallets and persistence scripts.

• RC4 Key: 1b43233d5a054808061c190336320e46
• RC4 Key: 4646070B47445451604F291809444703

Crypto Stealing Operation

The primary objective of CryptoClippy is to identify crypto wallet strings being copied into the clipboard. CryptoClippy sets up user-mode event hooks and uses a callback function to execute replacing Ethereum or bitcoin based wallets copied into the Windows clipboard with hardcoded wallet values owned by the threat actor. For more technical details, please see User-Mode Event Hook Setup.

Figure 6 illustrates the window capturing the clipboard input. Based on the execution flow of the loader, this particular application would normally not be visible.

The decompiled view of CryptoClippy’s clipboard function (shown in Figure 7) reveals that the wallet addresses used by the threat actor will be RC4 decrypted to be used later on, in any replacement of crypto wallets that take place.

CryptoClippy will perform a string check against the data being pushed into the clipboard. It will check for common leading characters associated with Ethereum or bitcoin related wallets. The string copied into the clipboard will be looped through to determine the character count. On line 27 of Figure 7, 25 is subtracted from the total character count and compared to see if it is less than or equal to 9.

This string check operation works on bitcoin addresses starting with a 1. Otherwise the code path will be skipped, and the string in the clipboard will be checked to see if it starts with either bc1 (related to bitcoin) or 0x (related to Ethereum).

The debugging view shown in Figure 8 shows the API GetClipboardData and the return value of the API, which contains the example Ethereum wallet copied.

Once the clipboard data is obtained, the string checks noted in the decompiled view above will be performed, looking for specific crypto wallet-like characters used. In Figure 9, an Ethereum wallet was provided as input and was subsequently checked for the starting character value of 0x.

The function responsible for manipulating the clipboard will swap out the Ethereum wallet address the user copied and replace it with the wallet address of 0xB49aeae711FBa241f657dA46A998833A6591848b for Ethereum by using the API SetClipboardData.

A small subset of example wallet addresses were tested. Table 1 contains user-supplied values that were copied and then subsequently replaced by the crypto clipping function.

Table 1. Examples of copied wallets and the replaced wallets.

To maintain access to the victim computer, CryptoClippy obtains persistence by adding Ricoly.lnk to the Startup folder (\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Ricoly.lnk). The Ricoly.lnk would be launched as the user logs in, which would execute the Ricoly.bat script, which would then execute Ricoly.ps1.

Additional efforts to maintain access are contained in an RC4-encrypted PowerShell script called Tozzia.ps1. The CryptoClippy payload injected into svchost.exe extracts the Tozzia.bat and Tozzia.ps1 files.

Along with two other scripts, the Tozzia.ps1 script contains various capabilities related to registry modifications of terminal services, local account creation, net commands and event log clearing. These three scripts are covered in more depth in Backdoor.

Conclusion

The overall proliferation of cryptocurrency-focused malware has been gaining momentum the last few years. The threat actor in this particular instance has implemented the following activities in their campaigns:

• Incorporating malvertising
• Using TDS
• Limiting the scope of targeting
• Keying the payloads to the environment
• Employing more complex and stealthier techniques to hide the overall functionality of the loader and clipper
• Creating custom algorithms for data manipulation

These practices highlight an interesting shift, especially in cryptocurrency-targeting malware. We often see two particular methods for the distribution of such threats. They may be pushed using a botnet like with Laplas Clipper and Smokeloader, or there may be an underlying malware-as-a-service (MaaS) element such as with Eternity Clipper.

Protections and Mitigations

Palo Alto Networks customers using Cortex XDR receive protections at the endpoints from the malware techniques described in this blog. Palo Alto Networks Next-Generation Firewalls with Advanced URL Filtering and DNS Security identify domains associated with the CryptoClippy campaign as malicious.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America Toll-Free: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Appendix

The Appendix to this post contains more in-depth descriptions of the activities of this malware. This section will roughly follow the order of activities as described in the infection diagram in Figure 1.

Infection via LNK File

The .lnk file found within the .zip file that is initially downloaded by victims contains a truncated command, shown in Figure A1. Double-clicking the file will execute an obfuscated command located in the target field of the shortcut responsible for checking into the actor-controlled domain, shown in Figure A3.

The .lnk file utilizes a few different character padding methods for obfuscation, which include the following character sets:

• ^
• !!
• :~

Figure A2 shows how this padding is used in the .lnk file.

The LNK deobfuscates to the following PowerShell command, which will upload the string uiPX to the attacker-controlled domain tunneldrive[.]com via HTTP protocol (shown in Figure A3).

It should be noted that in cases observed by Unit 42 researchers, the infection chain traces to files with the extension .lnk. These files are usually contained in a .zip archive. However, during pivoting in this campaign, we observed another variation to the infection flow where the initial payload is an .exe file (reported on VirusTotal) that is linked to the previously mentioned domain mydigitalrevival[.]com.

When we examined the .exe file that impersonates WhatsApp Web, we found that once it's executed, it will contact the previously mentioned tunneldrive[.]com domain. It will then drop and execute a .bat file to delete itself.

This .bat file (shown in Figure A4) uses an obfuscation that gradually builds up its payload similar to the one detailed in this blog, but with more obfuscation. In addition, this obfuscation type appears to be adopted from Daniel Bohannon’s Invoke-Obfuscation project, which is a technique widely used by Brazilian threat actors.

Stage 1 - Loader

The first PowerShell script loader Ricoly.ps1 is launched and executed by the Ricoly.bat batch file. The Ricoly.ps1 script's purpose is to decrypt a dropped second-stage obfuscated/encrypted script ps also residing in C:\Users\<USERNAME>\AppData\Roaming\Ricoly.

The Ricoly.ps1 script utilizes an XOR key that is mostly hardcoded (statically set), while one portion of the XOR key is dynamically derived from the processor ID of the computer. This keys the payload and adds an additional layer of anti-analysis, as shown in Figure A5.

Stage 2 - Loader

We used the following CyberChef XOR recipe (also shown in Figure A6) to decrypt the second stage payload:

• XOR KEY: b8 55 2e 7c 48 f6 44 ea c1 7c 9e 09 eb b0 f5 f1 23 f4 22 42 02 15 a1 cb ed 69 50 c1 1b 46 bf eb fb ff 00 08 06 ec bc c5 55 c1 de 96 14 3b bb a8 85 59 13 70 0b 28

An encrypted EXE file named sc is written to the file system when it’s downloaded during the first stage mentioned above. This EXE file will then be the target and focus of the second stage ps script.

The functionality of the second stage PowerShell script ps is to act as a reflective PE loader. It does so using .NET methods and D/invoke to work with .NET delegates to assist in evasion and dynamic resolving.

The ps script will determine if the operating system is 32-bit or 64-bit. It will also determine the API functionality needed from kernel32.dll to act as a reflective loader. It does this by using GetDelegateForFunctionPointer for resolving the needed APIs such as VirtualAlloc and CreateThread.

The ps script will then XOR decrypt the payload and invoke the EXE file sc (as shown in Figure A7).

The EXE file sc, reflectively loaded into memory, acts as the main loader using syscalls to inject code into another newly created process. The newly created svchost.exe process contains CryptoClippy.

Folder Name and Mutex String Generator

The first few functions of the stealer will first map out the file system to create a folder to be used. This is achieved by using the APIs GetWindowsDirectoryA, GetVolumeInformationA and SHGetFolderPathA.

The stealer contains a function that will uniquely create alphanumeric strings. This string generator is used in several locations within the main program. It is first used to create a unique folder name under the AppData path. To do this, a constant value is used as a parameter to the string generator (shown in Figure A8).

In this instance, the constant is 0x79FE6D, which will be used within the string generator function and mapped to the format string %08x-%08x.

The string-generating function will use the constant value provided to the function and the volume serial number queried from the victim’s system. It will create the following string as an example: 079fe6d-de786dd1 (shown in Figure A9).

The algorithm will shuffle the string 079fe6d-de786dd1 by splitting the string by each character. The first operation will be an XOR performed by the first character of the string against the value FFFFFFFF.

The resulting operation will then be shifted right by 1 and XORed by the constant 0x82F63B78. The resulting XOR operation will then follow the same set of operations a total of eight times per each character in the 16 character example string 079fe6d-de786dd1.

The completion of the algorithm returns the folder name to be added to the AppData directory (shown in Figure A10). The folder name in this instance was 55abf82d and the full path was C:\Users\xxx\AppData\Roaming\55abf82d. This will vary based on the constant and volume serial number provided as input to create unique alphanumeric strings.

Mutex

The creation of the stealer’s mutex also uses the string generator function with a different constant value (shown in Figure A11) supplied as a parameter. In this instance, the value is 0x24F2D5.

User-Mode Event Hook Setup

In order for the stealer to facilitate clipping out crypto wallets copied to the clipboard and replacing them with the hardcoded wallets included in the binary, it will start by calling the API SetWinEventHook to set up event hooks for calling the function responsible for interacting with clipboard data when the specific events are triggered.

• EVENT_OBJECT_FOCUS
• EVENT_OBJECT_VALUECHANGE
• EVENT_SYSTEM_FOREGROUND

The event hooks setup will have a process scope of receiving events from all processes as well as all existing threads, and then skip hooking the owning process responsible for creating the hooks. Following the setup of event hooks is the creation of a Windows event object (shown in Figure A12). It does this by calling the Windows API CreateEventA, which is used for synchronization, and it will signal to a thread when a particular event has occurred and completed.

Following the Windows object event creation, the stealer will use the API RegisterClassExA. This API is provided a pointer to the WNDCLASSEX structure containing wcbClass and various structure fields.

After this, CreateWindowExA is called, which will create a window with the structure pointed to by the previous API. The important field in this structure for our analysis is the field lpfnWndProc, which points to the malware author’s clipboard function.

Backdoor

During CryptoClippy execution, this threat will decrypt and write the files Tozzia.bat and Tozzia.ps1 to the file system, which are embedded within itself. The batch file Tozzia.bat is executed, which in turn will execute Tozzia.ps1 (shown in Figure A13).

Figure A14 shows Tozzia.ps1 being written to the file system and executed, providing additional persistence.

Figure A15 shows Tozzia.ps1 gaining persistence by creating a scheduled task.

Two additional scripts, Giddia and Knowledgeprojects, were decrypted following the decryption of the Tozzia script but were not executed or written to the file system. Carving the two scripts from memory, Giddia and Knowledgeprojects, reveals a few hundred lines of additional script code.

The Giddia script (shown in Figures A16 and A17) contains capabilities for manipulating registry property values related to terminal services, with the goal of weakening them. It also contains capabilities for net commands and local account-related operations.

The Knowledgeprojects script (shown in Figures A18 and A19) contains capabilities to use PowerShell for clearing logs.

Hunting Queries

You can use the following XQL queries to hunt for the different stages of the infection.

Injection to svchost.exe

Indicators of Compromise

Infrastructure

• tunneldrive[.]com - 104[.]21.7.130:80
• mydigitalrevival[.]com - 172[.]67.160.80:80
• hollygap[.]com - 172[.]67.134.21:443, 104[.]21.5.250:443
• yogasmob[.]com
• preflightdesign[.]com
• pickconferences[.]com

Additional Resources

• Pervasive Brazilian Financial Malware Targets Bank Customers in Latin America and Europe – Cybereason
• Weird Ways to Run Unmanaged Code in .NET - xpnsec
• Emulating Covert Operations - Dynamic Invocation (Avoiding PInvoke & API Hooks) - The Wover
• Migrating from P/Invoke to D/Invoke - klezvirus
• Offensive P/Invoke: Leveraging the Win32 API from Managed Code - SpecterOps
• SysWhispers2 - Github
• Investigating a Monero Coin Miner - Triskele Labs

Updated April 5, 2023, at 5:34 a.m. PT.