Around 100,000 exchange API keys belonging to users of the trading-bot service 3Commas were obtained by an attacker.
Unauthorized trades started appearing on user accounts in October 2022. On 10 December the company published an update saying it had found no evidence of a compromise of its systems. On 28 December an anonymous party published a sample of the keys and threatened to release the rest. The chief executive confirmed the data was authentic, and the company asked exchanges to revoke every connected key.
Now the mechanism, which is the reason this course exists.
The attackers did not need to withdraw anything. 3Commas says it has no access to withdraw or deposit funds from connected accounts, and the standard advice for any bot key is to leave withdrawal off.
So they did something else. Per HAPI Labs' analysis, they used victims' balances to buy thin, illiquid assets at prices they set, taking the other side of those trades themselves.
Nobody reconciled the total. ZachXBT verified $14.8M lost across 44 victims. A group of traders claimed about $22M. HAPI Labs counted $27.3M across 86 users as of 10 January 2023.
The advice was built around one question, can an attacker withdraw, and the attackers answered a different one.
Trade permission alone was sufficient, because a balance can be converted into worthless assets exactly as effectively as it can be moved away.
An API key is the highest-privilege object most people have on an exchange account, and it is the one they configure once and never look at again.
It bypasses the login
This is the property to internalise, and it is why F107-03 put an allow-list first.
Your password, your two-factor authentication, your hardware key and your session are all part of authentication: proving you are you, at the start of a session.
An API key does not participate in any of that. It is a credential presented directly to the venue's interface, and the venue acts on it. There is no login to defend, no code to enter, and no session to expire.
Which means every control you configured in F107-03 is, with respect to this key, irrelevant. F107-03's own autopsy is the 2019 Binance breach, where the attackers obtained user API keys alongside two-factor codes, and the keys were the part that did not require anybody to be tricked twice.
Four restrictions
Scope. What the key may do. Usually read, trade, and withdraw as separate switches, sometimes with more granularity.
IP allow-list. Which network addresses may present the key. This is the load-bearing one and the least used.
Expiry. Some venues support it, many do not.
Sub-account isolation. Confining a key to a portion of your holdings, where the venue supports sub-accounts.
Scope limits what a key can do. An IP restriction limits who can use it at all.
A leaked key that only works from an address the attacker does not control is inert. It does not matter what permissions it carries, because it never gets presented successfully. A 3Commas key that only worked from 3Commas's own servers would have been worth nothing to whoever held a copy.
The objection is that it is inconvenient, and the objection is true if you connect from a laptop on changing networks. It is not true for the case that actually matters, which is a bot or a script running on a server with a fixed address, and that is the case that produced the autopsy.
So the rule follows the use: a key for automation gets an IP restriction, always, because automation runs from a fixed place. A key for your own occasional use should probably not exist, because you have a login.
Why trade permission is enough
The mechanism in the autopsy is worth working through, because it is not obvious and it defeats the standard configuration.
The attacker holds a key with trade permission on your account, and separately holds a position in a token with very little liquidity. F107-02 gave you the tool: a thin book.
Setup. They own 1,000,000 units of a token that trades around $0.01, so a nominal $10,000 position that they could not sell for anything close to that, because the book cannot absorb it.
Step one. Using your account, they place buy orders for that token far above the market. Your balance of $50,000 in a liquid asset is spent buying their tokens.
Step two. They are the seller. Their limit sell orders are resting exactly where your account is buying.
Say your account buys 500,000 units at an average of $0.10:
500,000 x $0.10 = $50,000 of your balance transferred to them
What each side now holds:
You: 500,000 units of a token whose real market is around $0.01, which is a nominal $5,000 and realistically far less, because F107-02's exit argument says the book on the way out is thinner than the way in.
Them: $50,000 of a liquid asset, in their own account, already withdrawable.
Your loss: roughly $45,000 to $50,000, achieved without a single withdrawal from your account.
Two things to notice.
First, the exchange's records show your account placing normal orders. There is no unauthorized transfer to point at, and disputing it means arguing that trades your own credential authorized were not yours.
Second, and this is the general lesson: the permission model asked whether assets could leave. The attacker changed what the assets were instead. Any permission that can alter the composition of a portfolio is functionally a permission to reduce its value, and no venue's permission screen frames it that way.
The lifecycle
Create narrowly. Read-only unless trading is genuinely required. A very large share of keys exist for tracking and reporting and need nothing else, and a read-only key cannot produce the worked example.
Restrict by IP, always, for anything automated.
Record why it exists. In the F109-01 inventory: what it is for, which service holds it, and the date it should die. A key with no recorded purpose is a key nobody will ever confidently revoke.
Rotate on a schedule. Quarterly is defensible. Rotation bounds the value of a leak you have not detected, and the 3Commas users had unauthorized trades running from October and confirmation in late December.
Revoke the moment the purpose ends. This is Ronin's lesson in F109-01, and it is the step that fails, because ending a purpose is a decision and revoking is a task and nothing connects them.
Revoke immediately on any suspicion, including a service you use disclosing an incident, and without waiting for that service to confirm anything. In the autopsy the company published a no-evidence update eighteen days before confirming. A user who revoked on the reports rather than waiting for the confirmation closed that window eighteen days earlier.
Third-party services
The whole autopsy is about giving keys to a service. Sometimes there is a good reason, and the assessment is F107-04's counterparty question applied to access rather than to balance.
What is the minimum permission this actually needs? Portfolio trackers and tax tools need read-only. If a tracker asks for trade permission, that is the finding.
Where is the key stored, and how? You will usually not get a satisfying answer, which is itself the answer.
What happens if they are breached? Assume they will be, and size the grant so the outcome is survivable rather than betting they will not.
Can you restrict by IP to their servers? Some services publish their addresses. That a service does not is a real signal about how much thought has gone into this.
I disabled withdrawals on my key, so the worst case is limited.
This is the exact belief the autopsy defeated. 3Commas says it has no withdrawal access, and its leaked keys still cost their owners millions.
Disabling withdrawal removes one route. It leaves every route that changes what you own rather than where it is, and the worked example shows those are equivalent in outcome and easier to execute, because they do not trip any of the venue's withdrawal defenses.
The corrected version of the question is not can they withdraw. It is:
What is the worst outcome available to whoever holds this key, assuming they are hostile and creative?
For a trade-enabled key on a spot account, the answer is close to the full balance. For one with margin or futures access, the answer is worse than the balance, because leverage can produce a loss larger than the position.
For a read-only key the answer is a privacy exposure rather than a financial one, which is not nothing given F106-04, and is a different order of problem.
That reframing is the whole lesson, and it generalises past API keys to every grant in F109-01's map.
An API key bypasses the login rather than passing it, so your password, your two-factor authentication and your hardware key are all irrelevant to whoever holds one. Disabling withdrawal is not sufficient, because trade permission drains an account by changing what you own instead of where it is: buy a thin pair at a price the attacker sets with the attacker on the other side, and $50,000 becomes $5,000 of an illiquid token with no transfer to dispute. The load-bearing restriction is the IP allow-list, because it makes a leaked key inert regardless of scope. And ask the right question of every grant: not can they withdraw, but what is the worst outcome available to a hostile holder.