Over the years, there have been multiple cases when iOS devices were infected with targeted spyware such as Pegasus, Predator, Reign and others. Often, the process of infecting a device involves launching a chain of different exploits, e.g. for escaping the iMessage sandbox while processing a malicious attachment, and for getting root privileges through a vulnerability in the kernel. Due to this granularity, discovering one exploit in the chain often does not result in retrieving the rest of the chain and obtaining the final spyware payload. For example, in 2021, analysis of iTunes backups helped to discover an attachment containing the FORCEDENTRY exploit. However, during post-exploitation, the malicious code downloaded a payload from a remote server that was not accessible at the time of analysis. Consequently, the analysts lost “the ability to follow the exploit.”

In researching Operation Triangulation, we set ourselves the goal to retrieve as many parts of the exploitation chain as possible. It took about half a year to accomplish that goal, and, after the collection of the chain had been completed, we started an in-depth analysis of the discovered stages. As of now, we have finished analyzing the spyware implant and are ready to share the details.

The Operation Triangulation infection chain

The implant, which we dubbed TriangleDB, is deployed after the attackers obtain root privileges on the target iOS device by exploiting a kernel vulnerability. It is deployed in memory, meaning that all traces of the implant are lost when the device gets rebooted. Therefore, if the victim reboots their device, the attackers have to reinfect it by sending an iMessage with a malicious attachment, thus launching the whole exploitation chain again. In case no reboot occurs, the implant uninstalls itself after 30 days, unless this period is extended by the attackers.

Meet TriangleDB

The TriangleDB implant is coded using Objective-C, a programming language that preserves names of members and methods assigned by the developer. In the implant’s binary, method names are not obfuscated; however, names of class members are uninformative acronyms, which makes it difficult to guess their meaning:

In some cases, it is possible to guess what the acronyms mean. For example, osV is the iOS version, and iME contains the device’s IMEI.

The strings in the implant are HEX-encoded and encrypted with rolling XOR:

id +[CRConfig unmungeHexString:](id a1, SEL a2, id stringToDecrypt) {
  // code omitted
  while (1) {
	hexByte[0] = stringBytes[i];
	hexByte[1] = stringBytes[i + 1];
	encryptedByte = strtoul(hexByte, &__endptr, 16);
	if (__endptr == hexByte) 
          break;
	i += 2LL;
	if (j)
  	    decryptedString[j] = encryptedByte ^ previousByte;
	else
  	    decryptedString[0] = encryptedByte;
	++j;
	previousByte = encryptedByte;
	if (i >= stringLength) 
          break;
  }
  decryptedString[j] = 0;
  // code omitted
}

The rolling XOR algorithm implemented in the implant for string decryption

C2 communications

Once the implant launches, it starts communicating with the C2 server, using the Protobuf library for exchanging data. The configuration of the implant contains two servers: the primary and the fallback (contained in the lS and lSf configuration fields). Normally, the implant uses the primary server, and, in case of an error, it switches to the fallback server by invoking the -[CRConfig swapLpServerType:] method.

Additionally, the sent and received messages are encrypted with symmetric (3DES) and asymmetric (RSA) cryptography. All messages are exchanged via the HTTPS protocol in POST requests, with the cookie having the key g and a value that is a digit string from the pubKI configuration parameter.

The implant periodically sends heartbeat beacons that contain system information, including the implant version, device identifiers (IMEI, MEID, serial number, etc.) and the configuration of the update daemon (whether automatic downloads and installations of updates are enabled).

Heartbeat beacon snippet, implant v1.7.0.5 running on iOS 15.3.1

TriangleDB commands

The C2 server responds to heartbeat messages with commands. Commands are transferred as Protobuf messages that have type names starting with CRX. The meaning of these names is obscure: for example, the command listing directories is called CRXShowTables, and changing C2 server addresses is handled by the command CRXConfigureDBServer. In total, the implant we analyzed has 24 commands designed for:

• Interacting with the filesystem (creation, modification, exfiltration and removal of files);
• Interacting with processes (listing and terminating them);
• Dumping the victim’s keychain items, which can be useful for harvesting victim credentials;
• Monitoring the victim’s geolocation;
• Running additional modules, which are Mach-O executables loaded by the implant. These executables are reflectively loaded, with their binaries stored only in memory.

One of the interesting commands we discovered is called CRXPollRecords. It monitors changes in folders, looking for modified files that have names matching specified regular expressions. Change monitoring is handled by obtaining a Unix file descriptor of the directory and assigning a vnode event handler to it. Whenever the implant gets notified of a change, the event handler searches for modified files that match the regex provided by the attacker. Such files are then scheduled for uploading to the C2 server.

The parameters of this command are as follows:

Below, we describe the implant’s commands, specifying the developer-assigned command names along with their numerical identifiers when possible.

Odd findings

While researching the TriangleDB implant, we found a lot of curious details:

• The developers refer to string decryption as “unmunging” (as the method performing string decryption is named +[CRConfig unmungeHexString:] );
• Throughout the code, we observed that different entities were given names from database terminology, which is the reason why we dubbed the implant TriangleDB:
  

  Entity	Developer-used terminology for the entity
  Directory	Table
  File	Record
  Implant module
  Process	Schema
  Keychain entry	Index, row
  C2 server	DB Server
  Geolocation information	DB Status
  Heartbeat	Diagnostic data
  Process of exchanging data with C2 server	Transaction
  Request to C2 server	Query
  iOS application	Operation

• While analyzing TriangleDB, we found that the class CRConfig (used to store the implant’s configuration) has a method named populateWithFieldsMacOSOnly. This method is not called anywhere in the iOS implant; however, its existence means that macOS devices can also be targeted with a similar implant;
• The implant requests multiple entitlements (permissions) from the operating system. Some of them are not used in the code, such as access to camera, microphone and address book, or interaction with devices via Bluetooth. Thus, functionalities granted by these entitlements may be implemented in modules.

To be continued

That’s it for TriangleDB, a sophisticated implant for iOS containing multiple oddities. We are continuing to analyze the campaign, and will keep you updated with all details about this sophisticated attack.

TriangleDB indicators of compromise

MD5      063db86f015fe99fdd821b251f14446d
SHA-1    1a321b77be6a523ddde4661a5725043aba0f037f
SHA-256  fd9e97cfb55f9cfb5d3e1388f712edd952d902f23a583826ebe55e9e322f730f

Satacom downloader, also known as LegionLoader, is a renowned malware family that emerged in 2019. It is known to use the technique of querying DNS servers to obtain the base64-encoded URL in order to receive the next stage of another malware family currently distributed by Satacom. The Satacom malware is delivered via third-party websites. Some of these sites do not deliver Satacom themselves, but use legitimate advertising plugins that the attackers abuse to inject malicious ads into the webpages. The malicious links or ads on the sites redirect users to malicious sites such as fake file-sharing services.

In this report we cover a recent malware distribution campaign related to the Satacom downloader. The main purpose of the malware that is dropped by the Satacom downloader is to steal BTC from the victim’s account by performing web injections into targeted cryptocurrency websites. The malware attempts to do this by installing an extension for Chromium-based web browsers, which later communicates with its C2 server, whose address is stored in the BTC transaction data.

The malicious extension has various JS scripts to perform browser manipulations while the user is browsing the targeted websites, including enumeration and manipulation with cryptocurrency websites. It also has the ability to manipulate the appearance of some email services, such as Gmail, Hotmail and Yahoo, in order to hide its activity with the victim’s cryptocurrencies shown in the email notifications.

Satacom technical analysis

The initial infection begins with a ZIP archive file. It is downloaded from a website that appears to mimic a software portal that allows the user to download their desired (often cracked) software for free. The archive contains several legitimate DLLs and a malicious Setup.exe file that the user needs to execute manually to initiate the infection chain.

Various types of websites are used to spread the malware. Some of them are malicious websites with a hardcoded download link, while others have the “Download” button injected through a legitimate ad plugin. In this case, even legitimate websites may have a malicious “Download” link displayed on the webpage. At the time of writing, we saw the QUADS plugin being abused to deliver Satacom.

Websites with embedded QUADS ad plugin

The plugin is abused in the same way that other advertising networks are abused for malvertising purposes: the attackers promote ads that look like a “Download” button and redirect users to the attackers’ websites.

WP QUADS ad plugin within the website’s content

After the user clicks on the download button or link, there’s a chain of redirects that automatically takes them through various servers to reach a website masquerading as a file-sharing service to distribute the malware. In the screenshot below, we can see examples of websites that are the final destinations of the redirection chains.

Fake ‘file-sharing’ services

After the user downloads and extracts the ZIP archive, which is about 7MB in size, a few binaries, EXE and DLL files are revealed. The DLLs are legitimate libraries, but the ‘Setup.exe’ file is a malicious binary. It is about 450MB, but is inflated with null bytes to make it harder to analyze. The original size of the file without the added null bytes is about 5MB and it is an Inno Setup type file.

Null bytes added to the PE file

Inno Setup installers usually work as follows: at runtime the binary extracts a child installer to a temporary folder with the name ‘Setup.tmp’. Then it runs the child installer ‘Setup.tmp’ file that needs to communicate with the primary installer with arguments pointing to the location of the original ‘Setup.exe’ and its packages in order to retrieve the BIN data inside the ‘Setup.exe’ file for the next step of the installation.

In the case of the Satacom installer, the Setup.tmp file, once running, creates a new PE DLL file in the Temp directory. After the DLL is created, the child installer loads it into itself and runs a function from the DLL.

It then decrypts the payload of Satacom and creates a new sub-process of ‘explorer.exe’ in order to inject the malware into the ‘explorer.exe’ process.

Based on the behavior we observed, we can conclude that the malware performs a common process injection technique on the remote ‘explorer.exe’ process called process hollowing. This is a known technique used to evade detection by AV applications.

The malicious payload that’s injected into the ‘explorer.exe’ process uses the RC4 encryption implementation to decrypt its configuration data, communication strings and data for the other dropped binaries on the victim’s machine. The encrypted data is stored inside the malicious payload.

The malware uses different hardcoded keys to decrypt the data at each step. There are four different RC4 keys that the malware uses to perform its actions, first decrypting the HEX string data to use it for its initial communication purposes.

RC4 keys (left pane) and encrypted HEX strings (right pane)

In the screenshot above, the left pane shows the four RC4 hardcoded keys as HEX strings, and in the right pane we can see the HEX strings that are decrypted using the RC4 ‘config_strings’ key to get the strings for the first initialization of communication with the C2. If we decrypt the strings ourselves using the key, we get the result shown in the screenshot.

