quick note: This transaction analysis written somewhat informally; not a lot of narrative, just wanted to get to the point for all those that want to "get to the point"
Aggregating Preliminary Information Directly From Source
Starting with the first tweet from Liquid Global:
Second Tweet (2/2) Below:
Transcribing the Addresses
Appears that 'Liquid Global' was at least polite enough to provide us with specific addresses that were compromised (or received compromised funds).
Bitcoin - 1Fx1bhbCwp5LU2gHxfRNiSHi1QSHwZLf7q
Ethereum - 0x5578840aae68682a9779623fa9e8714802b59946
Tron - TSpcue3bDfZNTP1CutrRrDxRPeEvWhuXbp
XRP - rfapBqj7rUkGju7oHTwBwhEyXgwkEM4yby
Starting With Bitcoin
Without wasting any time, we're going to go check out the Bitcoin address in question that was either used by hackers to receive stolen funds or had funds stolen from it (the tweet wasn't really clear on what role these addresses play in the grand scheme of the hack itself).
We're going to start at a fairly unorthodox location - Ernst & Young's blockchain tool.
Because their tool provides the best flat, visual look of a raw Bitcoin transaction. We don't need any cluttered views (blockchair), or overly simplistic layouts (blockchain.com).
Their tool also provides a transaction visualizer (only tracks TXs, no singling out of individual wallets / clusters like I recommended to them months ago).
Let's start by throwing in the Bitcoin address given to us by Liquid Global into the tool - 1Fx1bhbCwp5LU2gHxfRNiSHi1QSHwZLf7q.
^^ general info / stats relevant to the address (at the time of writing)
Below is the most recent incoming TX to the address:
https://explorer.blockchain.ey.com/bitcoin/address/1Fx1bhbCwp5LU2gHxfRNiSHi1QSHwZLf7q (warning, you have to sign into their website to use their tool ; its understandable if you don't want to do this - there are tons of screenshots within this analysis to compensate for that)
This transaction may look normal at first glance, but when you look closer, it quickly becomes obvious that the structure of this transaction deviates from the "norm".
For those that are confused, start by looking at the addresses on the left side of the transaction. This is where the 'inputs' are listed. For this specific TX we can see that there are six different inputs for this transaction, but they each come from the same address.
TX ID - dda75afb38c54939f9398e4b9a3117fe571ef46987e915cbd1a6d78546c6ae07
Brainstorming on the fly here, such a transaction can only be manifested by virtue of someone specifically and selectively crafting such a transaction (by hand vs. using popular wallet apps / tools for Bitcoin).
Also, it is likely that the 'sender' of funds for this TX (1F2jBn5qwMkDfWR5CH4TjqKWEwQWT3rBm6), received at least 5+ separate transactions from entirely separate sources for the specific purpose of allowing the attacker to meticulously select these inputs later whenever they determined it was appropriate to initiate a withdrawal of funds from the address.
Tossing This Transaction in the E&Y Bitcoin TX Visualizer
One of the (few) good things about E&Y's Bitcoin block explorer tool is that it allows users to "visualize" transactions. The only caveat here is that you can visualize specific transaction IDs (not autonomous wallet addresses for some reason).
Fortunately for us, the caveat mentioned above will not pose a problem in this case since we're specifically looking to find out more about this strange transaction with 5+ uniquely different inputs all coming from the same wallet address (sender).
From here, we just have to scroll up slightly and click "visualize transaction" (instructions for those that have decided to take on the chore of getting access to this tool).
Doing so takes us to the following page.
Below is another look at the screenshot above (with annotations for those that may be a little confused).
Exploring One of the Transactions Inputs
We're going to pick one of these inputs (at random), to explore since they're all coming from the same source.
If we 'click' on one of these input boxes, then the transaction visualizer will "expand" the node by showing us an additional node extending out from said 'input', pointing to a specific "transaction ID".
Below is a 'GIF' showing the literal process of node expansion with the E&Y Bitcoin transaction analysis visualizer (to help provide readers with a better way to visualize what's meant when we use words like 'expand' and 'node' in this context).
Further credit to Ernst & Young is warranted here because they include the relevant transaction information on the lefthand side of the page in an easy-to-find location (without obfuscating the visual).
Let's see what happens when we attempt to examine the transactions that are on the 'input' side of this transaction ID.
Okay, so its clear that there are a ridiculous # of inputs associated with this transaction ID.
Before moving forward, let's recap where we are right now and how we got here:
- Starting with the Bitcoin address given to us by 'Liquid'
- Looking at the most recent transaction into that address (dda75afb38c54939f9398e4b9a3117fe571ef46987e915cbd1a6d78546c6ae07), we noticed that each of the six inputs for that transaction were from the same sending address (1F2jBn5qwMkDfWR5CH4TjqKWEwQWT3rBm6)
- Looking to make sense of this anomalous transaction structure we made use of Ernst & Young's transaction visualizer
- From that point, we expanded a node attached to one of these inputs, which yielded the TX ID - 3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65
- When we attempted to expand that node to visualize the inputs associated with that transaction (which would tell us where the duplicate input addresses received their funds from), several dozen inputs popped up.
We're not screwed by any means though - we just need to utilize a different set of tools.
When it comes to Bitcoin, whenever you see / notice a transaction that has dozens of inputs / outputs, its likely that at least one of those addresses is related to another on the same side of that transaction.
This association inherent in this relationship can be mathematically linked using certain heuristics derived from the mathematical properties of blockchain itself to definitively 'link' two or more addresses together. WalletExplorer is one of the few tools publicly available that automatically perform this analysis on the backend in order to present wallet addresses within the context of their associated 'cluster' (if there is one).
What We Hope to Accomplish With 'WalletExplorer'
Our hope is to come up with some 'hits' when we enter that TX ID we were examining above (the one w a ton of inputs) in the 'walletexplorer.com', site block explorer.
Slight Hitch in Our Plans
When we attempted to enter that TX ID we extracted from the expanded node in the prior section into the search bar on 'walletexplorer.com', this message popped up in response.
Since we're performing this analysis in the immediate aftermath of the 'hack' news becoming public, this transaction ID has not yet been analyzed and indexed by 'walletexplorer'.
So are we screwed?
Hell no. There are plenty of other sites that we can accomplish this same objective. The first alternative we're going to visit is 'ethonym.com'.
What is 'Ethonym'?
Apparently this website was setup by Princeton researchers to accompany a study originally published in 2014 titled, 'btctrackr: Finding and Displaying Clusters in Bitcoin'.
Fortunately, this tool is available online (just like the 'walletexplorer' site we just visited). The current site address is 'ethonym.com'.
Below is a screenshot showing what Ethonym provides for us when we enter in our target TX ID in their search (3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65)
- At first glance, it appears that all this site does for us is provide a vanilla view of the banal details of the transaction - and this is true to an extent. But an expert researcher knows how to make lemonade out of lemons like this.
- Since there are so many inputs for this transaction, its highly unlikely that all of them were derived within the past 24 hours (which would exclude it from the indexed blockchain transactions on 'walletexplorer' at the time of writing).
- Following this logic, if we can find at least one wallet address among this transaction's 'inputs' that have a history that spans beyond the current 24-hour time window this piece is being published in,then we can plug that address into 'walletexplorer' so that we can glean cluster-based information about the transaction / hack that way.
To keep things simple, we're going to start with the very first address on the input side of the transaction (index '0', to be specific).
Target address = 1PH8nyZmwxD1xjiAvVAN2Gzh1o1tqHZ7HX
Opening up a new tab on this site for this address leads to us being shown the following.
Perfect, we guessed right on our 'first try' (among the sea of inputs we would've had to sift through otherwise). Let's see what we get when we throw this address in 'walletexplorer'.
But before we do - here's a critical question readers should have answered before moving on.
Why Are We Throwing This Address in 'WalletExplorer'?
- Originally we wanted to put this entire TX ID in walletexplorer, but we weren't able to since the transaction was confirmed on the blockchain so recently (within the past 24 hours from the time of writing; 'walletexplorer' says it needs at least 24 hours to analyze & index all new transactions & discovered addresses using the 'clustering' method).
- Rather than allow this minor obstacle to stop us dead in our tracks, we decided to analyze the inputs of the transaction to see if we can find an address that was created outside of this 24-hour bounded time limit. The logic here is that if we do find an address with a TX history that indicates its been in existence for longer than 24 hours (which we did), then we can plug this into the site to see if that address, specifically, is attached / connected to any clusters (bonus points if that cluster is actually labeled on the site).
- If we are able to definitively identify a cluster attached to that address, then we'll at least be able to pursue our first concrete lead - which would be the working theory that all of the associated addresses among that cluster are potentially associated to this act in some capacity.
- Obviously there are some characteristics the associated cluster may possess that make this conclusion a de facto non-starter. For example, if it is discovered or deduced that the cluster associated with this 'index 0' input of the 3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65 transaction is actually an exchange hot wallet, then we'd have to tentatively sideline that sweeping theory about all discovered associated addresses in the cluster potentially being equally as culpable as the address that led us to said cluster.
Evaluating WalletExplorer Results
Let's see if we get a match.
Great! Looks like we got a match (outlined below for those that didn't spot the confirmation message given to us by the site in the image above).
Before moving forward from this point, its worth noting that the two prior screenshots do not show the entirety of the transaction (inputs / outputs), involved in the funding TX that funded our index 0 address.
Rather, it isolated the corresponding constituent of the TX that funded this address (specifically by only showing the 'input' corresponding with this address within the larger TX).
If what's written above doesn't really make sense, just take a look at the 'full transaction' below.
Same screenshot above re-published below with the two relevant addresses (included in the isolated screenshot), for the reader edification.
Below are the Corresponding Cluster Address URLs for Both Addresses
- Cluster Address for the 'Index 0' Address ( 1PH8nyZmwxD1xjiAvVAN2Gzh1o1tqHZ7HX) - https://www.walletexplorer.com/wallet/f97953a42ea0e703
- Cluster Address for the Input That Funded the 'Index 0' Address (3HayLeUFQfpPXkZr1VMzF4Hh6452ShnbBF) - https://www.walletexplorer.com/wallet/0225d7ed9f8f20da
Let's evaluate the 'index 0' cluster first.
Yikes, this is the only wallet in that "cluster" (so no other addresses that could be associated with this one via heuristics ; good stealth here, I suppose).
Let's see if the same is true for the funding transaction.
As we can see (from a quick helicopter view):
- This cluster has sent a combined 100k+ transactions (108,456 specifically is the tally on 'walletexplorer'). This is an astronomical # of transactions, even for a full cluster of addresses. The only clusters that produce comparable numbers are exchange hot wallet addresses. But we can't make that blanket assumption about this cluster until we glean more information.
- There were some massive transactions that exited from this wallet toward the end of last year (2020).
Continuing from the last bullet point above, let's take a look at some of the last outgoing transactions from this cluster.
Casting Some Doubt On Our Initial 'Hot Wallet' Identity Theory
Check out the following transaction below (from the cluster TX history panel on the 'walletexplorer' site).
transaction ID - https://www.walletexplorer.com/txid/34228605363cda7d3cc0893b10053d8fd197229331bac51b53bd8e53a3cfd588
The address labeled 'Huobi-2' in the screenshot above corresponds to an address that is attached to Huobi's cluster in some way (we don't know how yet; you'll find out as you read along).
Since we know that the 'Huobi-2' label was given by 'walletexplorer' to denominate all wallets related to that exchange's Bitcoin hot wallet (#2), it is likely that the related address in question is an exchange 'deposit address' (or is at least designed to mimic the functionality of one).
We should be able to parse this out quickly without having to go through too much trouble. Let's start by isolating the transaction that includes both the target cluster address and this 'Huobi-2' cluster associated address.
The wallet recipient address (associated with the Huobi-2 cluster), is 12zfnG3nWtmGcP5XVJVXGXaEFtFLDRn2yc.
Upon observing the TX history of that address, it quickly became apparent that this address' behavior diverged significantly from what one would typically expect of a 'classic' deposit address (as we've known them to function up to this point in the blockchain sphere).
Couple Quick Points
Typically whenever there are funds sent to an exchange deposit address, those funds are swept to the hot wallet (automatically) via some script or other coded functionality (instantiated by the exchange).
The withdrawals don't match the deposits (tell tale sign).
One Big Exception to the 'Rule' Outlined Above
Bitcoin's average fee required per TX (confirmation within 1-2 hours of being propagated to the network) has been through the roof over the past few weeks and throughout 2021, in general (compared to what its been at, historically).
Thus, its not entirely unreasonable to excuse the aberrant behavior of that Huobi quasi-deposit address as the abnormal activity could just be a byproduct of the exchange (Huobi), pursuing an alternative strategy of managing Bitcoin deposit addresses to reduce the total # of transactions (since every address 'sweep' constitutes a transaction, which is a cost incurred solely by the exchange responsible for geneating said deposit address). Thus, its not unreasonable to give Huobi the benefit of the doubt that they were likely looking to save money on fees by abstaining from sweeping every input sent to the deposit address, choosing instead to allow inputs to aggregate to some extent first before sweeping (which would reduce the overall # of transactions the exchange must initiate; ultimately saving them a considerable amount of money during times when the average fee was north of $20-30 per transaction).
Proffering Additional Evidence in Support of This High Fee Claim
If you've been following blockchain this year (at all), then you likely know the information above about Bitcoin's exorbitant fees at one point is an obvious truth. But for newcomers to this space (or those that were somehow blissfully unaware of being forced to pay $50+ to send a simple Bitcoin transaction from point A to B), this phenomenon may be "news".
Hopefully this isn't the case (since this means that person is likely very behind on what's going on). But just in case, this following section provides evidence that substantiates the claim that Bitcoin's fees had climbed to regions never before seen (from inception to present).
The chart above (credit: BitcoinVisuals), provides historical data for the average fee (per transaction) for Bitcoin on May 21st, 2021. As we can see, on that day, the average cleanly surpassed the $20 mark that day.
However, this mark pales in comparison to the record set just a month prior (April 2021).
The chart above ('BitcoinVisuals'), shows that the average fee (USD) / TX surpassed $60 at its height in April.
With all that being said, this fee theory could be entirely incorrect. Perhaps the deposit address is malicious. Since we cannot make a definitive assessment of that address, we'll leave it alone.
Returning to Our Recently Identified Cluster
Remember when we were first examining the transaction history of this cluster?
We observed large chunks of Bitcoin being evacuated with haste at the end of last year (*with most of the EOY action taking place on December 28th, 2020*).
Let's check out where those outgoing transactions were headed to.
The screenshot above shows the recipient
address cluster for these massive transactions was the same for each TX (this cluster was given the generic label, '016c0783fc' by 'walletexplorer'; there is no significance to these numbers).
Let's see what we find when we track this cluster (recipient). Below is a screenshot of that recipient cluster's TX history.
Once again, all of the most recent outgoing transactions from this cluster are all directed toward one particular recipient cluster (as was the case with the transactions that led us here).
Following this tertiary cluster of interest brings us here:
Let's check out the top wallets in this cluster
We're going to see if we can glean any greater information about this cluster by examining one of the top, active addresses (the most active address was selected here for time's sake).
That address = 3Q99aAkdz9HVWaypdk36zy4gE6MyG6TMRE
Dissecting Address 3Q99aAkdz9HVWaypdk36zy4gE6MyG6TMRE
Sparing some time here, I'm going to skip over some of the intermediate banal details and bring our attentions to one specific transaction initiated by this address (send), worthy of further examination.
That TX ID = 07555ccbc50d3c4c1dadf8f3a2b5c4a9222ceaeccb6ddc05360d1da464811efd.
Below is a visualization of this transaction (using the E&Y BTC TX visualizer tool we introduced at the beginning of this report).
Specifically, attention needs to be paid to the 1P4JZb3Rxr9tgqwwdZ22DdAMV1nS1bVmUr address (index '1' on the 'outputs' side of the TX)
Wondering Why? Good Question (Let's Find Out Now)
Let's bring this transaction back to 'walletexplorer' briefly, so we can isolate the TX details in a less visually obfuscated environment.
Outgoing funds from that '1P4dUV' address we just identified, lead here.
Scrolling down, we can see this address was an input for a transaction whose recipient (output) is Binance's hot wallet address [other address listed as an output here is either the change address or intended]; according to 'walletexplorer', the '3'-prefix address is the change address, and Binance's hot wallet is the intended recipient.
Its extremely important to note that any incoming funds going to Binance's hot address can be assumed to be Binance-controlled (unless there exists a clan of Binance sympathizers that enjoy making spontaneous, anonymous donations to the exchange).
Where Have We Seen That Wallet Address Before?
Staying on track here - let's recall the original transaction ID that plunged us down this rabbit hole to begin with.
That TX ID was - 3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65
Brief Recap (Again)
- We started with the Bitcoin address given to us by 'Liquid' in their tweet announcing they had been compromised.
- Examining the most recent incoming TX for that address (dda75afb38c54939f9398e4b9a3117fe571ef46987e915cbd1a6d78546c6ae07), we noticed that each of the six inputs for that transaction were from the same sending address (1F2jBn5qwMkDfWR5CH4TjqKWEwQWT3rBm6)
- Looking to make sense of this anomalous transaction structure we made use of Ernst & Young's transaction visualizer
- From that point, we expanded a node attached to one of that TX's inputs, which yielded the TX ID - 3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65
- When we attempted to expand the node assigned to that specific TX ID to visualize the inputs associated with that transaction, our transaction visualizer filled up with several dozen inputs (undermining the effectiveness of the tool at that point)
- From there, we decided to visit the website, 'ethonym.com' (to analyze this transaction ID), after our initial search on 'walletexplorer' proved futile (TX ID age was not >24 hours at that point).
Below is a screenshot of the TX details for 3c65862447b861b6a808efbcf591e4b6f412386e9aa9471c2bf5aa80430f7b65 from Ethonym.
Wait a minute...there's that address again (the Binance pseudo-deposit address).
Quick FAQ on Exchange Deposit Addresses
- It is known that deposit addresses are under the power / authority of exchanges. However, exchanges are typically not considered to be culpable whenever illicit funds are "covertly" sent to a given exchange under the assumption that no exchange could possibly police all of the transactions it receives (even though Binance has went out of its way on multiple occasions to suggest that it can do just that due to recently obtained, enhanced compliance tools / capabilities or via a new relationship the exchange established with a firm in possession of these supposed capabilities).
- Everything outlined in #1 becomes null and void when a deposit address is seen performing any action outside of the normal sweep of funds to the exchange's hot wallet (or some other designated, static address).
- What compounds Binance's guilt here is that this pseudo-deposit address was not only seen executing transactions that defy the possibility it was ever legitimately generated for an assumed customer. The transaction captured in the screenshot above shows that address as one of the inputs to a transaction that transfers funds to the wallet address that ultimately sent funds to the alleged hack address (listed publicly by 'Liquid').
- This pseudo Binance address was an input in the transaction above post-compromise, which makes its inclusion as an input here even more suspect (borderline flagrant in the author's honest, uncensored opinion).
The author of this research is eagerly awaiting Binance's explanation for why an address which appears to be a run-of-the-mill deposit address is also seen as an input to a transaction where funds are sent directly to an address that then sent those funds, in turn, to the address that 'Liquid' identified as "compromised" in their tweet announcement circa midnight August 19th (EST; GMT-4).
There are several other suspicious TX IDs attached to addresses with damning transaction histories / wallet associations that strongly implicate Binance (definitively) as a complicit actor (or antagonist / provocateur) of the Liquid Global exchange hack.
For the sake of brevity, those additional artifacts were not included in this analysis (since one egregious link is all that's needed to prove complicity at the very least). However, if this decision ends up breeding skepticism among this report's audience, the author has no qualms satiating demands for additional published proof linked to Binance.
Ultimately, based on what we excavated from the blokchain in this analysis, we can deduce:
A) Binance is either involved directly as an accomplice or enabler / facilitator of the Liquid Global exchange hack
B) Binance is serving as the laundromat for this 'hack' (which, frankly, is the most benign conclusion one could draw from the evidence we uncovered within this report).
Again, to reiterate - if Binance or any other related / interested entity (entities) feel this report's conclusion somehow remains unsubstantiated, the author will provide additional comprehensive evidence (by showcasing additional conflicting examples that some may argue could be more detrimental to whatever plausible deniability Binance has left at this point).
With that said, please remain cognizant of the fact that there's a stark difference between having a legitimate gripe with material facts presented within this report and disagreeing / disputing this report's conclusion on the basis of unrelated, subjective beliefs about what Binance is / is not capable of or what type of behavior you deduce their "true motivations" or incentives / deterrents should elicit.
Such subjective, indisputable projections of reality undermine the ironic benefit blockchain provides for situations like this - which is an objective, mathematical detached outline of facts gleaned from a network that's able to function without requiring any 3rd-party, generalized consensus, or "popular vote" construction to derive a cryptographically secure version of the blockchain accepted by the network by using an objective measure like 'Proof of Work' as a benchmark each individual node must use to appraise all gossiped, competing versions of the blockchain (if there are any), that they receive in order to arrive at an independent, but predictable conclusion about which one is the "true" Bitcoin blockchain - making the process inherently (trustless) and also impossible in any practical sense to modify retroactively.