1. What is the StepDrainer attack?
Blockaid, a blockchain security firm, reported on October 31 that a toolkit known as StepDrainer had been planted on at least 12 decentralized finance and token-launch websites. Visitors who tried to connect a wallet were shown fraudulent prompts built to collect token approvals and signatures. Researchers linked the intrusions to compromised domain infrastructure rather than to flaws in the protocols themselves.
StepDrainer is a wallet-drainer kit, a bundle of malicious code that imitates the wallet-connection step of a legitimate application. Instead of simply linking a user's wallet to a service, the code asks for permissions that let an attacker move assets later. Because the prompt appears on a site the user already trusts, the request can look routine.
The campaign stands out for its breadth. Rather than targeting a single project, the operators reached a dozen separate sites in a short period, which suggests a shared weakness in how those sites were hosted or how their domain settings were managed. Investigators are still examining that common thread, and no single root cause has been publicly confirmed.
2. Which sites were affected?
Among the sites named in the reporting were Pickle Finance, Origami Finance and Fluxbeam, alongside others in the DeFi and token-launch segment. Blockaid's count of at least 12 grew from an earlier alert covering a smaller group, which later expanded as researchers found the same toolkit on additional properties.
At least one of the affected teams said it had restored its website after the intrusion. Teams that regained control generally pointed their domains back to their normal infrastructure and urged visitors to hold off on connecting wallets until a formal security notice was published. That caution reflects a practical problem: after a domain is corrected, cached records can linger on some networks, so a small number of users may still be routed to the malicious copy for a while.
No significant aggregate loss figure has been published. That absence does not prove that nobody lost funds, but it indicates that the damage, if any, had not been quantified when the first reports appeared.
3. How does a DNS-based attack reach users?
The Domain Name System translates a readable web address into the numeric location of the server that hosts the site. If an attacker gains access to the account or registrar settings that control those records, the address can be pointed at a server the attacker runs. A visitor who types the correct address, or follows a bookmark, then lands on a copy that looks identical to the real site.
This is why the technique is difficult for ordinary users to detect. The address bar can show the genuine name, the page layout can match the original, and the smart contracts behind the service remain untouched. The only visible difference may be the wallet prompt that appears when the user clicks to connect.
Attacks of this kind shift the focus of security away from contract audits, which examine on-chain code, and toward the web layer that sits between users and those contracts. A protocol can be flawless on-chain and still expose its users if the website that fronts it is compromised.
4. What do the fraudulent prompts ask for?
The malicious prompts are designed to harvest token approvals and signatures. An approval is a standard permission in which a wallet owner allows a specific address to spend a given token on their behalf. Decentralized exchanges and lending markets rely on approvals constantly, and users grant them many times without a second thought.
The danger arises when an approval is granted to an attacker's address, particularly when the amount is unlimited. Once such a permission exists, the attacker can transfer the approved tokens at any time, without asking the owner again. Signatures can be abused in a similar way if they authorize transfers or permissions off-chain.
Importantly, the reporting indicates that no private keys were stolen. Harm depended on users approving the malicious requests. A wallet whose owner never signed or approved anything on a tampered site was not exposed through this route.
5. What should users who connected a wallet do?
Anyone who connected a wallet or signed a request on one of the flagged sites should review their token approvals and revoke any that they do not recognize. Approval-management tools, which read the permissions recorded on-chain for an address and let the owner cancel them, are the standard way to do this. Revoking an approval costs a small network fee but removes the attacker's ability to spend that token.
Users who interacted with an affected site may also consider moving remaining assets to a fresh wallet, since a newly created address carries no earlier permissions. This is a precaution rather than a requirement, and it is most relevant to those who granted broad or unlimited approvals.
As a general habit, users can read each wallet prompt before confirming it, check which address is being granted a permission, and treat any unexpected request on a familiar site with suspicion. Where a project has announced a problem, waiting for its official all-clear before reconnecting is the safer course.
6. Why do drainer kits keep spreading?
Wallet-drainer kits have become a recurring feature of crypto crime because they lower the effort needed to run a theft campaign. The operators of a kit supply the deceptive interface and the logic for collecting approvals, while the people deploying it need only a way to place the code in front of victims. Compromising a trusted site, as in this case, is one of the most effective ways to do that.
Defenders have responded with monitoring services that flag suspicious front ends and push warnings to wallet software. Blockaid's identification of this campaign is an example of that approach: security firms watch for sites that begin serving known malicious scripts and alert the affected teams and the wider community.
Even so, the speed of a domain-level attack means that some users can be exposed in the interval between the compromise and the warning. In the DeFi sector, where transactions are irreversible and there is generally no central party able to reverse an unauthorized transfer, that interval matters.
7. What are the broader implications for DeFi?
The incident highlights how much of decentralized finance still depends on conventional internet services. Smart contracts may run on a blockchain with no central operator, but most users reach them through websites that rely on domain registrars, hosting providers and account logins. Each of those is a potential point of failure that the blockchain itself cannot protect.
Projects can reduce this exposure through stronger controls on the accounts that manage their domains, such as hardware-based authentication and restricted access, and through regular review of who can alter their records. Some teams also publish multiple official access routes so that users have an alternative if one is compromised, although this approach carries its own risk of confusing visitors.
For users, the lesson is that the strength of a protocol's code does not guarantee the safety of every route to it. The shared nature of this campaign, which touched many unrelated projects at once, suggests that security reviews should extend beyond the contracts to the full chain of services that deliver a project to its users.
8. Why does the web layer matter for self-custody?
Self-custody means a user holds the keys to their own assets, and no company can freeze or recover them. That design removes the risk of an exchange failing, but it also moves responsibility for every decision onto the individual. Each time a wallet prompt appears, the user is effectively acting as their own security team, usually with only a few seconds and a short summary of the request on screen.
Attackers exploit exactly that condition. A prompt that arrives on a site a person has used many times, at a moment when they expect to be asked for a connection, draws far less scrutiny than an unsolicited message from a stranger. Compromising a trusted domain therefore borrows the credibility the project has built over time and turns it against its own users.
Wallet developers have added transaction previews and warnings for known malicious addresses, and these help. They are not complete, however, because a newly created attacker address has no history to flag. The most reliable protection remains a careful reading of what is being approved, combined with limiting approvals to the amounts a user actually intends to spend.
9. How can projects limit the damage from a hijacked front end?
One approach is to lock the registrar account with the strongest available authentication and to restrict the number of people who can change records. Another is to enable registry-level protections that require extra verification before a domain's settings can be altered, which raises the cost of a hijack even if a login is stolen.
Monitoring also plays a role. A team that is alerted the moment its records change, or that regularly checks what its public site is serving, can detect a swap within minutes rather than hours. Prompt public warnings then give users a chance to avoid the compromised site while the team repairs the problem.
None of these measures eliminates the risk, but together they narrow the window in which a malicious copy can operate. For a sector built on the idea that users do not need to trust intermediaries, closing that window is a practical necessity rather than an optional improvement.
10. What happens next?
Investigators are still examining what the affected sites have in common, and the answer will determine whether further projects are at risk. Affected teams are expected to publish formal security notices that explain what occurred, confirm when it is safe to reconnect wallets and describe any measures taken to prevent a repeat.
Until those notices appear, the guidance from the teams involved remains consistent: avoid connecting a wallet to a flagged site, and revoke any suspicious approvals granted to it. Readers should consult each project's official announcements for its current status, since the number of affected sites and the details of the intrusion may change as the investigation continues.