Once the HEX strings are decrypted, ‘explorer.exe’ initiates its first communication. To do so, it performs a DNS request to don-dns[.]com (a decrypted HEX string) through Google DNS (8.8.8.8, another decrypted string) and it queries for the TXT record.

DNS query for TXT record through Google to don-dns[.]com

Once the request is complete, the DNS TXT record is received as another base64-encoded RC4-encrypted string: “ft/gGGt4vm96E/jp”. Since we have all of the RC4 keys, we can try to decrypt the string with the ‘dns_RC4_key’ and get another URL as a result. This URL is where the payload is actually downloaded from.

Decrypted string of TXT record

The payload: malicious browser extension

The Satacom downloader downloads various binaries to the victim’s machine. In this campaign we observed a PowerShell script being downloaded that installs a malicious Chromium-based browser extension that targets Google Chrome, Brave and Opera.

The extension installation script is responsible for downloading the extension in a ZIP archive file from a third-party website server. The PowerShell script downloads the archived file to the computer’s Temp directory and then extracts it to a folder inside the Temp directory.

After that, the script searches for the possible locations of shortcuts for each of the targeted browsers in such places as Desktop, Quick Launch and Start Menu. It also configures the locations of the browsers’ installation files and the location of the extension on the computer.

Finally, the PS script recursively searches for any link (.LNK) file in the above locations and modifies the “Target” parameter for all existing browser shortcuts with the flag “–load-extension=[pathOfExtension]” so that the shortcut will load the browser with the malicious extension installed.

Chrome shortcut with the extension parameter

After performing this action, the script closes any browser processes that may be running on the machine, so that the next time the victim opens the browser, the extension will be loaded into the browser and run while the user is browsing the internet.

This extension installation technique allows the threat actors to add the addon to the victim’s browser without their knowledge and without uploading it to the official extension stores, such as the Chrome Store, which requires the addon to meet the store’s requirements.

Extension installation PowerShell script

Malicious extension analysis

After installation of the extension, we can analyze its functionality and features by checking specific files stored in the extension’s directory. If we take a look at the first lines of the ‘manifest.json’ file, we’ll see that the extension disguises itself by naming the addon “Google Drive,” so even when the user accesses the browser addons, the only thing they will see is an addon named “Google Drive”, which looks like just another standard Google extension installed inside the browser.

The manifest.json file settings

Another malicious extension file that always runs in the background when the user is browsing is ‘background.js’, which is responsible for initializing communication with the C2. If we take a closer look at the JavaScript code, we’ll find an interesting function call at the bottom of the script with a string variable that is the address of a bitcoin wallet.

Background.js script snippet

Looking at the script’s code, we can conclude that the extension is about to fetch another string from the hardcoded URL, into which the script inserts the bitcoin address. The JavaScript receives data in JSON format, which shows the wallet’s transaction activity, and then looks for a specific string within the latest transaction details.

JSON of the transaction details

There are two strings on the page that contain the C2 address. The “script” string is a HEX string that contains the C2 host of the malware, and the “addr” string is the Base58-encoded C2 address. The reason for using the last cryptocurrency transaction of a specific wallet to retrieve the C2 address is that the server address can be changed by the threat actors at any time. Moreover, this trick makes it harder to disable the malware’s communication with its C2 server, since disabling wallets is much more difficult than blocking or banning IPs or domains. If the C2 server is blocked or taken down, the threat actors can simply change the ‘script’ or ‘addr’ string to a different C2 server by performing a new transaction. And since the extension always checks these strings to retrieve the C2, it will always ask for the new one if it’s ever changed.

Decoded C2 address from the transaction details

The extension has several other scripts that are responsible for initializing the received commands and become functional after the C2 address is retrieved, because the scripts need to obtain some important information from the C2. For example, the C2 holds the BTC address that will be used when the BTC is transferred from the victim’s wallet to the threat actor’s wallet.

Threat actor’s BTC wallet address

To get hold of the victim’s cryptocurrency, the threat actors use web injects on the targeted websites. The web inject script is also provided by the C2 after the extension contacts it. In the following screenshot, we can see the ‘injections.js’ script from the extension, which fetches the web inject script from the C2 server.

The injections.js script

After the addon contacts the C2 server – extracted as mentioned above – the server responds with the web inject script that will be used on the targeted websites.

Webinject script from C2 server

If we take a closer look at the script, we can see that the threat actors are targeting various websites. In the version of the script shown above we can see that it targets Coinbase, Bybit, KuCoin, Huobi and Binance users.

Since the script within the C2 can be changed at any time, the threat actors can add or remove other web injection targets, as well as start targeting cryptocurrencies other than BTC, which makes this extension pretty dynamic and allows threat actors to control the malicious extension by changing the scripts.

If we look at the script, we can see that the extension performs various actions on the targeted websites. For example, it has the ability to retrieve the victims’ addresses, obtain account information, bypass 2FA, and much more. Moreover, it’s capable of transferring BTC currency from the victim’s wallet to the attackers’ wallet.

Functions from the web inject script

Looking at the full web inject script, we can conclude that the idea behind it is to steal BTC currencies from victims who have the malicious extension installed. The extension performs various actions on the account in order to remotely control it using the web inject scripts, and eventually the extension tries to withdraw the BTC currency to the threat actors’ wallet. To circumvent the 2FA settings for transactions, the web inject script uses 2FA bypass techniques.

Snippet of the BTC withdrawal function from the web inject script

Before stealing the cryptocurrency, the extension communicates with the C2 server to get the minimum BTC value. It then compares this value with the actual amount of money in the target wallet. If the wallet contains less cryptocurrency than the minimum amount received from the C2, it doesn’t withdraw any cryptocurrency from it.

Minimum amount threshold from C2

The script also performs several other checks before stealing the BTC currency. For example, it also checks the BTC to USD exchange rate.

When the amount of BTC in the target wallet meets the C2 checks, the script performs the withdrawal function to steal the BTC currency from the victim.

Performing balance check

In addition to stealing BTC, the malicious extension performs additional actions to hide its activity.

For example, the malicious extension contains scripts that target three different email services: Gmail, Hotmail and Yahoo. The idea behind the scripts is to hide the email confirmation of the transaction performed by the malicious extension.

Each script makes visual changes to the emails once the victim reaches the email service’s page. It searches for pre-defined email titles and content, and when it finds them, it simply hides them from the victim by injecting HTML code into the message body. As a result, the victim is unaware that a specific transaction transferring crypto currency to the threat actors’ wallet was made.

Extension JS targeting Gmail

In addition, the extension can manipulate email threads from the targeted websites, so if the victim opens a thread from, for example, Binance, it can change the content of the emails and display a fake email thread that looks exactly like the real one. It also contains a placeholder for desired strings that the extension can inject into the content of the message page.

Fake email thread template

The malicious extension has many other JavaScripts and it’s capable of performing additional actions. For example, it can extract information through the browser, such as the system information, cookies, browser history, screenshots of opened tabs, and even receive commands from the C2 server.

JavaScripts: requesting commands from the C2 (left pane) and taking screenshots (right pane)

The purpose of the extension is to steal BTC and manipulate targeted cryptocurrency websites and email services to make the malware as stealthy as possible, so the victim doesn’t notice any information about the fraudulent transactions. The extension can update its functionality due to the technique used to retrieve the C2 server via the last transaction of a specific BTC wallet, which can be modified at any time by making another transaction to this wallet. This allows the threat actors to change the domain URL to a different one in case it’s banned or blocked by antivirus vendors.

Victims

This campaign targets individual users around the world. According to our telemetry, in Q1 2023 users in the following countries were most frequently infected: Brazil, Algeria, Turkey, Vietnam, Indonesia, India, Egypt, Mexico.

Conclusions

Satacom is a downloader that is still running campaigns and being developed by the threat actor behind it. This threat actor continues to distribute malware families using various techniques, such as ad injection via ad plugins for WordPress websites.

The recently distributed malware, which is a side-loaded extension for Chromium-based browsers, performs actions in the browser to manipulate the content of the targeted cryptocurrency website. The main purpose of this malicious extension is to steal cryptocurrency from victims and transfer it to the threat actors’ wallet.

Moreover, since it is a browser extension, it can be installed in Chromium-based browsers on various platforms. Although the installation of the malicious extension and the infection chain described in this article are Windows-specific, if the threat actors want to target Linux and macOS users, they could easily do so, provided the victims use Chromium-based browsers.

Appendix I – Indicators of Compromise

Satacom files
0ac34b67e634e49b0f75cf2be388f244
1aa7ad7efb1b48a28c6ccf7b496c9cfd
199017082159b23decdf63b22e07a7a1

Satacom DNS
dns-beast[.]com
don-dns[.]com
die-dns[.]com

Satacom C2
hit-mee[.]com
noname-domain[.]com
don-die[.]com
old-big[.]com

Hosted PS scripts
tchk-1[.]com

Malicious extension ZIP
a7f17ed79777f28bf9c9cebaa01c8d70

Malicious extension CC
you-rabbit[.]com
web-lox[.]com

Hosted Satacom installer ZIP files
ht-specialize[.]xyz
ht-input[.]cfd
ht-queen[.]cfd
ht-dilemma[.]xyz
ht-input[.]cfd
io-strength[.]cfd
fbs-university[.]xyz
io-previous[.]xyz
io-band[.]cfd
io-strength[.]cfd
io-band[.]cfd
can-nothing[.]cfd
scope-chat[.]xyz
stroke-chat[.]click
icl-surprise[.]xyz
new-high[.]click
shrimp-clock[.]click
oo-knowledge[.]xyz
oo-station[.]xyz
oo-blue[.]click
oo-strategy[.]xyz
oo-clearly[.]click
economy-h[.]xyz
medical-h[.]click
hospital-h[.]xyz
church-h[.]click
close-h[.]xyz
thousand-h[.]click
risk-h[.]xyz
current-h[.]click
fire-h[.]xyz
future-h[.]click
moment-are[.]xyz
himself-are[.]click
air-are[.]xyz
teacher-are[.]click
force-are[.]xyz
enough-are[.]xyz
education-are[.]click
across-are[.]xyz
although-are[.]click
punishment-chat[.]click
rjjy-easily[.]xyz
guy-seventh[.]cfd

