UNC4899, Crypto, and the AirDrop Vector: Blending Physical & Digital Ops
Just caught the latest report on UNC4899 (also tracked as Jade Sleet) leveraging AirDrop to compromise a crypto firm. It’s a stark reminder that social engineering isn't just phishing emails anymore; the threat model is expanding to physical proximity. The fact that a developer accepted a trojanized file via AirDrop on a work device highlights a significant gap in our 'human firewall' training.
While the report attributes this with moderate confidence to the state-sponsored group, the technical execution is fascinating. They bypassed the traditional perimeter entirely. For macOS environments, AirDrop can be a massive blind spot if not strictly managed via MDM profiles.
To lock this down, we need to ensure AirDrop is disabled or restricted to 'Contacts Only' across the board. You can verify current settings on endpoints using the following:
defaults read com.apple.sharingd DiscoverableMode
If you need to enforce a lockdown immediately without waiting for MDM propagation, you can script a disable command (though a reboot is often required for full effect):
sudo /usr/libexec/PlistBuddy -c "Set :AirDropEnabled:Enabled false" /Library/Preferences/com.apple.sharingd.plist
Given the high-value targets (crypto keys), the payoff for a physical access attempt is massive for groups like UNC4899.
Has anyone implemented successful technical controls to block AirDrop on macOS without breaking legitimate workflow for creative teams? Or is strict policy the only way forward?
The telemetry gap here is the real problem. AirDrop establishes a peer-to-peer connection via Bluetooth and Wi-Fi Direct, which often doesn't hit the corporate DNS or HTTP proxies. Unless your EDR is monitoring for process creation from ~/Downloads immediately following a sharingd event, you're flying blind. We've started correlating opendirectoryd logs with execution alerts to catch this, but false positives are high.
We enforce a strict 'Contacts Only' policy via Jamf configuration profiles, but honestly, for high-value engineering or finance teams, you should just disable it entirely. The friction is negligible compared to the risk of a supply chain injection like this. If an attacker is close enough to AirDrop a file, they're close enough to tailgate or use a rogue USB. Physical security controls need to catch these vectors before the device even receives the file.
I'm curious about the trojanized file itself. Was it a signed DMG bypassing Gatekeeper? If UNC4899 is using valid developer certs (or exploiting CVE-2025-XXXX related to signature validation), simply blocking the transfer method might not be enough if they pivot to iMessage or email attachments. We need to assume the file is the threat, not just the transport vector.
On the red team side, we often see users leave AirDrop on 'Everyone' for convenience. If you can't enforce a total ban via MDM immediately, a local audit script is a quick win to visualize your exposure. You can use the following command on endpoints to check the current discovery mode:
defaults read com.apple.sharingd DiscoverableMode
If it returns `Off`, you're safe. If it returns `Everyone`, you have a specific target for immediate remediation. It’s faster than waiting for Jamf reports to propagate during a critical incident.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access