In web3, a developer's laptop is often one step away from signing keys, cloud sessions and package publishing rights, which makes developers the preferred way in for the most capable attackers. Several of the largest crypto thefts began with a developer running code from a fake recruiter, a "pre-employment test" or a fake video call client, followed by theft of sessions and keys. This guide sets out how to separate developer work from key material, handle untrusted code safely, harden the IDE, Git and package tooling, protect accounts and publishing identities, and detect and respond when a lure succeeds. It is for security leads, engineering managers and individual developers at protocols, wallets, exchanges and infrastructure providers. Hiring-side controls for fraudulent remote workers are covered in the Insider Threat from Fake IT Workers Guide (North Korean IT Worker Schemes); this page focuses on protecting the developers you already have.
Key takeaways
- Untrusted code never touches a privileged machine. Every external repository, test task or "debug this" request is opened first in a disposable, credential-free environment and destroyed afterwards.
- Keys and code live on different devices. Signing keys, seed phrases and treasury access belong on dedicated signing devices and hardware wallets, never on the laptop used for development, chat and browsing.
- Developer tools execute things. Package lifecycle scripts, IDE tasks, Git filters, dev containers and AI coding agents can all turn repository content into execution, so each needs a control.
- Publishing rights are production credentials. npm, PyPI and front-end deploy rights should come from CI with OIDC and provenance, not from a long-lived token on a laptop.
- Assume a successful lure means total credential theft. Response means isolating the device, rotating everything it could reach and warning contacts, not just removing a file.
How developers are targeted
The FBI's September 2024 public service announcement on North Korean social engineering against the crypto industry (I-090324-PSA) describes actors who research specific DeFi and crypto businesses, study employees' professional profiles and build tailored scenarios, usually a job offer or an investment, then sustain rapport over long periods before delivering malware. Attribution to state actors comes from government and industry reporting; individuals are not named here.
| Lure | What the developer is asked to do | Warning signs | Primary control |
|---|---|---|---|
| Fake recruiter or paid task | Clone and run a take-home project, fix a failing test | Well-known firm, unusually high pay, no room to negotiate, deadline pressure | Disposable VM on a non-company device; never on the work laptop |
| Fake investor or partner call | Join a call on an unfamiliar video platform, then "fix" an audio or camera error | Domain is not Zoom, Meet or Teams; a script is needed to unlock the call | Only approved meeting clients; no pasted commands; verify the contact separately |
| Community or support request | Help debug a contract or reproduce a bug from a repository | New account, urgency, request to move to another messaging app | Untrusted-code procedure; security team triage |
| Fake document | Open a "report" or slide deck from a link | Unexpected attachment, odd file type, login prompt | Attachments disabled by default, open in isolation |
| Compromised contact | Review a new repository from someone you know | Familiar account, unfamiliar behaviour | Out-of-band check; a real relationship does not verify the bytes |
| AI agent setup request | Let a coding agent install or review the project | Repository includes agent instruction or tool configuration files | Agent runs only inside the same isolated environment, with approvals |
The indicators in the FBI announcement are worth turning into policy text: requests to run code or install applications on company devices, pre-employment tests that require unfamiliar packages, insistence on unusual software for simple tasks, and requests to move the conversation to a different app. In the Bybit hack, a Safe{Wallet} developer's laptop was compromised through a malicious Docker project, and the attackers reused the developer's live AWS session tokens to tamper with the signing front-end.
Separating development from keys and money
The single most effective design decision is that no device used for development, chat, email or browsing can sign a privileged transaction or reach seed material.
| Device or environment | Allowed | Not allowed |
|---|---|---|
| Development laptop | Code, reviewed dependencies, approved IDE extensions, chat | Seed phrases, hot wallet keys, signer keys, standing production admin sessions |
| Disposable analysis VM or cloud sandbox | External repositories, take-home tasks, unknown documents | Any inherited credential, SSH or GPG agent, browser session, wallet, password manager |
| Dedicated signing device | Multisig interface, hash verification tools, hardware wallet | Email, chat, general browsing, developer tooling |
| Hardware wallet or HSM | Private keys and signing | Blind signing of privileged transactions |
| CI with OIDC | Package publishing, front-end deploys, contract deployment scripts | Long-lived publishing tokens stored as secrets when OIDC is available |
The FBI's mitigations include keeping wallet credentials, seed phrases and private keys off internet-connected devices, and requiring multiple factors and approvals from several unconnected networks before company funds move. For signer devices and multisig procedures, see the Multisig Treasury Operations Guide for Protocols and Companies.
Choosing the isolation boundary
The SEAL DevSecOps framework distinguishes three boundaries for handling untrusted code:
- Separate analysis device: for repeated high-risk research or credible targeted activity; no production access, no personal accounts, separate identity and network controls.
- Disposable virtual machine or cloud sandbox: the default for normal external-code review; fresh image, no inherited credentials, restricted egress, evidence export, destroyed after use.
- Hardened container or dev container: lower-risk routine work only; rootless, no privileged mode, no Docker socket, no home-directory binds, no forwarded agents. Containers share the host kernel, so they are confinement rather than isolation, and a repository-controlled definition can request exactly the mounts that remove the protection.
Small teams can meet the default with a cloud VM template that is created per task and deleted after. Larger organisations should offer a managed analysis service, because a developer under deadline pressure will use the normal laptop if the safe path is slow.
Handling untrusted code: the intake procedure
- Verify before retrieval. Record the sender, organisation, channel, repository URL, revision and requested task. Verify the sender through a separate trusted channel. Ask why the task needs installation, recursive submodules, an extension, elevated privileges or cloud credentials. Route unexplained urgency, secrecy or privilege requests to security. Identity verification only tells you who sent the code, not that it is safe.
- Retrieve in isolation. Fresh environment, current Git release, clean Git configuration, no recursive submodules on first clone, no token embedded in the URL, IDE in Restricted Mode and AI agents disabled. If authentication is needed, use a short-lived read-only credential for that one repository.
- Inspect before running tools. Compare with the claimed upstream, then review manifests and lockfiles, install hooks (npm
preinstall,install,postinstall,prepare), Python build backends and.pthfiles, Cargobuild.rs, test fixtures, executable configuration files, long lines, encoded blobs and Unicode bidirectional characters. Check.gitmodules,.gitattributes,.vscode/,.idea/,.devcontainer/, agent instruction and MCP configuration files, Dockerfiles and Compose files. - Execute with bounded capabilities. Snapshot the clean state, then install, build, test or start an agent one boundary at a time, with privileged containers, host sockets, home mounts and production routes disabled, and approval required for agent shell and network calls.
- Tear down and re-validate. Export only reviewed source changes, destroy the environment, and repeat the review when the repository, a dependency, a container image or tooling configuration changes.
Hardening the developer toolchain
| Surface | How repository content becomes execution | Control |
|---|---|---|
| Package managers | Lifecycle scripts run on install; typosquatted or confused dependencies resolve to attacker packages | npm ignore-scripts for inspection, lockfiles with exact versions, verify namespace and integrity, delay adoption of brand-new releases |
| VS Code and other IDEs | Tasks with runOptions.runOn: folderOpen after trust; workspace settings pointing to executables; sideloaded VSIX | Keep security.workspace.trust.enabled on; Restricted Mode for external code; approved extension list; no repository-supplied VSIX |
| Git | Recursive submodule flaws (for example CVE-2024-32002), configured clean and smudge filters, hooks paths, credential helpers | Patch Git, clone without recursion first, inspect effective configuration, credential-free first retrieval |
| Containers | RUN, ENTRYPOINT, privileged mode, Docker socket or home directory mounts | Read definitions before starting; rootless; no socket mounts |
| AI coding agents | Repository instructions or prompt injection turned into tool calls | Run inside the isolated environment; require approval; scope tools and egress |
In VS Code, Restricted Mode disables tasks, debugging, workspace settings that point to executables, extensions that have not opted in, AI agents and the terminal until the folder is trusted. Setting security.workspace.trust.startupPrompt to once forces a trust decision for each new folder. Pair the IDE controls with application allowlisting on high-value machines: the FBI recommends that firms holding large amounts of crypto allow only whitelisted programs on network-connected devices.
Accounts, sessions and publishing identities
- Phishing-resistant MFA: FIDO2 security keys on email, source control, registrars, cloud consoles, package registries and the password manager, with at least two keys per account and SMS recovery removed. The Solana web3.js npm compromise began with a cloned npm login page that captured a password and one-time code.
- Dedicated browser profiles: a minimal profile for high-value accounts with only the password manager extension, and no wallet extensions in the everyday profile.
- Short, bound sessions: cloud console and CLI sessions should be short-lived, issued just in time for production changes and alerted on use from new networks, because stolen session tokens bypass MFA that has already been satisfied.
- Publishing from CI: npm trusted publishing uses OIDC from GitHub Actions, GitLab CI/CD or CircleCI instead of long-lived tokens and, from GitHub Actions and GitLab, generates provenance automatically. Once it works, set the package to "Require two-factor authentication and disallow tokens". See the Web3 and Crypto Security Guide for front-end and dependency integrity.
- Offboarding publish rights: registry roles sit outside most identity provider reviews. In the Mastra npm supply chain attack, a former contributor's account still had publish rights across the scope, and Microsoft attributed the campaign to the North Korean actor it tracks as Sapphire Sleet.
Every token, deploy key, publishing role and cloud session a developer holds is a non-human identity with an owner, a scope and an expiry. Inventory them per developer so that a compromise or departure can be revoked in one pass. See the Crypto Exchange Identity and Key Security Guide.
Communications and personal exposure
- Verified channels: use Signal with safety numbers checked over a second channel for anything touching keys or deployments, and agree a backup platform in advance.
- Approved meeting software only: a meeting link to an unfamiliar platform, followed by an "error" that you are asked to fix by running a command, is a known lure; SEAL's DPRK response playbook describes it. ATT&CK tracks this pattern as T1204.004 Malicious Copy and Paste.
- Public footprint: developers with signer or deploy roles should limit what their public profiles reveal about those roles, and use separate addresses for different functions so on-chain activity does not map neatly to people.
- Reporting culture: make it easy and blame-free to report "I think I ran something". Hours matter more than embarrassment.
Detection and response
SEAL's DPRK response playbook says to assume that private keys, files and online accounts have all been stolen once the malware is confirmed, and that attackers may use your accounts to impersonate you to contacts. A response runbook therefore needs to be broad and fast:
- Disconnect the device from networks but keep it powered for forensics where possible; do not reinstall yet.
- From a clean device, move funds from any wallet whose keys the device could reach, and pause or rotate any signer it held, using the multisig emergency process.
- Revoke and reissue cloud sessions and keys, source control and registry tokens, SSH keys, CI secrets and password manager sessions; log out all sessions on email and chat.
- Warn colleagues and external contacts that messages from the developer's accounts may be fraudulent.
- Review recent commits, package publishes, front-end deploys and infrastructure changes made from the developer's identities.
- Rebuild the device from a known-good image, and only then restore access with new credentials.
Contract exploits and protocol-wide incidents follow the Web3 Incident Response Playbook.
What to monitor and measure
- Endpoint signals: unknown binaries or scripts launched from download and project folders, new persistence (launch agents, scheduled tasks), processes reading browser profile and wallet extension storage, and outbound connections from developer machines to newly registered domains.
- Identity signals: cloud sessions used from new networks or VPN addresses, MFA device registration attempts, token creation outside CI, and registry publishes without provenance.
- Metrics: share of external-code reviews done in the sanctioned environment; number of developer laptops holding wallet keys or seed material (target zero); share of packages published only through OIDC with tokens disallowed; median time from suspected lure to full credential rotation; share of privileged accounts on FIDO2 only; lure simulation report rate.
Common failure patterns
- "It is only a test task." Running a take-home project on the work laptop because the disposable environment is unavailable or slow.
- Keys on the development machine. A hot wallet key in an
.envfile or a browser wallet in the everyday profile turns a malware infection into a direct loss. - Trusting the workspace to read the code. Clicking "Trust" to get syntax highlighting enables tasks and settings that the reviewer has not read.
- Standing cloud sessions. Long-lived console or CLI sessions on a developer laptop that can modify production front-ends, as in the Bybit chain.
- Publish rights that outlive the role. Former contributors and old tokens left on registry scopes.
- Cleaning one file and moving on. Treating a confirmed lure as a malware removal task rather than a full credential compromise.
Framework mapping
| Practice | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ATT&CK v20 techniques addressed |
|---|---|---|---|
| Lure awareness and reporting | PR.AT-01 | AT-2, AT-2(3) | T1566.002, T1566.003, T1585.001 |
| Isolating untrusted code and allowlisting | PR.PS-05, PR.IR-01 | CM-7, CM-11, SC-39, AC-20 | T1204.001, T1204.002, T1204.004 |
| Phishing-resistant MFA and short sessions | PR.AA-03 | IA-2 | T1539, T1528, T1555.003 |
| Publishing through CI with provenance | GV.SC-01 | SR-3, SI-7 | T1195.002 |
In ISO/IEC 27001:2022 Annex A, the closest controls are A.6.3 (awareness and training), A.8.1 (user endpoint devices), A.8.19 (installation of software on operational systems) and A.8.5 (secure authentication).
Practitioner checklist
- Publish a rule that no external code, test task or unknown document is run on a company device outside the sanctioned disposable environment.
- Provide that environment as a one-click VM or sandbox with no inherited credentials and restricted egress.
- Remove all wallet keys and seed material from developer laptops; move signing to dedicated devices and hardware wallets.
- Enforce VS Code Workspace Trust, an approved extension list and no sideloaded VSIX packages.
- Require FIDO2 keys on email, source control, registries, registrars and cloud consoles, with SMS recovery removed.
- Move package and front-end publishing to CI with OIDC and provenance, and disallow tokens on published packages.
- Issue short-lived, just-in-time cloud sessions for production changes and alert on use from new networks.
- Inventory each developer's tokens, keys and publish roles, and revoke them on role change the same day.
- Run lure simulations based on fake recruiter and fake meeting scenarios, and reward fast reporting.
- Rehearse the compromised-developer runbook, including moving funds and rotating signers from a clean device.
Standards and references
- FBI IC3: North Korea Aggressively Targeting Crypto Industry with Well-Disguised Social Engineering Attacks
- Security Alliance (SEAL): Developer-Targeted Intrusions
- Security Alliance (SEAL): Handling Untrusted Code
- Security Alliance (SEAL): North Korea (DPRK) Attack Response
- Microsoft: Visual Studio Code Workspace Trust
- npm Docs: Trusted publishing for npm packages
- Security Alliance (SEAL): Hardware Security Keys
Related NHI Mgmt Group resources: Insider Threat from Fake IT Workers Guide (North Korean IT Worker Schemes) · North Korea Cyber Operations Guide · Web3 and Crypto Security Guide · Multisig Treasury Operations Guide for Protocols and Companies