TraderTraitor aimed fake job offers at the engineers who hold the keys

The week

On April 18, 2022, the FBI, CISA and the Treasury Department issued a joint advisory on North Korean state-sponsored activity against blockchain and cryptocurrency companies. Targets included exchanges, where people buy and sell digital currencies; decentralized finance protocols, financial services run by software on a blockchain rather than by a traditional institution; play-to-earn gaming companies; crypto trading firms; venture capital funds; and individuals holding large amounts of cryptocurrency.

The kind of approach it warned about runs like this. A software engineer at a cryptocurrency company receives a message on a professional networking site from a friendly recruiter. The role sounds excellent and the pay is better than what she earns now. Over a few days the conversation feels normal: a call, some questions about her experience, then a request to download an application to complete a technical exercise. She does it on her work laptop, where her tools are. The application works as described, and it also opens a door.

What the advisory described

The advisory described the Lazarus Group, a hacking group linked to the North Korean state and also tracked under names such as APT38, BlueNoroff and Stardust Chollima. It said the activity had been observed since at least 2020. The group sent large numbers of spear-phishing messages to employees. Spear-phishing is targeted deception: unlike mass spam, each message is tailored to a specific person, using what the attacker knows about their job and interests.

The targets were often in system administration or software development and IT operations roles. The messages came through a variety of communication platforms, frequently disguised as recruitment for well-paid jobs.

Recipients were encouraged to download trojanized cryptocurrency applications, which the advisory called TraderTraitor. A trojanized application is named after the Trojan horse: software that appears to be something useful, such as a trading or price-prediction tool, but carries hidden malicious code that gives the attacker access to the computer it runs on.

The advisory gave technical detail. The applications were built with common cross-platform tools, JavaScript running on Node.js inside the Electron framework, and ran on Windows and macOS. They were derived from open-source projects and promoted on professional-looking websites. Names listed included DAFOM, TokenAIS, CryptAIS, AlticGO, Esilet and CreAI Deck. A built-in “update check” downloaded and ran a second-stage payload, often a remote access trojan called Manuscrypt, which let the operators run commands on the machine.

From there, the advisory said, the actors sought private keys or other weaknesses that would let them make fraudulent blockchain transactions. Their activity after the initial compromise was tailored to each victim, and was sometimes completed within a week of the intrusion. The advisory recommended application allowlisting, least-privilege access, multi-factor authentication, training on social engineering, and verifying cryptocurrency software against its primary source.

A pattern already seen

None of the method was new to the agencies. In February 2021, CISA and the FBI had described AppleJeus, a family of trojanized cryptocurrency applications used by the same group. TraderTraitor was a refinement: better-looking applications, aimed more precisely at the engineers inside crypto firms rather than their customers.

A week focused on North Korea

The advisory landed in a week already focused on North Korea. Four days earlier, the FBI had attributed the theft of roughly $620 million in cryptocurrency from the Ronin network, which supported the blockchain game Axie Infinity, to Lazarus Group and APT38. Treasury’s Office of Foreign Assets Control added an Ethereum address used in the theft to its sanctions listing for the group, meaning US persons were barred from dealing with it.

The Ronin theft had taken place in late March and went unnoticed for several days. Ronin’s operators said the attackers had gained control of five of the nine validator keys needed to approve withdrawals from the network’s bridge. Several of those keys belonged to a single company, which left the multi-signature design less independent than it looked.

The bridge was paused while the operators investigated. Sky Mavis, the company behind Axie Infinity, said it would reimburse affected users, and in early April announced a $150 million funding round intended in part to do so. For an industry that had marketed itself on code replacing trust, the episode was a reminder that a handful of keys on a handful of machines still decided everything.

The message to the industry was blunt. The people being hunted were the engineers who held the keys, rather than executives or finance staff.

Most phishing defenses assume a familiar pattern: an unexpected message, often impersonating a colleague or supplier, asking the recipient to click a link or open a file. Staff are trained to spot it, and email systems are tuned to filter it.

TraderTraitor used a different pretext. It approached engineers and administrators as job candidates, offering attractive roles and drawing them into conversations over days or weeks, often on professional networking sites and messaging apps. The payload, the malicious part of the attack, arrived as a step in what looked like a normal hiring process.

