Minimum Viable OPSEC

Introduction

Recently, it’s become apparent to me once more just how poor the state of operational security in the blockchain industry is. I want to say it’s surprising, but it’s really not at all, that developers are plagued by these poor practices as well. This has disastrous consequences for end users and even their own projects. A couple of examples include the biggest crypto hack of all time back in 2022 with $624M being lost. A more recent example is the WazirX hack from July this year with $235M lost. In an environment as harsh as this, where the average dev is being targeted by the best cybercriminals of a nation at all times, we need to be better.

With massive consequences like this, developers should take their OPSEC seriously. However, most don’t. Why? None of the developer education out there covers this topic. It’s only grizzled veterans that eventually land upon this information and sometimes when it’s too late. The little that does is either complicated or really long (due to nested, mandatory linked articles) and skipped over as a result.

Thus, I present yet another guide… we’re keeping things to the bare minimum needed to remain reasonably secure in this harsh environment. Please note that this is restricted to the operational security of your social media accounts, private keys, and machine. Maintaining anonymity or pseudonymity is a non-goal of this guide. Please see the Hitchhiker’s Guide to Online Anonymity for that.

It also needs to be noted that this is only individual due diligence. It is only strong if your colleagues are also following similar principles.

There are additional factors to be considered when applying OPSEC to an organization, especially given internal tooling may not be the same. If you’d like help designing convenient policies and beefing up your organization’s OPSEC, feel free to contact us to schedule a consultation.

Despite my intro, this guide is also suitable for non-devs. Instead of bombarding you with links to tools and resources, we’ve focused on giving explanations geared towards accessibility to everyone. However, where required, you will have to spend some time learning some skills.

Certain information will be repeated across different sections. Take it to heart. This isn’t intentional but think of it as spaced repetition.

Additionally, some of the material herein is terse in the interest of not making this too long. This is meant as an introduction. Readers are recommended to go beyond the depths of this guide and do their own guided research on topics given here to solidify understanding.

Securing your machine

Secure password setup and management

Let’s begin with anti-patterns for passwords. They will be explained later on in the guide:

• Generating passwords with only the default password policy on most sites
• Using less than 128 bits of entropy for master passwords such as for your wallets and password manager
• Generating non-diceware passwords
• Not relying on absolutely random sources like a word list for a diceware phrase password
• Not using a dedicated password manager
• Storing passwords in your browser. You know that little “Save password for this site?” feature? Avoid it. Instead use a dedicated password manager, the attack surface for them is much less than web browsers.
• Reusing passwords

With that out of the way, let’s move on to secure password generation. This entire following section can be summarized with the below xkcd comic.

Given just how critical this step is, we will be covering this first. You are highly encouraged not to skip this section.

Passwords are typically generated with “something memorable but not easy to crack”, then mangled and padded (i.e., 50m3s3cUr3_p455w0rd, somesecure_password69). Recommendations are lines from songs, relatives’ and pets’ names plus birthdays in accordance with most sites’ compliance of a mix of upper and lowercase letters, numbers and characters, et cetera.

These have all been cracked. Don’t believe me? Let’s take a short detour to Hashmob.

Here are very short extracts from the hashes-org found list from 2021. The document is very large so just these will have to do. You can sate your curiosity by looking at Hashmob’s word lists.

These passwords are cracked using techniques like dictionary attacks specifically rainbow tables and by brute-force attacks. If you are technical, please look at the hashcat wiki for more information.

Use of esoteric word(s) like “inveigled” or “vacillant” doesn’t make your password secure either. Wikipedia and by extension Wiktionary databases, classics books, and social media (yes, “sigmarizzler492” is not safe either) are used to seed attacks in modern techniques.

Ditch what you know about secure passwords. When it comes to password strength, entropy is king. This is a fancy term for randomness of data, measured in bits.

Let’s take a coin toss as an example. You’d only have to guess twice to cover all possible results. The entropy of this would be $\log_2(2)$ where 2 is the number of outcomes giving us 1 bit. Reversing this gives us the number of possible outcomes.

Fun fact: The entropy of shuffling a deck of cards is about 226 bits meaning there are $52!$ (52 factorial) possible outcomes. 128 bits is the minimum strength for modern encryption schemes. For scale, the number of atoms in the universe is estimated at 272 bits.

Password strength is the product of its length and entropy per symbol used, i.e., $\text{Strength} = \text{Entropy} \times \text{Length}$. Symbol here could define a single character, word, number, or emoji. 128 bits is the minimum strength for modern encryption schemes so this should be safe to use.