Redirectors to Satacom installer
back-may[.]com
post-make[.]com
filesend[.]live
soft-kind[.]com
ee-softs[.]com
big-loads[.]com
el-softs[.]com
softs-labs[.]com
soft-make[.]com
soft-end[.]com
soon-soft[.]com
tip-want[.]click
get-loads[.]com
new-loads[.]com
file-send[.]live
filetosend-upload[.]net
file-send[.]cc

Appendix II – MITRE ATT&CK Mapping

This table contains all the TTPs identified during analysis of the activity described in this report.

Sometimes when investigating an infection and focusing on a targeted attack, we come across something we were not expecting. The case described below is one such occurrence.

In June 2022, we found a suspicious shellcode running in the memory of a system process. We decided to dig deeper and investigate how the shellcode was initially placed into the process and where on the infected system the threat was hidden.

The infection chain

We were unable to reproduce the whole infection procedure, but we were able to reconstruct it from the point at which PowerShell was executed, as shown in the sceme below.

General attack execution flow

In a nutshell, the infection chain is as follows:

1. PowerShell script runs via the Task Scheduler and downloads the lgntoerr.gif file from a remote server.
2. The script decrypts lgntoerr.gif, resulting in a .NET DLL, which is then loaded.
3. The .NET DLL extracts and decrypts three files from its resources: two DLLs and an encrypted payload. The extracted files are placed in the ProgramData directory.
4. The .NET DLL creates a task to autorun the legitimate ilasm.exe component at system startup via Task Scheduler.
5. Task Scheduler starts ilasm.exe from the ProgramData directory.
6. ilasm.exe launches fusion.dll, a malicious DLL hijacker, from the same directory.
7. fusion.dll loads the second decrypted DLL.
8. That DLL creates a suspended dllhost.exe process.
9. It then decrypts the payload from the encrypted binary file.
10. The decrypted payload is loaded into the dllhost.exe process as a DLL.
11. The PID of the dllhost.exe process is saved to a file in the ProgramData directory.
12. The dllhost.exe process passes control to the decrypted payload.
13. The payload DLL extracts and launches the miner DLL in memory.

We named this malware Minas. From our reconstruction of the infection chain, we determined that it originated by running an encoded PowerShell script as a task, which we believe with low confidence was created through GPO:

Encoded PowerShell command

Technical description

The core functionality of the PowerShell script is to launch the malware installation process. To do this, the PowerShell script downloads an encrypted payload from a remote server, decrypts it using a custom XOR encryption algorithm with the key “fuckkasd9akey” and loads the  payload into memory:

Decoded PowerShell command

The payload is a .NET binary (DLL) that is launched by the PowerShell process, passing three arguments:

$a.GetType(“I.C”).GetMethod(“I”).Invoke($null, ([Byte[]]($d),”A5D9FD13″,0));

1. $d: .NET DLL as an array of bytes;
2. A5D9FD13: (key for decrypting resources in the .NET DLL);
3. 0: (parameter used to block the creation of more than one main payload process).

This .NET binary (which we will refer to as “the installer”) is responsible for the subsequent installation of the malware components contained in the resources of .NET DLL.

Using hash functions (Ap, SDBM, RS), the installer creates a directory structure:

C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\ilasm.exe
C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\fusion.dll
C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}
C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}.dll

Example files and directories

Next, it checks for the presence of the legitimate ilasm.exe file (version 4.0.30319 located at %windir%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe or version 2.0.50727 located at %windir%\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe) on the system (note that if ilasm.exe is present on the system, it should be in one of these directories). If the file is not found, the installation process will be terminated. As soon as ilasm.exe is found, a Scheduled Task is created as a persistence mechanism:

• Task path – C:\Windows\System32\Tasks\Windows\Microsoft\{RSHash(ApHash(Hostname))}\{ApHash(RSHash(Hostname))}
• File name - C:\ProgramData\{ApHash(MachineName)}\{ApHash(MachineName)}\ilasm.exe
• Delay - 120 seconds

After this, the files are copied to the previously created directories as mentioned above (see directory structure).

The malware then proceeds to append the first 100 bytes of the installer to the file {RSHash(MachineName)} that was extracted from the “_64_bin” .NET DLL resource, and the resulting file is encrypted (the key is the machine name in lower case). In addition, up to 10240 of random bytes are appended to the fusion.dll and {SDBMHash(MachineName)}.dll files, thus rendering hash detection by anti-malware products ineffective.

After that, the installer starts the previously created task for the running ilasm.exe, which in turn loads the malicious fusion.dll library located in the same directory, under the assumption it is using the legitimate fusion.dll (DLL hijacking technique).

The malware execution process consists of two loaders: DLL hijacker fusion.dll and the next stage loader {SDBMHash(MachineName)}.dll.

The DLL hijacker does three things:

1. Hides the console of the ilasm.exe process.
2. Determines whether the name of the process is ilasm.exe. If not, it terminates the process.
3. Based on the SDBM hash function, it builds the path C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}.dll and tries to load that DLL into memory via the LoadLibraryA API function.

The loaded {SDBMHash(MachineName)}.dll DLL again checks whether the name of the process is ilasm.exe.

It then generates the file path C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})} and checks if it exists. If the file exists, it reads the value (decimal number) from it. This decimal number is the PID of the dllhost.exe process multiplied by 0x1F4 created by a previous run of Minas. The loader then tries to terminate the process with that PID.

It then reads and decrypts (recall that the key is the machine name in lower case) the main payload (the miner) located at C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}. In addition, the loader creates a process environment variable (SetEnvironmentVariable) configuration with values ​​{“addr”:”185.243.112.239:443″,”p”:”143e256609bcb0be5b9f9c8f79bdf8c9″} (see the configuration description below for more details).

Passing parameters through the process

After that, {SDBMHash(MachineName)}.dll creates a suspended dllhost.exe process, creates a section, maps it into the dllhost.exe process and writes the previously read and decrypted file (raw loader with the miner component). It then reads the memory of the dllhost.exe process, determines the entry point of the main thread and rewrites it to:

sub rsp, 48
call (section with the body of a previously written data)
nop

The PID of the created dllhost.exe process multiplied by 0x1F4 is then written to C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}, after which the dllhost.exe process resumes. It then terminates the ilasm.exe process.

Last but not least, dllhost.exe passes control flow to the decrypted raw loader that maps the XMRig miner (assembly of the XMRig miner in the form of a DLL file) in the process memory, and then launches it using reflective loading.

The miner gets the values ​​of the process environment variable configuration using (GetEnvironmentVariable). These values ​​are used for mining cryptocurrency with the following configuration:

"-o 185.243.112.239:443" (IP address obtained from environment variable configuration, addr value) — acts as the address of the mining server.
"--tls" Enables SSL/TLS support (requires pooling support).
"--tls-fingerprint 14E18CC1BD2F1AF7344B31692CAEDA949A62F71475F43AE4D9EA287E9847B495" Pool TLS certificate thumbprint for certificate hard pinning.
"cpu-max-threads-hint 64" Maximum number of threads.
"-B" Runs the miner in the background.
"--rig-id 143e256609bcb0be5b9f9c8f79bdf8c9" (rig ID obtained from configuration environment variable, p value) — Rig ID for pool statistics (requires pool support).

Conclusion

Minas is a miner that uses a standard implementation and aims to hide its presence. The difficulty of detection is achieved due to encryption, the random generation of names and the use of hijacking and injection techniques. It also has the ability to stay on the infected system using persistence techniques.

Although we were unable to determine with complete certainty how the initial PowerShell command was executed, our indicators pointed to execution via GPO. This is particularly worrisome because it means the attackers have compromised the network, indicating that they are going to great lengths to install their miners.

Also, it is very likely that a new variant will be released in the future that avoids AV detection. As a rule of thumb, use an AV that doesn’t primarily rely on signature detection, but also looks at (processes) behavior.

Minas indicators of compromise

MD5 hashes
08da41489b4b68565dc77bb9acb1ecb4
06fe9ab0b17f659486e3c3ace43f0e3a
f38a1b6b132afa55ab48b4b7a8986181
63e0cd6475214c697c5fc115d40327b4

More indicators of compromise and YARA rules for detecting Minas malware are available for TIP subscribers. Contact intelreports@kaspersky.com for more details.

Every once in a while, someone will come across malicious apps on Google Play that seem harmless at first. Some of the trickiest of these are subscription Trojans, which often go unnoticed until the user finds they have been charged for services they never intended to buy. This kind of malware often finds its way into the official marketplace for Android apps. The Jocker family and the recently discovered Harly family are just two examples of this. Our latest discovery, which we call “Fleckpe”, also spreads via Google Play as part of photo editing apps, smartphone wallpaper packs and so on.

Fleckpe technical description

Our data suggests that the Trojan has been active since 2022. We have found eleven Fleckpe-infected apps on Google Play, which have been installed on more than 620,000 devices. All of the apps had been removed from the marketplace by the time our report was published but the malicious actors might have deployed other, as yet undiscovered, apps, so the real number of installations could be higher.

And here is a description of Fleckpe’s modus operandi. When the app starts, it loads a heavily obfuscated native library containing a malicious dropper that decrypts and runs a payload from the app assets.

Malicious library loading

The payload contacts the threat actors’ C&C server, sending information about the infected device, such as the MCC (Mobile Country Code) and MNC (Mobile Network Code), which can be used to identify the victim’s country and carrier. The C&C server returns a paid subscription page. The Trojan opens the page in an invisible web browser and attempts to subscribe on the user’s behalf. If this requires a confirmation code, the malware gets it from notifications (access to which was asked at the first run).

Intercepting notifications

Having found the code, the Trojan enters it in the appropriate field and completes the subscription process. The victim proceeds to use the app’s legitimate functionality, for example, installs wallpapers or edits photos, unaware of the fact that they are being subscribed to a paid service.

Entering the confirmation code

The Trojan keeps evolving. In recent versions, its creators upgraded the native library by moving most of the subscription code there. The payload now only intercepts notifications and views web pages, acting as a bridge between the native code and the Android components required for purchasing a subscription. This was done to significantly complicate analysis and make the malware difficult to detect with the security tools. Unlike the native library, the payload has next to no evasion capabilities, although the malicious actors did add some code obfuscation to the latest version.

Core logic inside the native method

Victims

We found that the Trojan contained hard-coded Thai MCC and MNC values, apparently used for testing. Thai-speaking users notably dominated the reviews for the infected apps on Google Play. This led us to believe that this particular malware targeted users from Thailand, although our telemetry showed that there had been victims in Poland, Malaysia, Indonesia and Singapore.

The Thai test MCC and MNC values

