Drift's $285M Heist: The Six-Month Social Engineering Campaign
The revelation that the $285M Drift heist was the result of a six-month social engineering campaign is chilling. While the technical exploit (the nonce issue) was the mechanism, the true entry point was human. DPRK actors starting in Fall 2025 systematically groomed targets, likely through fake job offers or collaborative coding projects on platforms like LinkedIn or Telegram.
This highlights a massive gap in our security posture: we patch code, but we can't patch people. The attackers didn't just find a bug; they built a relationship to bypass the "human firewall."
Since these campaigns often rely on delivering payloads via seemingly legitimate dev tools or scripts, I've updated our detection rules to look for specific anomalous PowerShell activity often seen in these initial stages. If you're hunting, check for mshta executing remote content or PowerShell downloading strings from obscure IP spaces.
Here is a KQL query for Sentinel to hunt for potential loader activity associated with these long-term intrusions:
DeviceProcessEvents
| where ProcessVersionInfoOriginalFileName =~ "powershell.exe" or ProcessVersionInfoOriginalFileName =~ "mshta.exe"
| where ProcessCommandLine contains "DownloadString" or ProcessCommandLine contains "http"
| where InitiatingProcessFileName in ("explorer.exe", "cmd.exe", "word.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc
Given the sophistication of these long-term SE ops, what frameworks are you using to validate the identity of "recruiters" or "partners" before any file sharing occurs?
The timeline is the scariest part. Six months means they likely had access to internal comms or project management tools well before the exploit was deployed. We've started enforcing 'Zero Trust' on internal docs—even for devs—so any request to view source requires secondary approval via a different channel (e.g., Slack to verify an email request). It adds friction, but it kills the 'lone wolf' impersonation angle.
This tracks with the recent shift to 'Dev' targeting. They aren't just spamming employees anymore; they are targeting the specific people with write access to smart contracts. If you have devs on GitHub or LinkedIn, they need to know that a 'Senior Rust Developer' DM from a 'Tier 1 VC' is almost certainly Lazarus. We use a dedicated 'burner' account for initial external comms just to verify legitimacy before moving to official channels.
The grooming phase is notoriously silent, but lateral movement leaves tracks. We started correlating SSO logs with HR platform activity. If a dev logs in from a new ASN or device ID without a corresponding employment status change, we flag it for manual review.
For teams using Sentinel, here’s a KQL snippet to hunt for these anomalies:
SigninLogs
| where Result == "0"
| where DeviceDetail.isCompliant == false
| summarize Count() by UserPrincipalName, Location
It’s not a silver bullet, but it caught a similar test in our lab environment.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access