When the Justice Department moved to seize or restrain more than $1.2 billion stolen from Binance, it was part of a larger effort that saw $2.7 billion frozen across several cryptocurrency platforms. That freeze worked because some platforms acted fast. The theft itself, attributed to TraderTraitor, succeeded because defenders were still organized around outdated threat models.
If you run compliance for an exchange, custodian, or any firm dealing with digital assets, these are the mistakes that keep showing up.
Why These Mistakes Keep Happening
Compliance programs are built around audit cycles, while threat actors like TraderTraitor and APT38 operate on campaign cycles. The FBI reports that FaceStealer pulled in more than $400 million over 18 months, longer than most control-testing windows. A program focused on annual attestations will always lag behind a campaign that evolves monthly.
There's also an ownership gap. Social engineering sits between security, HR, and compliance, so no one owns it end to end. The mistakes below thrive in that gap.
Mistake 1: Treating Social Engineering as a Training Problem
Why It Happens: Awareness training is easy to document and audit. A completion rate looks like a control.
The Consequence: FaceStealer defeats awareness. The FBI describes it as capable of deceiving "even the most experienced technical and security conscious computer user." Attackers send Calendly invitations from accounts stolen from prior victims, so the sender is a real, trusted contact. They replay videos of past victims to fake a crowded meeting, then stage a fake technical error and offer a "fix" that installs a cookie harvester, keylogger, screen capturer, and backdoor.
The Fix: Move from awareness to enforced technical controls. Restrict software installation through application allowlisting. Require that meeting clients be installed only from managed sources. Treat any in-meeting prompt to run a fix as a reportable event with a defined escalation path. Map these to the relevant functions in NIST Cybersecurity Framework (CSF) 2.0 (Protect and Detect) rather than filing them under training.
Mistake 2: Assuming a Trusted Identity is a Verified Identity
Why It Happens: Business workflows run on relationships. If a known contact proposes a call, friction feels rude.
The Consequence: In the FBI's account, hackers hijacked Telegram, LinkedIn, Slack, and Discord accounts, then contacted the victim's connections, sometimes months later. With access to prior chat histories, they tailored messages to high-value contacts. Some used AI-generated deepfakes of prominent cryptocurrency figures. Your contact's account can be real and still be hostile.
The Fix: Build out-of-band verification into policy for any request that grants access, moves funds, or asks someone to install software. Confirm through a separate, pre-established channel. Apply Zero Trust Architecture principles to communications, not just networks: no channel is trusted by default.
Mistake 3: Scoping the Threat Model to Your Own Perimeter
Why It Happens: Frameworks like ISO/IEC 27001 define an information security management system around your assets and your suppliers. Individual employees' personal accounts and open-source dependencies often fall outside the scope.
The Consequence: The FBI says North Korean actors are targeting developers and maintainers of widely downloaded software libraries, with attempts directed at NPM and Rust crates maintainers. For an exchange, a compromised dependency or a developer's compromised personal account is a path into production.
The Fix: Extend third-party risk assessment to software supply chain exposure. Inventory critical open-source dependencies. Require that developers with production access use managed devices for any work-related video meeting. Document the decision in your Statement of Applicability, including why any exclusion is acceptable.
Mistake 4: Building Transaction Monitoring for Yesterday's Laundering Patterns
Why It Happens: Rules-based monitoring is defensible to examiners because it's explainable. Rules, however, encode known typologies.
The Consequence: Elliptic reports that North Korea's launderers are creating worthless tokens and moving stolen assets through decentralized exchange liquidity pools, so no funds pass directly from the wallets holding stolen assets to the wallets receiving them. The Justice Department notes the actors continue to launder through bridges, mixers, and exchanges. Direct-link tracing alone misses this.
The Fix: Add blockchain analytics that trace through liquidity pools and flag newly minted, thinly traded tokens as intermediary risk. Revisit your risk assessment against the FATF Recommendations on virtual assets. Test your monitoring against laundering scenarios that break direct wallet-to-wallet links, and document the results for examiners.
Mistake 5: Treating Law Enforcement Contact as a Post-Incident Task
Why It Happens: Legal and compliance teams worry about disclosure, so outreach waits until facts are settled.
The Consequence: The Justice Department credited immediate action for freezing billions in stolen assets "before they got beyond law enforcement reach." Speed was the variable. Assets that moved before a freeze were gone.
The Fix: Establish pre-incident relationships. Name a contact for the Justice Department's digital asset liaison function and the FBI. Draft a freeze-request playbook within your Computer Security Incident Response Team procedures: who authorizes contact, what wallet data you hand over, and how you coordinate with peer platforms. Rehearse it in tabletop exercises where the clock matters.
Prevention Checklist
- Social engineering controls include technical enforcement, not only training
- Application allowlisting blocks unapproved installs triggered by "meeting fixes"
- Out-of-band verification is mandatory for access, fund movement, and software installation requests
- Policy covers deepfake and replayed-video risk in live meetings
- Developers use managed devices for work-related video calls
- Critical open-source dependencies are inventoried and monitored
- Third-party risk scope includes software supply chain exposure
- Monitoring detects laundering through liquidity pools and newly created tokens
- Risk assessment is mapped to NIST Cybersecurity Framework (CSF) 2.0 and the FATF Recommendations
- Law enforcement contacts are named and a freeze-request playbook is tested
- Peer-platform coordination channels exist before an incident, not after
The FBI's warning is worth repeating to your board: if you can't imagine a scenario where you'd fall prey to this, you're not thinking creatively enough. Your compliance program should be.