Kaspersky security products detect the malicious app as Trojan.AndroidOS.Fleckpe.

Conclusion

Sadly, subscription Trojans have only gained popularity with scammers lately. Their operators have increasingly turned to official marketplaces like Google Play to spread their malware. Growing complexity of the Trojans has allowed them to successfully bypass many anti-malware checks implemented by the marketplaces, remaining undetected for long periods of time. Affected users often fail to discover the unwanted subscriptions right away, let alone find out how they happened in the first place. All this makes subscription Trojans a reliable source of illegal income in the eyes of cybercriminals.

To avoid malware infection and subsequent financial loss, we recommend to be cautious with apps, even those coming from Google Play, avoid giving permissions they should not have, and install an antivirus product capable of detecting this type of Trojans.

IOCs

Package names
com.impressionism.prozs.app
com.picture.pictureframe
com.beauty.slimming.pro
com.beauty.camera.plus.photoeditor
com.microclip.vodeoeditor
com.gif.camera.editor
com.apps.camera.photos
com.toolbox.photoeditor
com.hd.h4ks.wallpaper
com.draw.graffiti
com.urox.opixe.nightcamreapro

MD5
F671A685FC47B83488871AE41A52BF4C
5CE7D0A72B1BD805C79C5FE3A48E66C2
D39B472B0974DF19E5EFBDA4C629E4D5
175C59C0F9FAB032DDE32C7D5BEEDE11
101500CD421566690744558AF3F0B8CC
7F391B24D83CEE69672618105F8167E1
F3ECF39BB0296AC37C7F35EE4C6EDDBC
E92FF47D733E2E964106EDC06F6B758A
B66D77370F522C6D640C54DA2D11735E
3D0A18503C4EF830E2D3FBE43ECBE811
1879C233599E7F2634EF8D5041001D40
C5DD2EA5B1A292129D4ECFBEB09343C4
DD16BD0CB8F30B2F6DAAC91AF4D350BE
2B6B1F7B220C69D37A413B0C448AA56A
AA1CEC619BF65972D220904130AED3D9
0BEEC878FF2645778472B97C1F8B4113
40C451061507D996C0AB8A233BD99FF8
37162C08587F5C3009AFCEEC3EFA43EB
BDBBF20B3866C781F7F9D4F1C2B5F2D3
063093EB8F8748C126A6AD3E31C9E6FE
8095C11E404A3E701E13A6220D0623B9
ECDC4606901ABD9BB0B160197EFE39B7

C&C
hxxp://ac.iprocam[.]xyz
hxxp://ad.iprocam[.]xyz
hxxp://ap.iprocam[.]xyz
hxxp://b7.photoeffect[.]xyz
hxxp://ba3.photoeffect[.]xyz
hxxp://f0.photoeffect[.]xyz
hxxp://m11.slimedit[.]live
hxxp://m12.slimedit[.]live
hxxp://m13.slimedit[.]live
hxxp://ba.beautycam[.]xyz
hxxp://f6.beautycam[.]xyz
hxxp://f8a.beautycam[.]xyz
hxxp://ae.mveditor[.]xyz
hxxp://b8c.mveditor[.]xyz
hxxp://d3.mveditor[.]xyz
hxxp://fa.gifcam[.]xyz
hxxp://fb.gifcam[.]xyz
hxxp://fl.gifcam[.]xyz
hxxp://a.hdmodecam[.]live
hxxp://b.hdmodecam[.]live
hxxp://l.hdmodecam[.]live
hxxp://vd.toobox[.]online
hxxp://ve.toobox[.]online
hxxp://vt.toobox[.]online
hxxp://54.245.21[.]104
hxxp://t1.twmills[.]xyz
hxxp://t2.twmills[.]xyz
hxxp://t3.twmills[.]xyz
hxxp://api.odskguo[.]xyz
hxxp://gbcf.odskguo[.]xyz
hxxp://track.odskguo[.]xyz

In early April, we detected a significant increase in attacks that use banking Trojans of the QBot family (aka QakBot, QuackBot, and Pinkslipbot). The malware would be delivered through e-mail letters written in different languages — variations of them were coming in English, German, Italian, and French. The messages were based on real business letters the attackers had gotten access to, which afforded them the opportunity to join the correspondence thread with messages of their own. As a general rule, such letters would be urging the addressee — under a plausible pretext — to open an enclosed PDF file. As an example, they could be asking to provide all the documentation pertaining to the attached application or to calculate the contract value based on the attached cost estimate.

Example of a forwarded letter containing a malicious attachment

Such simulated business correspondence can obstruct spam tracking while increasing the probability of the victim falling for the trick. For authenticity, the attackers put the sender’s name from the previous letters in the ‘From’ field; however, the sender’s fraudulent e-mail address will be different from that of the real correspondent.

A short look at QBot

The banking Trojan QBot was detected for the first time in 2007. Since then, it has gone through multiple modifications and improvements to become one of the most actively spread malware in 2020. In 2021, we published a detailed QBot technical analysis. Currently the banker keeps getting new functions and module updates for increased effectiveness and profit.

QBot distribution methods have also evolved. Early on it was distributed through infected websites and pirated software. Now the banker is delivered to potential victims through malware already residing on their computers, social engineering, and spam mailings.

QBot infection chain

New QBot infection chain

The QBot malware delivery scheme begins with an e-mail letter with a PDF file in the attachment being sent. The document’s content imitates a Microsoft Office 365 or Microsoft Azure alert advising the user to click Open to view the attached files. If the user complies, an archive will be downloaded from a remote server (compromised site), protected with a password given in the original PDF file.

Examples of PDF attachments

In the downloaded archive there is a .wsf (Windows Script File) file containing an obfuscated script written in JScript.

Obfuscated JScript

After the WSF file is deobfuscated its true payload gets revealed: a PowerShell script encoded into a Base64 line.

Encoded PowerShell script

So, as soon as the user opens the WSF file from the archive, the PowerShell script will be discretely run on the computer and use wget to download a DLL file from a remote server. The library’s name is an automatically generated alphabetic sequence varying from one victim to another.

Decoded PowerShell script

The PowerShell script will try in succession to download the file from each one of the URLs listed in the code. To figure whether the download attempt was successful, the script will check the file size using the Get-Item command to get the information. If the file size is 100,000 bytes or more, the script will run the DLL with the help of rundll32. Otherwise, it will wait for four seconds before attempting to download the library using the next link down the list. The downloaded library is the Trojan known as QBot (detected as Trojan-Banker.Win32.Qbot.aiex).

Technical description of malicious DLL

We have analyzed the Qbot samples from the current e-mail campaign. The bot’s configuration block features company name “obama249” and time stamp “1680763529” (corresponding to April 6, 2023 6:45:29), as well as over a hundred IP addresses the bot will be using to connect to command servers. Most of these addresses belong to those users, whose infected systems provide an entry point into the chain which is used to redirect the botnet traffic to real command servers.

Qbot’s functionality hardly changed in the past couple of years. As before, the bot is capable of extracting passwords and cookies from browsers, stealing letters from your mailbox, intercepting traffic, and giving operators remote access to the infected system. Depending on the value of the victim, additional malware can be downloaded locally, such as CobaltStrike (to spread the infection through the corporate network) or various ransomware. Or else the victim’s computer can be turned into a proxy server to facilitate redirection of traffic, including spam traffic.

Statistics

We have analyzed the QBot attack statistics collected using Kaspersky Security Network (KSN). According to our data, the first letters with malicious PDF attachments began to arrive in the evening of April 4. The mass e-mail campaign began at 12:00 p.m. on the following day and continued until 9:00 p.m. During that time we detected an approximate total of 1,000 letters. The second upsurge began on April 6, again at noon, with over 1,500 letters dispatched to our customers this time. For the next few days new messages kept coming, and soon, on the evening of April 12 we discovered another upsurge with 2,000 more letters sent to our customers. After that cybercriminal activity went down, but users still receive fraudulent messages.

Geography of Qbot family attacks, April 1–11, 2023 (download)

In addition, we checked which countries were targeted by Qbot the most by relating the number of users attacked in a given country against the total number of users attacked worldwide. It turned out, the bank Trojan QBot was a more common issue for the residents of Germany (28.01%), Argentina (9.78%), and Italy (9.58%).

QBot is a well-known malware. Kaspersky solutions for consumers and for business use multi-layered approach, including Behavior Detection to detect and block this threat including the variant described in this article. All components of the attack are detected as HEUR:Trojan.PDF.QBot.gen, HEUR:Trojan.Script.Generic, Trojan-Banker.Win32.Qbot, and HEUR:Trojan-Dropper.Script.Qbot.gen, PDM:Trojan.Win32.Generic. Kaspersky solutions also detect and block most of the spam emails used in this attack.

Qbot indicators of compromise

MD5

PDF files
253E43124F66F4FAF23F9671BBBA3D98
39FD8E69EB4CA6DA43B3BE015C2D8B7D

ZIP archives
299FC65A2EECF5B9EF06F167575CC9E2
A6120562EB673552A61F7EEB577C05F8

WSF files
1FBFE5C1CD26C536FC87C46B46DB754D
FD57B3C5D73A4ECD03DF67BA2E48F661

DLL
28C25753F1ECD5C47D316394C7FCEDE2

Malicious links

ZIP archive
cica.com[.]co/stai/stai.php
abhishekmeena[.]in/ducs/ducs.php

DLL
rosewoodlaminates[.]com/hea/yWY9SJ4VOH
agtendelperu[.]com/FPu0Fa/EpN5Xvh
capitalperurrhh[.]com/vQ1iQg/u6oL8xlJ
centerkick[.]com/IC5EQ8/2v6u6vKQwk8
chimpcity[.]com/h7e/p5FuepRZjx
graficalevi.com[.]br/0p6P/R94icuyQ
kmphi[.]com/FWovmB/8oZ0BOV5HqEX
propertynear.co[.]uk/QyYWyp/XRgRWEdFv
theshirtsummit[.]com/MwBGSm/lGP5mGh

It is often the case that something new is just a reincarnation of something old. We have come across a series of clipboard injection attacks on cryptocurrency users, which emerged starting from September 2022. Although we have written about a similar malware attack in 2017 in one of our blogposts, the technique is still very relevant today as it doesn’t have any perfect solution from the perspective of operating system design. The only way to prevent such attacks is to be extremely cautious and attentive, or use a decent anti-malware solution to detect a piece of malicious code. As long as such attacks continue to thrive in the modern ecosystem of the cryptocurrency world, it’s worth explaining how they work and where the danger lies.