The campaign targeted crypto firms, but the method fits any institution whose engineers hold valuable access, including banks, payment processors, broker-dealers and fintechs. Approaches like this will sometimes succeed, however good the training. The useful question is how far one success can reach.

We take the problem in five parts. First, how a recruitment attack unfolds, step by step. Second, why a job offer makes such effective bait. Third, who the attack is aimed at, and what their access reaches. Fourth, how to keep one success small. Fifth, how the stakes and the rules differ across types of financial firm.

How a recruitment attack unfolds

A few terms make the rest of the story easier to follow.

Keys, privileges and endpoints

Blockchain and cryptocurrency. A blockchain is a shared digital ledger, a record of transactions copied across many computers so that no single party controls it. Cryptocurrencies are digital assets recorded on such ledgers. What matters for this story is how they move: a transaction is approved by a digital signature, and once it is recorded, it generally cannot be reversed. There is no bank to call to stop a payment.

Private keys. A private key is a secret number that proves ownership of digital assets and authorizes their movement. Whoever holds the key can sign transactions. It works like a signature stamp honored instantly, anywhere in the world, with no one checking whether the person holding it is the right one. That is why crypto firms guard keys so carefully, and why attackers want them.

Multi-signature and bridges. Many platforms require several keys to approve a transaction, so that no single stolen key is enough. A bridge is a service that moves assets between blockchains, usually by holding large pools of them under such multi-key control. The protection depends on the keys being truly independent. If one organization holds most of them, one compromise can be enough, as Ronin showed.

Privileged access. In any organization, most staff have ordinary access: email, documents, the applications they use. A smaller group has privileged access, the power to change systems themselves. System administrators manage servers and accounts. Developers write and change the code that runs the business. Cloud administrators control the rented computing infrastructure on which many firms now run. Their accounts are the master keys of the organization.

Malware on an endpoint. An endpoint is any device a person uses: a laptop, a desktop, a phone. When malware runs on an endpoint, it typically acts with the permissions of whoever is logged in. If that person is an administrator, the malware inherits administrator-level reach. It can also read what the person’s browser holds, including session tokens that let it act as the person without knowing their password.

Put those together and the logic of TraderTraitor is clear. Compromise the laptop of one person with privileged access, and you may be a short step from the keys that move money irreversibly.

Seven steps from a friendly message to a theft

Each step of a recruitment-based attack is also a place where it can be stopped. The sequence below is a general illustration of the technique the advisory described, not a reconstruction of any specific case.

1. Research. The attacker identifies a company and the people in it who hold valuable access. Public profiles on professional networking sites often list job titles, skills and current projects, which is enough to pick targets.
2. First contact. A message arrives from someone presenting as a recruiter or hiring manager, usually on a networking site or messaging app rather than corporate email. The role is plausible and attractive.
3. Building trust. Over days or weeks, the conversation continues. There may be calls, follow-up messages and questions about experience. Nothing yet looks suspicious, because nothing yet is.
4. The ask. At some point the target is asked to download something: an application to test, a coding exercise, a document describing the role. In the TraderTraitor case, the advisory described trojanized cryptocurrency applications.
5. Execution. The target runs the file, often on a work laptop. The application may appear to work normally, while hidden code gives the attacker a foothold on the machine.
6. Expansion. From that foothold, the attacker looks for what the engineer can reach: saved credentials, session tokens, code repositories, cloud consoles, key management systems.
7. The objective. If the engineer’s access leads to systems that can move assets, the attacker moves them, as quickly as possible, and begins laundering them across many addresses.

Seen this way, the defense is a series of checkpoints rather than a single wall. Training and a safe reporting culture work at steps two through four. Blocking unapproved software works at step five. Separating privileged work from everyday work, and monitoring for unusual behavior, work at step six. Multi-person approval for asset movements works at step seven.

A firm that has only the first checkpoint is betting everything on every engineer spotting every fake recruiter. A firm with all of them can afford for some people to be fooled.

What happens to the money

