Contagious Interview Reloaded: DPRK Fake macOS Updates Deliver Crypto-Stealers
Just caught the latest write-up on The Hacker News regarding the resurgence of the Contagious Interview campaign. The DPRK-linked actors are upping their game with a macOS malvertising push that leads users to a fake, full-screen "software update" portal. It’s a slick social engineering move—mimicking the exact UI users expect to see during an OS upgrade.
What stands out is the delivery mechanism. Instead of just a phishing email, they are using the ad ecosystem to funnel traffic to these malicious pages. The end goal is a crypto-stealer, likely deployed via a malicious DMG or PKG that the user is tricked into installing.
For incident responders, here are a few quick checks to run on potentially compromised Macs. First, look for unsigned applications or recent modifications in the LaunchDaemons folder:
ls -la /Library/LaunchDaemons/ | grep -v "com.apple"
You should also verify the quarantine attributes of recently downloaded files to see if they originated from the web:
xattr -l /Applications/UnsureApp.app
Since this is malvertising, perimeter filtering is key. However, convincing internal users to verify URLs before downloading "updates" is the hard part. How is everyone handling this specific "fake update" social engineering vector? Are you relying purely on technical controls like Gatekeeper, or has anyone had success with specific user awareness campaigns?
We've started flagging any download of .pkg files originating from non-Apple CDN IP ranges. Our SIEM rule is pretty simple but effective for catching this early:
DeviceProcessEvents
| where FileName in~ ("installer", "pkgutil")
| where InitiatingProcessFileName != "softwareupdated"
The full-screen HTML overlay is particularly nasty because it often disables interactions with the rest of the browser. We're recommending users force-quit the browser via Activity Monitor if they see a "stuck" update screen.
MDM is your best friend here. I've pushed a configuration profile that disables the "Open any file" option in Gatekeeper for standard users, forcing them to go through IT for unsigned packages. It breaks a few dev workflows, but it stops these droppers cold.
Also, check for new login items. These malware families often hook into LaunchAgents:
osascript -e 'tell application "System Events" to get the name of every login item'
If you see items you don't recognize, nuke them immediately.
The HTML/CSS they use for the fake update screen is getting scarily accurate. I tested a similar clone recently, and even the progress bar animation mimics Big Sur/Monterey perfectly.
One tip for devs: If you have to allow PKG installs for your remote workers, ensure you validate the hash before execution. Don't just trust the download link from the "update" page.
shasum -a 256 ~/Downloads/update.pkg
Compare that output against your vendor's official checksum. It saves you every time.
To complement the network rules, inspecting runtime behavior is critical. These payloads typically execute immediately after a DMG is mounted. I recommend an osquery hunt for child processes of diskimages-helper running outside of system directories.
SELECT pid, name, path, cmdline FROM processes WHERE parent LIKE '%diskimages-helper%' AND path NOT LIKE '/System/%';
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access