JINX-0164: Custom macOS Malware & Fake Recruiters Hitting Crypto Devs
Just reviewed the Wiz research on JINX-0164, and it’s a stark reminder that macOS is no longer a "safe" OS for high-value targets. They are orchestrating campaigns against crypto firms using fake recruiter personas—likely sending poisoned documents or fake interview links.
What stands out is the bespoke macOS malware and the intent to pivot to CI/CD infrastructure. Once they compromise a developer's machine, they aren't just looking for crypto wallets; they are likely hunting for AWS/GCP credentials or SSH keys to the build pipeline.
Since this is custom malware, signature-based detection might lag. You might want to check for unsigned binaries attempting to establish persistence. Here is a Python snippet to scan for unsigned apps in common persistence directories:
import subprocess
import os
paths = ["~/Library/LaunchAgents", "/Library/LaunchAgents"]
for path in paths:
p = os.path.expanduser(path)
if os.path.exists(p):
for root, dirs, files in os.walk(p):
for file in files:
if file.endswith(".plist"):
full_path = os.path.join(root, file)
# Check codesignature
result = subprocess.run(['codesign', '-dv', full_path], capture_output=True, text=True)
if "code object is not signed" in result.stderr:
print(f"[!] Unsigned persistence agent: {full_path}")
How is everyone handling the "Bring Your Own Device" (BYOD) risk for devs handling CI/CD secrets? Is MDM strict enforcement mandatory now, or are people relying on endpoint isolation?
Great post. We’ve seen a similar uptick in 'HR' phishing targeting our engineering team. The macOS angle is concerning because many orgs don't run EDR on Macs as aggressively as on Windows.
We deployed Osquery to monitor for changes to /etc/hosts and unusual launchd modifications. Also, blocking script interpreters (Python/Bash) from downloading payloads directly via curl is a solid interim control until signatures catch up.
The pivot to CI/CD is the real killer here. If they get a dev's GitHub token, it's game over for the repo.
I'd recommend checking for TCC (Transparency, Consent, and Control) bypasses in your telemetry. If a unsigned app is trying to access Downloads or Desktop without user prompt, kill it immediately.
log show --predicate 'eventMessage contains "kTCCService"' --last 1h
We enforce strict signing policies via Jamf. Any binary not signed by our dev certificate gets blocked from execution. It causes some friction for the devs when they want to run random ad-hoc tools, but it stops this kind of bespoke malware dead in its tracks.
Also, hardware keys (YubiKeys) for SSH auth are a must-have to mitigate credential theft.
That friction from strict signing is worth it, ZeroDayHunter. To augment that, we audit endpoints for unsigned disk images landing in Downloads, as that's the primary dropper for these campaigns. This quick snippet flags unsigned DMGs for review:
find ~/Downloads -name "*.dmg" -exec sh -c 'codesign -dv "$1" 2>&1' \; | grep -B1 "not signed"
It catches the payload before a user even attempts to run it.
To build on that, we also audit persistence mechanisms heavily. Many of these malwares rely on LaunchAgents. You can quickly scan for non-Apple persistence entries with:
ls -l ~/Library/LaunchAgents/ | grep -v "com.apple"
Finding anything here that isn't signed or recognized by your team is a huge red flag for potential C2 communication.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access