In a nutshell, the attack relies on malware replacing part of the clipboard contents once it detects a wallet address in it.

Past attacks

This technique of replacing clipboard contents is more than a decade old. It all started from banking trojans focused on specific banks and replacing bank account numbers in the clipboard. Here is a report from CERT Polska that warned Polish users about such a threat targeting users of local banks in 2013. However, such attacks required detecting a particular internet banking environment, and their success depended also on other fields being filled correctly (i.e. bank SWIFT code, branch name, etc). Focusing on something global and provider-independent, such as a cryptocurrency wallet, made it much more efficient for cryptothieves. Adding increased value of cryptocurrencies made it a very lucrative target. So, this is where we started seeing the first clipboard attacks on cryptocurrency owners. They were replicated and reused in other malware too. We even made a generic detection for some of such families, naming them Generic.ClipBanker.

Why it is dangerous

Despite the attack being fundamentally simple, it harbors more danger than would seem. And not only because it creates irreversible money transfers, but because it is so passive and hard to detect for a normal user. Just think of it, most malware is only efficient when there is a communication channel established between the malware operator and the victim’s system. Backdoors require a control channel, spying trojans require a way to pass stolen data, cryptominers need network communication too, etc. It’s only a small fraction of malware that exist on their own and do not require any communication channel. But this is the most dangerous and harmful kind: self-replicating malware, such as destructive viruses and network worms; ransomware that silently encrypts local files, and so on. While worms and viruses may not connect to the attacker’s control servers, they generate visible network activity, or increase CPU or RAM consumption. So does encrypting ransomware. Clipboard injectors, on the contrary, can be silent for years, show no network activity or any other signs of presence until the disastrous day when they replace a cryptowallet address.

Another factor is detection of the malware payload. While most malware is discovered through an association with known bad infrastructure (IPs, domains, URLs), or when it automatically activates a malicious payload, clipboard injectors do not run their evil payload unless an external condition (the clipboard contains data of certain format) is met. This further lowers the chances of new malware being discovered through automatic sandboxing.

Trojanized Tor Browser installers

Some recent developments in the use of this type of malware seek to abuse Tor Browser, a tool to access the dark web using the Onion protocol, also known as the Tor network. We relate this to the ban of Tor Project’s website in Russia at the end of 2021, which was reported by the Tor Project itself. According to the latter, Russia was the second largest country by number of Tor users in 2021 (with over 300,000 daily users, or 15% of all Tor users). The Tor Project called to help keep Russian users connected to Tor to circumvent censorship. Malware authors heard the call and responded by creating trojanized Tor Browser bundles and distributing them among Russian-speaking users. The first variants appeared in December 2021, but only since August 2022 have we seen a larger wave of torbrowser_ru.exe malicious executables. The trojanized installers offered Tor Browser with a regional language pack, including Russian, as the file name suggests:

Supported languages in the trojanized installer

We have come across hundreds of similar installers that all behaved according to the following scenario:

Trojanized Tor Browser extracting and launching a malware payload

The target user downloads Tor Browser from a third-party resource and starts it as torbrowser.exe. The installer is missing a digital signature and is just a RAR SFX (self-extracting executable) archive. It contains three files:

• The original torbrowser.exe installer with a valid digital signature from the Tor Project.
• A command-line RAR extraction tool with a randomized name.
• A password-protected RAR archive (random password).

The SFX starts the original torbrowser.exe as a disguise, while also running the RAR extraction tool on the embedded password-protected RAR archive. The purpose of protecting it with a password is to evade static-signature detection by antivirus solutions. It doesn’t protect the malware from sandbox-based detection. The password and the destination for the extraction are part of the trojanized torbrowser.exe executable, and may be extracted via manual analysis. Once the file is dropped inside one of the current user AppData subdirectories, the dropped executable is started as a new process and registers itself in the system autostart. Most of the time, the executable is disguised with the icon of a popular application, such as uTorrent.

Clipboard-injector malware

The payload of this installer is passive and communicationless clipboard-injector malware.

The malware is protected with the Enigma packer v4.0, which complicates analysis. Enigma is a commercial software protector. The malware authors likely used a cracked version of the packer lacking any license information. However, if this or another instance from the same malware authors appears in the hands of law enforcement officers, we would like to leave a reference to their system drive serial number, which we extracted from the malware sample: 9061E43A.

The payload of this malware is rather simple: the malware integrates into the chain of Windows clipboard viewers and receives a notification every time the clipboard data is changed. If the clipboard contains text, it scans the contents with a set of embedded regular expressions. Should it find a match, it is replaced with one randomly chosen address from a hardcoded list.

Hexdump of the malware data with regular expressions and replacement wallet IDs

