Wallet address replacement is a tampering technique that swaps a legitimate cryptocurrency destination with an attacker controlled one. It often happens inside browser requests, signing flows, or application data before the user sees the final transaction. Because the interface can still look normal, the fraud is hard to spot.
Expanded Definition
Wallet address replacement is a post-input tampering technique that alters a cryptocurrency destination after the sender has entered or selected it, but before the transaction is finalised. The goal is to redirect funds to an attacker-controlled wallet while preserving the appearance of a legitimate transfer. In practice, the change may occur in browser memory, page script, clipboard content, signing prompts, or application data streams, which makes it a deceptive integrity problem rather than a simple user error. Because the attack targets transaction construction, it sits at the intersection of application security, endpoint compromise, and payment fraud.
Definitions vary across vendors, but the security concern is consistent: the intended recipient is replaced without the user’s informed consent. That makes this closer to transaction tampering than to credential theft, although it may be enabled by malware, malicious browser extensions, or compromised web content. NIST guidance on integrity and access control in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because the underlying problem is protecting transaction data from unauthorised modification. The most common misapplication is treating wallet address replacement as user negligence, which occurs when defenders ignore tampering in the transaction path and focus only on phishing at the login stage.
Examples and Use Cases
Implementing protections against wallet address replacement rigorously often introduces friction in checkout and signing workflows, requiring organisations to weigh transaction speed against stronger verification and integrity checks.
- A browser-based crypto payment form is altered by injected JavaScript so the displayed recipient looks correct, but the signed transaction sends funds elsewhere.
- A clipboard hijacker replaces a copied wallet address with a similar-looking attacker address just before the user pastes it into a transfer screen.
- An attacker with access to a wallet application or browser extension modifies the destination field during a signing flow, bypassing the user’s original selection.
- A compromised merchant checkout page changes payout details in hidden form fields before the final request is submitted to the payment processor.
- In wallet approval workflows, the recipient address shown in the interface does not match the address embedded in the transaction object, creating a mismatch that should be blocked by validation controls and integrity checks.
Teams evaluating this threat should also review browser and endpoint hardening guidance from OWASP Top 10, because script injection and client-side manipulation often make the attack possible. In mature environments, transaction integrity checks are paired with human verification steps, but those controls only work if the final signed payload is independently confirmed.
Why It Matters for Security Teams
Wallet address replacement matters because it breaks trust in the final step of value transfer, where users believe they are authorising one recipient but are actually approving another. For security teams, the issue is not merely fraud detection; it is preserving the integrity of transaction data across browser, application, and signing layers. In identity and access terms, the attacker is often exploiting a trusted session or a legitimate approval path, which means the control failure may not appear in authentication logs at all. That is why endpoint protection, content security, code integrity, and transaction validation all need to work together.
Operationally, this threat is especially relevant for organisations handling crypto payouts, treasury transfers, escrow workflows, and NHI-controlled signing automation. If an agent or service wallet can initiate payments, the same tampering pattern can affect non-human identities as well as human users. Security monitoring should therefore look for destination drift, last-moment field changes, and mismatches between displayed and signed values, not just failed logins or suspicious IPs. Organisations typically encounter the consequence only after funds have been irreversibly transferred, at which point wallet address replacement becomes operationally unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI wallet and service identity controls address transaction tampering against automated signers. | |
| NIST CSF 2.0 | PR.DS-6 | Data integrity protection applies when transaction destinations are altered in transit or at rest. |
| NIST SP 800-53 Rev 5 | SI-7 | System and information integrity controls address unauthorized modification of transaction objects. |
| NIST SP 800-63 | Identity assurance matters when a trusted session is abused to approve a different wallet address. | |
| OWASP Agentic AI Top 10 | Agentic workflows can be coerced into approving altered destinations through tool or prompt tampering. |
Protect non-human signing paths with integrity checks and strict approval boundaries.
