RACE #40 Of The Secureum Bootcamp Epoch∞

This is a write-up for RACE-40, Quiz of the Secureum Bootcamp (opens in a new tab) for Ethereum Smart Contract Auditors. It was designed by Pablo Misirov (aka cbym) (opens in a new tab) a founding employee at Spearbit (opens in a new tab) / Cantina (opens in a new tab). He is an interdisciplinary applied researcher experienced in cybersecurity, communications, user experience, markets and artificial intelligence.

Participants of this quiz had a single attempt to answer 8 questions within the strict time limit of 16 minutes. If you’re reading this in preparation for participating yourself, it’s best to give it a try under the same time limit!

May 12, 2025 by patrickd

Question 1 of 8

Analyze the following transaction:

MethodID: 0x6a761202
[0]:  00000000000000000000000096221423681a6d52e184d440a8efcebb105c7242
[1]:  0000000000000000000000000000000000000000000000000000000000000000
[2]:  0000000000000000000000000000000000000000000000000000000000000140
[3]:  0000000000000000000000000000000000000000000000000000000000000001
[4]:  000000000000000000000000000000000000000000000000000000000000b2b2
[5]:  0000000000000000000000000000000000000000000000000000000000000000
[6]:  0000000000000000000000000000000000000000000000000000000000000000
[7]:  0000000000000000000000000000000000000000000000000000000000000000
[8]:  0000000000000000000000000000000000000000000000000000000000000000
[9]:  00000000000000000000000000000000000000000000000000000000000001c0
[10]: 0000000000000000000000000000000000000000000000000000000000000044
[11]: a9059cbb000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025b
[12]: e296951600000000000000000000000000000000000000000000000000000000
[13]: 0000000000000000000000000000000000000000000000000000000000000000
[14]: 00000000000000000000000000000000000000000000000000000000000000c3
[15]: d0afef78a52fd504479dc2af3dc401334762cbd05609c7ac18db9ec5abf4a07a
[16]: 5cc09fc86efd3489707b89b0c729faed616459189cb50084f208d03b201b001f
[17]: 1f0f62ad358d6b319d3c1221d44456080068fe02ae5b1a39b4afb1e6721ca7f9
[18]: 903ac523a801533f265231cd35fc2dfddc3bd9a9563b51315cf9d5ff23dc6d2c
[19]: 221fdf9e4b878877a8dbeee951a4a31ddbf1d3b71e127d5eda44b4730030114b
[20]: aba52e06dd23da37cd2a07a6e84f9950db867374a0f77558f42adf4409bfd569
[21]: 673c1f0000000000000000000000000000000000000000000000000000000000

A. Tx is dangerous because it includes a delegatecall to contract 0x96221423681a6d52e184d440a8efcebb105c7242.
B. Tx is dangerous because it includes a delegatecall that transfers a 0 token amount to address 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516.
C. Tx is safe because it initiates a call to the 0xa9059cbb router selector allowing it to execute a multi-token swap.
D. Not enough data is provided to analyze this transaction.

Solution

Correct is A, B.

In this question we are solely given the Solidity function selector (MethodID) and the calldata that is being passed to that function. We lack any further information on the transaction such as the address of the contract being called.

Based on the given bytes signature 0x6a761202 we are however able to determine possible methods in question via services such as 4byte.directory (opens in a new tab), which tells us that a known text signature is the following:

execTransaction(address,uint256,bytes,uint8,uint256,uint256,uint256,address,address,bytes)

Recognizing this as the execTransaction method for executing a transaction with Gnosis Safe requires some familiarity with it - or some Internet research skills. Either way, we're able to determine that the parameter of type uint8 controls the operation used. If operation is set to 0, Gnosis Safe will execute a normal call, if set to 1, it will be a delegatecall.

Option A is indeed true as we can see that the operation parameter has been set to delegatecall in the given transaction:

[3]:  0000000000000000000000000000000000000000000000000000000000000001

And the target of the delegatecall operation is indeed 0x96221423681a6d52e184d440a8efcebb105c7242 as specified by the first parameter (address to) within the given calldata:

