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.

Related Unit 42 Topics Cryptocurrency, Bitcoin

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.

Image 1 is a tree diagram showing the infection chain for CryptoClippy, showing the path from initial delivery to communication with C2 (labeled C&C in the figure).
Figure 1. CryptoClippy attack diagram.

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.

Image 2 is a screenshot of the content of the malicious domain, showing a couple paragraphs in Portuguese and a button with the text “Continuar para o WhatsApp Web" ("Continue to WhatsApp Web" in Portuguese)
Figure 2. The content of the malicious domain.

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).

Image 3 is a screenshot of victim browsing history, showing their searches for WhatsApp web
Figure 3. The victim’s browsing history.

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).

Image 4 is a screenshot of the mydigitialrevival[.]com website. It offers options to unlock WhatsApp.
Figure 4. The mydigitalrevival[.]com site.
Other domains we discovered belonging to this campaign are preflightdesign[.]com and pickconferences[.]com, which had the same content in Portuguese.

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

Image 5 is a screenshot of the contents of the .zip file containing the .lnk file. The filename is “WhatsApp-RKQT.lnk.
Figure 5. The initial ZIP file contains the LNK file inside.

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.

Image 6 is a screenshot of the clipboard input. It shows many lines of code.
Figure 6. Capturing the clipboard input.

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.

Image 7 is a screenshot of the decompiled view of CryptoClippy’s clipboard function. Highlighted is line 27 as well as the 0x and the bc1 as the string check option checks for Bitcoin or Ethereum.
Figure 7. The decompiled view of the CryptoClippy’s clipboard function.

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.

Image 8 is a screenshot of an Ethereum wallet. Highlighted is the section showing the user’s Ethereum wallet.
Figure 8. Ethereum wallet example used - 0xdB055877e6c13b6A6B25aBcAA29B393777dD0a73.

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.

Image 9 is a screenshot of an Ethereum wallet. Highlighted is the section showing the threat actor’s Ethereum wallet.
Figure 9. Ethereum wallet example used - 0xB49aeae711FBa241f657dA46A998833A6591848b.

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.

Coin Example Wallet Replaced Wallet Value
ETH 0xdB055877e6c13b6A6B25aBcAA29B393777dD0a73  0xB49aeae711FBa241f657dA46A998833A6591848b
BTC bc1qa5wkgaew2dkv56kfvj49j0av5nml45x9ek9hz6  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC 17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC 1JqDybm2nWTENrHvMyafbSXXtTk5Uv5QAn  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC 3279PyBGjZTnu1GNSXamReTj98kiYgZdtW  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF
BTC bc1qa5wkgaew2dkv56kfvj49j0av5nml45x9ek9hz6  1MVUhqKLr8eEDazESmxxc4mvu6YTaMudMF

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.

Image 10 is a screenshot of the WhatsApp-RKQT .lnk file Properties pane. The Target field contains the command to run.
Figure A1. The LNK file with the target field containing the command to run.

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.

Image 11 is a screenshot of many lines of code showing the character padding method that obfuscates the .lnk file.
Figure A2. LNK character obfuscation.

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).

Image 12 is a screenshot of the PowerShell command run with the .lnk execution to upload a string to the threat actor’s domain.
Figure A3. PowerShell command that is run with LNK execution to upload a string to the actor domain.

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.

Image 13 is a screenshot of many lines of code showing the BAT file dropped at the first stage, containing obfuscation.
Figure A4. BAT file dropped as first stage.

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.

Image 14 is a screenshot of many lines of code. It is the PowerShell script that responsible for the XOR decrypting. Highlighted is the XOR key in red. Highlighted in purple is the invoking .ps file.
Figure A5. PowerShell script responsible for XOR decrypting the next script to be executed.

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
Image 15 is a screenshot of many lines of code showing the decoded second stage PowerShell .ps file after running the recipe in CyberChef.
Figure A6. CyberChef recipe to decode second stage PowerShell script file ps.

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).

Image 16 is a screenshot of many lines of code. The red highlight code shows the APIs, and the code highlighted in purple is the XOR key.
Figure A7. Second stage PowerShell script using D/invoke methods and XOR operation.

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.

Image 17 is a screenshot of two panes. On the left highlighted in red is the constant used for the folder. On the right highlighted in purple are the 11 references to the generator function.
Figure A8. Constant value referenced and xrefs of function alphanumeric generator.

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).