The entropy per symbol depends on how large the set it belongs to is. A set of numbers 0-9 for example has 3.322 bits per symbol so you’d need a password of length ~41 to reach 128 bits of password strength. Increased set sizes (i.e., ASCII or Unicode) result in smaller password lengths.

Most people have a tough time trying to recall symbols or 41 numbers. Memorizing a phrase is much easier as you can mentally associate between them. Thus we have random passwords that are easy to remember but with a high enough entropy that they are nearly impossible to crack.

This method is called diceware since originally you manually rolled five dice with the resulting 5-digit number corresponding to a single word in a wordlist. Nowadays, nearly all password managers come with diceware functionality.

Note: These phrases have to be random. Remember our earlier comments on Wikipedia and social media used to seed attacks? Turns out human psychology is predictable. Through a little elicitation (fancy term for getting to know you through innocuous conversation) even more information could be extracted to seed attacks (i.e., your mother’s maiden name, where you grew up, your favorite show, character, etc.).

It doesn’t matter what you use for your password (passphrase is more accurate here), as long it has enough bits for your risk appetite.

A shared WiFi password could be 80 bits. Sensitive secrets like a wallet password or the master key to a password manager should never be less than 128 bits.

Password managers

Phrases are much easier to remember than 10 esoteric characters while maintaining equivalent security. However, remembering more than one quickly becomes a difficult task.

You can’t reuse passwords to solve this problem as OPSEC failure, a phish, or some other data leak on a site with a shared password will lead to all of your accounts being broken into.

Some sites store their customers’ password data unencrypted or plaintext as it were. RockYou was one of them and its data breach in 2009 yielded a password database that is still used in seeding attacks today.

Another, more recent and scary incident was the breach of a data broker and background check company that leaked what’s estimated to be about 3 billion lines of data, including US social security numbers, phone numbers, email addresses, past and current physical addresses, and full names. It affected mainly US citizens and some from Canada and the UK. Worse still, it turns out the company had an official mirror where this data was published in plaintext.

You can’t save passwords in browsers either. They have too wide of an attack surface and are the first to be exposed and targeted by malicious code.

That leaves us with password managers.

Their features include:

• Sync across your devices
• Password auto-fill with browser extensions
• Encrypted password databases with modern schemes like AES256 bit
• In-built diceware password generators with configurable desired entropy and character sets like ASCII, extended ASCII, etc.

Now, there are many options for a password manager. We’ll list some popular ones below.

