While we finalized this blog post, a technical analysis of this activity was published by fellow researchers from Cisco Talos. While it overlaps with our findings to some extent, our report provides additional extended information about the activity.
Since July 2024, Check Point Research (CPR) has been tracking an extensive and ongoing phishing campaign that leads to the deployment of the Rhadamanthys stealer. This campaign masquerades as various companies and falsely claims that victims have committed copyright infringement related on their Facebook pages.
The phishing emails, typically sent from Gmail accounts, prompt recipients to download an archive file, which triggers the infection through DLL side-loading. The vulnerable binary then installs the latest version of the Rhadamanthys stealer (version 0.7), which includes new capabilities such as an alleged AI-powered OCR (optical character recognition) module.
In this report, we share our ongoing efforts to study the use of the Rhadamanthys stealer, which both cybercriminals and state-sponsored actors have adopted. We provide an in-depth examination of the phishing campaign, the tactics used by the attackers, and the updates introduced in this latest version of Rhadamanthys.
Throughout 2024, we have been monitoring threat actors’ activities leveraging the Rhadamanthys stealer, including its use by Void Manticore, an Iranian actor operating in Israel and Albania. In one campaign tied to Handala, a persona linked to Void Manticore, the Rhadamanthys stealer was distributed under the guise of a F5 update. This marked their first use of the stealer, which they continued to deploy in subsequent campaigns impersonating Israeli and international companies.
Simultaneously, Check Point Software Technologies began receiving reports of phishing lures mimicking Check Point- branded emails leading to the deployment of Rhadamanthys. Given Handala’s previous interest in Check Point and threats they published in their Telegram channel, our initial assumption was that they were also behind this campaign. However, further analysis revealed this was merely a coincidence and the Check Point lures were part of a larger, distinct cybercrime-oriented cluster, which we explore in detail.
The newly identified cluster is characterized by spear-phishing emails sent from Gmail accounts allegedly from well-known companies claiming supposed copyright violations. These emails, which appear to come from the legal representatives of the impersonated companies, accuse the recipient of misusing their brand on the target’s social media page and requesting the removal of specific images and videos.
The removal instructions are said to be in a password-protected file. However, the attached file is a download link to appspot.com
, linked to the Gmail account, which redirects the user to Dropbox or Discord to download a password-protected archive (with the password provided in the email).
We observed hundreds of emails impersonating dozens of companies, each sent to a specific address from a different Gmail account. Almost 70% of the impersonated companies are from Entertainment /Media and Technology/Software sectors. This is possibly due to the fact that those sectors have a high online presence and are more likely to send such requests than other sectors. These high profile sectors also have frequent copyright-related communications, making such phishing attempts appear more credible.
The attackers likely used an automated tool, possibly with AI integration, though they do not leverage modern AI engines, rather a much older classic machine learning, typical for OCR software, to generate both the emails and the accounts. While most emails are written in the recipient’s local language or English, occasional errors occur. For example, one email intended for an Israeli target was written in Korean instead of Hebrew, with only the target’s name correctly localized.
Figure 4 – Copyright campaign infection chain.
As we stated, the infection begins with a spear-phishing email containing a link to download a password-protected archive. This archive typically includes three files: a legitimate executable, a DLL (which contains the packed Rhadamanthys), and a decoy Adobe ESPS or PDF file. When the executable is run, it utilizes DLL sideloading to load the malicious DLL, which subsequently unpacks and loads the Rhadamanthys components.
The legitimate executables and the names given to the DLL for sideloading:
Legitimate Executable (Often renamed) | Sideloaded DLL |
---|---|
Launcher.exe | msimg32.dll |
AcroLicApp.exe | msimg32.dll |
AdobeARM.exe | SensApi.dll |
Once active, the stealer writes a significantly larger copy of the DLL into the Documents
folder, masquerading as a Firefox-related component (FirefoxData.dll
). It also creates a registry key for persistence:
The only difference between the dropped DLL and the one from the initial package is an appended empty overlay. This is a simple trick intended to evade hash-based detection, as the random padding changes the original hash of the executable. Sometimes, the enlarged size of the file may also cross the acceptable file size threshold defined by a particular antivirus engine, and as a result, the file is not scanned.
As the Rhadamanthys modules are loaded, they are injected into one of the following processes from the system32 directory:
The process of loading Rhadamanthys modules and their general flow did not change much since the last version, 0.5.0, that we described in detail in our previous report. The initial Rhadamanthys executable has a hardcoded package from which Stage 2 is unpacked.
The role of Stage 2 is to run extensive evasion checks on the compromised machine, connect to the Command-and-Control server (C2), and download the next package which contains Stage 3. Stage 3, shipped steganographically in a WAV file, is a rich set of stealer modules and attacks various targets. We described most of these modules in our previous article.
A complete list of Rhadamanthys Stages 2 and 3 is available in Appendix A.
The campaign’s targets are distributed across a wide geographic area, including the US, Europe, the Middle East, East Asia, and South America. However, it’s important to note that our target observations are limited by our customers’ that were targeted by this campaign. We believe this is part of a much larger campaign, with likely many more countries affected than we’ve seen.
Figure 6 – Map of targeted countries according to Check Point’s telemetry.
Although Rhadamanthys was previously linked to nation-state threat actors like those from Russia or Iran, we assess that this campaign is more likely the work of a cybercrime group rather than a state-sponsored operation for the following reasons:
While working on this report, Recorded Future, a cyber security company,released a comprehensive analysis of Rhadamantys 0.7.The Rhadamanthys version used in this campaign, identified as 0.7, is the latest release at the time of this writing. It was introduced by the developer of the malware a few months ago in the following announcement:
Figure 7 – Source: https://x.com/g0njxa/status/1812902577530454023
The author stated that text recognition is implemented with AI. As AI is currently a hot topic, this may help promote the product and show that it uses cutting-edge technology. However, as we found out, the component introduced by Rhadamanthys does not incorporate any of the modern AI engines but instead uses much older classic machine learning, typical for OCR software.
In this latest release, the author announced many improvements. Some of the existing components were polished and modified. Only one new executable, the OCR component, was added.
In the package downloaded from the C2, we find the following:
/bin/amd64/imgdat.bin
) – An executable in XS2 format./etc/bip39.txt
) – A small dictionary.The ImgDat is the OCR module that the author mentioned in the announcement: “Added AI graphics and PDF recognition to extract phases”. The newly added text file bip39.txt
is its configuration and contains a dictionary of search phrases that will be checked against the extracted text.
The name Bip39 suggests that it is related to the Bitcoin Improvement Proposal 39, which states how to create phrases out of numbers to make wallet protection codes easier for humans to remember. According to the specification, Bip39 contains a dictionary of 2048 words – just like the file we found. We compared it with the official Bip39 wordlist and confirmed that the content is the same: https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt (https://www.blockplate.com/pages/bip-39-wordlist).
Based on this information, we assume that the OCR module is applied to search for documents where such phrases may be stored, and the retrieved information will be further used in attacks on Bitcoin wallets. This set of phrases used for text recognition suggests that the campaign is motivated by financial gain rather than espionage purposes.
How ImgDat is deployed
The ImgDat executable is deployed by the main module of Stage 3 (coredll.bin), which is responsible for coordinating the work of all the stage’s components. In the ImgDat module, calling the Entry Point retrieves a list of its exported functions that are used later.
The exported functions:
init
– Initializes the OCR component with a given configuration and returns the context structure.delete
– Destroys the initialized structure.process
– Implements the main operations – image processing and text extraction.Workflow:
init
is called and the content of “bip39.txt” is passed to it to initialize the component with the given list of searched phrases. They are stored in the dedicated linked list that is a part of the context structure.process
is fetched from ImgDat. The core module walks through the disks of the infected machine and then calls this function on every retrieved path.If the extension matches, the file content is read and passed to the process
function from the ImgDat module.
The OCR implementation
The image is loaded via the GDI+ interface and then preprocessed to facilitate text recognition. First, all pixels from the image are loaded into the dedicated buffer:
The RGB components of the picture are compressed into a single byte.
The OCR functionality is implemented within the function denoted as extract_text
that is a part of the process
API. When we look inside, we can find a reference to thresholding, a well known technique commonly applied in OCR software. Its role is to enhance the contrast to be able to distinguish the text from the background of the image.
[thresholding] image = %p , (%d , %d) (%d , %d)\n
The image is then processed using a trained local machine learning model. Extracted sentences are stored in the dedicated structure.
Finally, the extracted phrases are separated into words, which are then compared with the previously initialized token list. If there are enough matches (at least 9 strings from the list and at least 12 strings processed), the process
function returns true
.
The model has limited precision. For example, it handles only the most popular fonts and cannot recognize handwritten text. In addition, it doesn’t do well with text in mixed colors (especially if one line of the text is darker than the background and another is lighter).
In this article, we analyzed a large-scale phishing campaign discovered in July 2024. This campaign used a copyright infringement theme to spread the Rhadamanthys info stealer. This campaign employed tactics including DLL sideloading and anti-detection techniques, making the latest version of Rhadamanthys (0.7) more potent and more challenging to detect. We also examined Rhadamanthys’ new OCR features.
The campaign’s widespread and indiscriminate targeting of organizations across multiple regions suggests it was orchestrated by a financially motivated cybercrime group rather than a nation-state actor. Its global reach, automated phishing tactics, and diverse lures demonstrate how attackers continuously evolve to improve their success rates.
Check Point Customers Remain Protected Against the Threats Described in this Report.
Check Point’s Threat Emulation provides comprehensive coverage of attack tactics, file types, and operating systems:
Harmony Endpoint provides comprehensive endpoint protection at the highest security level, crucial to avoid security breaches and data compromise :
Harmony Email and Collaboration provides comprehensive inline protection at the highest security level.
Stage 2 – Unpacked from the hardcoded package:
Name | Format | SHA256 |
---|---|---|
dt.x86 | XS1 | bea558e8129fcb647e6f42c8beda4464e109dd3cd546342c0337dbd50616f991 |
early.x86 | XS1 | 4fd469d08c051d6997f0471d91ccf96c173d27c8cff5bd70c3f2c5008faa786f |
early.x64 | XS1 | 633b0fe4f3d2bfb18d4ad648ff223fe6763397daa033e9c5d79f2cae89a6c3b2 |
netclient.x86 | XS1 | b97dd0279e112e0591b38064f59077102ab188b07a069cb104e66e4756e2570a |
phexec.bin | XS1 | 13872271ee511aa83f3f27d5db248516652b10a079ad01f78ed734cd2a87ec77 |
prepare.bin | shellcode | d96ec4b08c08b81ba9075423d5e83bf330de09866066b4bdb459bcbac389a350 |
proto.x86 | shellcode | a905226a2486ccc158d44cf4c1728e103472825fb189e05c17d998b9f5534d63 |
stage.x86 | shellcode | 44f3936ee158d2846664bf5cd795fd90a99441186b20b90ff241ba1b38a6a3e9 |
strategy.x86 | XS1 | 219a6387d91c4b2c8e91c8613192af950bd9c790114a238eb0e1e7c878f6e728 |
unhook.bin | XS1 | 37438095a5e7be0ce12997dc23d1ff117912989d2f24beab95284f9380f65834 |
ua.txt | plain text | aeba4ece8c4bf51d9761e49fad983967e76c705a06999c556c099f39853f737c |
processex.x | plain text | 3ca87045da78292a6bba017138ff9ee42b4e626b64d0fee6d86a16cc3258c8c3 |
Stage 3 – Downloaded from the C2:
Name | Format | SHA256 |
---|---|---|
coredll.bin (32) | XS2 | 3737501bbd4abd0844da016c0263399e3c670ae52952b30ca46c6c96cf4e318d |
coredll.bin (64) | XS2 | 6012386eab453f4fb1cfb88fb5b05ba9ec71a838029ea51bcff4c0b5a2fbfad2 |
taskcore.bin (32) | XS2 | c0b319bb19092fe3c193e5139fcdf599502b669143b06c676e81f46ab50fb4ed |
taskcore.bin (64) | XS2 | 18273fa35c54332d8763cb17a5ae92de5636f3a05c507ce18d9d6a77c3139deb |
stubmod.bin (32) | XS2 | d97aa65123c26509e3fc1a9963962b7f707a50ddca44a9a12fd03e654ab5aa66 |
stubmod.bin (64) | XS2 | fd9fbfa809450415e8d0d79199ec8686cb7071d6e13a5b76f0ce1b03a2a61302 |
runtime.dll | PE, .NET | a87032195e38892b351641e08c81b92a1ea888c3c74a0c7464160e86613c4476 |
loader.dll | PE, .NET | 3d010e3fce1b2c9ab5b8cc125be812e63b661ddcbde40509a49118c2330ef9d0 |
KeePassHax.dll | PE, .NET | fcb00beaa88f7827999856ba12302086cadbc1252261d64379172f2927a6760e |
imgdat.bin (32) | XS2 | 2625d99af56c79de32f9fba2332f63eb9c88707e9ea83985bce5df9022ced99a |
imgdat.bin (64) | XS2 | ffb264a19af7c8a8dd5357b62c45fcd3063ca946aa2710740c4e8b21f8e697d9 |
bip39.txt | plain text | 24ce42c2fd4a95c1b86bbee9bce1e1cf255bd0022e19bab6bd591afd68b7efdb |
Lua extensions | LUA code | – |
C2:
Archives:
DLL: