Honeypot Crypto Scam Techniques Explained: A Comprehensive Guide

The blockchain world faces numerous security threats that emerge at an alarming rate and adapt to new and evolving environments. Among these, the honeypot scam is a particularly popular form of fraud. In February 2024, a single cybercriminal executed multiple honeypot scams, successfully stealing approximately $3.2 million from victims. This incident involved at least nine separate scams that were intricately linked to deceptive marketing tactics, including the use of paid actors promoting these scams via Telegram channels. There have been hundreds, if not thousands, of such incidents. 

This article offers an in-depth look at honeypot attacks on Ethereum smart contracts, covering their mechanisms, identifying features, and detailed protection strategies.

What Is A Honeypot Crypto Scam?

In a cryptocurrency context, a honeypot is a deceptive smart contract aimed at drawing unwary investors to make high returns or offer unique services. They are crafted to give the initial appearance of legitimacy and profitability. However, they contain a hidden mechanism to mint tokens to the exploiter and drain the pool. As a result, honeypot scams either drain victim’s funds or hinder withdrawals. Due to technical vulnerabilities, psychological manipulation, and the complicated nature of blockchain technology, even experienced cryptocurrency users can be fooled by honeypot scams.

Mechanisms Of A Honeypot Attack

The scammer then enters into the “promotion stage” of the contract, using different channels, including social media, forums, and chat groups dedicated to cryptocurrency investments. This is often through promises of high returns, special features, or taking advantage of opportunities that can lure victims. Initial interactions with the contract are meticulously built to work flawlessly and allow for deposits and withdrawals in small amounts. Trust is built, which encourages bigger investments, but it is actually step 2: exploitation.

Honeypots follow a complex lifecycle that exploits both technological and psychological weaknesses. Usually, it starts from step 0, ‘contract development,’ where upon creating a deliberately vulnerable or trap-filled smart contract, an attacker who is normally knowledgeable about blockchain technology and sometimes works as a programmer will develop it with malicious intent so that it appears legal enough for potential victims.

After creation, this malicious smart contract must be deployed on the Ethereum blockchain (step 1). This step involves paying gas fees and interacting with the Ethereum network to store the contract’s bytecode. In order to make it look more legitimate and attractive, attackers initially send some funds into this uninviting structure, thus giving people the illusion that there may be some liquidity or profit.

The real nature of these scams comes to light when victims try to withdraw large sums of money. This happens when investors realize their funds have been locked because of hidden mechanisms within the smart contracts code. These may range from simple withdrawal limitations to more intricate logical traps. The perpetrators might resort to certain concealment techniques like using numerous form contracts, deploying proxy contracts, or designing complex communication patterns to not be detected and make their operation last longer — step 3 or the final stage of the bait scam.

This type of scam has been especially apparent on Twitter, where malicious links that bait users into interacting with honeypot contracts are rampant. 

Honeypot Features

While honeypot scams can vary in their specific implementations, they often share common characteristics that can aid in their identification: 

• One prevalent feature is the presence of an apparent vulnerability in the contract. This “vulnerability” is a trap designed to lure in potential targets who believe they can exploit it for personal gain.
• Restricted withdrawals are another hallmark of honeypot scams. While deposits are typically unrestricted and encouraged, withdrawals are often impossible or limited to specific addresses controlled by the attacker. This one-way flow of funds is a clear red flag for potential victims.
• When available, the source code of honeypot contracts may include misleading elements. Comments or functions that allow profitable interactions may be present but are actually non-functional or deceptive. This misdirection is intended to create a false sense of security or opportunity for potential victims.
• To create an illusion of legitimate activity, scammers might simulate transactions. This can include transfers between addresses controlled by the attacker to mimic user interactions and make the contract appear more active and trustworthy than it actually is.
• Some honeypot contracts implement time-based restrictions, allowing withdrawals only after a certain period. However, these time locks are often coupled with other mechanisms to prevent actual withdrawals, serving merely as a delay tactic to keep victims invested for longer periods.
• Balance inconsistencies are another common feature of honeypot scams. The contract may report balances that don’t align with actual token or Ether holdings, creating a false sense of value or liquidity. This discrepancy can be used to entice further investments or prevent withdrawals. The contract manipulates its internal balance to prevent withdrawals. The contract may appear to have sufficient funds, but internal accounting mechanisms make withdrawals impossible.
• Complex approval mechanisms are sometimes employed in honeypots. These systems make it appear as though users have control over their funds when, in reality, these approvals are meaningless and do not grant actual access to the trapped assets.
• Some honeypots rely on external contracts or oracles for critical functionalities. The attacker can manipulate these dependencies to prevent legitimate operations, adding another layer of complexity to the scam.