[0]:  00000000000000000000000096221423681a6d52e184d440a8efcebb105c7242

The calldata passed to this address specifies that the method is 0xa9059cbb, which, after looking it up, you should be familiar with as transfer(address,uint256) - a method typical for an ERC-20 token transfer.

[11]: a9059cbb000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025b
[12]: e296951600000000000000000000000000000000000000000000000000000000
[13]: 0000000000000000000000000000000000000000000000000000000000000000

The target of this token transfer is 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516, with an amount of 0 - which may appear harmless at a glance. But the fact that the token contract is being called using delegatecall is highly suspicious. Determining whether this transaction was just a benign mistake requires checking the token contract's code.

Its source code has not been published anywhere, but its decompilation is trivial and allows us to see that the contract has indeed nothing to do with tokens. Instead it sets the passed token transfer destination address within the first storage slot (0) and returns. But since the contract is delegate-called, this means that the first storage slot of the calling Gnosis Safe is being overwritten.

The first storage slot in Gnosis Safe typically holds the address of the current owner or the contract's "master" (the contract's controller). An attacker able to change this, is able to take control of the Gnosis Safe.

Options C and D are contradictory to what we have found above and therefore incorrect.

At this point you might have noticed that this question was based on the recent Bybit hack. If you'd like to have more information on it, take a look at Matthieu Bonetti's write-up (opens in a new tab), upon which this explanation is largely based on. Also take a look at pcaversaccio (opens in a new tab)'s script which could have helped preventing this incident.

Question 2 of 8

Analyze the following scenario and answer what was the biggest OpSec failure:

Alice steps off the stage at the Global DeFi Summit in New York, adrenaline still rushing from her presentation. She had just introduced MuerucesDAO’s latest features to a big institutional crowd using the battered ASUS "Windows Threshold 1" laptop her mother gifted her when she got the job a few years ago. Outside in the lobby, she connects into a network called "Free-GlobalDeFi-WiFi" requiring a simple registration form over plain HTTP that barely registers as a concern at the moment. She just needs to send a few emails before catching her flight home.

At a corner table she makes eye contact with Surazal, a nice developer she’d met earlier. He’s been helpful, helping her to upgrade video drivers so her presentation would shine in 4K. She recalls him fiddling with a small HDMI dongle on her laptop promising improved compatibility. Right now though, she’s not thinking about Surazal’s configurations. Her phone vibrates with an urgent email from what appears to be MuerucesDAO’s CFO: they need her signature to rebalance $1.5 billion from the treasury to a new vault contract. The message includes a shortened link “https://tinyurl.com/yfbyf2ub” (opens in a new tab), with a note urging her to “please hurry”.

Alice blindly clicks the link and browses to the site, notices it loads slowly. A large figure flickers on the screen. No obvious red flag scams in the interface, but then again, she’s pressed for time. Her plane leaves in a few hours. She unzips a pocket in her bag and pulls out her Ledger Nano X. She’s aware she hasn’t updated it in ages, but that can wait for another day, right? After plugging the Ledger in, the device lags while retrieving transaction data. Some fields read uncomprehensive hexadecimal but the final prompt states it needs her confirmation. She gives a quick glance at the approximate total… it’s about the same as the rebalancing request. "That’s good enough" - she thinks, and clicks the tiny Ledger buttons to confirm.

Fifteen minutes later, her phone lights up with frantic calls. The CFO is in full panic mode: the entire $1.5 billion in stablecoins has just vanished, wired off to some mysterious address. Nobody can make sense of it, but she was the last one to sign.

A. Using an unsecured conference WiFi portal with a MITM server changed the transaction mid-way.
B. Blind signing a transaction on the Ledger Nano X despite not understanding what it displayed.
C. Installing suspicious video drivers from Surazal on her Windows work computer.
D. Clicking an urgent email link to a dApp from her colleague without verifying its sender nor target website.

Solution

Correct is B.

Have you noticed Pablo's easter eggs? MuerucesDAO is SecureumDAO. Surazal is Lazarus.

A: Transactions are cryptographically signed and cannot be changed by a Man-In-The-Middle attack. It is true however that, after signing up to get access to the unsecured conference WiFi, she should have turned on a VPN to reduce the risk of such attacks.

