The technologies that connect us are continually advancing, and while this brings tremendous new capabilities to users, it also opens new attack surfaces for adversaries and abusers. Social engineering represents a class of threats that has extended to virtually every technology that enables human connection. Our recent analysis of a phishing attack connected to the blockchain reaffirms the durability of these threats as well as the need for security fundamentals to be built into related future systems and frameworks. Credential phishing haunts our customers day in and day out in the web2 world, which is the version of the internet that most of us are familiar with and use today. It’s a profitable business for cybercriminals, even if margins are slim and there’s significant risk associated with monetizing credentials to a business (for example, through [human-operated ransomware attacks]()). Now, imagine if an attacker can – single-handedly – grab a big chunk of the nearly [2.2 trillion US dollar cryptocurrency market capitalization]() and do so with almost complete anonymity. This changes the dynamics of the game and is exactly what’s happening in the web3 world [multiple times a month](). Web3 is the decentralized world that is built on top of cryptographic security that lays the foundation of the blockchain (in contrast, web2 is the more centralized world). In web3, funds you hold in your non-custodial wallet are secured by the private key that is only known to you. Smart contracts you interact with are immutable, often open-source, and audited. How do phishing attacks happen with such a secure foundation? This is what we will explore in this blog. We will share some necessary background information, and then dive into the [Badger DAO attack](), a phishing attack that occurred in November-December 2021, during which the attacker was able to steal approximately 121 million US dollars from users. The Badger DAO attack highlights the need to build security into web3 while it is in its early stages of evolution and adoption. At a high level, we recommend that software developers increase security usability of web3. In the meantime, end users need to explicitly verify information through additional resources, such as reviewing the projects documentation and external reputation/informational web sites. ## Overview: Web3 concepts To dissect the attack, we need the necessary background. ### Blockchain The blockchain is a distributed ledger secured by cryptographic algorithms. It can be thought of as a database that shows transfers of cryptocurrency coins from one account to another. The largest blockchains by market capitalization today are Bitcoin and Ethereum. Transactions you submit to a blockchain may modify the ledger, for instance, by transferring cryptocurrency coins from your account to another account. Blockchains are public, meaning all transactions are visible publicly. Blockchain web front ends (e.g., for the Ethereum blockchain) exist to explore transactions, accounts, and smart contracts. ### Accounts and non-custodial wallets Accounts are associated with the cryptocurrency coins you may hold. On the blockchain this is represented by an entry in the ledger that transfers cryptocurrency coins from one account to your account. From a set of such entries you can derive account balances. Wallets visualize the cryptocurrency coins associated with your account. Contrary to popular belief, wallets actually do not hold your cryptocurrency coins. Cryptocurrency coins are stored on the distributed ledger, i.e., the blockchain. A wallet allows you to use its cryptographic keys to sign transactions that take action (e.g., transfer to another account) on the cryptocurrency coins associated with your account. In other words, your cryptographic keys give you access to your cryptocurrency coins. Disclose that key to a different party and your funds may be transferred without your consent. There are two types of wallets – custodial wallets and non-custodial wallets. The former are wallets associated with cryptocurrency exchanges, whereas the latter is a wallet local to your device. The big difference between the two is who has access and manages the cryptographic keys to sign transactions. Non-custodial wallets provide the owner access to the cryptographic keys, whereas custodial wallets do not. ### Smart contracts Smart contracts are code deployed on the blockchain that can hold cryptocurrency coins and transact . Smart contracts only execute when a regular account (also called externally owned account (EOA)) or another smart contract triggers its execution. ### Smart contract front ends Triggering the execution of smart contracts is not trivial. One has to (1) create a valid transaction populating its fields appropriately, (2) sign the transaction with one’s private key, and (3) submit the transaction to the blockchain. In order to increase usability, smart contract providers often create a smart contract front end so users can interact with the smart contract using familiar tools, such as a browser (with a non-custodial wallet plugin.) In the security context, one must consider the entire front-end stack, including content distribution services. ### ERC-20 tokens ERC-20 tokens are special types of cryptocurrency coins (i.e., tokens) that are implemented via an ERC-20 smart contract, essentially as a balance sheet with a set of functions that allow the transfer of these tokens from one account to another. Each ERC-20 token has its own smart contract that implements the [ERC-20 token standard](). For example, [LINK]() is a token. In order to transfer tokens from one account to another, the sender of the transaction needs to be approved to transfer those tokens. The owner of the token is automatically approved for those transactions, but the owner can also delegate approval to additional entities, like smart contracts, so those smart contracts can move funds on behalf of a user. This is required for decentralized finance (DeFi) smart contracts, such as decentralized exchanges (DEXes), as these are used to exchange tokens of different types (e.g., [LINK for USDC token on Uniswap V3 DEX]()). ### Decentralized exchange (DEX) A decentralized exchange (DEX) allows you to trade cryptocurrencies while owning your private key, thus keeping full control of your cryptocurrency. Hardware wallets can be used with DEXs, giving users a higher level of security for a user's private keys. ## Phishing attacks There are multiple types of phishing attacks in the web3 world. The technology is still nascent, and new types of attacks may emerge. Some attacks look similar to traditional credential phishing attacks observed on web2, but some are unique to web3. One aspect that the immutable and public blockchain enables is complete transparency, so an attack can be observed and studied after it occurred. It also allows assessment of the financial impact of attacks, which is challenging in traditional web2 phishing attacks. Recall that with the cryptographic keys (usually stored in a wallet), you hold the key to your cryptocurrency coins. Disclose that key to an unauthorized party and your funds may be moved without your consent. Stealing these keys is analogous to stealing credentials to web2 accounts. Web2 credentials are usually stolen by directing users to an illegitimate web site (e.g., a site posing as your bank) through a set of phishing emails. While attackers can utilize a similar tactic on web3 to get to your private key, given the current adoption, the likelihood of an email landing on the inbox of a cryptocurrency user is relatively low. Instead, different tactics can be employed to reach and trick cryptocurrency users into giving up their private key: * Monitoring social media for users reaching out to wallet software support and jumping in with direct messages spoofing support to steal one’s private key directly2 * Distributing new tokens for free to a set of accounts (i.e., “Airdrop” tokens), and then failing transactions on those tokens with an error message to redirect to a phishing website6 or a website that installs coin mining plugins that steal your credentials from your local device3 * Typosquatting and impersonating legitimate smart contract front ends4 * Impersonating wallet software and stealing private keys directly The ‘ice phishing’ technique we discuss in this post doesn’t involve stealing one’s private keys. Rather, it entails tricking a user into signing a transaction that delegates approval of the user’s tokens to the attacker. This is a common type of transaction that enables interactions with DeFi smart contracts, as those are used to interact with the user’s tokens (e.g., swaps) as shown in Figure 1. Figure 2 and 3 show what the approval can look like. In this example, we show the initial approval (step 1 in Figure 1), interface, and transaction signature requests that are needed for the Uniswap DEX to exchange USDC tokens for LINK tokens. Note that the spender in the legitimate request is [0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45]() (the Uniswap V3: Router 2). Once the approval has been granted, it permits the Uniswap V3: Router 2 smart contract to transfer USDC tokens on the user’s behalf to execute the swap (steps 3 and 4 in Figure 1). ![Diagram showing an example of a Uniswap flow](https://www.microsoft.com/security/blog/uploads/securityprod/2022/02/Fig1-Uniswap-example-flow.png)_Figure 1. Uniswap example flow_ ![Screenshot of a Uniswap approval interface, and screenshot of Approval transaction signature request.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/02/Fig2-3-Uniswap-approval-interface.png)_Figure 2. Uniswap approval interface. Figure 3. Approval transaction signature request._ In an ‘ice phishing’ attack, the attacker merely needs to modify the spender address to attacker’s address. This can be quite effective as the user interface doesn’t show all pertinent information that can indicate that the transaction has been tampered with. In the example above, a user isn’t able to tell whether the account to be authorized 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45 (shown in Figure 3) is indeed the Uniswap V3: Router 2 or an address controlled by the attacker. Once the approval transaction has been signed, submitted, and mined, the spender can access the funds. In case of an ‘ice phishing’ attack, the attacker can accumulate approvals over a period of time and then drain all victim’s wallets quickly. This is exactly what happened with the Badger DAO attack that enabled the attacker to drain millions of US dollars in November-December 2021. ### Badger DAO attack Badger is a DeFi protocol that allows one to earn interest on Bitcoin deposits; it launched on Ethereum mainnet in December 2020. Users deposit wrapped Bitcoin into vaults that earn yield through a variety of yield farming strategies. Badger currently has 978 million US dollars total volume locked (TVL). Figure 4 shows the timeline of the Badger DAO attack. Badger smart contract front-end infrastructure (in particular, its Cloudflare portion) was compromised (gaining access to a Cloudflare API key), allowing the attacker to inject malicious script into the Badger smart contract front end. This script requested users to sign transactions granting ERC-20 approvals to the attacker’s account (0x1fcdb04d0c5364fbd92c73ca8af9baa72c269107). Note that based on blockchain explorer etherscan, the attacker’s account has been active since 2018 and associated with a variety of phishing-related attacks and cryptocurrency scams (e.g., this [transaction hash]()). The script was first injected into _app.Badger.com_ on November 10, 2021, but injection was inconsistent, only targeting wallets with certain balance and modifying the script periodically. Injection stopped on December 2, 2021 at 12:31:37 AM (UTC). On November 21, 2021, the first funds were transferred by the attacker (possibly a test transaction). On December 2, 2021 at 12:48:25 AM, actual funds were drained from victims’ accounts. This draining of funds continued until 10:35:37 AM that day. Badger paused contracts (where possible) starting at 03:14:00 AM, causing some of the attacker’s transactions to fail. In the end, the attacker was able to drain 121 million US dollars from almost 200 accounts within 10 hours. ![Diagram showing the Badger DAO timeline, outlining attacker's actions, the victims' action, the Badger DAO's actions, and the Forta Agent detections.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/02/Fig4-Badger-DAO-attack-timeline.png)_Figure 4. Badger DAO attack timeline_ ### Detections using Forta The web3 stack is still nascent and bares risks for users. This ‘ice phishing’ attack was unprecedented in the amount of funds stolen. It currently ranks 6th in the [rekt leaderboard]() of most expensive crypto hacks. Note that funds drained were mostly from user wallets as opposed to Badger DAO’s smart contracts. While Badger proceeded with a postmortem and actions to secure infrastructure and unpause contracts6, attacks like these will likely continue. Fortunately, transactions on the blockchain are public, allowing the identification of these sorts of attacks as early as possible and in an automated way. Learning from the Badger DAO attack and in order to better detect similar attacks in the future, we have authored and [open-sourced]() [an agent]() on Forta, a real-time threat detection platform for smart contracts. Forta pipes blockchain transactions to the agent for analysis. Our agent monitors transactions for phishing attacks in two stages: 1. A suspicious ERC-20 approval detector that triggers when an EOA address was granted approvals to multiple ERC-20 contracts. This step of the agent essentially identifies the preparation step (token approvals) of the ‘ice phishing’ attack. 2. A suspicious ERC-20 transfer detector that triggers when an incriminated EOA address starts transferring funds. This step of the agent alerts when funds are drained from user’s wallets. Executing the detector on the blocks involved in the Badger DAO attack (block 13650638-13726863) would have created the two alerts shown below. These alerts would have been raised well before the attack was noticed manually, as shown in Figure 4. Smart contract providers are able to subscribe to these alerts and possibly integrate into automated response processes (e.g., pausing smart contracts or disabling the smart contract web front-end) via the [Forta Explorer](), [OpenZeppelin’s Defender](), or other means. The alerts provide actionable information that can quickly allow incident responders to identify and investigate attacker’s transactions. For instance, transaction 0x3cad03b779572c11c8188d9660d39ba76d5ae20ec254df89df9c79b5874d17f7 shows attacker 0x1fcdb04d0c5364fbd92c73ca8af9baa72c269107 was granted approval for bSLP token (smart contract 0x88128580acdd9c04ce47afce196875747bf2a9f6) by victim 0xc610d02270c39a0581fe0137f5e93ae5053d3c66. Alert 2 on 0x3cad03b779572c11c8188d9660d39ba76d5ae20ec254df89df9c79b5874d17f7 on Nov 20th 2021 08:59:06AM { "name": "Suspicious ERC-20 EOA Approvals", "description": "0x1fcdb04d0c5364fbd92c73ca8af9baa72c269107 was granted approvals to 2 ERC-20 contracts", "alertId": "PHISHING-SUS-ERC20-EOA-APPROVALS", "protocol": "ethereum", "severity": "High", "type": "Suspicious", "metadata": { "last_contract": "0x88128580acdd9c04ce47afce196875747bf2a9f6", "last_tx_hash": "0x3cad03b779572c11c8188d9660d39ba76d5ae20ec254df89df9c79b5874d17f7", "last_victim": "0xc610d02270c39a0581fe0137f5e93ae5053d3c66", "uniq_approval_contract_count": 2 } } Alert 2 on 0xccc9ea1cbe146e274aff202722307b1443b781af67363bf2f256e0cc39cc1d0a on Nov 21st 2021 11:32:30AM { "name": "ERC-20 Transfer by Suspicious Account", "description": "0x1fcdb04d0c5364fbd92c73ca8af9baa72c269107 transferred funds from 0x6def55d2e18486b9ddfaa075bc4e4ee0b28c1545 contract to address 0x91d65d67fc573605bcb0b5e39f9ef6e18afa1586", "alertId": "PHISHING-SUS-ERC20-EOA-TRANSFERS", "protocol": "ethereum", "severity": "Critical", "type": "Exploit", "metadata": { "last_contract": "0x6def55d2e18486b9ddfaa075bc4e4ee0b28c1545", "last_attacker_address": "0x91d65D67FC573605bCb0b5E39F9ef6E18aFA1586", "last_tx_hash": "0xccc9ea1cbe146e274aff202722307b1443b781af67363bf2f256e0cc39cc1d0a", "last_victim": "0x38b8F6af1D55CAa0676F1cbB33b344d8122535C2" } } ## Recommendations Here are some recommendations end users could follow to protect themselves against threats like the Badger DAO attack. Note that these recommendations put a lot of burden on the users; we encourage web3 projects and wallet providers to increase usability to help users perform these actions: 1. Review the smart contract you are interacting with. 2. Is the contract address correct? Unfortunately, one can’t rely on the smart contract front-end to interact with the right smart contract. One needs to check the contract address that appears in the transaction to be signed before it is submitted. This is an area where wallet providers can innovate and add a layer of security. 3. Has the smart contract been audited? Several web sites can help with that assessment, such as [defiyield](). 4. Is the contract upgradable (in other words, is it implemented as a proxy pattern) such that when bugs are uncovered, the project can deploy fixes? Etherscan’s contract tab shows whether smart contract has been implemented as a proxy. 5. Does the smart contract have incident response or emergency capabilities, like pause/ unpause? Under what conditions are these triggered? 6. What are the security characteristics of the smart contract after deployment? [CertiK Skynet]() tracks post-deployment security intelligence through on-chain monitoring. 7. Manage your crypto currencies and tokens through multiple wallets and/or periodically review and revoke token allowances. makes doing this easy. For project developers, smart contract audits are a necessary first step, but audits need to expand to the entire infrastructure and incident response processes. After deployment, monitoring (e.g., through [Forta]() or [CertiK]()) may give you the time to prevent or limit an exploit draining funds. Lastly, we recommend ensuring that all your audit and security incident response processes are documented in a dedicated section on the project’s website. The ‘ice phishing’ attack in late 2021 that we analyzed in this blog is just one example of the threats affecting the blockchain technology today. Since then, many more hacks have occurred that impacted blockchain projects and users. In this blog we identified possible ways to identify these attacks quickly and enumerated a set of security practices that project developers and users can follow. Blockchain technology is developing rapidly, and with broader adoption in the horizon, we encourage researchers to continue examining this emerging tech, sharing findings with the broader community, and helping improve security through both secure code and informed security products. _**Christian Seifert **Microsoft 365 Defender Research Team_ ### Further reading 1. [Web2 vs Web3]() 2. [Common scams and how to avoid them]() 3. [Hunting Huobi, MyEtherWallet, and Blockchain.info Scams]() 4. [Read that link carefully: Scammers scoop up misspelled cryptocurrency URLs to rob your wallet]() 5. [Update: Transaction Error Messages]() 6. [Phisher Watch: Airdrop Scams]() 7. [BadgerDAO Exploit Technical Post Mortem]() The post [‘Ice phishing’ on the blockchain]() appeared first on [Microsoft Security Blog]().

Query Builder