Theft is only half the operation. The proceeds then have to be moved beyond reach. Stolen funds are typically split across many addresses, swapped into other assets, moved between blockchains through bridges, and passed through mixing services that pool funds from many users to obscure their origin. Eventually some are converted to ordinary currency through brokers or exchanges with weak controls.

Speed matters at this stage too. Some stablecoin issuers can freeze tokens held at a known address, and exchanges can block deposits from flagged addresses, so attackers convert quickly. Blockchain analytics firms trace flows in public ledgers, and law enforcement has seized portions of stolen funds in several cases. Recovery is possible, but it is partial and slow, which is why prevention carries so much weight.

Why the timeline matters

The advisory noted that post-compromise activity was sometimes completed within a week. That shapes defense. A control that detects a problem in a monthly review is too slow. Signals from steps five and six need to reach someone who can act within hours, and the step-seven controls need to hold even if nobody has noticed anything yet.

Why a job offer makes good bait

Recruitment works as a pretext because it is personal, flattering and private. An engineer exploring a new job is unlikely to forward the conversation to their current employer’s security team. The exchange may happen on a personal phone or account. Requests that would seem odd from a stranger, such as downloading an application to complete a technical exercise or reviewing a code sample, look routine in a hiring process.

It mirrors the real market

It also exploits a real feature of the market. Skilled engineers, especially in specialized fields such as blockchain development, are approached by recruiters often. Many genuine approaches look very much like the fake ones. Take-home coding tests are a normal part of technical hiring. Telling people “never engage with recruiters” is neither realistic nor fair.

The attackers also understood the rhythm of hiring. A real process includes delays, scheduling, a friendly screening call and then a technical step. A fake one that follows the same rhythm earns trust at each stage. By the time the file arrives, the engineer has had several normal interactions, and the request feels like the natural next step.

It bypasses the controls firms invested in

That means email filtering and standard awareness training cover only part of the risk. The approach may never touch corporate email. The file may arrive by a direct download link, a code repository or a messaging app. The engineer may still run it on a work laptop, because that is where their development tools are.

Developers are also, by temperament and job, used to running code from many sources. Installing a package, cloning a repository and running a script are routine. Training that treats every unexpected file as suspicious does not fit how engineers actually work, and engineers tend to discount it.

Personal devices blur the line

Running the test on a personal laptop instead of a work one helps less than it seems. Engineers often sign in to work tools from personal devices, sync password managers across them, or use one code-hosting account for both personal projects and company repositories. A personal machine with a synced browser profile may hold the same sessions as the work laptop.

Firms can narrow this by requiring managed devices for any access to company systems, keeping company code-hosting identities separate from personal ones, and limiting which devices can hold privileged sessions at all. Each step reduces what a compromised personal machine can reach.

What helps

Training that names recruitment lures explicitly, with real examples, helps. It should be specific to engineers: the take-home test that must be run locally, the trading tool to evaluate, the repository to clone and build. It should give a clear rule, such as running any external test only in a disposable environment provided for the purpose, rather than a vague warning.

So does a reporting route that carries no embarrassment. An employee should be able to say “a recruiter sent me something odd” without implying they are leaving. Thanking reporters and keeping their reports confidential makes the next report more likely.

The cultural point matters as much as the technical one. In a firm where talking to a recruiter is treated as disloyalty, engineers will hide exactly the conversations security most needs to hear about. In a firm where it is understood as normal professional life, they are more likely to speak up when something feels wrong.

Telling real recruiters from fake ones

Engineers can be given a few simple checks. A genuine recruiter can usually be confirmed through the hiring company’s own careers page or a phone number found independently. Real hiring processes rarely require running an unfamiliar application on the candidate’s current work machine. A request to install software, especially a trading or wallet tool, or to run code locally before any formal interview, is a signal to pause.

None of those checks is perfect. Attackers have built convincing company websites and impersonated real firms. The checks raise the cost of the deception and give engineers a reason to stop and ask, which is often enough.

A sandbox for hiring tests