B: This was indeed the crux of the attack. Keeping her hardware wallet updated might have prevented this, as such updates may come with improvements in readability of transaction data.

C: The way that Surazal helped was certainly highly suspicious and there's a good chance that Alice's laptop has been infected with malware. The main purpose of using dedicated hardware wallets is exactly this scenario though - had Alice not blindly signed the transaction, she would've likely been able to notice something suspicious despite her laptop being infected.

D: It's indeed a very bad practice to blindly click on links without any verification of where they might lead and whether they are legitimate. But this was not the main culprit of the issue at hand.

Question 3 of 8

What seed values did Profanity rely on, enabling the attacker’s brute‑force?

A junior developer at MuerucesDAO wanted a catchy Ethereum vanity address for the project’s treasury. They used the open source tool Profanity to generate an address that began with “0xFAF0…”. Two days after launch, the wallet was emptied: an attacker brute‑forced the private key in minutes.

A. 32-bit value using unsigned integers.
B. 256‑bit value from classic /dev/urandom.
C. 64‑bit basic value derived from the current Unix timestamp.
D. 128‑bit entropy string from a BIP‑39 mnemonic.

Solution

Correct is A.

In September 2022, users of Profanity, a vanity address generator for Ethereum, were the targets of an attack. Attackers took advantage of a weakness in the wallet’s key generation process to access and drain $3.3 million in tokens from users’ wallets.

Generation of random values, such as private keys, is commonly performed using a cryptographic pseudorandom number generator (CPRNG) seeded with a random value. In this case, Profanity seeded the CPRNG with an unsigned integer, meaning that there were only 232 (about 4.3 billion) possible seed values.

From Halborn - Explained: The Profanity Address Generator Hack (September 2022) (opens in a new tab)

Question 4 of 8

How did Alice get doxxed?

Late one evening, Alice receives a message from Surazal, a nice developer she met at a conference while talking about NFT's. He tells her how much he loves her Facebook page about NFTs and recommends her to download a new wallet called NFTViewer - available only for Android - which renders images by pulling them straight from the URLs embedded in each token’s metadata. Surazal sends her an NFT and tells her to check it out, curious, Alice taps “View”.

The next day, Surazal appears at Alice's door demanding Bitcoin to leave her alone.

A. Surazal scanned Alice's Facebook page and used the WHOIS IP address to find her street. Alice should have hidden the WHOIS IP address details.
B. The NFT’s metadata loaded a hidden HTML page that exploited an old Android WebView bug to read nearby WiFi SSIDs. Surazal matched the strongest SSID to a WiGle database and located her building. Alice should have kept her Android OS up to date.
C. The NFT image URL pointed to Surazal’s server. NFTViewer fetched it directly, exposing Alice’s home IP. Alice should view the NFT only while connected to a VPN.
D. Alice uploaded photos to Facebook straight from her phone. Their EXIF data still contains GPS coordinates so Surazal extracted the coordinates and mapped them to her address. Alice should have stripped EXIF metadata (or taken photos with geotagging off) before publishing them on Facebook.

Solution

Correct is C.

A: It's indeed possible for an attacker to use WHOIS information to determine the owner of a domain, including the owner's address. But this doesn't apply for Facebook pages.

B: Something like this is certainly possible, but a such a vector typically requires a high level of sophistication from the attacker. You'd expect Alice to be a high-value target and the attacker to be a state actor or belonging to some other criminal organization.

C: As you might be aware, it's often only the NFT metadata that is actually stored on blockchains. Due to the high storage cost of data on blockchains, the actual NFT contents are usually off-chain, on services like IPFS. But there's nothing preventing NFT creators from hosting them on their own server. An attacker can create a unique NFT solely for the victim such that, when they view it, the victim's IP address is leaked (opens in a new tab). This can indeed lead to the attacker roughly determining the victim's location, although I'd argue that it's unlikely the IP address alone would be sufficient to find Alice's house on its own in most cases.