It is not always easy to identify a honeypot scam, as they also vary in nature, but being aware of the above characteristics can help a lot. 

Techniques Employed in Honeypot Scams

Honeypots are smart contracts that intentionally contain vulnerabilities to lure attackers and cause them to lose their funds. Based on their internal working principles, honeypots can be divided into several types, such as balance disorder, inheritance disorder, hidden state updates, hidden transfer, and more.

Note: this categorization cannot be exhaustive since writing honeypots is like an art, and people can get really creative. For example, a bad actor could theoretically hide some assembly block somewhere to low-level write a high number to the storage slot of our entry of the balance mapping.  We haven’t heard of such a scenario, but it’s important to understand that scammers can devise new honeypot schemes beyond this categorization.

Malicious Upgradeability

A malicious upgradeability technique involves a smart contract that can be upgraded to a harmful version after investment, converting it into a honeypot. This tactic is particularly deceptive as it exploits the upgradable nature of some smart contracts.

Example Code:

pragma solidity ^0.8.0;
contract Upgradeable {
    address public implementation;
    function upgradeTo(address _newImplementation) public {
        // Only the contract owner can call this
        require(msg.sender == owner);
        implementation = _newImplementation;
    }
    fallback() external payable {
        address impl = implementation;
        require(impl != address(0));
        (bool success, ) = impl.delegatecall(msg.data);
        require(success);
    }
}
contract MaliciousUpgrade {
    function () external payable {
        // Malicious code here
    }
}

In this example, the Upgradeable contract can be upgraded to the MaliciousUpgrade contract, which can contain harmful logic.

Balance Disorder (BD)

The balance disorder honeypot exploits new Ethereum users’ misunderstanding of contract balance updates. The attacker makes the user believe that sending Ether larger than the contract’s balance will result in the entire balance being transferred to their account, which is not the case due to the order of balance updates and transfer operations.

Example Code:

contract A {
    function trans() public payable {
        if (msg.value >= address(this).balance) {
            payable(msg.sender).transfer(address(this).balance + msg.value);
        }
    }
}

Inheritance Disorder (ID)

When a smart contract inherits from another, not all attributes are inherited as expected. Attackers exploit this by constructing conditions based on same-named attributes in parent and child contracts, misleading victims about the contract’s behavior.

Example Code:

contract A {
    address public owner;
    constructor() {
        owner = msg.sender;
    }
    modifier onlyowner {
        require(msg.sender == owner);
        _;
    }
}
contract B is A {
    address public owner = msg.sender;

    function b1() public payable {
        if (msg.value == address(this).balance) {
            owner = msg.sender;
        }
    }
    function b2() public onlyowner {
        payable(msg.sender).transfer(address(this).balance);
    }
}

Skip Empty String Literal (SESL)

A flaw in the Solidity compiler previously allowed skipping hard-coded empty string literals, causing parameter mismatches during function calls.

Example Code:

contract A {
    function test(uint amount, bytes32 msg, address sender, address owner) public {
        // Transfer logic
    }

    function trytest(uint amount) public {
        this.test(amount, '', msg.sender, owner);
    }
}

Type Deduction Overflow (TDO)

Type deduction by the Solidity compiler can lead to integer overflows, causing endless loops and preventing the execution of subsequent code.

Example Code:

