JINX-0164 Uses LinkedIn Lures and macOS Malware to Target Crypto Developers

A newly tracked threat actor called JINX-0164 is targeting cryptocurrency organizations by using LinkedIn social engineering, fake meeting pages, and custom macOS malware to compromise developer machines and reach software delivery systems.

Wiz CIRT and Wiz Research said the actor has been active since at least mid-2025 and appears financially motivated. The campaign targets developers through recruiter-style or business outreach, then uses malware to steal credentials, cloud keys, GitHub tokens, and cryptocurrency wallet data.

The campaign matters because the attackers are not stopping at one infected Mac. In documented cases, they moved from a compromised developer laptop into internal repositories, CI/CD systems, and package distribution workflows, turning trusted development infrastructure into a possible infection path for other employees.

How the LinkedIn Attack Starts

The attack usually begins with a believable LinkedIn message. The actor may pose as a recruiter, business partner, or industry contact and invite the target to a virtual meeting.

The meeting link points to a fake conferencing site that impersonates familiar services such as Microsoft Teams or Slack. The page then shows a technical problem and tells the victim to download a “fix” for audio or meeting access.

That fake fix runs a bash script on macOS. The script downloads a payload that masquerades as an audio component named coreaudiod and saves it under a ChromeUpdater name before launching it with launchctl.

Attack stage	What happens	Why it matters
LinkedIn outreach	The attacker builds trust through a recruiter or business lure	Victims are less likely to question the meeting invite
Fake meeting page	The target is sent to a spoofed conferencing or support page	The download looks like a normal troubleshooting step
macOS payload	AUDIOFIX is installed through a bash dropper	The attacker gains credential theft and remote access capability
Developer infrastructure access	Stolen tokens are used against repositories and CI/CD systems	The compromise can spread through trusted code workflows

AUDIOFIX Steals Developer and Crypto Secrets

The main malware used in the LinkedIn lure chain is AUDIOFIX, a Python-based macOS infostealer and backdoor. It targets both Intel and Apple Silicon Macs.

Once running, AUDIOFIX can steal data from macOS Keychain files, browsers, password managers, SSH keys, local configuration files, cloud credentials, shell history, and cryptocurrency wallet extensions. It also targets active sessions from communication tools such as Discord, Slack, and Telegram.

This gives the attacker several ways to expand the breach. GitHub tokens can open repository access, cloud keys can expose infrastructure, and communication sessions can help the attacker monitor internal conversations or impersonate employees.

JINX-0164 Moves Into Code Repositories

Wiz found that the actor used stolen credentials to move from developer endpoints into code distribution systems and development infrastructure. In one case, the attacker injected the AUDIOFIX payload into internal repositories to infect additional developers who pulled and built affected branches.

The actor also used deceptive Git tactics. That included changing committer names and email fields to impersonate legitimate developers, pushing directly to main where protections were weak, and hijacking branches when direct main-branch access was not possible.

Wiz’s findings show why developer laptops now count as part of the software supply chain. A compromised endpoint can become the bridge between a social engineering attack and a wider internal code compromise.

The npm Supply Chain Attack Hit @velora-dex/sdk

JINX-0164 has also been linked to a public package compromise. StepSecurity analyzed a registry-only attack against @velora-dex/sdk v9.4.1, a DeFi SDK used by cryptocurrency developers.

The malicious version was published to npm on April 7, 2026. It added three lines to dist/index.js that decoded and ran a shell command the moment the package was imported. This was not a normal install-hook attack, so disabling package scripts would not stop the payload from running after import.

The payload fetched a shell script from attacker infrastructure and installed MINIRAT, a Go-based macOS backdoor. The GitHub source repository was not modified, which suggests the malicious package was published directly to the npm registry outside the normal source workflow.

MINIRAT Gives Attackers Persistent Remote Access

MINIRAT is lighter than AUDIOFIX, but it still gives attackers useful control. It can register infected machines with command-and-control infrastructure, upload and download files, and execute shell commands.

That makes it useful in a supply chain compromise. A developer may import a package as part of a project build, trigger the payload, and unknowingly give the attacker remote access to the workstation.

The attack also shows why crypto-focused packages are attractive targets. A single compromised SDK can reach developers who already work with wallets, private keys, token swaps, trading tools, and sensitive infrastructure.

Why GitHub Commit Verification Matters

One of the clearest defensive lessons from this campaign is that commit identity cannot be trusted only by name and email. Git allows users to set author and committer identity locally, which attackers can abuse after gaining repository access.

GitHub Vigilant Mode helps by marking commits and tags with verification statuses. GitHub says this can help other users gain more confidence in whether commits attributed to a developer were actually created by that developer.

In the JINX-0164 case, unverified commit information helped surface developer impersonation attempts. Teams should combine signed commits with branch protection, required reviews, audit logs, and CI/CD secret controls.

What Security Teams Should Look For

Defenders should treat this campaign as an endpoint, identity, repository, and cloud incident at the same time. The attacker’s path moves across those layers quickly once a developer machine is infected.

Security teams should search for fake meeting domains, suspicious launchctl jobs, malware file paths, unexpected VPN provider traffic, GitHub token use from unusual IP addresses, deleted workflow logs, and unverified commits pushed from developer machines.

They should also check whether developers installed @velora-dex/sdk v9.4.1. The @velora-dex/sdk compromise analysis recommends treating affected machines and all secrets accessible from them as compromised.

• Audit developer Macs for suspicious LaunchAgents and launchctl jobs.
• Search for ChromeUpdater, coreaudiod, profiler, and unusual files in macOS application support paths.
• Review GitHub audit logs for unverified commits, unusual pushes, and unexpected workflow activity.
• Rotate GitHub, npm, cloud, SSH, and CI/CD secrets from any exposed developer machine.
• Check lockfiles and dependency trees for @velora-dex/sdk v9.4.1.
• Review outbound traffic to known JINX-0164 domains and payload servers.
• Watch for unexpected VPN usage from developer endpoints and cloud consoles.

Recommended Defenses for Crypto and Web3 Teams

Crypto organizations should assume developers are high-value targets. Recruiter lures, fake meeting apps, and npm package compromises all work because developers regularly install tools, join calls, and handle sensitive repositories.

Teams should enforce phishing-resistant MFA, use hardware-backed keys for GitHub and cloud access, limit long-lived tokens, require signed commits, and prevent direct pushes to protected branches. They should also isolate CI/CD secrets so a stolen developer token cannot expose the entire pipeline.

GitHub’s commit verification guidance should be part of a larger repository security policy. Verification helps, but it works best with vigilant mode, required reviews, branch protections, audit logging, package provenance, and fast token revocation.

Why This Campaign Is Hard to Contain

JINX-0164 combines several attack paths that many companies still treat separately. It starts with social engineering, lands on macOS endpoints, steals credentials, moves into source control, and can poison software dependencies.

That makes cleanup more complicated than removing one malware file. If a developer Mac was compromised, responders need to review local secrets, cloud access, repository activity, package publishing history, CI/CD workflows, and any code pulled or built by other developers during the exposure window.

The safest response is to assume stolen credentials were used quickly. Rotate tokens, verify repository history, rebuild affected machines, and treat any unexpected package publication or unsigned commit as a possible supply chain incident.

FAQ