D: Facebook generally strips EXIF data from photos for privacy reasons. Though that doesn't mean that users aren't often voluntarily giving more than sufficient information for an experienced OSINT analyst to determine a user's exact location. Personally, I'd actually say this was the more likely vector to truly dox Alice's home address in this case.

Question 5 of 8

Analyze the scenario below and select the correct answer.

Alice, a seasoned validator operator running 32 validators for a
major L1 blockchain noticed unauthorized withdrawal credentials
changes on March 15th, 2024 at 03:14 UTC. The attacker managed to
extract 768 ETH (~$1.2M at the time) despite her sophisticated
security setup:

- Online validator nodes running consensus clients
- 3/5 Multisig for withdrawal operations
- Geographically distributed key shards using Shamir's Secret Sharing (4-of-7)
- Air-gapped signing machine running OpenBSD
- Regular security audits and penetration testing

## Timeline of Events

### March 1-10
- Alice attended ETHDenver, presenting on "Advanced Validator Security"
- Contributed to three major PRs on validator client software
- Set up a new monitoring stack using Prometheus/Grafana on AWS
- Updated her Yubikey firmware through the manufacturer's official channel
- Met promising developer Surazal at the conference

### March 12-14
- Deployed new metrics collection service on validator nodes
- Rotated AWS access keys as part of monthly security protocol
- Performed routine USB firmware update on air-gapped signing machine
- Merged PR #234 from Surazal improving monitoring alerts

### March 15
- 03:14 UTC: First unauthorized withdrawal credential change detected
- 03:17 UTC: Remaining validators compromised in sequence
- 03:22 UTC: All funds withdrawn to Tornado Cash
- 03:45 UTC: Alice discovers the incident and initiates emergency protocols

## Technical Environment

### System Architecture

1. Validator Nodes (validator-01 through validator-32)
   - Debian 12
   - Consensus + execution clients
   - Prometheus metrics
   - Public internet access

2. Air-gapped Signing Machine (signer-01)
   - OpenBSD 7.4
   - Offline HSM + Yubikey Series 5
   - No network interfaces
   - Used only for key operations and transaction signing

3. Monitoring Server (monitor-01)
   - Debian 12
   - AWS CloudWatch integration
   - Prometheus/Grafana stack
   - Public internet access

4. Cold Storage System (backup-01)
   - Debian 12
   - Offline backup system
   - Weekly airgapped syncs
   - Stores encrypted backups

### Security Measures
- LUKS full disk encryption on all systems
- Custom IDS monitoring SSH attempts on monitor-01
- S3 bucket with versioning for encrypted backups
- GPG signing for all git commits
- 2FA on all online services (Yubikey + TOTP)
- Mandatory code review by 2 senior team members

### Recent System Changes
- New AWS CloudWatch metrics integration
- OpenBSD security firmware update
- Prometheus node exporter deployment
- New SSH key rotation policy implementation
- Added Surazal's GPG key to trusted developers

## Suspicious Events (Logs)

### Monitoring Server Logs (monitor-01)

Mar 13 15:42:13 monitor-01 sshd[12445]: Failed password attempt from 185.142.236.43
Mar 13 17:22:31 monitor-01 aws-cloudwatch: New IAM role assumed for metrics collection
Mar 14 04:18:22 monitor-01 aws-cli: Successfully rotated access keys
Mar 14 09:45:12 monitor-01 systemd: aws-cloudwatch-agent.service started
Mar 14 15:33:27 monitor-01 github: Surazal's PR #234 merged successfully
Mar 14 23:55:02 monitor-01 systemd: prometheus-node-exporter.service started
Mar 15 02:45:33 monitor-01 kernel: New network interface detected: aws0

### Air-gapped Signing Machine Logs (signer-01)

Mar 14 02:13:45 signer-01 kernel: usb0: mass storage device detached
Mar 14 08:22:17 signer-01 authpf: key authentication successful
Mar 14 08:22:19 signer-01 doas: firmware verification completed
Mar 14 10:15:33 signer-01 sysupgrade: base system upgrade completed
Mar 14 10:15:45 signer-01 kernel: usb0: mass storage device attached
Mar 14 10:16:02 signer-01 kernel: usb0: device identifies as "OpenBSD USB Update Media"
Mar 15 03:12:45 signer-01 kernel: usb0: unknown HID device attached
Mar 15 03:12:47 signer-01 kernel: usb0: device identifies as "USB Advanced Input Device"