We identified the following regular expressions inside the sample.
bc1[a-zA-HJ-NP-Z0-9]{35,99}($|\s) – Bitcoin
(^|\s)[3]{1}[a-km-zA-HJ-NP-Z1-9]{25,34}($|\s) – Litecoin/Bitcoin Legacy
(^|\s)D[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}($|\s) – Dogecoin
(^|\s)0x[A-Fa-f0-9]{40}($|\s) – ERC-20 (i.e. Ethereum, Tether, Ripple, etc)
(^|\s)[LM]{1}[a-km-zA-HJ-NP-Z1-9]{25,34}($|\s) – Litecoin Legacy
((^|\s)ltc1[a-zA-HJ-NP-Z0-9]{35,99}($|\s) – Litecoin
(^|\s)8[0-9A-B]{1}[1-9A-HJ-NP-Za-km-z]{93,117}($|\s) – Monero
(^|\s)4[0-9A-B]{1}[1-9A-HJ-NP-Za-km-z]{93,117}($|\s) – Monero

Each sample contains thousands of possible replacement addresses for Bitcoin. Including thousands of addresses makes it harder to denylist them or to trace the theft. However, we collected all of them and would like to share them with researchers and investigators in an attachment to this blog.

The malware authors also preserved a feature to disable their creation: a special hotkey combination (Ctrl+Alt+F10). Pressing it causes the malware to unregister all handlers and stop running. The purpose was likely to disable the malware during the testing stage.

Victimology

Among the roughly 16,000 detections, the majority were registered in Russia and Eastern Europe. However, the threat spread to at least 52 countries worldwide. Here are the TOP 10 countries affected, according to our own data:

• Russia
• Ukraine
• United States
• Germany
• Uzbekistan
• Belarus
• China
• Netherlands
• United Kingdom
• France

Detections of the malicious Tor Browser worldwide, January 2022 – February 2023 (download)

Given that we only see a fraction of the real picture, the global number of infections may well be several or even tens of times higher.

Impact

To measure the impact, we collected hundreds of known malware samples, unpacked them from Enigma, and extracted the cryptowallet replacement addresses. Then we walked through the respective blockchains and calculated the total inputs to the wallets, assuming they all came from compromised users. This is how we measured the total loss caused by this single malware developer.

Stolen cryptocurrencies (converted to USD at the exchange rate valid at the time of writing) (download)

Due to its advanced technology that anonymizes transaction data to achieve maximum privacy, the Monero public ledger doesn’t reveal the transferred amount, so we couldn’t really look into it, but it is likely to be very small compared to the Bitcoin theft.

We believe that the actual theft is bigger because this research is focused on Tor Browser abuse. There may be other campaigns, abusing different software and using other means of malware delivery as well as other types of wallets.

Countermeasures

A mistake likely made by all victims of this malware was to download and run Tor Browser from a third-party resource. We haven’t managed to identify a single website that hosts the installer, so it is likely distributed either via torrent downloads or some other software downloader. The installers coming from the official Tor Project were digitally signed and didn’t contain any signs of such malware. So, to stay safe, in the first place, download software only from reliable and trusted sources.

However, even if you do download a rogue file masked as something else, using a decent antivirus solution or uploading the file to VirusTotal could help identify any malicious intent. Despite all attempts to evade detection, the malware will get discovered, it’s only a matter of time.

Lastly, if you would like to check if your system is compromised with malware from the same class, here is a quick Notepad trick. Type or copy the following “Bitcoin address” in Notepad: bc1heymalwarehowaboutyoureplacethisaddress

Now press Ctrl+C and Ctrl+V. If the address changes to something else — the system is likely compromised by a clipboard-injector type of malware, and is dangerous to use. At this stage we recommend scanning your system with security software for any malware presence. But if you want to have full confidence that no hidden backdoors remain, once a system is compromised, it should not be trusted until rebuilt.

Bitcoin address replaced by malware after pasting in an infected system

Stay safe and don’t let your coins fall into the hands of criminals.

Appendix (indicators of compromise)

Examples of clipboard injectors:

0251fd9c0cd98eb9d35768bb82b57590
036b054c9b4f4ab33da63865d69426ff
037c5bacac12ac4fec07652e25cd5f07
0533fc0c282dd534eb8e32c3ef07fba4
05cedc35de2c003f2b76fe38fa62faa5
0a14b25bff0758cdf7472ac3ac7e21a3
0b2ca1c5439fcac80cb7dd70895f41a6
0c4144a9403419f7b04f20be0a53d558
0d09d13cd019cbebf0d8bfff22bf6185
0d571a2c4ae69672a9692275e325b943

Examples of Tor Browser installers:

a7961c947cf360bbca2517ea4c80ee11
0be06631151bbe6528e4e2ad21452a17
a2b8c62fe1b2191485439dd2c2d9a7b5
53d35403fa4aa184d77a4e5d6f1eb060
ad9460e0a58f0c5638a23bb2a78d5ad7
cbb6f4a740078213abc45c27a2ab9d1c
eaf40e175c15c9c9ab3e170859bdef64
89c86c391bf3275790b465232c37ddf5
1ce04300e880fd12260be4d10705c34f
c137495da5456ec0689bbbcca1f9855e

Replacement addresses for Bitcoin wallets:
Download address list (PDF)

In recent months, we observed an increase in the number of malicious campaigns that use Google Advertising as a means of distributing and delivering malware. At least two different stealers, Rhadamanthys and RedLine, were abusing the search engine promotion plan in order to deliver malicious payloads to victims’ machines. They seem to use the same technique of mimicking a website associated with well-known software like Notepad++ and Blender 3D.

The treat actors create copies of legit software websites while employing typosquatting (exploiting incorrectly spelled popular brands and company names as URLs) or combosquatting (using popular brands and company names combined with arbitrary words as URLs) to make the sites look like the real thing to the end user—the domain names allude to the original software or vendor. The design and the content of the fake web pages look the same as those of the original ones. Threat actors then pay to promote the website in the search engine in order to push it to the top search results. The technique is called “malvertising”.

Our observations

In the following snapshots, we can see Google ads promoting fake pages for AMD drivers and the Blender 3D software. If we take a closer look at the URLs, we will see that the domain names incorporate the software name but are in fact unrelated to the real AMD or Blender 3D vendors. In most cases, the top-level domains are different from those of the official sites as well. The use of less common TLDs enables the threat actors to register second-level domains that are similar to the real ones. These domains lure victims to click on the link and access the fake website more often than random domains registered in a more common domain zone, such as COM, because they may look more like a legitimate website.

Fake AMD and Blender 3D websites in search results

We visited some of the promoted sites and obtained the malicious payloads they were distributing. In this article, we will focus mainly on the “Blender 3D” fake websites.

Fake Blender 3D web pages

The size of the downloaded file (ZIP archive) is 269 MB, which is close to the original Blender installer size. The size of 257 MB stated on the fake web page matches that of the original Blender 3D installer, but it does not match the size of the fake download.

When the user clicks the “Download” button, the archive blender-3.4.1-windows-x64.zip (E0BDF36E4A7CF1B332DC42FD8914BA8B) is downloaded.

The size of the file (BBA8AA93FCDDA5AC7663E90C0EEFA2E7) extracted from the archive is 657 MB. When launched, it drops two files into the temp directory:

• The original Blender 3D MSI installer (marked green on the screenshot below), whose size is also 657 MB;
• A PE file that acts as a next-stage loader for a malicious PE file (marked red), which also has the same size as the original installer: 657 MB.

Dropped files: the original Blender 3D MSI installer and the malicious loader

The size of the dropped malicious loader is this big because it is inflated with junk bytes when the PE file is created. The deflated malicious loader size is about 330 KB, and the rest is junk.

Junk bytes inflating the loader

After the initial installer (extracted from the archive) drops these two files, it runs the malicious PE file using the CMD method (cmd.exe /c [Filename] command) to hide it from the user. Additionally, the initial installer also runs the original Blender 3D MSI to make the victim believe that the desired software is running.

Thus, the threat actors disguise their malicious payload through the installation of another software product by creating a “pre-installer” for the legitimate software, which will put both the malware and the desired genuine software on the victim’s machine.

Blender 3D installer launched by the “pre-installer”

The screenshot above shows the actual software installer running, but if we take a closer look at the processes, we will notice a short-lived sub-process (cmd.exe /c -> “SetupFileProgram”) run by the “pre-installer”. This short-lived process is the loader for the malware.

The loader

The loader is a .NET file protected by an unregistered version of .NET Reactor. It seems to use an anti-debugging technique in order to prevent a debugger from executing and dynamically analyzing the binary. In a nutshell, the loader runs a new powershell.exe process and manipulates it to execute numerous PowerShell commands, which instruct it to access a third-party URL in order to get the payload. The payload is a base64-encoded, AES-encrypted fileless binary. Further commands are related to decoding and decrypting that binary, then running it in memory, within a newly created aspnet_compiler.exe process, a legitimate Windows .NET framework compilation tool.

In this case, we observed two detection evasion tricks during the runtime:

• The fileless technique, which involves getting a payload from an online source and loading it directly into the memory of a process;
• LOLBAS (living-off-the-land binaries and scripts), which, in this case, is the use of a .NET compilation tool to run the malicious binary.

Below, we provide a more detailed analysis of the loader execution chain. After passing the loader anti-debugger, we can see that it starts a PowerShell process, so we will put a breakpoint at the CreateProcessW WinAPI call to observe the behavior.

Call of CreateProcessW to spawn a PowerShell process

Since we did not see any command passed to the PowerShell process when initializing it via the CreateProcessW call, we can conclude that it will be passed at some point later, so we can observe the passing of the PowerShell command(s) by putting a breakpoint at WinAPI WriteFile in order to see the command lines for the powershell.exe process.

So, after letting it run and reach the breakpoint, we will check the result in the return of the function call, and we can see in the stack that the first command pushed to the powershell.exe process was #Start-Sleep -seconds 30;.

Observing the pushed command(s)

We can try checking the memory section where the command is stored and searching for other commands that are being kept in the memory for later use by the loader.

Memory address of the pushed PowerShell commands

After taking all the data from this memory section, we will see all the commands passed to the powershell.exe process via the WriteFile WinAPI call.

PowerShell commands

If we read the commands, we will see exactly what the powershell.exe process is about to do. The commands instruct it to perform the following actions:

1. Download string data, which is part of the following URL, namely the name of the file: http[:]//45.93.201[.]114/docs/[RandomChars].txt. The downloaded data is a Base64-encoded string that is decoded into encrypted data.
2. Prepare the decryption method, AES-CBC, as can be seen in the screenshot above. We can also easily see and decode the Base64-encoded key and IV (initialization vector) used for decryption in the PowerShell command.
3. Decrypt the data into a Gzip-compressed binary.
4. Decompress the binary.
5. Invoke the binary to run it.

Decrypted binary

The extracted binary (RedLine stealer)

The binary that we obtained is the dropper of known malware, the RedLine stealer. The version of the stealer at hand uses an interesting technique to hide its malicious payload: it is encoded in the least significant bit of images stored in the resource section of the dropper, as well as the key and the IV bytes for its AES decryption.

Embedded images with a malicious payload

Payload decryption routine

After decrypting the payload, the dropper starts a legitimate process named “aspnet_compiler.exe”, which is part of the Microsoft .NET framework, and injects the payload into it.

Injecting a payload routine

Infrastructure

To deploy decoy pages, the malefactors register deceptive domain names, such as blender3d-software[.]net or blender3d-software[.]org. We have found more than fifty similar domains hosted at the same IP address: 91.229.23[.]200. These domain names mimic other software distribution sites as well, for example, afterburner-software[.]org, tradingviews-software[.]org, and unity-download[.]com.

The malicious payload could be stored on the same site (for example, hxxps[://]blahder3dsoft[.]store/Blender[.]rar) as the landing page or on a public service that can be used as the file hosting service (MediaFire or GitHub).

Conclusion

We are seeing an increase in the spread of malware families through Google Ads campaigns, specifically through search ads. Threat actors use fake websites to mimic legitimate software vendor websites to lure victims, and pay for ads to promote these. They use typosquatting and combosquatting for their malicious website domains, which have become common techniques in recent months. In some cases, such as the one described in this article, the threat actors also make sure to install the desired software alongside their malicious payload.

In recent campaigns, we observed mainly stealer-type malware, such as RedLine or the notorious Rhadamanthys, which is also known to use malvertising techniques to reach victims and steal data from their compromised machines.

This kind of distribution suggests that the threat actors are targeting victims, both individual and corporate, all around the world.

Indicators of Compromise

Prilex is a singular threat actor that has evolved from ATM-focused malware into unique modular PoS malware—actually, the most advanced PoS threat we have seen so far, as described in a previous article. Forget about those old memory scrapers seen in PoS attacks. Prilex goes beyond these, and it has evolved very differently. This is highly advanced malware adopting a unique cryptographic scheme, doing real-time patching in target software, forcing protocol downgrades, manipulating cryptograms, doing GHOST transactions and performing credit card fraud—even on cards protected with the so-called unhackable CHIP and PIN technology. And now, Prilex has gone even further.

A frequent question asked about this threat was whether Prilex was able to capture data coming from NFC-enabled credit cards. During a recent Incident Response for a customer hit by Prilex, we were able to uncover three new Prilex versions capable of blocking contactless payment transactions, which became very popular in the pandemic times.

This blog post covers the NFC-related capabilities of recent Prilex modifications.

Tap-to-pay

Contactless payment systems are composed of credit and debit cards, key fobs, smart cards, or other devices, including smartphones and other mobile devices that use radio-frequency identification (RFID) or near-field communication (NFC, implemented in Samsung Pay, Apple Pay, Google Pay, Fitbit Pay, or any bank mobile application that supports contactless) for making secure payments.

The embedded integrated circuit chip and antenna enable consumers to pay by waving their card, fob, or handheld device over a reader at a point-of-sale terminal. Contactless payments are made in close physical proximity, unlike other types of mobile payments that use broad-area cellular or WiFi networks and do not require close physical proximity.

Different ways of tap-to-pay, but only one technology: NFC

Here is how they work:

• To make a payment with a contactless credit card, the cardholder simply holds the card close to the contactless-enabled payment terminal (usually within a few inches).
• The terminal sends a radio frequency (RF) signal to the card, activating the RFID chip embedded in the card.
• The RFID chip in the card sends a unique identification number (ID) and transaction information to the terminal. The transaction data is non-reusable, so even if it is stolen by cybercriminals, they cannot steal the money by using that. Neither can they access the RFID chip to tamper with the data generation processes.
• The terminal sends the transaction information to the card issuer’s processing network for authorization.
• If the transaction is approved, the terminal usually displays a confirmation message, and the payment is processed.

The pandemic gave a boost to NFC payments

The size of the global market for contactless payments was estimated at $34.55 billion in 2021 and is expected to continue growing at a compound rate of 19.1% from 2022 to 2030 annually, according to GrandView Research. The market was dominated by the retail segment, which accounted for more than 59.0% of global contactless revenue in 2021. Recent years saw an increase in the number of retail tap-and-go transactions: retailers can clearly see the benefits of contactless payments, which reduce transaction time, increase revenue, and improve operational efficiency. As stated in a Mastercard global study covering the year 2020, 74.0% of retailers expressed the intention to continue using contactless payments beyond the pandemic.

According to the US Payments Forum, Visa reports that in the U.S., tap-to-pay accounts for 28% of all face-to-face transactions, five times the pre-pandemic levels, while Mastercard says that 82% of card-present transactions in the country are happening at contactless-enabled locations. In Australia, contactless payments were growing in popularity even before the pandemic, with four out of five point-of-sale purchases being contactless in 2019. In the coming years, the popularity of this payment method is expected to grow even more everywhere in the world.

Contactless credit cards offer a convenient and secure way to make payments without the need to physically insert or swipe the card. But what happens if a threat can disable these payments in the EFT software running in the computer and force you to insert the card in the PINpad reader?

Insert-to-get-robbed

We have observed three new Prilex versions in the wild and managed to obtain the latest one (version 06.03.8080). The two others are 06.03.8070 and 06.03.8072.

The obtained version was discovered as recently as November 2022 and appears to originate from a different codebase than the others we found at the beginning of that year. Prilex now implements a rule-based file that specifies whether or not to capture credit card information and an option to block NFC-based transactions.

Excerpt from a Prilex rules file referencing NFC blocking

This is due to the fact that NFC-based transactions often generate a unique ID or card number valid for only one transaction. If Prilex detects an NFC-based transaction and blocks it, the EFT software will program the PIN pad to show the following message:

Prilex fake error displayed on the PIN pad reader that says, “Contactless error, insert your card”

Of course, the goal here is to force the victim to use their physical card by inserting it into the PIN pad reader, so the malware will be able to capture the data coming from the transaction by using all the techniques described in our previous publication, such as manipulating cryptograms and performing a GHOST attack. Another interesting new feature added in the latest Prilex samples is the possibility to filter credit cards according to segment and create different rules for each segment. For example, these rules can block NFC and capture card data only if the card is a Black/Infinite, Corporate or another tier with a high transaction limit, which is much more attractive than standard credit cards with a low balance/limit.

Malware adapting to the latest trends

With contactless cards growing in numbers and adoption increasing all over the world, the number of payments using this method has increased significantly and is expected to grow further in the years to come. Since transaction data generated during a contactless payment are useless from a cybercriminal’s perspective, it is understandable that Prilex needs to force victims to insert the card into the infected PoS terminal. While the group is looking for a way to commit fraud with unique credit card numbers, this clever trick allows it to continue operating.

The Prilex family is detected by all Kaspersky products as HEUR:Trojan.Win32.Prilex and HEUR:Trojan.Win64.Prilex. More detailed analysis on the latest Prilex versions and a full analysis are available to customers of our private Threat Intelligence Reports. For any requests on this topic, please contact crimewareintel@kaspersky.com.

Introduction

DTrack is a backdoor used by the Lazarus group. Initially discovered in 2019, the backdoor remains in use three years later. It is used by the Lazarus group against a wide variety of targets. For example, we’ve seen it being used in financial environments where ATMs were breached, in attacks on a nuclear power plant and also in targeted ransomware attacks. Essentially, anywhere the Lazarus group believes they can achieve some financial gain.

DTrack allows criminals to upload, download, start or delete files on the victim host. Among those downloaded and executed files already spotted in the standard DTrack toolset there is a keylogger, a screenshot maker and a module for gathering victim system information. With a toolset like this, criminals can implement lateral movement into the victims’ infrastructure in order to, for example, retrieve compromising information.

As part of our crimeware reporting service, we published a new private report about recent Dtrack activity. In this public article we highlight some of the main findings shared in that report. For more information about our crimeware reporting service, please contact crimewareintel@kaspersky.com.

So, what’s new?

DTrack itself hasn’t changed much over the course of time. Nevertheless, there are some interesting modifications that we want to highlight in this blogpost. Dtrack hides itself inside an executable that looks like a legitimate program, and there are several stages of decryption before the malware payload starts.

First stage – implanted code

DTrack unpacks the malware in several stages. The second stage is stored inside the malware PE file. To get it, there are two approaches:

• offset based;
• resource based.

The idea is that DTrack retrieves the payload by reading it from an offset within the file or by reading it from a resource within the PE binary. An example of a decompiled pseudo function that retrieves the data using the offset-based approach can be found below.

Example of DTrack offset-oriented retrieval function

After retrieving the location of the next stage and its key, the malware then decrypts the buffer (with a modified RC4 algorithm) and passes control to it. To figure out the offset of the payload, its size and decryption keys, DTrack has a special binary (we have dubbed it ‘Decrypt config’) structure hidden in an inconspicuous part of the PE file.

Second stage – shellcode

The second stage payload consists of heavily obfuscated shellcode as can be seen below.

Heavily obfuscated second stage shellcode

The encryption method used by the second layer differs for each sample. So far, we have spotted modified versions of RC4, RC5 and RC6 algorithms. The values of the third stage payload and its decryption key are obtained by reading Decrypt config again.

One new aspect of the recent DTrack variants is that the third stage payload is not necessarily the final payload; there may be another piece of binary data consisting of a binary configuration and at least one shellcode, which in turn decrypts and executes the final payload.

Third stage – shellcode and final binary

The shellcode has some quite interesting obfuscation tricks to make analysis more difficult. When started, the beginning of the key (used to decrypt the final payload) is searched for. For example, when the beginning of the key is 0xDEADBEEF, the shellcode searches for the first occurrence of 0xDEADBEEF.

Chunk decryption routine example

Once the key is found, the shellcode uses it to decrypt the next eight bytes after the key, which form yet another configuration block with final payload size and its entry point offset. The configuration block is followed by an encrypted PE payload that starts at the entry point offset after decryption with the custom algorithm.

Final payload

Once the final payload (a DLL) is decrypted, it is loaded using process hollowing into explorer.exe. In previous DTrack samples the libraries to be loaded were obfuscated strings. In more recent versions they use API hashing to load the proper libraries and functions. Another small change is that three C2 servers are used instead of six. The rest of the payload’s functionality remains the same.

Infrastructure

When we look at the domain names used for C2 servers, a pattern can be seen in some cases. For example, the actors combine a color with the name of an animal (e.g., pinkgoat, purplebear, salmonrabbit). Some of the peculiar names used in the DTrack infrastructure can be found below:

Victims

According to KSN telemetry, we have detected DTrack activity in Germany, Brazil, India, Italy, Mexico, Switzerland, Saudi Arabia, Turkey and the United States, indicating that DTrack is spreading into more parts of the world. The targeted sectors are education, chemical manufacturing, governmental research centers and policy institutes, IT service providers, utility providers and telecommunications.

Conclusions

The DTrack backdoor continues to be used actively by the Lazarus group. Modifications in the way the malware is packed show that Lazarus still sees DTrack as an important asset. Despite this, Lazarus has not changed the backdoor much since 2019, when it was initially discovered. When the victimology is analyzed, it becomes clear that operations have expanded to Europe and Latin America, a trend we’re seeing more and more often.

IOCs

C2 domains
pinkgoat[.]com
purewatertokyo[.]com
purplebear[.]com
salmonrabbit[.]com

MD5
1A74C8D8B74CA2411C1D3D22373A6769
67F4DAD1A94ED8A47283C2C0C05A7594

Prilex is a Brazilian threat actor that has evolved out of ATM-focused malware into modular point-of-sale malware. The group was behind one of the largest attacks on ATMs in the country, infecting and jackpotting more than 1,000 machines, while also cloning in excess of 28,000 credit cards that were used in these ATMs before the big heist. But the criminals’ greed had no limits: they wanted more, and so they achieved it.

Active since 2014, in 2016, the group decided to give up ATM malware and focus all of their attacks on PoS systems, targeting the core of the payment industry. These are criminals with extensive knowledge of the payment market, and EFT software and protocols. They quickly adopted the malware-as-a-service model and expanded their reach abroad, creating a toolset that included backdoors, uploaders and stealers in a modular fashion. Since then, we have been tracking the threat actor’s every move, witnessing the damages and great financial losses they brought upon the payments industry.

The Prilex PoS malware evolved out of a simple memory scraper into very advanced and complex malware, dealing directly with the PIN pad hardware protocol instead of using higher level APIs, doing real-time patching in target software, hooking operating system libraries, messing with replies, communications and ports, and switching from a replay-based attack to generate cryptograms for its GHOST transactions even from credit cards protected with CHIP and PIN technology.

It all started with ATMs during a carnival celebration

During the carnival of 2016, a Brazilian bank realized that their ATMs had been hacked, with all the cash contained in those machines stolen. According to reports from law enforcement agencies, the criminals behind the attack were able to infect more than 1,000 machines belonging to one bank in the same incident, which allowed them to clone 28,000 unique credit cards across Brazil.

The attackers did not have physical access to the machines, but they were able to access the bank’s network by using a DIY device containing a 4G router and a Raspberry PI. By opening a backdoor, they were able to hijack the institution’s wireless connection and target ATMs at will. After obtaining initial network access, the attacker would run a network recognition process to find the IP address of each of the ATMs. With that information in hand, the attackers would launch a lateral movement phase, using default Windows credentials and then installing custom-crafted malware in the desired systems. The backdoor would allow the attacker to empty the ATM socket by launching the malware interface and typing a code supplied by the mastermind, the code being specific to each ATM being hacked.

ATM infected with Prilex ready to dispense money

The malware used in the attack was named Prilex and had been developed from scratch by using privileged information and advanced knowledge of the ATM network. To control the ATMs, Prilex did patch in legitimate software for jackpotting purposes. Besides its capability to perform a jackpot, the malware was also capable of capturing information from magnetic strips on credit and debit cards inserted into the infected ATMs. Afterwards, this valuable information could be used to clone cards and steal further funds from the bank’s clients.

Evolving into PoS malware

Prilex has evolved out of ATM-focused malware into modular point-of-sale malware targeting payment systems developed by Brazilian vendors, the so-called EFT/TEF software. As we noted in 2018, there are many similarities between their ATM and PoS versions. Their first PoS malware was spotted in the wild in October 2016. The first two samples had 2010/2011 as the compilation date, as shown on the graph below. However, we believe that invalid compilation dates were set due to incorrect system date and time settings. In later versions, the timestamps corresponded to the times when the samples were discovered. We also noticed that in the 2022 branch, the developers started using Subversion as the version control system.

Versions of the Prilex PoS malware: 3 new versions in 2022 (download)

As we see on the graph, Prilex was highly active in 2020, but suddenly disappeared in 2021, resurfacing in 2022 with a release of three new variants.

The PoS version of Prilex is coded in Visual Basic, but the stealer module, described in this article, is in p-code. In a nutshell, this is an intermediate step between high-level instructions in a Visual Basic program and the low-level native code executed by a CPU. Visual Basic translates p-code statements into native code at runtime.

A link to the past

Prilex is not the only type of PoS malware to originate in Brazil. We saw a weak link with the old Trojan-Spy.Win32.SPSniffer, which we described in 2010: both families are able to intercept signals from PIN pads, but use different approaches in doing so.

PIN pads are equipped with hardware and security features to ensure that security keys are erased if someone tries to tamper with the device. In fact, the PIN is encrypted in the device upon entry using a variety of encryption schemes and symmetric keys. Most often, this is a triple DES encoder, making it hard to crack the PIN.

There is a problem, though: these devices are always connected to a computer via a USB or serial port, which communicates with the EFT software. Older and outdated PIN pad devices use obsolete and weak cryptography schemes, making it easy for malware to install a USB or serial port sniffer to capture and decrypt the traffic between the PIN pad and the infected system. This is how SPSniffer gets credit card data. Sometimes the traffic is not even encrypted.

SPSniffer: serial port sniffer allowing capture of not-encrypted traffic

The main approach used by Prilex for capturing credit card data is to use a patch in the PoS system libraries, allowing the malware to collect data transmitted by the software. The malware will look for the location of a particular set of executables and libraries in order to apply the patch, thus overwriting the original code. With the patch in place, the malware collects the data from TRACK2, such as the account number and expiration date, in addition to other cardholder information needed to perform fraudulent transactions.

Initial infection vector

Prilex is not a widespread type of malware, as it is not distributed through email spam campaigns. It is highly targeted and is usually delivered through social engineering, e.g., a target business may receive a call from a “technician” who insists that the company needs to update its PoS software. The fake technician may visit the target in person or request the victims to install AnyDesk and provide remote access for the “technician” to install the malware.

Warning from a PoS vendor about Prilex social engineering attacks

Messing with the EMV standard

Brazil began migrating to EMV in 1999, and today, nearly all cards issued in the country are chip enabled. A small Java-based application lives inside the chip and can be easily manipulated in order to create a “golden ticket” card that will be valid in most—if not all—point-of-sale systems. This knowledge has enabled the criminals to upgrade their toolset, allowing them to create their own cards featuring this new technology and keeping them “in the business.”

The initial versions of Prilex were capable of performing the “replay attack,” where, rather than breaking the EMV protocol, they instead took advantage of poor implementations. Since payment operators fail to perform some of the validations required by the EMV standard, criminals can exploit this vulnerability within the process to their benefit.

In this kind of attack, fraudsters push regular magnetic stripe transactions through the card network as EMV purchases, as they are in control of a payment terminal and have the ability to manipulate data fields for transactions put through that terminal. Later they switched to capturing traffic from real EMV-based chip card transactions. The thieves could insert stolen card data into the transaction stream, while modifying the merchant and acquirer bank account on the fly.

Brazilian cybercriminals have successfully launched replay attacks since at least 2014. As pointed out by Brian Krebs, a small financial institution in New England battled some $120,000 in fraudulent charges from Brazilian stores within less than two days. The bank managed to block $80,000, but the bank’s processor, which approves incoming transactions when the core systems are offline, let through the other $40,000. All of the fraudulent transactions were debit charges. All of them came across MasterCard’s network and appeared to be chip transactions without a PIN to MasterCard’s systems.

Also worth mentioning is the attack against a German bank in 2019, which registered €1.5 million in losses and used the same technique. The Prilex gang claimed responsibility. Judging by the name fields and the functionality of the tool, they probably used the software they are selling in the black market.

To automate attacks using cloned credit cards, Prilex criminals used tools like Xiello, discovered by our telemetry in 2020. This tool allows the cybercriminals to use credit cards in a batch when making fraudulent purchases. It sends the purchase data to credit card acquirers, who then approve or deny the transactions.

Xiello tool used by Prilex to automate transactions

As the payment industry and credit card issuers fixed EMV implementation errors, replay attacks became obsolete and ineffective, pushing the Prilex gang to innovate and adopt other ways of credit card fraud.

From “Replay” to “Ghost”

The latest versions of Prilex show certain differences to previous ones in the way the attack occurs: the group has switched from the replay attacks to fraudulent transactions using cryptograms generated by the victim card during the in-store payment process, referred to by the malware authors as “GHOST transactions.”

In these attacks, the Prilex samples were installed in the system as RAR SFX executables that extracted all required files to the malware directory and executed the installation scripts (VBS files). From the installed files, we can highlight three modules used in the campaign: a backdoor, which is unchanged in this version except for the C2 servers used for communication; a stealer module; and an uploader module.

Prilex methods of maintaining persistence

The stealer module is responsible for intercepting all communications between the point-of-sale software and the PIN pad used for reading the card during the transaction. Once it identifies a running transaction, the malware will intercept and modify the content of the transaction in order to be able to capture the card information and to request new EMV cryptograms to the victim’s card. These cryptograms are then used in the GHOST transactions.

Method used to parse the PIN pad messages sent/received

In order to target a specific process, the criminals will perform an initial screening of the machine—to check if it is an interesting target with enough credit card transactions and to identify the process they will target.

After the process is identified, the malware will move forward to install the hooks needed to intercept the transaction information. As the communication between the PoS software and the card reader happens through the COM port, the malware will install a hook to many Windows APIs inside the targeted process, aiming to monitor and change data as needed. Interestingly enough, instead of allocating memory to the hook procedure, Prilex finds free space within the modules memory, a technique called code cave, making it hard for some security solutions to detect the threat in an infected system.

Hook code added into CloseHandle process

All captured information from the transaction is saved to an encrypted file placed in a directory previously set by the malware configuration. Those files will later be sent to the malware C2 server, allowing the cybercriminals to make transactions through a fraudulent PoS device registered in the name of a fake company.

Captured credit card data that will be later sent to the operator server

The previous version monitored the transaction in order to get the cryptogram, generated by the card for the original transaction, and then to perform a replay attack using the collected cryptogram. In this case, the cryptogram has the same ATC (Application Transaction Counter), allowing the fraudulent transaction to be identified by the reuse of the ATC as well as the fact that the date inside the cryptogram did not match the date when it was submitted, as the fraudulent transactions were submitted at a later point in time.

In GHOST attacks performed by the newer versions of Prilex, it requests new EMV cryptograms after capturing the transaction. These cryptograms will then be used in a fraudulent transaction through one of the cybercrime tools whose output log can be seen below.

[START GHOST]                    _ 
80CA9F17                          |
9F1701039000                      |  
002000800826435643FFFFFFFF        | Check PIN
9000                             _|

80AE80001D00000000010000000000000000760000008000098620060600B4E5C6EB -> Generate AC
80128000AA5EA486052A8886DE06050A03A4B8009000 -> Generated ARQC
[END GHOST]

The table above shows the data collected from the malware. It contains the Authorization Request Cryptogram (ARQC) that was generated by the card and should now be approved by the card issuer. After dissecting the response (80128000AA5EA486052A8886DE06050A03A4B8009000), we have the following information.

Multiple application cryptograms are applied to the card, where the amount of the transaction (blue), ATC (green) and the generated cryptogram (red) change for each transaction.

In a nutshell, this is the entire Prilex scheme:

Prilex: from infection to cashout

Backdoor module

The backdoor has many commands, and aside from memory scanning common to memory scrappers, older (ATM) Prilex versions also featured a command to debug a process and peek into its memory. It is highly likely that this was used to understand target software behavior and perform adjustments on the malware or environment to perform fraudulent transactions. Older versions of Prilex performed patching on specific software libraries, whereas newer samples do not rely on specific software anymore and will instead hook Windows APIs to perform its job.

The Prilex debugger

Here’s a list of commands used in the ATM version of Prilex, which include debugging:

Reboot, SendKeys, ShowForm, Inject, UnInject, HideForm, Recursos, GetZip, SetStartup, PausaProcesso, LiberaProcesso, Debug, SendSnapShot, GetStartup, CapRegion, CapFerro, KillProcess, Shell, Process, GetModules, GetConfig, StartSendScreen, StopSendScreen, ReLogin, StartScan, GetKey, SetConfig, RefreshScreen, Download, TakeRegions, Enviar Arquivo, ScanProcessStart, ScanProcessStop, StartRegiao, StopRegiao, StartDownload, StopDownload.

Even though a new set of commands has been added to the PoS version, we could find some of those from the ATM attack still being used. Numerous available commands are for general use, allowing the criminals to collect information about the infected machine.

Uploader Module

This module is responsible for checking the directory specified in the CABPATH parameter in the config file and sending all cab files generated from the stolen transactions to the server; the files are sent through an HTTP POST request. The endpoint used by the module is also mentioned in the uploader configuration file.

[SNDCAB]
CABHOST=C2
CABPORT=80
CABPAGE=/upload.php
CABPATH=c:\cab

The use of this module indicates a change in the group’s operation structure, since in the previous version, the collected information was sent to a server whose address was hardcoded into the stealer code, and the module used the same protocol as the backdoor. This uploader allows the operator to set the endpoint for the collected information as indicated in the configuration file; judging from the samples analyzed, it is possible to see a different infrastructure involved in the process.

Captured data stored in the uploader C2

Malware-as-a-service

In 2019, a website claiming to be affiliated with Prilex started offering what it said was a malware package created by the group. We have little confidence in these claims: the site could be operated by copycats trying to impersonate the group and catch some money using the reputation Prilex has earned over the years.

This website was still up and running at the time of writing this.

The asking price for what is supposedly a Prilex PoS kit is $3,500.

The website says its owners have worked with Russian cybercriminals in the past, another claim we cannot confirm. Worth mentioning, too, is that our Digital Footprint Intelligence service found citations of a Prilex malware package sold through Telegram chats, in an underground channel, priced between €10,000 and $13,000. We have no way of confirming that what is being offered is the real Prilex malware.

At the same time, Prilex now using Subversion is a clear sign they are working with more than one developer.

Conclusions

The Prilex group has shown a high level of knowledge about credit and debit card transactions, and how software used for payment processing works. This enables the attackers to keep updating their tools in order to find a way to circumvent the authorization policies, allowing them to perform their attacks.

Over years of activity, the group has changed its attack techniques a lot. However, it has always abused processes relating to PoS software to intercept and modify communications with the PIN pad. Considering that, we strongly suggest that PoS software developers implement self-protection techniques in their modules, such as the protection available through our Kaspersky SDK, aiming to prevent malicious code from tampering with the transactions managed by those modules. To credit card acquirers and issuers, we recommend avoiding “security by obscurity”: do not underestimate the fraudster. All EMV validations must be implemented!

Prilex’s success is the greatest motivator for new families to emerge as fast-evolving and more complex malware with a major impact on the payment chain.

To financial institutions who fell victims to this kind of fraud, we recommend our Kaspersky Threat Attribution Engine to help IR teams with finding and detecting Prilex files in attacked environments.

The Prilex family is detected by all Kaspersky products as HEUR:Trojan.Win32.Prilex and HEUR:Trojan.Win64.Prilex. More details about the threat and a full analysis is available to customers of our Threat Intelligence Reports. With any requests about our private reports, please contact crimewareintel@kaspersky.com.