Author’s note: I keep reading it as BitteWarten. :(

KeePass has a myriad number of forks like KeePassXC, which is open source. We will be covering KeePassXC. BitWarden (open source) is also recommended.

I prefer locally stored options because of incidents like the LastPass breach. You never know when a company will go belly up and take your data with it. That aside, both LastPass and 1password are not open source. If you ask any security professional, they will tell you how bad this is for a plethora of reasons. A main reason is it makes it a lot harder for white hats to review the code and submit goodwill fix recommendations.

Local options mean we’ll have to handle sync and backups ourselves. Losing our database is horrible for countless reasons, we can’t skip this step which is covered later.

Wallet security

I will assume you’re using MetaMask in which case the default options are secure enough. Just make sure to backup your secret recovery phrase in a safe place. Written on acid-free (for long-term storage), laminated paper in a fire-proof lockbox with a backup in the bank will do. You may also keep it in your password manager assuming it is securely setup with a strong master password.

If using with desktop, your wallet application should be stored on a machine that is not used for entertainment or communications and if possible, disconnected from the internet when not signing transactions to minimize the chance of you getting phished or installing malware.

For a mobile device, you should be reasonably safe if you stick to official sources for installing applications and follow the usual procedures to keep safe from phishing.

Most people recommend that you stick to mobile and hardware wallets to sign transactions. This is because most drainer sites are usually janky on mobile.

Note that hardware wallets aren’t as secure as marketed:

• The small screens could obfuscate crucial information about the transactions you’re signing.
• You still need a secure computer anyway as custom malware can be built to infect any hardware wallets upon connection for tx signing.
• They can be backdoored and aren’t invulnerable to “EvilMaid” attacks despite claims otherwise by the Ledger team.
• If stolen, a sophisticated and motivated hacker can still recover your crypto without knowledge of your PIN or private key.

Be sure to revoke any approvals immediately after use. Under no circumstances should you leave unlimited approvals active. Use https://revoke.cash/ if your wallet doesn’t have in-built approval revoking capabilities.

Private keys and secrets

Only add private keys to .env files when ready for mainnet deployment. Use dummy keys in all other cases. Remove them from the file immediately after.

Always ensure your .env file is added to .gitignore so it’s never pushed to your repo.

Apply the principle of least privilege for GitHub access tokens. Treat tokens with elevated access similar to your private keys.

Restrict OAuth access for external apps.

Phishing, social engineering, compromise and what to do about it

We’ll start with the basic best practices and say more later.

• Don’t click any suspicious links.
• Hover over embedded links like this with your mouse to preview where they’ll take you prior to clicking. On mobile you can do this by tapping and holding the link.
• Do not download files from untrusted sources.
• Do not RUN or OPEN files from untrusted sources.
• Review email addresses and website domain names thoroughly, cross-checking if they are legitimate.
• Do not plug in the “free USB drives” you got at a conference or any random USBs for that matter. Even if you find it on your desk. Ask first.
• Even something as simple as a charger. Bring your own. The importance cannot be understated. (S/O Hak5’s O.MG cable! See their rubber ducky for the USB drive version)
• If you absolutely MUST run anything from untrusted sources, do so in an isolated virtual machine environment sharing nothing with your main computer. Read more on this in the virtualization and segmentation section.
• Do not leave your computer unattended at a hackerhouse, conference or whatever.
• If possible, bring a device different from your work computer so nothing sensitive is affected in case of compromise.

Alright so, as is commonly known, humans are the weakest link in security especially as code security standards and quality steadily rise. Unfortunately, most organizations spend virtually zero effort on educating their personnel. Cybercriminals know this. In the near future, virtually all high-profile hacks will be as a result of social engineering on DPRK and other bad actors’ part. In fact, to scare you a little, you may have one in your company right now like this security company.

DPRK infiltration attempts are not new. See the thread in which Aztec interviews a North Korean operative.

To prevent getting phished, it’s extremely important to know what social engineering looks like. We’ll explore a few examples.

First, what is social engineering? Social engineering is defined as any act that influences a person to make a decision that may or may not be in their best interests. Social engineering exploits your emotions to influence decisions. Let’s look at a few phishing stories.

Linus from LinusTechTips recently got phished and locked out of his Twitter account. The story goes that he was at a barbecue cookout and received an email alert from “Twitter” about a login to his account from a new device.

He panicked and navigated to the linked site, inputting his login details. The key element here was fear backed up by similar graphics to a legitimate alert. It’s subtle but in addition to the engineered urgency, if you look at the graphic below that I pilfered from JohnHammond’s video, you see the location marked as somewhere in Russia. With their cybercrime reputation, it could’ve amplified any fears and urgency he felt:

Note: The biggest red flag is engineered urgency. You should keep your guard up when encountering it.

You can still see his shoulder in the corner of the screenshot from the video lmao. Inb4, “Hey, that’s my shoulder.” - the Deep.

Christopher Hadnagy shares a similar incident in his book. It’s been some years since I read it so I can’t recite it verbatim but as I remember it, there’s similar engineered panic, this time with Amazon.

It was right after a long day, his senses were dulled and he didn’t recognize the phishing attempt. Realization struck only after credentials were sent. Being educated on the subject as a social engineer himself, he immediately changed his password and contacted Amazon to let them know to watch for suspicious login attempts, successfully mitigating the incident.

The takeaway here is to keep a clear head when reading emails, especially those that try to elicit a strong emotion out of you, and verify their legitimacy.

Taylor Monahan, lead product manager at MetaMask and founder of MyEtherWallet has detailed threads showcasing phishing attempts by DPRK in crypto. Please read through them diligently to understand how they look like:

• Mega-thread of general phishing techniques employed by DPRK
• Extremely targeted spear-phishing example
• Phishing example targeting developers in particular

Here are a few essential steps to keep you safe:

• Use an adblocker like uBlock Origin to prevent malicious pop-ups and redirects that may land you on pages designed to phish you.
• Keep bookmarks of the legitimate domain names of sites you visit often (i.e., Twitter, Farcaster, Uniswap etc.).
• Verify any emails you receive against these bookmarks. A common technique is buying a domain name with the same name but a different top-level domain (i.e., https://uniswap.xyz instead of .org). It’s also not uncommon for attackers to impersonate sites with a third and fourth level domain on a malicious site. It may look like this https://airdrop.uniswap.somedomain.org/. This appears legitimate but is fraudulent. Legitimate websites will always have their domain (uniswap in this case) directly before their top-level domain, (.org here). https://uniswap.org Other TLDs include .com, .net, .io, et cetera.
• Avoid clicking on shortened URLs (i.e., bit.ly), they’ve been used to point towards malicious sites in the past. Use the Expand URL browser extension to see where they actually lead.
• Install the VirusTotal browser extension, read through the docs linked and right-click to scan any and all unfamiliar links including in emails. It also scans files to determine if they are malicious prior to download. It’s important to note that the results are shared publicly.
• Approach unsolicited messages with raised suspicion and vigilance, especially those with links attached.
• Verify that the sender is associated with whatever organization they claim to be from. Look them up on the company’s website. Check if the Twitter follows them. Search for the company independent of any attached links first as they may have false information on a phishing site designed to trick you. If the person claims to be someone you know, call them up personally outside of the attached message or verify on a different platform.
• Scan any links received this way with URLScan
• If you plan to navigate to these sites, do so with isolated browsing.
• If the links attached refer you to a page asking for credentials or other sensitive information like your authenticator codes, it may be a phish.
• Similarly, if they ask you to urgently make a monetary transaction, it may be a phish.
• Use different computers to segment communications and storage of secrets like SSH keys, crypto wallets, GitHub access tokens etc. Isolated virtual machines are great for this if you can’t get a separate machine. Refer to the section detailing them.

Here are a few browser extensions to help alert you to any phishing attempts. Please note that many of these are only available on the Chrome web store so you’ll need to switch browsers to either Chrome or other Chromium-based browsers like Brave if Google’s surveillance is a concern.

• Password Alert: official Google extension that alerts you whenever it detects you inputting your Google Account credentials in a malicious/phishing sign-in page.
• Kerberus Sentinel3: offers protection against address poisoning, scam detection via pop-ups, highlights likely fraudulent Twitter accounts and offers emergency alerts to events like a Ledger security vulnerability. Simulates transactions before they go through, offering you increased visibility into what happens should you sign them through Fire Wallet.

Phishing isn’t the only social engineering method that’ll be used against you. Another common one is elicitation. The goal isn’t to make you give up credentials, rather information. Here’s an extract from the FBI’s brochure on it:

Elicitation is a technique used to discreetly gather information. It is a conversation with a specific purpose: collect information that is not readily available and do so without raising suspicion that specific facts are being sought. It is usually non-threatening, easy to disguise, deniable, and effective. The conversation can be in person, over the phone, or in writing. Conducted by a skilled collector, elicitation will appear to be normal social or professional conversation. A person may never realize she was the target of elicitation or that she provided meaningful information.

The brochure presents the facts and techniques on elicitation far better than I can so I’ll skip over this section and refer you to their document.

On the topic of phishing, Google has excellent practice labs to help you learn and practice how to identify phishing attempts here.

There’s irony in the fact that the domain here could be cause for suspicion of phishing.

Please note the following down somewhere accessible as a sort of cheat-sheet.

Malware detection, monitoring and remediation

You shouldn’t ever be downloading and running random binaries off the internet. A lot of malware comes in the form of Excel files in emails, asking you to enable macros (a vector for code execution). Please never do this. Ideally, every untrusted file received over the internet should be run in an isolated, sandboxed virtual machine. Use common sense when doing this, you shouldn’t be running files that are clearly part of a phish attempt.

One of the most popular ways of malware distribution in web3 seems to be modded game clients, APKs (for Android) and binaries of “play2earn” games distributed to prospective degens for in-game monetary rewards via Telegram or Discord. An excuse for distribution in this manner may be “beta testing”, exclusive access or claims that the binaries are modded with cheats to help the victim accrue rewards faster or at an unfair advantage.

First, I’ll dispel the myth that using a specific OS makes you less vulnerable to malware. Motivated attackers will generate binaries for each architecture and OS out there. The fact that they know so many high-profile targets use Apple Silicon MacBooks nowadays pretty much guarantees that.

Malware developers are in possession of various techniques to evade or bypass your OS’s inbuilt protections and anti-virus so having these installed or enabled do not give you free reign to install random programs thinking you will be safe. You will get REKT.

That being said, a lot of malware shares similar techniques that can be flagged and give them away managing to evade anti-virus tools so we’ll detail those here.

Multi-factor authentication

Multi-factor authentication involves something the user knows (i.e., a password), something the user has (security token from an authenticator app or SMS or FIDO device like YubiKey), or something the user is (biometrics). The most common are the first two. Ideally, it’d be all three.

SMS should be avoided for this authentication. More on why below. Instead substitute it for security tokens from an authenticator app. Google Authenticator is great for most users and battle-tested. Authy has suffered breaches in the past.

Experts consider a FIDO hardware device/key to be the ultimate option. YubiKeys are considered the best in the market. Get your hands on one as soon as you can and set it up. It’s harder to get phished this way. You should have another as a backup given that if you lose your YubiKey or it’s stolen. That’s it.

Note: Most, if not all, applications do not have MFA set up by default. If it is, it’s with SMS. Please set it up manually every time you sign up for a new account anywhere. These settings can usually be found in the “Privacy and Security” section. If you’re having trouble thinking of accounts to start securing, here’s a short list:

• All your social media applications.
• Github.
• Your google account.
• Your email account, assuming you don’t use the above for this.

Preventing SIM swapping

SIM swapping, for its relative simplicity on the attackers’ side, has become a popular tool in the cybercriminal’s toolbox in recent years. Let’s dissect how it works.

When your phone is stolen, you need a SIM upgrade or are changing carriers, you can contact your carrier so you can keep your phone number on the new SIM. This process is called mobile number portability.

Some carriers handle this process without enough verification. The attacker will contact your carrier and social engineer them into porting your phone number to a SIM under their control.

They use personal information in this process to validate or back up their request. This info is recovered from data breaches online, directly from you through seemingly innocuous conversation, a spearphish or even your social media accounts. These may be your address, email address, date of birth, full name, social security number (remember the leak?) et cetera.

Since the operator on the other line has never heard your voice prior and with all this information, the port goes through more often than it doesn’t.

With how easy this takeover is, SMS is still the default multi-factor authentication method for countless applications. This extends to account recovery and ‘forgot password’ operations. You could be locked out of all your accounts without even knowing it.

To prove my point, if you don’t have MFA on anything other than SMS set up, please log out of your Twitter account and open a new private tab then attempt to get back in assuming you don’t know the password but have access to your phone number only. See how easy that was?

So how do we protect ourselves against this?

As previously mentioned, avoid SMS as a 2FA method. However, there are cases where it’s unavoidable. Contact your carrier and implement additional authentication for porting. These may include specifying physical, face-to-face authentication backed by identity documents and other vendor (US) specific instructions linked below:

• AT&T
• T-Mobile
• Verizon
• Google Fi

Hardening social media and contact paths

Miscellaneous advice

• Keep your devices and all applications up to date.
• Don’t share the following details publicly:
  • Your phone number.
  • Your operating system of choice (if anything other than Windows). This prevents an attacker from including malware compiled for your specific architecture and OS in any messages and instead sticking to their default assumption.
  • Your phone’s brand. Make sure to crop any screenshots you send given that could be a way to identify the manufacturer based on UI. This also applies to messages such as “Sent from my iPhone” in email.
  • Your personal email. Share an email alias instead.
  • The amount of crypto or fiat you hold. IRL attacks are increasingly common.
  • Your physical address.
• Do not take a picture of your recovery phrase and keep it on iCloud or whatever. That is just asking to get rekt. Do not keep it unencrypted either.
• When storing secrets on physical paper such as secret recovery phrases or password manager master passwords, keep them on acid-free, laminated paper in a fire-proof lockbox. Additionally, keep another backup in the bank.

Conclusion and acknowledgements

We’ve stuck to the general basics here, covering only topics that apply to most individuals and would like to reiterate that there are additional factors to consider when applying OPSEC to an organization like G-suite policies and not to mention any custom vendor software that may be in use.

If you’d like help beefing up your organization’s OPSEC and incident response, alongside other security work such as fuzzing and audits, please feel free to contact us.

Additionally, we’d like to thank the following individuals for their feedback and suggestions on this guide:

• pcaversaccio particularly for proof-reading the article and suggesting the use of Windows Sandbox, Isolated Browsing, ProtonPass and ProtonVPN. The discussion on segmentation of VMs and separate workstations was appreciated!
• Taylor Monahan for general suggestions on signing transactions.

We’d also like to recognise the work of the following as inspirations for this guide:

• Trail of Bits
• Cyberspatial