One practical measure removes much of the risk without asking engineers to stop talking to recruiters. Firms can provide a disposable, isolated environment, such as a cloud virtual machine with no access to company systems, and ask staff to run any external code there. The environment is cheap, and it turns a policy that engineers would sidestep into one they can follow. Engineers who are exploring a move can use it without telling anyone why.

The engineers who hold the keys

The advisory noted that the campaign aimed at people in system administration and development roles. The choice is deliberate. Those people reach production systems, the live systems that customers actually use; cloud consoles; code repositories, where the firm’s software is stored and changed; build pipelines, the automated assembly lines that turn code into running software; and, at crypto firms, the systems that hold or sign for digital assets. Compromising one of their machines can lead directly to the most valuable assets in the firm.

Why crypto firms were first

In crypto businesses, the stakes are stark because stolen assets can move irreversibly within minutes. Later press reporting indicated that the Ronin compromise began with an engineer who responded to a fake job offer, and that the attackers then reached the validator keys. Ronin’s operators also said a temporary arrangement had left one external validator’s signature available through their own systems, which gave the attackers the fifth key they needed.

Crypto firms were also young, fast-growing and often run by small engineering teams with broad access. Controls that a bank built over decades, such as segregation of duties and formal change management, were often thin or absent. That made them the obvious first target, not the only one.

The same logic in conventional finance

The logic carries over to conventional finance. Consider an engineer with access to payment release systems, or a database administrator for core banking, the central system that keeps a bank’s accounts and balances. Add a cloud administrator with broad rights. Each is a high-value target for any well-resourced adversary. A recruitment approach is a cheap way to reach them.

Conventional payments are not always irreversible, but they are fast. Wire transfers and instant payments can leave the institution before anyone notices. A compromised engineer who can change payment routing, beneficiary data or approval thresholds may be enough for a large loss.

Vendors’ engineers count too

The people who hold the keys do not all work for the firm. Wallet software providers, custody technology vendors, core banking processors, payment gateways and managed service providers employ engineers whose access reaches into their clients’ systems. A compromise at a supplier can deliver an attacker to many clients at once. Firms that map only their own staff miss that part of the exposure.

Supplier engineers are also harder to protect. The firm cannot train them directly, check their devices or watch their sessions. It can require, by contract, that suppliers apply equivalent controls to staff with access to its systems. It can also design its own approvals so that a compromised supplier cannot complete a high-value action alone. And it can ask suppliers to report promptly when one of their engineers is compromised, even if no client data appears to be affected.

Mapping who matters

Firms rarely know which employees are being approached. A short, periodic exercise helps: list the people whose single compromised device could move money, change production code or read sensitive data in bulk. That list defines who needs the strongest controls and the most specific training. In most firms it is short enough to manage individually.

Suppose a mid-sized payments company runs the exercise for the first time. Leaders expect a list of a few senior engineers. The actual list is longer and more surprising. It includes a contractor who maintains the deployment pipeline and two support engineers who can reset administrator accounts. It also includes a data analyst with read access to the full customer database for a project that ended a year ago. None of them had been treated as high-risk. The exercise takes an afternoon, and its most valuable result is removing access that nobody needed any more.

Mapping the paths as well as the people

People are only half of the map. The other half is paths: the routes from an ordinary laptop to a valuable system. A developer may have no direct access to production, yet hold a token that lets the build pipeline deploy code there. A support engineer may be able to reset the password of someone who does. Each indirect path is a way around controls designed for the direct one. Mapping them takes more effort than listing people, and it is where firms usually find their largest surprises.

Keeping one mistake small

If some approaches will succeed, the goal is to make sure one success cannot become a catastrophe. That calls for layers, each of which assumes the one before it might fail.

Separate everyday work from privileged work

Workstations used by engineers and administrators can block unapproved software through application allowlisting, which the advisory recommended, with a fast path for legitimate requests so developers do not route around the rule. Privileged actions can require a separate hardened device or a managed privileged session, a controlled, recorded channel used only for sensitive administrative work. Then a compromise of the laptop used for email, browsing and side projects does not expose production credentials.

Short-lived credentials help in the same way. Access to production or to signing systems can be granted for a task and expire within hours, rather than sitting permanently on a laptop. Malware that steals a credential gains a window, not a standing key.