contract A {
    function Test() public payable {
        if (msg.value > 0.1 ether) {
            uint256 multi = 0;
            uint256 amount = 0;
            for (var i = 0; i < msg.value * 2; i++) {
                multi = i * 2;
                if (multi < amount) break;
                amount = multi;
            }
            payable(msg.sender).transfer(amount);
        }
    }
}

Uninitialized Structure (US)

Uninitialized structures can cause data overwrites if not properly initialized.

Example Code:

contract A {
    uint random = uint(keccak256(abi.encodePacked(block.timestamp)));
    struct Test {
        address player;
        uint256 number;
    }
    function guess(uint256 guessnumber) public {
        Test memory test1;
        test1.player = msg.sender;
        test1.number = guessnumber;
        if (guessnumber == random) {
            payable(msg.sender).transfer(address(this).balance);
        }
    }
}

Hidden State Update (HSU)

Attackers can hide state changes that affect the contract’s behavior, making it difficult for victims to understand the true state.

Example Code:

contract A {
    bool varSet = false;
    bytes32 private hashPass;

    function SetPass(bytes32 hash) public payable {
        if (!varSet && msg.value >= 1 ether) {
            hashPass = hash;
        }
    }
    function GetGift(bytes memory pass) public returns (bytes32) {
        if (hashPass == keccak256(pass)) {
            payable(msg.sender).transfer(address(this).balance);
        }
        return keccak256(pass);
    }
    function PassHasBeenSet(bytes32 hash) public {
        if (hash == hashPass) {
            varSet = true;
        }
    }
}

Hidden Transfer (HT)

Long codes with hidden segments can deceive victims by hiding crucial logic.

Example Code:

contract A {
    address private _owner;

    function Test() public payable {
        require(msg.value > 0.5 ether);
        if (block.number > 1) {
            if (_owner == msg.sender) {
                payable(_owner).transfer(address(this).balance);
            }
        }
        payable(msg.sender).transfer(address(this).balance);
    }
}

Straw Man Contract (SMC)

Attackers deploy multiple contracts with similar names to mislead victims about the contract interactions.

Example Code:

contract A {
    address public owner;
    B public b;

    function pay() public payable {
        if (msg.value > 1 ether) {
            owner = msg.sender;
        }
    }
    function setB(address _b) public {
        b = B(_b);
    }
    function withdraw(uint _val) public {
        require(msg.sender == owner);
        b.addmsg(msg.sender, _val, "add");
        payable(msg.sender).transfer(_val);
    }
}
contract B1 {
    struct Message {
        address addr;
        uint val;
        string data;
    }
    Message[] public History;
    Message public Lastmsg;
    function addmsg(address _addr, uint _val, string memory _data) public {
        Lastmsg = Message(_addr, _val, _data);
        History.push(Lastmsg);
    }
}
contract B2 {
    struct Message {
        address addr;
        uint val;
        string data;
    }
    Message[] public History;
    Message public Lastmsg;
    function addmsg(address _addr, uint _val, string memory _data) public {
        revert();
    }
}

Unexecuted Call (UC)

Incorrect function call syntax prevents execution, trapping funds.

Example Code:

contract A {
    function trans() public payable {
        if (msg.sender.value >= 0.1 ether) {
            (bool success, ) = msg.sender.call{value: 1 ether}("");
            require(success);
        }
    }
}

Map Key Encoding Trick (MKET)

Honeypots use misleading mapping keys to trick victims into thinking they have ownership.

Example Code:

contract BankOfStephen {
    mapping(bytes32 => address) private owner;

    constructor() {
        owner['Stephen'] = msg.sender;
    }
    function becomeOwner() public payable {
        require(msg.value >= 0.25 ether);
        owner['Stephen'] = msg.sender;
    }
    function withdraw() public {
        require(owner['Stephen'] == msg.sender);
        payable(msg.sender).transfer(address(this).balance);
    }
    receive() external payable {}
}

Mechanisms

