Forta’s network of agents monitoring for suspicious transactions and state changes on the blockchain are increasingly important to the health of the ecosystem, however if these agents are to be maximally beneficial, their alerts must be accurate and relevant. Here I examine the alerts from the Ice Phishing Detection 2.0 agent, and particularly the set of addresses that appear in High severity alerts (suspected exploits - see documentation), to determine whether we can define a heuristic to better identify addresses engaged in ice phishing. I also look at the destination of stolen tokens - if this type of monitoring is to be fully taken advantage of, central institutions like OpenSea and Rarible should be monitoring for and blacklisting the sale of stolen tokens. In the context of the Tornado Cash sanctions, it seems increasingly likely that decentralized exchanges will be held accountable for receipt and “laundering” of stolen tokens.
Ice phishing has been growing in prominence since it was identified as the attack vector in the BadgerDAO hack. Additionally, while anyone can build agents on Forta’s network, in this case Microsoft’s Threat Intelligence team contributed to developing ice phishing detection. This increased focus from professional security researchers should mean that Forta’s detection is effective, with minimal false positives. The goal of this analysis is to examine high confidence alerts, to build our understanding of attacker behaviors both during and post exploitation.
This analysis is based on the alert output of the Forta Ice Phishing Detection 2.0 agent, obtained through their GraphQL API, scraped label data from Etherscan and Chainabuse, as well as transactions and event transfer data from Dune.
There is approximately a month’s worth of alert data available from Forta for this bot (15/08/2022 - 16/09/2022), so this forms our sample of possible ice phishing addresses. Future research could include alerts from the 1.0 version of this agent.
I have focused my analysis on Ethereum, in part because the majority of High severity alerts occur on that chain, but also to narrow the lens of this analysis and gain better insights into actor-specific behaviors.
Because the alerted addresses made a very small number of ERC-1155 transactions, I’ve ignored them here. The different transfer methods could be an interesting area of research in the future, but we will need additional data.
A small number of addresses appear to be responsible for the majority of activity detected by the Forta agent, suggesting a heuristic may be suitable to tracking their activity, and potentially preventing them from monetizing stolen assets.
There does appear to be a heuristic relevant to ice phishing exploiters with regards to their ERC-20 activity. Additional analysis is needed to identify a pattern in the observed ERC-721 phishing specific enough to distinguish attackers from traders.
The majority of ERC-721s stolen by these addresses appear to be being sold on OpenSea. By subscribing to Forta alerts, and implementing basic blockchain analysis, OpenSea could degrade the ability of exploiters to cash out these relatively illiquid assets.
The dataset of alerts is skewed towards a relatively small number of addresses. There are 1,270 High severity alerts on Ethereum, and only 97 unique attacker addresses. The top three addresses in terms of alert count are responsible for 619 alerts.
Address: Alert:
0x2aAa484D2a19e0B3B84d72280558e4D45beB6264 397
0xC28d5d922eB85c51b114f35242216Ae792f29F16 116
0x3A289C8c1c27d6FEAE33fB158f90abdbfea24397 106
0xf8238a3dd9a67b8419412eDE613A06D73Ffc2D93 39
0x9CeF2D0Ac483fb342dE51460949dfC6A139c398D 36
0x98A89ea045d8EC5Cf38Ffc2acD1774baB5f67b36 23
0xC1A0C058d417496e5ad26702e016d9f9dA00614E 22
0x6fe2eE963643Ac7E480aacaFEfddb3683E38fcf9 22
0xCFe3B948E8Bd94d4F22b900A88825Fc1E6695956 21
0xB66bD00923c7e9C7D368A79004Be27E19F241275 20
There are no obvious false positives in this dataset - 22 addresses have previously been identified as involved in phishing, either on Etherscan or Chainabuse, but none are labeled as any kind of service or other legitimate actor. However, this does not mean there are no false positives.
If we extend this to all Ethereum alerts regardless of severity, we can see that for 19,196 alerts, there are only 3,410 unique attacker addresses. However, labeling data from Etherscan does confirm a higher number of false positives.
I’ve broken the activity down by token type, because I expect the fundamental differences between ERC-20s and ERC-721s will affect the activity we see. Most ERC-20s are highly liquid, and are easily swapped for stablecoins or Ether on most decentralized exchanges, while ERC-721s should be more difficult to monetize. At the very least turning them into more liquid assets will require more than a swap on a DEX.
When we look at some summary statistics (dashboard available here) a few things stand out. The transaction activity is skewed towards a small number of phishing addresses, which is not unexpected given what we see in the alert data. It does confirm that there are probably a small number of addresses in this dataset we can isolate to better understand how ice phishers behave.
The above graphs show that the most active addresses in terms of incoming transactions (order of addresses is the same in both graphs) have the fewest incoming counterparties, i.e. unique addresses sending them transactions.
When we look at these addresses in more detail, we see something interesting. Both receive a single non-zero value transfer of an ERC-20 token, before receiving many zero value transfers of the same ERC-20 token. Interestingly the most active address 0x2aaa4… sends USDT to the second most active address 0x3a289…
When we filter transaction data for zero value transfers on Dune, we can see that this pattern is primarily exhibited by these two addresses, however there are three other addresses with multiple zero value transfers, two of which conform to this pattern of a non-zero value transfer followed by multiple zero value transfers from the same address.
Another typically interesting feature for identifying patterns in transactions is gas fees paid by an address. Looking at some summary statistics for the alerted addresses, we can see that addresses making these zero value transfers also appear to have low average gas paid with low standard deviation.
Small number of counterparties
Large number of incoming txs
Multiple zero value transfer events
Low average gas fee
We can see that again the activity is skewed towards a relatively small number of suspected phishing addresses. Interestingly, the top offenders in each category (ERC-20 & ERC-721) are not the same, perhaps suggesting the exploiters are focusing on one category of token, or it could just be that they are using different addresses for different phishing campaigns.
An interesting difference here relative to what we see with ERC-20 activity is that transaction count and victim count seem to be positively correlated.
Examining the transaction activity, these addresses don’t seem to have many immediately identifiable distinguishing characteristics. We can be relatively confident the most active addresses here are illicit, because they are forwarding ERC-721s to addresses already labelled as phishing on Etherscan (Fake_Phishing6169 and Fake_Phishing6231). The difficulty is distinguishing these phishing addresses from any other highly active NFT trader based on their transaction activity.
One possibility I explored was that ice phishers would be interested in emptying their victims wallets, the result being transfers from victims’ addresses of a diverse array of ERC-721s from different projects to the phishing addresses. However, when we test that hypothesis against our dataset, we see that most addresses (including those we’ve already seen linked to illicit activity) cluster in a space representing lower numbers of projects and tokens. This probably isn’t terribly surprising considering we wouldn’t expect most users to have exposure to a huge number of NFT projects.
Another interesting feature to explore would be time-in-wallet - on average how long after receiving an ERC-721 does an ice phishing address transfer/sell that token? In general this area needs additional exploration, and I was unable to identify a set of rules specific enough to identify ice phishing addresses without introducing a high rate of false positives.
We already identified that the top two recipients of ERC-721s from our set of 97 phishing addresses alerted on by the Forta agent are labeled by Etherscan as Fake_Phishing6169 and Fake_Phishing6231. So what are these addresses doing with the presumably stolen NFTs? A quick check on Etherscan shows that they are primarily selling these tokens on OpenSea, transacting with the Seaport 1.1 contract.
Implementing Forta monitoring to alert on transactions with suspected phishing addresses could allow OpenSea to reduce the number of stolen NFTs sold on their platform. It’s dominance in the space of NFT trading suggests it will continue to be used to monetize ice phishing and other NFT-related phishing and scams in the absence of increased deterrence and detection.
Heuristic Implementation - Implement the identified heuristic across a larger segment of blockchain data (the last year?) to determine how many additional addresses it detects, and to test whether it produces an acceptable false positive rate.
Forta Ice Phishing Bot 2.0 (six months later…) - We should produce better results if we conduct this analysis over a dataset of alerts spanning several months. A single month leaves us open to overfitting our heuristic (a handful of addresses produced the majority of alerts).
Unsupervised Learning - Dimensionality reduction and clustering of alerts could provide useful insights into distinguishing true positives from false positives, and build confidence in the alerts produced by the Forta agent.
EDA and QA for Forta agents - Although many Forta agents are monitoring for state changes or other relatively straightforward onchain activity, there are an increasing number of agents attempting to identify and alert on more complex behaviors. The ice phishing bot is one - there are also several attempting to identify money laundering and exploit preparation. In these cases, exploring the alerts they produce, and building iteratively on their detection logic could provide real value to the broader ecosystem through more concise and accurate alerting.
https://dune.com/tf0rs_/ice-phishing-gas-consumption