Attackers use permit phishing to trick users into signing a permit message that authorises token spending without a normal approval transaction. The signature can then be used to move assets if the contract and token support that flow. Defenders should verify what a signature authorises, reduce blind signing, and monitor for suspicious permit use.
How attackers turn a permit signature into asset movement
permit phishing works because the victim is not approving a normal on-chain transfer. Instead, the attacker tries to get a signature that grants spending authority to a contract or spender, often through a message the user does not fully read. Once signed, the attacker can sometimes use that permit to pull tokens later without another user prompt.
The key security difference is authority, not just transaction flow. A permit can separate “signing a message” from “sending a transfer,” which makes the interaction feel safer than it is. If the token standard and contract support permit-based spending, the signed message can become a reusable authorisation artefact. Crypto Scam and Drainer Guide explains how approval phishing and malicious signature requests are used in practice, while Phishing Guide provides the broader phishing patterns attackers rely on to push victims into fast, low-scrutiny signing.
Attackers usually hide the real effect behind wallet UX, misleading dApp branding, fake airdrops, support lures, or urgent prompts. The user thinks they are confirming login, claiming a reward, or performing a harmless check. In reality, the signed payload may authorise token spending, delegate allowance, or another action that the attacker can later execute against the same wallet or token contract. Top 10 Phishing Techniques is useful for recognising the lure patterns that commonly surround these requests.
Why permit phishing is effective against crypto users
Permit phishing succeeds when users treat a signature as equivalent to authentication, rather than as a binding authorisation. That confusion is powerful because many wallets present signatures with too little context, and many users are trained to click through prompts to reach the expected app action. The attacker does not need to break the cryptography if they can shape the user decision.
It is especially effective when the request is framed as “sign to continue” and the actual authority being granted is buried in the message details. That makes blind signing the central failure mode. The problem is not only phishing content, but the mismatch between what the user believes they are confirming and what the wallet will later allow the contract or spender to do. Solana web3.js npm compromise 2024 and Ledger Connect Kit npm compromise 2023 show how attackers combine trusted software paths with wallet-signing abuse to turn user trust into theft.
Once the permit exists, the attacker may not need to keep interacting with the victim. That reduces friction and creates a delayed theft path, which can make the initial compromise harder to connect to the later asset movement. In incident response terms, the dangerous event is often the signature itself, not the moment funds leave the wallet.
What defenders should check before they trust a permit request
The most important habit is to verify the exact authority being granted before signing. Practitioners should inspect the spender or contract address, the token involved, the approval scope, and whether the signature authorises one-time spending or an open-ended allowance. If the prompt cannot be explained in plain language, treat it as suspicious.
Defenders should also look for organisational controls around wallet interaction, such as allowing only approved dApps, warning on unusual contract targets, and training users to avoid blind signing. For teams that manage wallets or treasury access, the best control is to reduce the number of people and workflows that can approve high-impact signatures in the first place. The Crypto Scam and Drainer Guide is the most directly relevant internal reference for understanding approval phishing patterns and response decisions.
Where a signature has already been made, assume the permit may be usable until proven otherwise. That means checking for active allowances or delegated permissions, revoking what can be revoked, and monitoring for token movement or contract calls tied to the permitted spender. If the permit was exposed in a phishing flow, asset protection should start before a broader fraud investigation does.
Risk and Threat Considerations
Permit phishing is risky because it weaponises a legitimate signing action into a transfer right that may survive the original lure. The user may believe they only authenticated to an application, but the attacker is actually seeking a reusable authorisation path to drain assets later.
Failure mechanism: The victim signs a permit message without understanding the scope, and the attacker uses that authorisation to spend tokens or trigger contract-controlled movement without another approval prompt.
Impact: The wallet can lose assets even if no private key is exposed, and the theft may appear later than the phishing event, complicating detection, attribution, and recovery.
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-05 — Overprivileged NHI | Permit phishing grants excessive token-spending authority through signatures. |
| NHI-02 — Secret Leakage | Phished permit workflows can expose reusable authorisation material or tokens. | |
| NHI-07 — Long-Lived Secrets | Permits can behave like durable spending capability if not time-bounded or revoked. | |
| Recommendation — Limit signature-granted authority and review spending scopes before approval. Detect exposed signing artefacts and revoke any reusable authorisation immediately. Prefer short-lived permissions and enforce timely revocation of stale approvals. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The attack abuses signed authorisation flows to impersonate legitimate approval. |
| Recommendation — Treat signed permit flows as authentication-critical and validate them strictly. | ||
| MITRE ATT&CK | T1566 — Phishing | Permit phishing relies on social engineering to obtain the signature. |
| T1110 — Brute Force | No direct fit removed; omitted. | |
| Recommendation — Instrument phishing detections for lures that solicit wallet signatures. Omit | ||
Practitioner Guidance
What to verify: Verify the exact spender, token, scope, and expiry before any signature is accepted as legitimate. If the request is not clearly tied to a known workflow, treat it as an approval attempt rather than a harmless login step.
Decision rule: If the signature can authorise spending or delegation, prioritise transaction review and revocation readiness over user convenience. If it cannot be clearly explained in business terms, do not sign it on the assumption that it is routine.
What good looks like: Users can distinguish authentication from authorisation, wallets surface meaningful permit details, and teams can quickly identify and revoke suspicious approvals before they are used.
Practitioner takeaway: Permit phishing is dangerous because the theft starts at the moment of authorisation, not when funds move, so the control objective is to make every signature legible, intentional, and limited.