### Validator Node Logs (validator-01)

Mar 14 09:45:12 validator-01 systemd: prometheus-node-exporter.service started
Mar 14 09:46:33 validator-01 beacon: Attestation submitted successfully
Mar 14 23:55:02 validator-01 systemd: metrics collection enabled
Mar 15 03:14:01 validator-01 beacon: Withdrawal credentials change detected

### Cold Storage System Logs (backup-01)

Mar 14 15:33:27 backup-01 github-cli: Local repository sync completed
Mar 14 15:34:01 backup-01 gpg: New key imported: Surazal <surazal@protonmail.com>
Mar 14 15:34:05 backup-01 cron: Weekly backup started
Mar 14 15:35:12 backup-01 rsync: Backup completed successfully

## Additional Context
- Alice's GitHub shows 1,432 commits in the last year
- Her AWS infrastructure uses strict IAM roles
- Regular security audits (last one: February 28th)
- All SSH keys are rotated monthly
- Backup seeds stored in multiple bank vaults
- Surazal's contributions have been exceptional
- Team recently moved to using hardware security keys

A. The AWS CloudWatch metrics integration exposed internal validator metrics through a misconfigured IAM role, allowing the attacker to intercept signing operations.
B. A malicious device was connected to the air-gapped signing machine shortly before the compromise, likely capturing HSM interactions.
C. Developer Surazal socially engineered Alice, gained access to the backup seeds through the GPG key trust chain after his key was added to the trusted developers list.
D. The Yubikey firmware update from the manufacturer contained a supply chain attack that compromised the HSM's authentication mechanism.

Solution

Correct is B.

The fact that the attacker managed to extract ETH means that he somehow managed to compromise the air-gapped signing machine. The first unauthorized withdrawal happened on March 15. at 03:14 UTC. Just before that, a Human-Input-Device was attached to the air-gapped signing machine via USB:

Mar 15 03:12:45 signer-01 kernel: usb0: unknown HID device attached
Mar 15 03:12:47 signer-01 kernel: usb0: device identifies as "USB Advanced Input Device"

There are USB-devices, often referred to as "Bad USB", that are made to look like innocent USB sticks, but in reality they're capable of acting like input devices, such as a keyboard, in order to run certain commands on the machine they are attached to.

This is likely what happened here.

Question 6 of 8

Select the best OPSEC setup.

A. Purism Librem 14 + ProtonMail Bridge + quantum-resistant YubiKey + military-grade faraday backpack + biometric-encrypted Ledger + neural-network firewall + SOCKS proxy.
B. GrapheneOS Pixel + Coldcard + Signal + ProtonMail + faraday bag + yubikey.
C. iPhone 15 + ToR + ProtonMail + Signal + Home cloud encrypted backup + Authy 2FA.
D. LineageOS + Brave Browser + DuckDuckGo + NordVPN + Telegram + Bitwarden.

Solution

Correct is .

A: This option is full of fancy buzzwords. I'm also unaware of the existence of a "biometric-encrypted Ledger". It's highly unlikely for Ledger to ever base the encryption, or generation of, private keys upon biometrics which can not be changed but easily stolen.

B: A reasonable setup, with hardware wallet and a lack of fancy buzzwords.

C: No dedicated hardware wallet? Not a good idea in the OPSEC context of crypto-projects.

D: Also no mentioned of a dedicated hardware wallet device. It should further be noted that the LineageOS project's focus is device longevity and broad compatibility rather than security.

Question 7 of 8

What is the best way to configure the team’s environment in a realistic scenario?

You're tasked with setting up secure configurations for a high profile crypto team. The team needs to maintain public presence while protecting sensitive operations.

Required Configurations

Social Media (Twitter, Telegram)

Email & Workspace (Gmail, Microsoft)

Devices & OS (macOS, iOS)

Authentication (2FA, Yubikeys, Passkeys)

