Attackers use signature phishing to trick users into signing a malicious blockchain transaction or approval rather than entering a password. The signature can authorise token transfers, spending allowances, or contract interactions. Defenders should scrutinise requested permissions, verify the destination and contract details, and educate users that a signature can have real financial impact.
How signature phishing works in crypto attacks
Attackers abuse the signing step because it feels routine and often looks technical rather than suspicious. Instead of asking for a password, they present a transaction, approval, or wallet prompt that appears legitimate enough to sign. Once approved, the attacker can move funds, grant allowances, or trigger contract actions without needing to steal the password first.
That shift matters because a crypto signature is not just a login gesture. It can become an authorisation event with direct financial consequences, especially when the request is opaque, the contract is unfamiliar, or the permission is broader than the user expects.
What attackers try to hide in the signature request
Signature phishing works by separating the user’s intent from the transaction’s actual effect. The prompt may be framed as a claim, verification, mint, airdrop, wallet sync, or security check, while the signed data authorises token movement, unlimited spending approval, or interaction with a malicious contract.
In practice, attackers rely on users not reading the destination, spender, chain, or permission scope closely enough. The danger is especially high when the interface compresses a complex on-chain action into a simple approve or sign request, because the user may think they are proving ownership rather than granting value-bearing authority. NHIMG’s Crypto Scam and Drainer Guide covers approval phishing and malicious signature patterns in more detail.
Different campaigns also abuse different trust cues. Some lean on fake support, fake airdrops, or counterfeit dapps; others use copied branding, cloned pages, or malicious browser flows to make the signature seem routine. The common thread is that the attacker wants the victim to authorise something that is technically valid but commercially harmful.
How defenders should evaluate and reduce the blast radius
The useful defence is to treat every requested signature as a potential permission grant, not a harmless confirmation. Users should verify the exact contract, the destination, the asset involved, and whether the request is an approval, a transfer, or a contract call that can have side effects beyond the visible prompt.
When reviewing suspicious activity, focus on what the signature could unlock if it is genuine but malicious. That includes token allowances, session-like permissions inside wallet-connected apps, delegated spending, and repeated-use approvals that remain active after the initial interaction. If the request is unclear, the safest default is to stop and validate it through a separate trusted channel.
For broader context on how phishing campaigns are built and why they keep working, the Phishing Guide is useful, especially where attackers combine social engineering with convincing pretexts.
Risk and Threat Considerations
Signature phishing is dangerous because the attacker does not need account access in the usual sense. A single mistaken signature can create durable authorisation, enable asset movement, or open the door to later theft if the approval remains valid. The risk grows when users sign quickly, wallets compress permission details, or the contract interaction is hard to interpret.
Failure mechanism: The attacker substitutes a malicious authorisation request for a benign-looking prompt, then uses the signed transaction or approval to transfer tokens, spend allowances, or invoke contract logic under the victim’s authority.
Impact: Funds can be drained, allowances can persist beyond the initial click, and the compromise may be hard to unwind if the user does not immediately revoke permissions or move remaining assets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Signature phishing often leads to wallet or token theft. |
| NHI-05 — Overprivileged NHI | Malicious approvals create excessive delegated authority over assets. | |
| NHI-07 — Long-Lived Secrets | Persistent approvals and reusable wallet permissions extend abuse windows. | |
| Recommendation — Review exposed signing flows and revoke leaked credentials or approvals. Limit approval scope and remove standing allowances quickly. Shorten approval lifetimes and revalidate high-value permissions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Attackers exploit signed actions to invoke higher-impact functions. |
| Recommendation — Enforce function-level checks on sensitive transaction paths. | ||
| MITRE ATT&CK | T1566 — Phishing | Signature phishing is a phishing-based initial access and fraud technique. |
| Recommendation — Detect phishing delivery and block malicious lures before signature. | ||
Practitioner Guidance
What to verify: Check the spender address, contract address, requested amount, chain, and whether the prompt is an approval or a direct transfer. If the wallet UI hides any of those details, treat the request as high risk until independently verified.
Decision rule: If the signature would grant ongoing authority, such as an allowance or reusable approval, treat it as a privileged action and review it with the same care you would apply to a financial delegation. If it is time-sensitive or unexpected, decline first and investigate later.
Practitioner takeaway: The key judgement is to recognise that a signature can be an authorisation mechanism with real economic impact, so the correct control is not just “don’t share your password”, but “do not sign what you cannot explain.”