In recent years, cryptocurrency scams have evolved into a highly organized business model known as “Drainer-as-a-Service.” Within this model, developers create specialized set of malicious scripts, smart contracts, and infrastructure enabling other cyber criminals to efficiently steal cryptocurrency from users’ wallets. Attackers simply need to set up a phishing website and embed the drainer script. One of the most notorious examples of this approach is Inferno Drainer, known for the scale and sophistication of its attacks.
In November 2023, the creators of Inferno Drainer officially announced the service’s shutdown. However, it soon became clear that this was only a diversionary tactic. Evidence of continued operation emerged as early as the beginning of 2024. In addition, blockchain analysis indicates that critical smart contracts deployed on September 9, 2023, essential for the operation of the scheme, are still in use today.
Despite significant advances in cryptocurrency wallet security, implementation of malicious transaction warnings, enhanced anti-phishing solutions, and regular blacklisting of fraudulent websites, attackers continue to aggressively adapt to these tactics. In particular, Inferno Drainer continuously refines its methods to bypass security defenses.
The Inferno Drainer developers emphasize protecting their centralized infrastructure from detection by security researchers and law enforcement. Command server addresses are now encrypted and stored within the blockchain. In one of the latest Inferno Drainer variants we discovered in March 2025, communication with command servers is completely offloaded to proxy servers installed by service customers, making it nearly impossible to trace the actual Inferno Drainer infrastructure. Single-use smart contracts and frequent rotation of the blockchain addresses used for victim interactions allows Inferno Drainer to effectively bypass anti-phishing protections built into wallet applications.
Customers of Inferno Drainer also employ inventive tactics to avoid detection and blocking of their servers. They frequently rotate domain names, use intermediate servers for conditional redirection, and implement security tokens that hinder automatic detection of malicious websites. New social engineering and phishing methods enable attackers to effectively lure new victims.
According to our estimates, over the past six months alone, more than 30,000 users fell victim to Inferno Drainer scams, resulting in losses exceeding $9 million.
This article provides an in-depth analysis of an active phishing campaign targeting Discord users in crypto and blockchain communities. We thoroughly examine every stage of the attack, from phishing interaction mechanisms to the deep technical intricacies of Inferno Drainer’s operation, including the chain of malicious smart contracts and the subsequent transfer of stolen funds to the attackers’ wallets.
In January 2025, Check Point Research discovered that members of a prominent crypto community were targeted by a sophisticated phishing attack involving Discord. The attackers combined social engineering techniques with platform-specific features of Discord to carry out the attack. Users attempting to access a Discord support server from a legitimate Web3 project’s website were instead redirected to a phishing site impersonating the popular Collab.Land service and hosting a cryptocurrency drainer. Users received no security warnings indicating that either the website or the smart contracts they interacted with were malicious. Initially, we suspected that the Web3 project’s website had been compromised, but the reality turned out to be far more intriguing. Fortunately, the maintainers of the Web3 service quickly addressed the issue, and it appears that significant losses were avoided in this specific incident. Nevertheless, this event helped us understand the attackers’ methods and allowed us to link this phishing campaign directly to Inferno Drainer.
Collab.Land is a widely used bot in Discord and Telegram communities which facilitates token-gated access management. By verifying users’ cryptocurrency or NFT holdings, Collab.Land grants them access to exclusive channels or groups. Users connect their wallets and sign a message to prove ownership of the required assets, ensuring secure membership management within Web3 communities.
Typically, when joining a Discord server utilizing Collab.Land, users initially cannot access most channels. Instead, they interact with the Collab.Land bot, which provides a link redirecting them to the legitimate website ( _connect.collab.land_) to connect their wallet and verify their asset ownership. If verification is successful, users gain access to restricted channels.
In the attack we investigated, the initial interaction follows the same pattern. While browsing the legitimate Web3 service website, users clicked on an invitation link to join the associated Discord server. Once there, they saw numerous locked channels and only one accessible channel named **“verify-here”**, containing a message purportedly from the Collab.Land bot inviting them to verify their crypto assets. The entire scenario was convincingly realistic and capable of deceiving even experienced users:
**Figure 1** – Left: fake bot; right: legitimate Collab.Land bot.
There were subtle visual differences between the fake and legitimate bots, but we anticipate attackers will continue refining their imitation. Currently, the most critical distinguishing factor is the absence of a **“Verified App”** checkmark on the fake bot, which is prominently displayed on the genuine Collab.Land bot.
Another critical difference is what happens when a user clicks the **“Let’s go”** button. The legitimate bot provides clear instructions informing users that they need to sign a message with their wallet to verify ownership of their blockchain account. It explicitly emphasizes that this action does not trigger any blockchain transactions and does not require payment of gas fees. In contrast, the fake bot immediately displays a warning message that it will gain access to the user’s Discord username, avatar, and banner. It then redirects the user to the malicious website hosted at **hxxps://roles-collab[.]com** (previously, attackers used another domain— **org.redirect-302[.]com**):
**Figure 2** – Differences when clicking the “Let’s go” button. Left: Fake bot; right: Legitimate Collab.Land bot.
Next, the potential victim is redirected to a phishing website that closely resembles the legitimate Collab.Land service interface. It also displays the actual username and avatar, the community icon received from Discord, just like the legitimate Collab.Land does. Besides differences in color schemes and slight discrepancies in the size of wallet icons and labels, the phishing site prominently includes a banner at the top advising users to **“Always verify the address is [the phishing website’s URL].”**
**Figure 3** – Left: Phishing website; Right: Genuine Collab.Land website hosted at _connect.collab.land_
As demonstrated, potential victims reach the phishing website with just two clicks. After connecting their wallet, users are then prompted to sign malicious transactions.
**Figure 4** – Malicious transaction requesting approval to spend the victim’s USDC tokens.
After signing the malicious transaction, the wallet owner either directly transfers funds to the attackers or grants unlimited permission to spend tokens from their wallet.
Note that legitimate Collab.Land service genuinely requires wallet signature verification. Consequently, even experienced cryptocurrency users may lower their guard. As they expect the service to request a wallet signature, they may instinctively click “Approve” without careful inspection, falling into the trap.
In the following sections, we delve deeper into the underlying technical infrastructure, obfuscation techniques, and blockchain interactions that make Inferno Drainer attacks particularly resilient and challenging to mitigate.
The first step in compromising victims is to lure them into joining a malicious Discord server. But how do they attract the users? One effective method is hijacking expired vanity invite links, a technique that takes advantage of Discord’s custom invite system.
Many Discord servers use vanity URLs (e.g., _discord.gg/myproject_) to create memorable, branded invite links. These links are available only to Discord servers with Level 3 Boost. However, if a server owner stops paying and the server loses its boosts, the vanity invite link becomes available for anyone to claim.
Attackers can monitor and wait for high-value vanity links to expire. The moment a link becomes free, they instantly register it on their malicious server. As many users may still have the old invite saved in announcements, websites, or social media posts, they unknowingly join the attacker’s server instead of the legitimate one. Attackers don’t just hijack random vanity links; they specifically target links used by crypto projects, ensuring that the traffic they intercept is highly valuable. By monitoring invite URLs associated with crypto communities, NFT projects, and Web3 platforms, they increase the likelihood of attracting users who own cryptocurrency wallets and digital assets. This makes their malicious campaigns far more effective, as the victims are not just regular Discord users, but individuals who are more likely to hold valuable tokens, NFTs, or other assets worth stealing.
An interesting aspect of this campaign is how the use of Discord bots combined with OAuth2 authentication flow allows the attackers to evade automated detection of their malicious websites.
Let’s take a closer look at the technical workflow initiated when a user interacts with the malicious Discord bot:
`hxxps://roles-collab[.]com/oauth/callback?code={auth_code}&state={state}`
“`
HTTP/2 302 content-length: 0 location: hxxps://collab.land-wl[.]com/collab?token={JWT}&server={discord_server_id}&user={username}&avatar={avatar_id}%2Fnull
“`
This URL is only valid for approximately five minutes. After that, any attempts to access it result in a 404 error. This limits the time window for analysis and makes detection efforts even more challenging.
Attempting to use an expired or invalid token to access the attackers’ website also results in a 404 error.
Valid tokens can only be obtained through the intermediate server (roles-collab[.]com). To get a token, users must have a valid OAuth2 authorization code, which is exclusively generated by interacting with the malicious Discord bot.
As a result, without an invite link to the specific Discord servers hosting the malicious bot, identifying the attackers’ phishing websites becomes extremely challenging. Unfortunately, there is currently no centralized registry containing all Discord server invite links, which would allow us to scan and identify malicious bots.
Even if a phishing site is discovered through victim reports, this is not a major impediment for the attackers as they proactively rotate their phishing domains every few days. Our investigation identified numerous such domains, including:
By combining the tactics of short-lived tokens, intermediate OAuth2 servers, and rapidly rotating phishing domains, the attackers effectively evade detection and sustain their malicious operations over extended periods.
We have observed that Inferno Drainer customers continue to employ traditional phishing schemes involving fake token airdrops. For example, following the successful launch of the **$TRUMP** token on January 17, 2025, attackers quickly initiated their own phishing campaign promising free distribution of **$TRUMP** tokens through a website `airdop-trump[.]com`. In reality, “airdrop” participants became victims.
The phishing campaign also specifically targeted X (formerly Twitter) users from Japan ( `https://x[.]com/AYANONASDAQ/status/1881085122528866558`):
**Figure 5** – Screenshot of a phishing tweet promoting a fake $TRUMP token airdrop.
The main functionality of the drainer is implemented in a single JavaScript file ranging in size from 5 to 10 megabytes. For each customer, Inferno Drainer generates a unique script using multiple layers of obfuscation. These scripts typically have random names resembling UUIDs (Universally Unique Identifiers), such as `66bc4b94-a47f-4157-9a3b-9a4205f44360.js`. Even on the same phishing site, the script may be updated every few days, each time receiving a new filename. This strategy significantly complicates detection and blocking efforts by automated security tools.
The crypto drainer uses advanced obfuscation techniques to conceal strings and function calls, making analysis and reverse engineering more difficult. It also employs anti-debugging mechanisms to hinder dynamic analysis. These are the main methods used:
**1. String Obfuscation with Function-Based Indexing**
Instead of directly referencing common properties or methods, the drainer constructs them dynamically using functions that calculate substrings.
**Example:**
“`
_0x14213f[_0x28ed(10259, 0x54ec) + _0x28ed(18055, 0x2a22)]
“`
This is equivalent to:
“`
_0x14213f[“len” + “gth”]
“`
Here, “length” is reconstructed from smaller parts, hiding the string from straightforward detection.
**2. Split and Concatenate Strings with Function Calls**
The drainer avoids hardcoding strings by splitting them into smaller parts and concatenating them at runtime. Instead of using direct concatenation (e.g., +), it uses multifunctional helper functions like XeB8Fcz(), which perform different operations depending on the parameters.
Example:
“`
XeB8Fcz(‘debu’, ‘gger’, sOrjvb = 17)
“`
This is equivalent to:
“`
“debugger”
“`
However, **XeB8Fcz()** is a versatile function that can also perform arithmetic, and logical operations, depending on how it is called.
**3. Obfuscated Function Calls with Dynamic Property Access**
Functions are called indirectly by dynamically generating method names or using computed properties.
Example:
“`
_0x50afbe[‘cal’+’l’](undefined, someArg)
“`
This is equivalent to:
“`
_0x50afbe.call(undefined, someArg)
“`
This obfuscation hides the method name by breaking it into smaller strings.
**4. Encoded Indices and Arithmetic Obfuscation**
Array indices and function arguments are obfuscated with complex arithmetic expressions.
Example:
“`
_0xe3fceb[0x30a*-0x5+-0xf*-0x87+-0x175*-0x5]
“`
This evaluates to:
“`
_0xe3fceb[0]
“`
**5. Anti-Debugging Techniques Using Dynamic Function Construction**
Inferno Drainer includes anti-debugging mechanisms designed to hinder dynamic analysis and reverse engineering. These mechanisms rely on heavily obfuscated code, making it extremely difficult to understand the logic or identify specific technique.
**Original Obfuscated Code:**
“`
j_MFQX((”+_0xe3fceb[0x30a*-0x5+-0xf*-0x87+-0x175*-0x5]/_0xe3fceb[-0x15c0+-0xc1*-0x29+-0x929])[_0x50afbe(-0x1dc9+-0x2*-0xd8a+0x51*0x50)]!==-0xef*-0x23+-0x1685+0xa27*-0x1||_0xe3fceb[-0x2449*0x1+-0xa07+-0x3*-0xf70]%(-0x19dc*-0x1+0x111b+-0x2ae3)===-0x2e5*0x6+0x2*-0x304+0x1766?function(){return XeB8Fcz(XeB8Fcz([],sOrjvb=-(0xa3f+0xf02+-0x1920)),sOrjvb=-(-0x5*-0x42d+0x89*-0x2c+0x2cc));}[_0x2a4076(0x335c,_0x3ad540._0x538711,0xcc2)+_0x2a4076(-0x66,-0x8ea,-_0x3ad540._0x37eb35)+’uct’+’or’](XeB8Fcz(_0x50afbe(-0x73a+0xe7d+-0x1*-0xf59),_0x50afbe(-0x1c3+0x2033+-0x7d3),sOrjvb=-0x1*-0x117+-0x1cec+0x1be6))[_0x50afbe[‘cal’+’l’](undefined,-0x7*-0x420+-0x1658+0x1*0x1016)](_0x50afbe(-0x11*-0x24e+-0x2cd+-0xdc2)):function(){return XeB8Fcz([],sOrjvb=-(-0x2371+0x20e6+-0xab*-0x4));}[_0x38dcbe(0x3843,_0x3ad540._0x6840aa,0x15e6)+’str’+(‘uct’+’or’)](XeB8Fcz(_0x50afbe(-0x297a+-0x1*-0x6b+0x3*0x1539),_0x50afbe(-0x34*-0x8d+-0x7*0x5b7+-0x1*-0x21fa),XIfqRhC(0x19f7+-0x161b+0x3cb*-0x1)))[_0x50afbe(-0x3*-0xdfa+0x2802+-0x3b50)](‘sta’+’teO’+_0x2a4076(_0x3ad540._0x45ab88,0xbee,_0x3ad540._0x217f7b)+’ct’),EM8p5y(_0x1615be,-0x612+0xc*-0x88+0xc73);
“`
Once it’s partially deobfuscated, the code reveals a well-known anti-debugging technique that we described in our previous report. The technique leverages JavaScript’s dynamic function construction to inject a literal debugger statement into newly created functions. As these functions are invoked (in a recursive or continuously triggered manner), they cause the debugger to pause execution whenever developer tools are opened, effectively freezing the web application.
“`
__((” + _0xe3fceb[0] / _0xe3fceb[0])[‘length’] !== 1 || _0xe3fceb[0] % 20 === 0 ? function () { return XeB8Fcz(XeB8Fcz([], sOrjvb = -33), sOrjvb = -33); }[‘constructor’](XeB8Fcz(‘debu’, ‘gger’, sOrjvb = 17))[‘call’](‘action’) : function () { return XeB8Fcz([], sOrjvb = -33); }.constructor(XeB8Fcz(‘debu’, ‘gger’, XIfqRhC(17)))[‘apply’](“stateObject”), EM8p5y(_0x1615be, 1));
“`
Such logic is deeply buried within layers of obfuscation, making even the detection of the anti-debugging logic itself a non-trivial task.
**6. Multi-Layered Obfuscation**
The drainer combines these techniques recursively, requiring multiple rounds of deobfuscation to understand the logic. For example, a function name might be constructed using one layer of string obfuscation, while its arguments are calculated using encoded indices and arithmetic operations.
One critical aspect of a crypto drainer is that it must eventually direct funds to the attackers’ addresses. In some cases, these malicious addresses are hardcoded directly into the code. Even if the script is heavily obfuscated, hardcoded addresses can be relatively easy to extract and flag as malicious, allowing security vendors to warn potential victims and block transactions. Alternatively, some drainers (such as MS Drainer) query these addresses from a command server—often only when a victim’s wallet contains a sufficient balance. Although the configuration might be encrypted, the command server address itself can still be extracted from the drainer’s code.
In the case of the new version of Inferno Drainer we discovered, the Command & Control (C&C) server address is not hardcoded anywhere. Instead, both a portion of the configuration and the command server address are stored on the Binance Smart Chain within specialized smart contracts. The drainer retrieves these details via legitimate-looking JSON-RPC calls to one of the blockchain’s endpoints. Even if an analyst inspects the data returned by the smart contract, the task is complicated by two factors: first, the data is ABI-encoded (Application Binary Interface is a standardized way to encode function calls and data for smart contracts); and second, it is protected with AES encryption. In addition, multi-layer encryption is employed with several keys, making it extremely challenging to reverse-engineer the configuration directly.
**Two Smart Contracts with Separate Roles**
**Smart Contract 1 (referred to as “RemotePatchConfig Contract”): 0x158862Ec60B7934f1333e53AC1e148811A2E3BeB**
**Figure 6** – Deobfuscated malicious JavaScript: BSC smart contract query to obtain configuration.
**Smart Contract 2: 0xd24aeC3254652B0ab565E41A945b491e98Bb5FFC**
**Figure 7** – Deobfuscated malicious JavaScript: BSC smart contract query to obtain and decrypt C&C URL.
After decrypting the response from the contract, we can get the address of the server. The latest value for the address:
`hxxps://sharp-dev-40d.ivx9ctza.workers[.]dev`
**Variant Using Multicall3**
Another active variant of **Inferno Drainer** uses a different method for retrieving the C&C server address.
In this version, the Inferno Drainer script interacts with the legitimate smart contract **Multicall3**, located at the address **0xca11bde05977b3631167028862be2a173976ca11** on the BSC blockchain. It invokes the function aggregate3, passing parameters that target the Inferno Drainer configuration storage smart contract at:
Example Request:
“`
{ “calls”: [ { “target”: “0x72cD63650700E5395f4aB238cecD18497A33a83e”, “allowFailure”: true, “callData”: “0x6ee24abb” }, { “target”: “0x72cD63650700E5395f4aB238cecD18497A33a83e”, “allowFailure”: true, “callData”: “0x89dfec91” }, { “target”: “0x72cD63650700E5395f4aB238cecD18497A33a83e”, “allowFailure”: true, “callData”: “0xd3e0f3ba” }, … ] }
“`
In turn, the address of this storage smart contract is retrieved from the RemotePatchConfig contract (address: **0x158862Ec60B7934f1333e53AC1e148811A2E3BeB**), which we described earlier.
**Figure 8** – RemotePatchConfig contract storing the address of the storage smart contract.
The smart contract at **0x72cD63650700E5395f4aB238cecD18497A33a83e** contains only a fallback method with the following behavior:
Therefore, callData does not affect the outcome and can take any value.
This use of Multicall3.aggregate3 with multiple random selectors likely serves to complicate analysis and evade detection, as Multicall3 is a legitimate contract. The use of ABI-encoding helps the drainer to obfuscate communication, as the JSON shown above is encoded as follows:
“`
{ “method”: “eth_call”, “params”: [ { “to”: “0xca11bde05977b3631167028862be2a173976ca11”, “data”: “0x82ad56cb0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000500000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001e00000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000032000000000000000000000000072cd63650700e5395f4ab238cecd18497a33a83e…” }, “latest” ], “id”: 44, “jsonrpc”: “2.0” }
“`
**Response and Decoding**
The smart contract returns a previously stored value containing a **base64**-encoded string:
“`
dQBnAGcAYwBmADoALwAvAGQAaAB2AHAAeAAtAGEAcgBnAC0ANgBvAHEALgBwAG0ANQAzAHkAMQBiAGUALgBqAGIAZQB4AHIAZQBmAC4AcQByAGk=
“`
After decoding from **base64**, the result resembles a URL but remains unreadable, as it is encoded using the **ROT13** algorithm:
`uggcf://dhvpx-arg-6oq.pm53y1be.jbexref.qri`
Decoding this using ROT13 yields the C&C server address:
`https://quick-net-6bd.cz53l1or.workers[.]dev`
**Historical Data**
The data within this smart contract was updated multiple times between January 26-27, 2025, with over 100 changes recorded. Analysis of these update transactions revealed other addresses. The complete list of these addresses is very long. Therefore, we show only a selected few as examples:
We also identified four more smart contracts that were used previously to store C&C addresses:
Unlike the current contract, these older contracts stored data in plain text without using ROT13 encoding, and even without base64-encoding.
This evolution in data storage methods suggests an adaptation to enhance obfuscation and avoid detection, showcasing the continual development in the tactics used by Inferno Drainer.
We observed that all C&C URLs used in the current Inferno Drainer campaigns, as well as those stored in smart contracts late last year, point to **workers.dev** domain. This domain is related to Cloudflare Workers, a serverless platform that allows users to deploy JavaScript, Python, Rust, or WebAssembly applications. Security tools and firewalls rarely blacklist Cloudflare’s infrastructure, making it more resistant to takedowns. At the same time, we cannot say definitively whether Cloudflare Workers are used to host Inferno Drainer’s infrastructure or if they merely function as a proxy, and the core infrastructure is hosted elsewhere.
Starting in March 2025, we began observing drainer variants that no longer connect directly to their infrastructure but instead use a so-called “secure proxy.” This secure proxy is a PHP script installed on the customer’s server, which dynamically retrieves the current C&C server address from a smart contract and transparently forwards requests and responses between the victim and the C&C server. Unlike JavaScript executed in the victim’s browser, this proxy does not expose the real C&C server address.
Due to a misconfiguration on one of the Inferno Drainer customer’s hosts, we were able to access the source code of the secureproxy.php script.
**Figure 9** – secureproxy.php obfuscated code.
The script applies a light form of obfuscation where all string values are replaced with base64-encoded equivalents, making the code unreadable at first glance. However, since proper access control prevents retrieving the source code, this obfuscation appears to be more of an afterthought rather than a serious security measure.
After deobfuscating the script, we identified a key component: a BSC blockchain smart contract responsible for dynamically resolving the C&C server’s address:
Below is an excerpt from the deobfuscated version of the script:
“`
[ “”, “” ], “contractAddress” => “0xe9d5f645f79fa60fca82b4e1d35832e43370feb0” ]); $endpoint = urldecode($_GET[“e”]); $endpoint = ltrim($endpoint, “/”); $proxy->handle($endpoint); } else { http_response_code(400); echo “Missing endpoint”; } ?>
“`
We extracted the latest C&C address from this smart contract, as well as previous addresses that were set earlier:
Therefore, we can see the evolution of how Inferno Drainer developers attempt to shield their centralized infrastructure from detection and takedown. Their tactics range from storing server addresses in smart contracts, applying obfuscation, and layered encryption, to offloading proxy functionality to customers — all while continuing to leverage blockchain for address storage.
At the same time, we also found that the drainer can still contain obfuscated server addresses directly within the JavaScript code executed on the victim’s side, likely as a fallback mechanism:
“`
“rotatingURL_koy”: [ “mwpt9h-gc0d1q-shutter-88a0609b.koyeb[.]app”, “njc21n-vi8z47-jaatcom822-eb36cf51.koyeb[.]app” ]
“`
**Requests and encryption**
Inferno Drainer transmits data to its C&C servers using JSON messages that undergo multiple layers of AES encryption. Each encryption layer uses different keys, making it harder to analyze the intercepted traffic.
The encryption process relies on a combination of key sources:
`”inferno”is used as the final encryption layer.`
Each encrypted layer is wrapped inside a new JSON structure, which includes additional metadata, such as script version, customer identifier (unique to the attacker’s affiliate), short hashes of different values for integrity verification and, probably to prevent data spoofing.
The JSON payload contains various details about the victim’s interaction including timestamps, website, browser, and wallet data.
A typical request containing victim details and event logs:
“`
{ “walletAddress”: “{victim_wallet_address}”, “walletName”: “MetaMask Wallet WalletConnect”, “site”: “{landing_website_url}”, “fingerprintData”: { “visitorId”: “{unique_victim_id}”, “fingerprint”: null, “requestId”: null, “isTelegramMiniApp”: false }, “logs”: [ { “type”: “connect_but_seed_prompt”, “data”: { “walletName”: “MetaMask Wallet WalletConnect”, “walletAddress”: “{victim_wallet_address}”, “totalWalletPrice”: {wallet_value_in_usd} }, “createdAt”: {timestamp} } ] }
“`
Below is a list of some of the log message types that are sent to the server:
The created JSON payload is encrypted in four layers:
`”inferno”.`
The original JavaScript implementation of Inferno Drainer’s encryption algorithm is heavily obfuscated. To clarify its functionality, we provide a Python reimplementation of the core encryption logic.
“`
def get_short_hash(s): “””Computes a 32-bit hash similar to JavaScript’s hashCode function.””” hash_val = 0 for ch in s: hash_val = ((hash_val –. In this process, adjacent values (+1, -1) for the year, month, and the day_of_the week are also tried. For each key candidate, the script attempts to decrypt the data and parse it as a JSON object. This approach ensures robustness against minor time discrepancies between the client and server, preventing decryption failures caused by time zone differences or slight clock mismatches.`
Below is a simplified Python code snippet for decrypting the server response using the date as a key.
“`
def decrypt_response(encrypted_response, datetime_now): # First layer decryption with static key “inferno” first_layer = cryptojs_aes_decrypt(encrypted_response, “inferno”) decoded_first_layer = base64.b64decode(first_layer).decode(‘utf-8’) # Second layer decryption using a date-based key for delta_year in [-1, 0, 1]: for delta_month in [-1, 0, 1]: for delta_day in [-1, 0, 1]: test_date = date_key + relativedelta(years=delta_year, months=delta_month, days=delta_day) key = f”{test_date.year – 1900}-{test_date.month – 1}-{(test_date.weekday() + 1) % 7}” try: decrypted_data = cryptojs_aes_decrypt(decoded_first_layer, key) print(key) return json.loads(decrypted_data) except Exception: continue # Try next key variation return None
“`
By decrypting the server response, we gain access to the core configuration of the drainer. This includes the smart contract addresses involved in the attack, as well as the beneficiary addresses—the customer’s wallet address for a specific phishing resource and the drainer administrators’ address, which accumulates the majority of the stolen funds before redistribution.
Below is an example of a partial decrypted configuration retrieved from the Inferno Drainer C&C server:
“`
{ “drainerAddress”: “0x0000db5c8b030ae20308ac975898e09741e70000”, “customerAddress”: “0x1e54a3c6ea5b0cf6780e4270397209049af9e9f8”, “adminsNonSplittedHitsAddress”: “0x705aab0a328d21034cecc2c9eba842ccf7d02ba4”, “transferContracts”: { “1”: “0x000037bb05b2cef17c6469f4bcdb198826ce0000”, “25”: “0x000037bb05b2cef17c6469f4bcdb198826ce0000”, … }, “multiFunctionsContracts”: { “1”: “0x000061cf8922f785d356f046b10b11431be60000”, “25”: “0xcf6478b4b5e5a9f03d3e183f7a21c44b21f18669”, … }, “multiFunctionsContractBytecodes”: { “1”: “0x608060405234801561001057600080fd5b50604051610a1a380380610a1a83398181016040528101…”, … }, “factoryContracts”: { “1”: “0xed0e416e0feea5b484ba5c95d375545ac2b60572”, “25”: “0x343d61b74aa40fa17bc056feaf1726cb4f55d74d”, … } }
“`
Below is a detailed explanation of the configuration fields referenced in the decrypted response:
In the next section, we take a closer look at how the smart contracts referenced in the Inferno Drainer configuration are used, explore how they interact with each other, and provide real transaction examples that resulted in fund theft.
Before diving into the details of how these malicious smart contracts function and interact, we must highlight one crucial point.
Wallets such as MetaMask implement their own anti-phishing mechanism. Before approving a signature, these wallets check whether the destination address is blacklisted. If the target address is flagged as malicious, the wallet application typically either blocks the transaction or displays a prominent warning to the user:
**Figure 10** – Screenshot showing MetaMask’s warning when attempting to interact with a known phishing address.
In the following subsections, we demonstrate how Inferno Drainer circumvents these protections by utilizing short-lived intermediate smart contracts.
We use addresses and transaction examples from the Ethereum network. However, it is important to note that Inferno Drainer operates across multiple EVM-compatible networks, where smart contract addresses may vary. A comprehensive list of addresses for different networks can be found in the appendix.
The crypto drainer leverages an advanced smart contract-based scheme to steal crypto from victims’ wallets. We explain the attack flow to steal native tokens (e.g., Ethereum, BNB), the smart contracts involved, and how the stolen funds are accumulated.
The contracts involved are:
**Figure 11** – Draining native crypto flow.
**Fake Token Contract**
As shown earlier, the attack begins with the victim landing on a phishing site that closely mimics the legitimate Collab.Land interface. The fake site prompts the user to connect their cryptocurrency wallet, impersonating the Collab.Land authentication flow.
When the victim connects their wallet, they are prompted to sign a transaction. The target address for this transaction is one of **intermediate smart contracts,** designed to mimic a legitimate ERC-20 token contract.
These contracts are short-lived, typically used for less than 24 hours before being abandoned. At the time of this writing, there were **more than 500 contracts on Ethereum** with the same bytecode.
This strategy is deliberately employed to bypass anti-phishing measures; for example, cryptocurrency wallets like MetaMask quickly flag addresses associated with phishing attempts. By frequently deploying new contracts, attackers evade these warnings, making the scam more effective.
Examples of fake token contracts:
The contracts implement public methods typically seen in legitimate tokens, such as:
“`
function totalSupply() public view returns (uint256); function transferFrom(address sender, address recipient, uint256 amount) public returns (bool); function approve(address spender, uint256 amount) public returns (bool); function balanceOf(address account) public view returns (uint256); function symbol() public view returns (string memory); function transfer(address recipient, uint256 amount) public returns (bool);
“`
At first glance, these contracts appear harmless and exhibit typical ERC-20 functionality. However, the malicious behavior is hidden in how they handle undefined function selectors.
**Anomalous Usage Patterns**
If we examine the interaction patterns with these contracts on blockchain explorers like Etherscan, most transactions involve calls to **undefined methods**, such as:
**Figure 12** – Calling undefined methods “Claim” and “Verify” on the fake token contract.
Any call that does not match a known function selector (e.g., Verify(), Claim()) or is just a raw transfer of ETH, triggers the fallback logic. The approximate reconstructed code for this behavior:
“`
fallback() external payable { // 1) Load list of owners from an external “StorageContract” address[] memory owners = storage.getOwners(); bool isOwner = false; for (uint i = 0; i