A Thorough Investigation of the Binance Hack
Those of you who follow me know that I’m the founder of HodlBot. We built an easy way to diversify your cryptocurrency portfolio across the top 20 coins by market cap. Right now, our platform works on top of Binance’s API.
So when I read that Binance had been potentially hacked for $45 million last week, I was left feeling uneasy.
Since then, the storm has blown over; Binance announced that funds are safe and they would be covering any losses.
But I still feel unsatisfied. News coverage of the incident was extremely poor, there was little information released, and rumours are spreading like wildfire.
As someone who wants Binance to succeed, I feel conflicted about writing this article. Nevertheless, I have an obligation to my users, and to the community, to investigate this issue thoroughly.
I’m going to do my best to present a well-rounded perspective on the incident and clear up rumours.
Timeline of Events
Before we dig into the details, let’s put together a brief timeline of the incident using information released by official sources.
July 3rd at 8:44 PM UTC
The price of SYS shoots up to from 0.0004 BTC to 96 BTC.
July 3rd at ~9:00 PM UTC
July 3rd ~ 11:00 PM UTC
July 4th ~ 12:00 AM UTC
July 4th ~ 4:00 AM UTC
July 4th ~ 6:00 AM UTC
Binance releases an official incident recap stating that the incident had been attributed to irregular API trading activity.
What Does Binance Mean by Irregular API Trading Activity?
To understand why API attacks often coincide with coins being pumped to ridiculous heights, we first need to understand how Binance’s API works.
For the layman, Binance’s API allows computers to programatically interact with the exchange as if they were the user themselves. To enable API access, a user first generates a set of API keys. These keys are credentials that provide permission to interact with the account.
On Binance there are 3distinct levels of API permissions:
- Read — ability to get data about holdings, trade history, and the market.
- Trade — ability to execute trades
- Withdrawal — ability to withdraw funds
By default, read & trade permissions are enabled. However, withdrawal access is not. Because withdrawal access carries a much higher risk, Binance forces users to set up IP whitelisting and 2-factor authentication beforehand.
Consequently, when attackers steal usernames & passwords or API keys, they tend not to have withdrawal permission. Under this limitation, hackers have to find a way to move funds to accounts that have withdrawal access.
Here’s how they do it:
- Before the attack, the culprits will accumulate a large quantity of a coin that has low volume and a small order book.
- Attackers will use stolen accounts to send a torrent of buy orders via the API at a ridiculously pumped price (often 10,000x the normal price).
- The attackers make a huge profit by selling the coins they previously bought.
- Attackers try to withdraw their spoils from Binance. Once it’s off the exchange and onto the blockchain, it becomes almost impossible for anyone to reverse the trades.
What the Data Tells Us
Rather than fumbling around in the dark, we can use Binance’s API to pull historical data on SYS/BTC trades and see exactly what happened.
Price Activity & Volume
There was nothing peculiar about the price of SYS until July 3rd when prices suspiciously shot up to 96 BTC.
During the same time period, there was a massive uptick in trading volume and the number of total trades.
Things get interesting when we start pulling data from
This endpoint GETs a history of completed trades. Trades that fill at the time, from the same order, with the same price will have the quantity aggregated.
Notice how everyone’s talking about the 11 SYS sold at 96 BTC (~$7 million) when they should be talking about the 13,152 SYS sold at 1.1 BTC (~USD $97 million) instead.
By plotting all aggregate trader orders on a bubble chart, we can get a better sense of scale. Every circle is an aggregate trade order. The size of each circle represents the total trading volume in USD.
Something is very, very fishy about the 13,152 SYS trade order.
Because we have the aggregate trade ID, we can use it to GET all individual trades that make up the order.
What we find is 132 separate trade orders all buying 99 SYS for 1.1 BTC each. The last buy order is 84 SYS, capping the total aggregate to 13,512. This is strangely neat.
I’ve reached out to Binance and confirmed that every single individual trade comes from only one individual account.
Therefore, $96 million in trading volume must have come from only 1–133 accounts.
That’s a lot of money per account to keep on an exchange…
Unpacking the 11 SYS buy at 96 BTC
The 11 SYS buy at 96 BTC is even stranger. There is only one trade here. This means somebody must have had a whopping 1,056 BTC ($6,694,406) on their exchange account.
At this point, the simpler explanation would be a system glitch or exploit that allowed these erroneous trades to be placed.
Comparing the data against the VIA coin pump
Let’s compare this to the VIA coin incident, an attack we know that was instigated by hackers phishing API keys.
Price Activity & Volume
Prior to March 6, VIA experienced normal trading volatility.
Then suddenly on March 7, the price exploded.
Just like SYS, the number of trades and trading volume also spiked.
While VIA’s trading activity chart and candlesticks chart looks similar to SYS, the historical trade data looks very different.
Unlike SYS/BTC where we saw a bunch of massive trade orders, VIA/BTC has a large number of accounts involved in making smaller trades. In my mind, the VIA trades are way more typical of an API phishing attack.
SYS is just weird.
Just look at these aggregate trade orders plotted on top of each other.
If the attackers used API keys to make bogus trades for SYS, I’d imagine we’d see a distribution of trading volume similar to the VIA incident.
But they’re not.
If we unpack all of the trades into individual ones and compare the distribution of trading volume between the two, it’s obvious that the SYS trades had much higher trading volume.
Did we witness an API keys phishing attack? Or did we see something else entirely?
I’ll let you the reader, make up your own mind.
Clearing up the Rumours
~7,000 BTC leaving Binance’s hot wallet
Here is the link to the transactions under scrutiny.Many people are waving this around as evidence that funds were involuntarily withdrawn from Binance’s hot wallet.
So far, Binance has not responded to any of these accusations, which has added more fuel to the fire.
Clearing up a common misconception
I thought Binance’s maximum withdraw was 50 BTC, how could 2,000 BTC leave the hot wallet?
When the output of a transaction is used as the input of another transaction, it must be spent in its entirety.
Sometimes the coin value of the output is higher than what the user wishes to pay. In this case, the client generates a new Bitcoin address and sends the difference back. This is known as change.
Binance intelligently batches a bunch of withdrawals and sends all of them out in one transaction. However, it is not uncommon for there to be large amounts of change sent back to Binance’s change address.
I used the Blockexplorer API to pull a list of transaction outputs from April 30th to July 6th. Then I sorted them by transaction output in descending order.
As you can see, there a number of large transaction outputs above 2,000 BTC. This is because change is being sent back to the return address.
I’m not saying I know for sure that the withdrawal was authorized by Binance, but high output transactions above 2,000 BTC are not out of the ordinary and is certainly not evidence of theft.
51% attack on SYS
I won’t cover this topic in much detail because the SYS dev team has released a full debrief on the situation.Long story short, they claim this incident was a strange coincidence. SYS was not hacked.
Between an update to SYS 3.0.6, many miners set the fee they were requesting to be higher than the default rate. As such, many transactions with fees below this rate were left unmined.
With fewer active miners, transactions that would normally take a minute to clear were waiting in the mempool for hours. When this happened, many transactions were lumped into a single block. This caused huge block outputs, some over 1 billion SYS, and a build-up of unconfirmed transactions
Among the unconfirmed transactions, the SYS team saw a bunch of attempted withdrawals from the richest SYS account suspected to be an exchange hot wallet. At first, the SYS team thought it was suspicious activity and alerted the exchanges. Since then, they have confirmed the transactions were not the product of an attack.
What We Think About Centralized Exchanges
In times like this, you can hear the crowd calling for change.
And I agree, decentralized exchanges are the future.
But before we completely bash centralization. We should ask ourselves:
Are we not too idealistic about decentralization and the immutability of the blockchain?
After all, centralizing power in the face of disaster is standard protocol for most organizations because it is fast and efficient.
Take Binance for instance. Binance does not process trades on the blockchain but instead records them on an internal ledger. Because they do this, they are able to roll back all malicious trades.
So far, Binance has done a great job spotting irregular trading activity early enough to take preventative action. They averted diaster not once, but twice with VIA & SYS. Should we not give them credit for it?
They take responsibility for attacks that are not their fault. They have extremely deep pockets that allow them to cover any user losses during an attack. They are even putting 10% of all transaction fees into an insurance fund to protect against future mishaps.
Compare this to mistakes that happen on the blockchain.
Remember the DAO blunder which caused $60 million ETH to be lost? What do you do? Some argued that code was law, while others wanted to roll back the mistakes. The argument was so severe that it caused a hard fork and the birth of ETH classic.
I don’t know what the answer is to all of this, but it’s definitely not that all centralized exchanges should go to hell. We’re a long ways away from being able to throw away centralized exchanges altogether.
This is what Jesse Powell, the CEO of Kraken, had to say about Vitalik’s comment that “centralized exchanges should go burn in hell as much as possible”. He echoes my thoughts well.
I can assure you that we are already burning in hell quite a bit. Not as much as possible, thankfully, but it’s far from comfortable here in the 6th circle. The heretic’s plight is an eon of dealing with regulators, banks, hackers and confused newbies.
I don’t take Vitalik’s comments personally. The dream is getting to a point where decentralized exchanges are so great that centralized exchanges no longer have any advantages. Today, that point is a very long way off, and we’ll need centralized exchanges to get there.
You have to build the bridge before you can burn it.
About the Author
Written by Anthony Xie
I’m the founder of HodlBot.
I’m a big data nerd. I like to talk about all things data, finance, and crypto. You can find me on Twitter here.
At HodlBot, we make it easy to automatically create diversified cryptocurrency portfolios.
We created HODL10, HODL20, HODL30 indices and the first ever application that allows you to create your own personalized cryptocurrency index fund.
To get started all you need is a
- Cryptocurrency Exchange Account
- $200 in any cryptocurrency
VIA & SYS Data