Image 18 is a screenshot of many lines of code. Highlighted in red is the constant value. Highlighted in yellow is the volume serial.
Figure A9. Constant value and volume serial number concatenated into format string.

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.

Image 19 is a screenshot of many lines of code in two panes. In the left pane highlighted in red is the algorithm. Highlighted in purple on the right is the result, which is 94ee4d61.
Figure A10. Result of the algorithm used, which is the folder name to be created.

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.

Image 20 is a screenshot of the constant value used for mutex creation with the volume serial number. Highlighted in red is the constant itself.
Figure A11. The constant value used for mutex creation with volume serial number.

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.

Image 21 is a screenshot of the decompiled Windows event hooks and registering class.
Figure A12. Decompiled view of windows event hooks and registering class.

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).

Image 22 is a screenshot of the Tozzia.bat file contents with some information redacted.
Figure A13. Tozzia.bat file content.

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

Image 23 is a screenshot of many lines of code. It is the contents of the Tozzia.ps1 file.
Figure A14. Tozzia.ps1 content.

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

Image 24 is a screenshot of the scheduled task created by the Tozzia.bat file.
Figure A15. Scheduled task executing Tozzia.bat.

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.

Image 25 is a screenshot where highlighted in red is the name of the Giddia script.
Figure A16. PowerShell script name Giddia.
Image 26 is a screenshot of the Giddia script showing more of its capabilities. Highlighted in purple is the local account. Highlighted in red is log clearing.
Figure A17. Giddia capabilities.
Image 27 is a screenshot where highlighted in red is the name of the Knowledgeprojects script.
Figure A18. PowerShell script named Knowledgeprojects.

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

Image 28 is a screenshot of the Knowledgeprojects script showing more of its capabilities. Highlighted in red is log clearing.
Figure A19. Knowledgeprojects capabilities.

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

7db350f9ec3adb2b7f9a3e9e58c69112b5a7e2ed0337a1c4ac55c9a993116f5c WhatsApp-RKQT.lnk
15f9645e5621e87c96aa6c3497dde36ba83ec80d5f8f43c7cd809e8a636444e5 WhatsApp.Zip
096983764a75f1c0bab73dd2dea8b1e035ec1a03399fab97c71349a26856b759 Ricoly.bat
f22683e9d2a6e72b3149ef1f26392a1e080ae5f2f004543f2a45732eb78d1e98 Ricoly.ps1
c6c486800bcc9d935931c2c6fbde031942d288a124a60beb1e5d38949105b2ad ps.ps1
b6ab39b49d7d5752dbdade697a76e96d518b1b2df00c344772782c8f5950361e sc
766d25d37210ddc3f1afa84e597b3acdbf6dfb0917451f4a344ca5e570adb063 pf
7c3e9b05dcd5588c26e07d149af3c897c8879804eff1c3e2616c3dd1fcad65fe sc_deobfuscated
c88c98930181b6038a0565d9bc08ece16995ecbb01821eee6c5dd3772db694f8 sc_embedded_payload
32c9ddcc694ee6c5a38456c4c3e1b433840a18e384e59d63a5d825428abf036b Tozzia.bat
9e19b108f786bf33b58a9efb823619c2aab23107780ceae0baa2d8da19475eb2 Tozzia.ps1
2cff03f9efdaf52626bd1b451d700605dc1ea000c5da56bd0fc59f8f43071040 cacert.pem
f00ac1a50c39a4781f8f614205672bc72d55823b39c20bccffa3ba244fa74693 DSC_IMG0003.exe (Public)
5a1ce64e4fa19531a3222554bbe99aa6aeadb639d51b2a308648cb6e0fa55c05 DSCIM100001.exe (Public)
89d7c8c7846068c4f618f80d18944f2fcf47cbebe7390d73c1f16ef0ed48d90b 89d7c8c7846068c4f618f80d18944f2fcf47cbebe7390d73c1f16ef0ed48d90b.sample (Public)
498b55ff3967cabdd175c5ec11ef39a060ebded0f104575f2ef7ecb88fa9e9f1 75aa93e997427c55cc1cbe44d271da1971b7fdafcf85dc6cf69491c2e5931f1d.sample (Public)

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

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

Enlarged Image