One particularly insidious technique involves using sweeper scripts, also known as sweeper bots. These automated programs are designed to instantly transfer any deposited funds to a different wallet controlled by the attacker. As soon as a victim interacts with the compromised smart contract or wallet address, the sweeper bot springs into action. It monitors the contract or address for incoming transactions and, upon detecting a deposit, immediately initiates a transfer to move the funds to the attacker’s secure wallet.

 This rapid automated response often occurs faster than the victim can realize what’s happening, making it nearly impossible to cancel or reverse the transaction. The efficiency of sweeper bots makes them a favored tool among scammers, as they can operate 24/7 without human intervention, maximizing the potential for ill-gotten gains.

Some Known Honeypot Scams

Examining real-world honeypot scams provides valuable insights into their operation and impact. The DeChat incident in 2023 is a reminder of how even legitimate projects can inadvertently become vectors for scams. DeChat, a decentralized social media platform, accidentally shared a honeypot scam link during a token announcement. This incident caused confusion and potential losses among community members, highlighting the importance of vigilance even when interacting with established projects.

The SHIB Telegram hack is another notable example that shook the Shiba Inu community. In this case, the official Telegram channel of the popular meme coin project was compromised, and attackers shared a honeypot scam link. Established projects with large followings can be targeted to maximize the reach and impact of scams, exploiting the trust users place in official communication channels.

How To Spot And Prevent Honeypot Scams

Protecting oneself from honeypot scams isn’t as straightforward as finding a bug. It requires a combination of technical knowledge, due diligence, and necessary skepticism. A crucial step is conducting a thorough code review before interacting with any smart contract. For those who lack the technical proficiency to do this themselves, considering the services of a professional auditor or code auditing service can be a wise investment.

• Transaction history: Analyzing the transaction history of a contract using blockchain explorers like Etherscan can provide valuable insights. Users should look for patterns that might indicate fake activity or restricted withdrawals. Unusual transaction patterns or a history of failed withdrawal attempts can be red flags. A transaction history that suggests any transfers in are immediately transferred out (or, at least, shortly after) is a red flag. Honeypot scams need a script to sweep funds out to a third wallet. Look up the wallet on a block explorer and check for these patterns.
• Community Research: Community research is also an important part of fighting honeypot scams. Looking through forums, Twitter and news sites for any reported problems with a contract or token can provide an early sign. Beware of too good to be true reviews because they may have been written by scammers trying to make their scheme look legitimate.
• Detection Tools: Using honeypot detection tools can provide an additional layer of protection. While not foolproof, these tools can offer valuable insights into the potential risks associated with a smart contract. Tools like HoneyBadger, QuillCheck, and Token Sniffer analyze various aspects of smart contracts to identify potential honeypot characteristics.
• No audit: The chances of a honeypot are nearly always eliminated if a trustworthy company audits them.

Verifying the identity of the development team behind a project is another important step. Anonymous teams should be cautiously approached, as the lack of accountability can be a red flag. However, it’s important to note that even projects with known teams can be compromised or turn malicious.

The Role Of Smart Contract Audits

Conducting professional smart contract audits can avoid honeypot scams and other vulnerabilities. Such audits provide an independent evaluation of the contract’s code, functionality, and security, which is deeper than what most individual users can accomplish. Some projects do indeed have malicious developers working for them, who may also hide honeypot scams as traps.

The auditors identify possible problems through a mix of manual code review with automated tools and extensive testing. Casual observers or even experienced developers might not notice this kind of thorough probing that could find logic flaws and hidden weaknesses, among many more issues that are not easily apparent. However, most honeypot traps are contracts that deceptively look like real ones; hence requiring some level of skepticism from average crypto users.

Thus secure security practices in organizations as well as individuals are necessary to avoid falling victim to such scams.

Follow @hackenclub on 𝕏 (Twitter)

Final remarks

Honeypot scams are a threat that’s becoming increasingly popular. These scams are successful because they exploit technical weaknesses, human psychology, and the intricate nature of blockchain technology. Using detection tools, awareness, and examining audits or transaction history remain important components of safe participation in the cryptocurrency ecosystem.

It pays to be skeptical in crypto, so always dyor.