Watch for the unusual

Monitoring adds a layer behind those barriers. Endpoint tools on engineering machines can flag newly installed applications that are unsigned or rare across the firm, and outbound connections to infrastructure never seen before. An unsigned application is one whose maker has not attached a verifiable digital signature, a basic sign of legitimacy. A trojanized trading application installed by one developer stands out against a fleet where nobody else runs it.

That signal is cheap to collect and is most useful when someone reviews it daily. Identity systems can add a second signal: a privileged session from a new device, location or time of day for that user.

Remove single points of failure

The second set of controls removes single points of failure. Signing keys, wallet controls and high-value payment releases can require approval from several people on separate devices, so that no one compromised machine can move assets. The approvers should be truly independent: different teams, different devices and, where keys are concerned, different organizations or hardware security modules.

Approvers also need to see what they are approving. A multi-signature scheme in which each approver signs whatever the interface shows them can be defeated by compromising the interface. Independent verification of the transaction details, on a separate device or channel, closes that gap.

Code changes to payment or settlement systems can require review by a second engineer and deploy only through a pipeline that records who approved what. The pipeline itself needs the same protection, because an attacker who controls it controls everything it deploys.

Designing key custody for compromise

For firms that hold digital assets, custody design decides how much one compromise can take. Most hold the bulk of assets in cold storage, keys kept offline and used rarely under strict procedure, and only a working balance in hot wallets for routine withdrawals. Keys can be held in hardware security modules, tamper-resistant devices that sign without ever exposing the key, or split using multi-party computation so that no single machine ever holds a whole key.

Operational limits add further protection. Withdrawals above set amounts can require additional approvals or a time delay, during which unusual movements can be stopped. Withdrawals can be restricted to pre-approved destination addresses, with any change to that list itself subject to multi-person approval. These limits trade convenience for containment, which is the right trade for the largest balances.

The same thinking applies to conventional payments. Release limits, call-back verification for new beneficiaries and dual control on changes to payment templates are the bank equivalents. Many institutions already have them for fraud reasons; the task is to make sure an engineer with system access cannot bypass them from behind.

The cost of control

These controls cost speed, and teams resist them during urgent releases. Defining narrow, logged exceptions in advance keeps them in place when pressure rises. An exception process designed in a calm moment is far safer than one improvised during an outage.

They also cost money and talent. Hardened devices, privileged access tools and hardware key storage are not cheap, and some engineers find the friction frustrating enough to leave. The answer is to concentrate the friction on the short list of people and paths that matter, and keep everyone else’s work as smooth as possible.

Respond fast

The third set is response. If an engineer reports running a file from a recruiter, the security team should treat it as a possible compromise of everything that engineer can reach. That means a playbook to isolate the device, revoke sessions, rotate credentials and keys, review recent privileged activity and check repositories and pipelines for changes. The faster a report arrives and is acted on, the less an intruder can do with the access.

Speed depends on the culture described earlier. A report that arrives within the hour, from an engineer who felt safe making it, is worth more than any monitoring tool.

Watch the door in the other direction

Hiring runs in both directions. Financial firms also receive applications, and the same state has used fake candidates to seek remote technical jobs. A month after this advisory, in May 2022, the State Department, Treasury and the FBI issued guidance warning that North Korean IT workers were seeking freelance and remote work under false identities. Identity verification for new hires, especially remote ones, and staged grants of privileged access during onboarding protect against that reverse route. A new engineer does not need the keys to the payment system in week one.

Rehearse the first hour

A tabletop exercise built on this scenario is cheap and revealing. An engineer reports, at four in the afternoon, that a test from a recruiter behaved oddly on their work laptop. The team works through who is told, who decides to isolate the device, how sessions and keys are revoked, who checks the pipelines, and who speaks to the engineer. Most firms find at least one step nobody owns, often key rotation for systems managed by a vendor.

Evidence an examiner will ask for

Examiners and auditors tend to ask for the same documents after an incident of this kind: the list of privileged users and when it was last reviewed, access logs for privileged sessions, records of approvals for high-value transactions, the training content and attendance, and the incident response record with timestamps. A firm that keeps these current can show that its controls existed and worked, even if one engineer was fooled.

