9 January 2024. Someone takes control of the US Securities and Exchange Commission's X account and posts that spot bitcoin ETFs have been approved. Bitcoin rises more than $1,000. The SEC regains the account, corrects the record, and bitcoin falls more than $2,000.
The method was a SIM swap. The attacker convinced a carrier to move the phone number attached to the account onto a SIM they controlled, then used that number to reset the password.
Two steps. That was the entire attack, because multi-factor authentication had been disabled on the account for the previous six months. Disabled at the SEC's own request, because of problems accessing it.
The control was not defeated. It was switched off, on purpose, by the owner, for convenience, and never switched back on.
That is the shape of nearly every personal opsec failure in this course. Not an attacker who beat a control. A control that was not there, because six months earlier it was annoying and somebody made a reasonable-sounding trade that nobody ever revisited.
Opsec sounds like a discipline for people with adversaries. It is really just the practice of knowing what your security actually rests on, as opposed to what you assume it rests on.
Most people are wrong about this in the same specific way, and the SEC was wrong in exactly that way at institutional scale.
Follow your recovery chain to the root
Ask what protects your exchange account and the answer is usually "a strong password and 2FA."
Now ask a different question. If I lost that password right now, how would I get back in?
Probably: a reset link to your email. And if you lost access to your email? Probably: a code to your phone. And your phone number? A carrier account, protected by a PIN you set years ago, at a company whose retail staff can override it.
That is your real security model. Not the strong password. The chain.
Write out the chain for one account holding real value. A worked example:
- Exchange account, reset by
- Email inbox, reset by
- Phone number, controlled by
- Carrier account, reset by
- A call centre, using a PIN and some personal details
Five links. Now apply the rule that governs any chain: its strength is the weakest link, not the average and not the strongest.
The password may be 20 random characters, which is unbreakable in any practical sense. It contributes nothing, because the attacker never touches it. They enter at link five, which is defended by a call centre employee who is measured on call resolution time.
Now count how many separate accounts terminate at that same root. For most people the phone number is the recovery path for the email, and the email is the recovery path for every exchange, every custodian, and every service holding identity documents. Say that is 8 accounts:
One compromised phone number resolves to 8 account takeovers, sequentially, with no additional attacker effort per account.
That is the number that should change your behaviour. Not the strength of any one credential. The fan-out from the root.
Do this for real, on paper, for your highest-value account. Most people discover that a phone number they have not thought about in years is the thing standing between an attacker and everything.
Fixing the root
Get the phone number out of the chain. Wherever a service lets you remove SMS as a recovery method, remove it. This is the single highest-value action in this lesson and it is usually four clicks.
Rank your factors properly.
- Hardware security key. A physical device that must be present. Resistant to phishing in a way nothing else on this list is, because the key checks the domain itself and will not respond to a lookalike.
- Authenticator app, with the backup codes printed and stored offline. Good. Vulnerable to being typed into a convincing fake page, which is the gap the hardware key closes.
- Email. Acceptable only if the email itself is defended at level 1 or 2.
- SMS. Last, and for a specific reason worth internalising.
It is presented as one and it does not behave like one, because on most services SMS is simultaneously a recovery path.
A genuine second factor means an attacker with your password still cannot get in. A recovery path means an attacker with the factor does not need your password at all. When the same channel does both jobs, it is not adding a factor. It is adding a bypass around everything else.
That is the SEC. The attacker never learned a password. They took the number and reset.
Lock the carrier account with a port-out PIN or whatever the strongest equivalent is where you are, understanding that this raises the cost rather than closing the door. Several documented SIM swaps ran through bribed or complicit carrier staff, which no customer-side setting prevents. This is exactly why the real fix is removing the number from the chain rather than hardening it.
Use a dedicated email for financial accounts. Not the one on your public profiles, not the one on data broker lists, not the one in fifteen breach corpora. An address an attacker cannot easily connect to you removes you from most automated target lists before any of this matters.
Devices have roles
The second half of opsec is arranging things so that a compromise stays a nuisance instead of becoming a loss.
The failure shape is a single machine that browses everything, installs everything, and also holds keys. One malicious extension, one infostealer in a downloaded file, one dependency in a project, and the compromise and the funds are in the same place.
Separate by role.
- The machine you browse, download, and experiment on is assumed dirty. Treat it as though it already is.
- Signing happens on hardware, where the private key never touches the general-purpose machine even when that machine is compromised. This is the entire argument for a hardware wallet and F104 builds it out.
- If you must run a software wallet with real value, it deserves its own user account at minimum, and its own machine if the value justifies it.
Then the ongoing hygiene, which is unglamorous and does most of the work: audit browser extensions and remove the ones you no longer use, because extensions change hands and an abandoned one is an update away from being hostile. Keep the signing device's firmware current. Do not install anything from a link, ever, including things that appear to come from a hiring process.
Where the seed leaks
Four places, and they account for most self-inflicted losses.
A photo in the camera roll. It syncs. It is in the cloud within seconds and it is in whatever backup you have forgotten about. Anyone reaching that account reaches the seed.
A cloud-synced note. Same failure with an extra step. It feels more deliberate, which is why people trust it more.
A password manager vault. This is the one people argue about, so here is the reasoning rather than the rule. Password managers are good, and you should use one for passwords. The LastPass breach in F106-05 exposed roughly 30 million encrypted vaults, and vaults with weak master passwords could be cracked offline at leisure over the following years. A leaked password is reversible: you change it. A leaked seed is not: those funds are gone the moment the vault is opened, which may be three years after a breach you already forgot about. Same container, different reversibility.
A message you sent to yourself. In any app, on any platform, including a draft email. It is a file on somebody's server.
The rule underneath all four is one sentence. The seed never becomes a file. Paper, metal, split shares in F110-03. Never typed into anything that has a network connection, which includes the one you are reading this on.
I use a very strong master password, so a breached vault is not a problem for me.
Partly true and it does not survive the reversibility argument.
A strong master password does mean offline cracking is impractical, and that is worth having. But the exposure lasts as long as the encrypted blob exists, which is forever, against attackers whose capability improves the whole time. You are betting that a specific secret stays uncrackable over decades while the attacker keeps the file.
That bet is fine for a password, because you can change a password at any point and the bet resets. You cannot change a seed phrase without moving every asset it controls, and the LastPass victims did not learn there was a problem until funds started moving years later.
The asymmetry is not about how good your password is. It is that one failure mode has an undo and the other does not.
The audit, which takes an hour
Do this once, properly, and then annually.
- Write out the recovery chain for your three highest-value accounts, all the way to the root.
- Remove SMS recovery everywhere it is optional.
- Move your strongest account to a hardware key, and store the backup codes offline.
- Create a dedicated email for financial accounts and migrate those accounts to it.
- Lock the carrier account.
- Search your own devices for your seed: camera roll, notes, password manager, sent messages, drafts. Destroy what you find and treat the seed as exposed if it was ever in any of them.
- List browser extensions and remove everything not actively used.
The last one takes four minutes and is the one people skip.
Your funds are held by whatever sits at the root of your recovery chain, which is usually a phone number nobody has thought about in years, and the fan-out from that root is the number that should worry you rather than the strength of any single password. Get the phone number out of the chain, rank factors with hardware keys first and SMS last, keep a dedicated financial email, and separate the machine you browse on from the thing that signs. The seed never becomes a file, because a leaked password is reversible and a leaked seed is not. And notice the shape of the autopsy: the control was not beaten, it was switched off six months earlier for convenience.