Communications (WhatsApp, Signal)

Infrastructure (Domains, DNS)

A. Quantum-encrypted email signatures + Military-grade 2FA with DNA verification + Blockchain validated password manager + AI powered intrusion detection + Custom built encrypted messenger + Proprietary security protocol stack
B. ProtonMail with PGP + Bitwarden premium + Google Authenticator + Private DNS + Signal for all comms + Custom firewall rules
C. Microsoft 365 with Conditional Access + LastPass Enterprise + Duo Security + Cloudflare Zero Trust + Teams for communication + Azure AD SSO
D. Google Workspace with advanced protection + 2FA, Hardware keys only (no SMS/TOTP) + Offline password manager + HSM backup + Separate devices for public/private accounts + Private WHOIS + Cloudflare proxy + OS Auto updates + disk encryption

Solution

Correct is D.

A: The first option is once again filled with fancy buzzwords that don't really make much sense aside from possibly being good marketing to the uninformed.

B: This setup appears to focus on the protection of privacy, rather than the security of operations for a high profile crypto project.

C: Suggests an enterprise-grade setup that is not applicable to the given use case.

In Pablo's own words on D:

"good opsec can be simple. a good team would use this setup to keep operation execution high while staying secure."

Question 8 of 8

Surazal sent you a file. What does it do?

A. The file is from a crypto mining malware called XMRig which uses the victim's CPU to mine Monero. To protect yourself, monitor CPU usage and use antivirus software to detect unauthorized mining processes.
B. The file is from a Discord stealer that steals authentication tokens and accesses user admin accounts. To protect yourself, enable 2FA on Discord and regularly check active sessions in account settings.
C. The file is from a malware called Wish which steals crypto wallet data and exfiltrates it to an attacker controlled C2 server. To protect yourself, use cold wallets for private key storage and never store seed phrases on your computer.
D. The file is from a credential stealer that captures browser stored passwords and cookies. To protect yourself, use a password manager and enable browser security features like phishing protection.

Solution

Correct is C.

It's simple to tell that the given file is obfuscated JavaScript. We can also recognize from keywords like NODE_ENV, that this is script supposed to be executed with NodeJS, and not in the browser.

We can get further hints on the script's purpose by decoding some of the base64 strings contained:

echo QXBwRGF0YS9Mb2NhbC9Hb29nbGUvQ2hyb21lL1VzZXIgRGF0YS9EZWZhdWx0L0xvY2FsIFN0b3JhZ2UvbGV2ZWxkYg== | base64 --decode
# AppData/Local/Google/Chrome/User Data/Default/Local Storage/leveldb
 
echo QXBwRGF0YS9Mb2NhbC9FeG9kdXM= | base64 --decode
# AppData/Local/Exodus
 
echo c2VlZA== | base64 --decode
# seed
 
echo aHR0cHM6Ly9hdHRhY2tlci5jb20vd2ViaG9vaw== | base64 --decode
# https://attacker.com/webhook
 
echo QXBwRGF0YS9Sb2FtaW5nL0VsZWN0cnVtL3dhbGxldHM= | base64 --decode
# AppData/Roaming/Electrum/wallets
 
echo QXBwRGF0YS9Sb2FtaW5nL2Rpc2NvcmRwdGIvTG9jYWwgU3RvcmFnZS9sZXZlbGRi | base64 --decode
# AppData/Roaming/discordptb/Local Storage/leveldb
 
echo QXBwRGF0YS9Sb2FtaW5nL01vemlsbGEvRmlyZWZveC9Qcm9maWxlcw== | base64 --decode
# AppData/Roaming/Mozilla/Firefox/Profiles

After decoding a few of the strings, we can already make a good guess on what it does: It appears to access information from cryptocurrency wallets (Exodus, Electrum), the databases of browsers (Chrome, Firefox) and apps (Discord). It also appears to look for a "seed" and communicate with a webhook belonging to the attacker.

A quick Internet search reveals that there exists indeed an open source malware called "Wish Stealer" that fits what we've found perfectly.

← RACE #39 Of The Secureum Bootcamp Epoch∞