An Ethereum user approves a token swap on what appears to be Uniswap, confirms the transaction, and watches the confirmation number appear on-screen. Minutes later, the wallet is empty. The interface looked correct, the transaction details appeared reasonable, and the site URL matched what they expected. Yet the user was never connected to the real Uniswap at all—a DNS hijack or man-in-the-middle attack intercepted the connection, displayed a convincing replica, and executed a malicious contract interaction instead. This scenario is not theoretical; it happens repeatedly across the Web3 ecosystem.
The attack succeeds because users typically verify very little. They assume that if a website loads, if a wallet is installed, and if a transaction appears to confirm, they have successfully used a legitimate service. The rabby wallet extension introduces several layers of protection against this category of attack—transaction simulation, contract approval review, and integration with security systems—but these tools only work if users understand what they prevent and how to use them. Verification is not automatic. It requires understanding how DNS works, what certificate validation means, and why transaction simulation is a defense against contract-level fraud rather than network-level deception.
How DNS hijacking creates convincing fraud
The Domain Name System (DNS) is the phone book of the internet. When a user types a URL or clicks a link, their device queries DNS servers to translate “uniswap.org” into an IP address where the real website lives. If an attacker controls that translation—through a compromised router, a rogue WiFi network, ISP-level manipulation, or even a legitimate but insecure DNS service—they can redirect the user to a server they control. That server can host an exact visual replica of the legitimate website.
This attack is not obvious because the browser, the wallet extension, and the user’s operating system may not have tools that clearly signal a compromise at this level. The fake website can have a valid SSL certificate (because the attacker controls the IP address, they can obtain a certificate for any domain they host locally). The URL bar may appear correct because the browser shows the domain the user requested, not the actual destination. Most critically, the wallet extension itself might not have built-in DNS verification for every dApp a user visits—it cannot independently confirm that the server responding to the request is the legitimate one.
An attacker running this attack typically deploys a contract address in the transaction payload that differs from what the user believes they are approving. When the user signs the transaction, they authorize that malicious contract to execute code—often a token transfer from the user’s address to the attacker’s. The signature proves that the user’s private key authorized the action. Blockchain observers see a valid transaction signed by the user’s wallet. Recovery is not possible because, from the ledger’s perspective, the transaction is completely legitimate.
The defense against DNS hijacking has two components: ensuring the device reaches the correct IP address and ensuring the user understands what contract they are actually authorizing. SSL/TLS certificates help with the first: a proper certificate pinning or validation system confirms that the site the user reached is controlled by the legitimate organization. The second requires the rabby wallet extension to display the actual contract address in a format the user can verify and allow the user to simulate the transaction before signing.
SSL/TLS certificate validation and when it fails
Modern web browsers verify that a website’s SSL certificate was issued by a trusted Certificate Authority and that the certificate matches the domain name in the URL. This system is useful but has known limits. A browser certificate validation failure typically shows a warning screen, but users can often bypass it by clicking “advanced” and accepting the risk. An attacker who has compromised a device’s root certificate store or who can trick a user into installing a malicious certificate authority can defeat validation without the browser showing any warning.
Additionally, a valid SSL certificate for a domain does not guarantee the domain is legitimate. An attacker who can register a look-alike domain—such as “uniswap-app.org” instead of “uniswap.org”—can obtain a valid certificate for the fake domain and host a replica site. The certificate will be perfectly valid; the domain will be subtly different. This is sometimes called a homograph attack when the domains are visually indistinguishable.
Wallet extensions like Rabby can partially mitigate this by maintaining a list of known legitimate domain names and warning users when they connect to sites not on that list. However, this approach has its own limitations: new legitimate dApps appear constantly, maintaining an accurate list is labor-intensive, and attackers can register domains that closely resemble legitimate ones in ways that might not trigger automated detection. The list-based approach is therefore useful as one layer, but it should not be relied upon as the sole defense.
A stronger approach combines certificate pinning (storing a cryptographic hash of a specific legitimate certificate or public key within the wallet extension’s code) with the assumption that any transaction presented to the user should be carefully reviewed before signing. This is why the rabby wallet extension provides human-readable transaction details and contract approval review: even if the user cannot independently verify the network connection, they can see exactly what the transaction will do and refuse to sign if anything looks wrong.
Transaction simulation as a defense against invisible contract fraud
When a user clicks “approve” or “swap” on a dApp, the website creates a transaction object and sends it to the wallet for signing. That object includes the contract address to be called, the function to be executed, the parameters passed to that function, and the value being sent. The user typically sees only a summary: “Approve 1,000 USDC for trading” or “Swap 10 ETH for USDC.”
Transaction simulation involves running the transaction against the blockchain state without actually signing or broadcasting it. The wallet extension can execute the transaction locally using a node connection or API service, observe what would happen if it were broadcast, and report the result to the user. This reveals whether the contract does what the user expects or whether it performs something different—such as transferring tokens to a different address, minting attacker-controlled tokens, or executing a reentrancy attack.
For token approvals specifically, the attacker’s goal often involves getting the user to set a very high allowance to a malicious contract. The user might see a friendly popup saying “Approve USDC for Uniswap,” but if they are actually approving a different contract address, the transaction simulation should show a different address and a potentially unlimited or extraordinarily high amount. The simulation result allows the user to catch this discrepancy before signing.
However, transaction simulation has an important limitation: it shows what the contract will do at the time of simulation, not necessarily what will happen when the transaction is actually broadcast. A contract can be designed to behave differently depending on external state—the time of day, the user’s current balance, whether other transactions have occurred, or what address is calling it. An attacker might craft a contract that appears harmless when simulated but executes the theft only when broadcast a few seconds later. This is rare but possible, which is why simulation should be treated as a powerful tool, not an absolute guarantee.
Man-in-the-middle attacks at the wallet-to-node level
DNS hijacking is not the only network attack that affects wallet users. A man-in-the-middle (MITM) attack can occur at multiple points: between the user’s device and the dApp website, between the wallet extension and the Ethereum node it connects to, or even between the browser and a local service the wallet relies on. These attacks differ in their mechanics but share the goal of either misdirecting the user or altering the transaction before it reaches the blockchain.
A MITM attack between the wallet and a node could theoretically intercept transaction data and return false simulation results or altered balance information. If the wallet trusts the response without verification, the user might see an incorrect simulation result and approve a harmful transaction thinking it is safe. Modern wallet design mitigates this by using HTTPS connections to node providers, validating responses against multiple sources when possible, and making it clear to the user which node the wallet is connected to.
The rabby wallet extension allows users to configure custom RPC endpoints for each network, making the node connection visible and controllable. A sophisticated user can run their own Ethereum node and point the wallet to it, eliminating reliance on third-party node providers entirely. For most users, however, this is impractical, and trusting a reputable provider like Infura or Alchemy is a reasonable trade-off. The key is understanding that the node provider has visibility into which addresses and contracts the user interacts with.
If privacy is a concern, users can route wallet requests through Tor or a VPN, but this does not change the fact that the node provider can see the transaction details. In contrast, a MITM that intercepts the connection can observe information the node would not ordinarily see—such as which website the user is visiting or what wallet extension they are using. Using HTTPS and keeping the browser and operating system up to date reduces this risk significantly.
Phishing detection and scam prevention limits
Many modern wallet extensions, including Rabby, integrate with threat intelligence services or maintain internal databases of known phishing domains and scam contracts. When a user connects to a suspicious site or attempts to interact with a known malicious contract, the wallet may display a warning. This is genuinely useful and has prevented many users from losing funds.
However, the scam prevention approach has fundamental limitations. New malicious contracts and domains are created constantly, and no database can include all of them. An attacker who has not been reported yet will not appear in any blacklist. Additionally, threat intelligence systems depend on reports from victims, researchers, and users, which means there is always a lag between when an attack begins and when it is added to a detection list. A freshly deployed phishing site might operate for hours or days before being detected and added to block lists.
More importantly, a scam prevention database cannot protect against sophisticated fraud that does not rely on a known malicious contract or obvious phishing domain. An attacker who registers a legitimate-looking domain and deploys a new contract specifically for a single attack will not be in any database. The user’s only defense in that case is careful reading of the transaction details and understanding what should and should not be approved.
Users should also be aware that some scams involve social engineering rather than technical network attacks. A link sent through Discord, Twitter, or Telegram might claim to be from a legitimate project but actually be a phishing link registered minutes earlier. The wallet cannot evaluate the source of a link or verify that a message actually came from the project it claims to be from. The user must take responsibility for following links carefully and understanding why they are visiting a site before connecting a wallet.
Building a personal verification routine for Web3 interactions
Protecting against DNS hijacking and MITM attacks requires developing a personal verification routine that goes beyond relying on the wallet’s built-in protections. Start by confirming the domain through multiple independent channels. If you are planning to use Uniswap, visit the official Uniswap documentation, check the project’s GitHub repository for the correct domain, and verify it against social media accounts controlled by the Uniswap team. Visit the site from multiple networks or devices if possible; if a DNS hijack is targeting you specifically, it may only affect one network or ISP.
Once connected to what you believe is the correct dApp, carefully examine the transaction details before signing. The rabby wallet extension displays the contract address, function name, and parameters in a human-readable format. Write down or screenshot the contract address and verify it against the official documentation for the dApp. For token approvals, confirm that you recognize the token symbol and that the approval amount is reasonable. If an approval shows “unlimited,” verify that is intentional and understand the risk: the approved contract can take that token from your address at any time in the future.
Request transaction simulation when the wallet offers it, and carefully review the simulation results. If the simulation shows that a token is being transferred to an address you do not recognize, or if the amount differs from what you expected, stop and investigate before signing. Check the contract address in a block explorer like Etherscan, read the contract source code if it is verified, and cross-reference it against the dApp’s official documentation. This is time-consuming, but the cost of a wrong signature can be devastating.
Hardware wallet integration through rabby wallet extension adds another verification opportunity: you can review the transaction on the hardware wallet’s screen before physically confirming it. The hardware wallet shows the same contract address and function that the extension displays, allowing you to cross-check the details on two different devices. If the two devices show different contract addresses or functions, there is a MITM attack occurring, and you should immediately disconnect and investigate.
Multisignature accounts and approval workflows
For users managing larger or more sensitive addresses, multisignature wallets (often abbreviated as “multisig”) provide an additional verification layer. A multisig address requires multiple private keys to authorize a transaction, distributing the risk across several people or devices. The Rabby wallet extension supports multisignature accounts, allowing a user to create or import a multisig address and manage it through the extension.
In a multisig setup, even if an attacker successfully performs a DNS hijack or MITM attack and tricks one device into signing a malicious transaction, the transaction cannot be broadcast without signatures from the other required parties. The other signers—whether they are different devices, different people, or devices in different geographic locations—can review the transaction independently and refuse to sign if it looks suspicious.
This is especially powerful for defending against sophisticated attacks where the attacker has compromised one device but not all of them. If you store one key on a hardware wallet, another on your phone, and a third with a trusted colleague, an attacker who compromises your phone still cannot steal from the multisig address without obtaining the other two keys. The process is slower than single-signature approval, but the security trade-off is often worth it for high-value addresses.
For dApp interactions, the multisig approach also encourages a more deliberate approval process. You cannot accidentally approve a scam token transfer because the transaction must be reviewed and signed by multiple parties. This review process, combined with the rabby wallet extension‘s transaction simulation and human-readable details, creates a system where casual mistakes are significantly harder to make.
Staying informed about emerging threats and updates
The landscape of DNS hijacking techniques, MITM attacks, and phishing methods evolves continuously. Attackers invest significant effort in understanding how users interact with wallets and dApps, and new vulnerabilities are discovered regularly. Staying secure requires paying attention to security updates from the Rabby team, monitoring reports from Web3 security researchers, and understanding how your own behavior might increase or decrease your exposure.
The open-source nature of the Rabby wallet extension means that the codebase is publicly available for review on GitHub. Security researchers, auditors, and users can examine the code and report vulnerabilities responsibly. This transparency is a strength, but it also means that users who are interested in understanding exactly how their wallet validates certificates, simulates transactions, or detects scams can do so by reading the source code. For most users, this level of technical review is not practical, but following the project’s security announcements and update notifications is reasonable.
Beyond wallet updates, users should understand the broader security ecosystem of their browser and operating system. Browser security updates often include certificate handling improvements, phishing detection enhancements, and fixes for MITM vulnerabilities. Keeping the browser, operating system, and any security software up to date is a foundational requirement for preventing many network-level attacks from succeeding in the first place.
Finally, recognize that no security system is perfect, and a single breach can be irreversible. The most important question is not whether you can eliminate all risk—you cannot—but whether you can make the cost of attacking you so high that an attacker would rather target someone else. Careful domain verification, review of transaction details, use of hardware wallets, and multisig approval workflows collectively create a system where compromising your funds requires significant effort and sophistication. This is not absolute security, but it is the best practical defense available today.
Frequently asked questions
Can the rabby wallet extension protect me from DNS hijacking if I connect to a fake Uniswap website?
The rabby wallet extension can warn you if you connect to a domain known to be malicious, and it displays human-readable transaction details and contract addresses so you can verify what you are actually approving. However, the extension cannot independently verify that the website you are visiting is legitimate just by analyzing network traffic. You must confirm the domain through multiple independent sources—official documentation, GitHub, or verified social media accounts—before connecting your wallet.
What does transaction simulation show, and what are its limitations?
Transaction simulation runs the proposed transaction against the current blockchain state and shows you what would happen if it were broadcast—which tokens would be transferred, to which addresses, and in what amounts. This reveals many types of fraud where a malicious contract would steal your tokens. However, simulation shows the contract’s behavior at the moment of simulation; a sophisticated contract could behave differently when actually broadcast if external state changes or if the attacker designed it to do so. Use simulation as a powerful tool, but do not treat it as an absolute guarantee.
How do I use token approval review to avoid scams?
Token approval transactions allow a contract to transfer your tokens on your behalf up to a specified limit. When approving a token for use on a dApp, verify that the contract address matches the official address from the dApp’s documentation, and confirm that the approval amount is reasonable. Unlimited approvals are sometimes necessary, but they mean the approved contract can take that token from your address at any time in the future. If you later stop using a dApp or become suspicious of it, you can revoke the approval through the same wallet extension.