Measures that show progress

A few measures tell leaders whether the program is working. Count the people and paths on the high-risk list, and the standing privileged credentials that never expire. Track the share of privileged actions performed from hardened devices or sessions. Measure the time from a report to device isolation, and count reports of suspicious recruiters. A rising report count is good news. It means engineers trust the route.

Leaders should resist turning these into targets for individual teams. A team measured on fewer incidents has a reason to report fewer. The purpose is to see whether the firm’s exposure is shrinking, and the numbers are most useful when they are reviewed with the people who produce them.

The objections

The strongest objection is that crypto thefts are a crypto problem. Banks have reversible payments, examiners, segregation of duties and decades of controls. That is partly fair: a conventional bank is much harder to drain through one laptop. But the attack targets people and access, not the asset class. Any firm whose engineers can change payment logic, approve releases or read customer data in bulk has the exposure. The controls that protect it were often designed with insiders and outages in mind, rather than a patient state adversary.

A second objection is that the controls slow engineering and drive talent away. They can, if applied to everyone. Applied to a short list of people and paths, with good tooling, the slowdown is small. The comparison is with the cost of one successful approach, which in this period ran to hundreds of millions of dollars.

How the stakes differ across financial firms

The same technique lands differently depending on the type of firm, the assets it holds and the rules it answers to. Firms should check with counsel on which requirements apply to them.

Crypto exchanges and custodians

Exchanges and custodians hold customer assets directly, often in hot wallets, keys kept online for fast withdrawals. Their exposure is the most immediate. In New York, firms licensed by the Department of Financial Services as virtual currency businesses are covered by its cybersecurity regulation, Part 500, which requires access controls and multi-factor authentication. Elsewhere, oversight was lighter and varied by state, and many decentralized finance protocols had no regulator at all.

Decentralized protocols and bridges carried a particular weakness. Their multi-signature controls were sometimes held by a small group of developers or early backers, some of them anonymous, using ordinary laptops. The independence of the signers was asserted more often than tested.

Banks and credit unions

Banks and credit unions answer to their prudential regulators: the OCC, the Federal Reserve and the FDIC for banks, the NCUA for federally insured credit unions. Examiners use the interagency guidance published through the Federal Financial Institutions Examination Council. Its August 2021 guidance on authentication and access called for stronger controls on privileged users and for risk assessments that consider social engineering. A theft traced to one engineer’s laptop would raise questions about privileged access, segregation of duties and payment approvals.

Smaller institutions often rely on core processors and managed service providers for much of their technology. For them, the engineers who hold the keys may work for a vendor. Contracts and vendor oversight have to reach those people, through requirements for privileged access controls at the provider and evidence that they work.

Broker-dealers and investment advisers

Broker-dealers are overseen by the SEC and FINRA, and must protect customer records and information under Regulation S-P, which also applies to registered investment advisers. Their engineers may control trading systems, client account data and connections to clearing firms. A compromise there may not drain an account as quickly as a crypto theft, but unauthorized trading or data theft carries its own regulatory and reputational cost.

Fintechs and payment companies

Fintechs that are not banks often fall under the Federal Trade Commission’s Safeguards Rule, which the FTC updated in late 2021 to require more specific controls, including multi-factor authentication and access restrictions. Many also face requirements from bank partners and card networks. Young fintechs tend to share crypto firms’ profile: small teams, broad access and pressure to ship. They are attractive targets for the same reasons.

Sanctions and reporting

Sanctions add a layer for every type of firm. When stolen funds flow to a sanctioned state, firms that later handle those funds face compliance questions. Treasury’s decision in April 2022 to list an address tied to the Ronin theft made that concrete: exchanges and other businesses that touched the funds had to screen for it.

Reporting obligations also apply. Banks file suspicious activity reports; public companies must consider disclosure; many firms have contractual duties to notify partners. Knowing in advance who decides on each of those, and on what evidence, keeps a fast-moving incident from becoming a compliance failure as well.

Insurance is not a backstop

Many firms assume insurance will cover a theft of this kind. Coverage depends heavily on policy wording. Crime and fidelity policies, cyber policies and specialist digital asset policies each treat social engineering, employee error and digital assets differently. Limits for social engineering losses are often far smaller than the potential loss. Firms holding large digital asset balances have found coverage scarce. Risk and legal teams should read the policies against this scenario before relying on them.

Staff are both the target and the defense

Across all of these firms, the engineers being approached are among the most valuable people the firm employs. Treating them as suspects backfires; equipping them to recognize and report approaches protects both them and the firm.

What one laptop can reach

• Who are the ten or twenty people whose single compromised laptop could move money, change production code or read customer data in bulk, and when was that list last reviewed?
• Can any one person, on one device, move a large sum or sign for digital assets?
• If an engineer told us today that they had run a file a recruiter sent, what would happen in the next hour?
• Do engineers have a safe, isolated place to run external code, and would they feel safe telling us they had been talking to a recruiter?
• How do we verify the identity of remote technical hires, and how quickly do they get privileged access?

With hindsight

North Korean operations against the crypto industry kept growing after 2022. What the April advisory described as a campaign became a sustained enterprise.

More thefts, the same name

In January 2023, the FBI attributed the June 2022 theft of about $100 million from the Harmony Horizon bridge to Lazarus Group and APT38. In August 2022, Treasury had sanctioned Tornado Cash, a cryptocurrency mixing service, saying it had been used to launder proceeds of the Ronin theft among others. That sanction was later contested in court, and Treasury removed it in March 2025.

In December 2024, the FBI and Japan’s National Police Agency attributed the May 2024 theft of about $308 million in bitcoin from the Japanese exchange DMM Bitcoin to TraderTraitor. Their account matched the 2022 advisory closely. An operator posing as a recruiter contacted an employee of a wallet software company and sent a “pre-employment test” that compromised the employee’s machine. The attackers later used that access to manipulate a legitimate transaction.

In February 2025, the FBI attributed the theft of about $1.5 billion in digital assets from the exchange Bybit, one of the largest thefts on record, to the same TraderTraitor activity. The companies involved later said the attack ran through a compromised developer machine at a third-party wallet software provider. The name that first appeared in a 2022 advisory was attached, nearly three years later, to a theft more than twice the size of Ronin.

Reading advisories as previews

That progression matters for how leaders read threat advisories. An advisory describing a technique against one industry is often an early look at a capability that will be refined, scaled and turned toward others. The DMM and Bybit cases also showed the technique moving up the supply chain, from the target firm’s own engineers to engineers at the software providers it depended on.

Fake recruiting remained a common technique against developers. Security researchers tracked campaigns, under names such as Contagious Interview, in which fake interviewers asked software developers to download and run code as part of a technical test. It continued to work for the same reasons it worked in 2022: it is personal, it happens outside corporate channels, and it targets the people with the most access.

The reverse route

The reverse pattern also became a major concern. US authorities warned repeatedly about North Korean IT workers who won remote jobs at US companies under false identities to earn revenue for the regime. In January 2025 the FBI reported that some were also extorting employers with stolen data. The hiring process became a route in from both sides: fake recruiters reaching real engineers, and fake engineers reaching real employers.

Rules caught up in places

Regulation moved, unevenly. New York’s amended Part 500, finalized in November 2023, added explicit requirements for privileged access management and phased in broader multi-factor authentication. Financial firms more generally responded with stronger identity checks in hiring, hardened privileged access and multi-party approval for asset movements.

What held up

The advisory’s picture of the threat held up well. The same group and the same lure reappeared in the DMM Bitcoin case, and the same group in the Bybit theft.

By this point in 2026, recruitment-based social engineering and fraudulent candidates are standard topics in financial sector threat briefings. The firms that fared best had assumed an approach would eventually succeed and limited what one compromised engineer could do. Bybit’s loss showed that even multi-signature controls fail when the approvers cannot independently verify what they sign.

No training program will stop every well-crafted approach to every engineer. Someone will be fooled; the question worth asking is what that person’s laptop can reach when they are, and whether the same is true of the laptops at the firm’s key vendors.