North Korean hackers use Git hooks to deliver cross-platform malware

North Korean threat actors are using malicious Git hooks to target software developers through fake job interviews and coding assessments.

The campaign is linked to the long-running Contagious Interview operation, which uses fake recruiter outreach to convince developers to clone and run attacker-controlled projects. The latest twist hides the malware loader inside Git hook files that can execute during normal development tasks.

BEST SPRING 2026 DEALS

Editor's Choice

Private Internet Access

Access content across the globe at the highest speed rate.

70% of our readers choose Private Internet Access

70% of our readers choose ExpressVPN

ExpressVPN

Browse the web from multiple devices with industry-standard security protocols.

Nord VPN

Faster dedicated servers for specific actions (currently at summer discounts)

The attack is dangerous because it abuses tools developers already trust. Instead of sending a suspicious attachment, attackers hand over a coding test that looks like a normal repository and waits for the developer to reach a Git action that triggers the malicious hook.

How the Git hooks attack works

The malicious repository contains a .githooks directory with a pre-commit hook. In legitimate projects, pre-commit hooks help teams run tests, check formatting, or block bad code before a commit goes through.

In this campaign, the hook acts as a lightweight malware loader. When triggered, it fingerprints the victim’s operating system and contacts attacker infrastructure to download the correct payload for that machine.

Researchers reported payload delivery for Windows, macOS, and Linux. That cross-platform design makes the campaign especially risky for developers, since many engineering teams use mixed operating systems.

At a glance

Why developers are being targeted

Developers make valuable targets because their devices often hold source code, SSH keys, API tokens, package registry credentials, cloud sessions, and cryptocurrency wallets.

The Contagious Interview campaign takes advantage of the hiring process. Attackers pose as recruiters, send realistic technical assignments, and pressure victims to run code locally as part of an interview.

This approach lowers suspicion because coding tests often require downloading a project, installing dependencies, and running build commands. Attackers use that routine workflow as cover for malware execution.

Git hooks give attackers a quieter trigger

Git hooks are built into Git. They let scripts run before or after events such as commits, checkouts, merges, and pushes.

That makes them useful for legitimate development work, but also attractive to attackers. A malicious pre-commit hook can run when the developer tries to commit changes, before the commit completes.

Reports also describe the use of post-checkout hooks in related activity. These can run when a developer switches branches, giving attackers another chance to execute code during normal repository use.

Cross-platform payloads increase the threat

The malicious hook checks the victim’s operating system and requests a matching payload from attacker-controlled infrastructure. Windows victims can receive a command-based payload, while macOS and Linux victims can receive shell-based payloads.

This gives attackers one entry point across several developer environments. It also allows them to reuse the same fake interview workflow against different targets without rewriting the entire attack chain.

The payloads are linked to malware families previously seen in DPRK-related developer targeting, including BeaverTail and InvisibleFerret. These tools can support credential harvesting, file theft, keylogging, browser data collection, and remote access.

Indicators of compromise

Why this attack can bypass developer caution

Many developers inspect application code before running it, but fewer check hidden folders, hook paths, or repository automation files with the same level of care.

Attackers exploit that gap. A small hook file can look less suspicious than a large executable or obvious malware script, especially inside a repository that appears to match a job assignment.

The use of a Vercel-hosted domain also helps the operation blend in. Developers often see Vercel, GitHub, package managers, and cloud-hosted assets during routine work, which can make malicious infrastructure feel less unusual at first glance.

How security teams can reduce exposure

Organizations should treat external coding tests as untrusted software. Developers should not run recruiter-provided repositories on primary workstations that contain production credentials, internal source code access, or saved browser sessions.

A safer workflow uses a clean virtual machine or disposable sandbox with no personal wallets, no SSH keys, no package registry tokens, and no active cloud sessions.

Security teams should also add detection around Git hook paths and suspicious developer tool activity. A hook that downloads and executes remote content should trigger review, especially when it appears in a repository received through a job interview.

• Inspect .githooks, .husky, .vscode, package scripts, and install scripts before running a new repository.
• Use a disposable virtual machine for coding tests from unknown recruiters.
• Do not store crypto wallets or production credentials on interview test machines.
• Monitor for curl, wget, PowerShell, cmd, bash, or Python launched from Git hooks.
• Review changes to core.hooksPath in local Git configuration.
• Block known malicious domains and defanged indicators in security tooling after validation.

What developers should check before committing code

Before committing changes in an unfamiliar repository, developers should check whether the project uses a custom hooks directory. The .githooks and .husky folders deserve special attention because both can contain scripts that run during Git workflows.

Developers should also review package.json, build scripts, task files, and setup instructions. Fake interview projects often hide execution steps inside normal-looking developer workflows.

If a recruiter asks a candidate to disable security tools, run a paste-and-execute command, or connect a wallet to finish a test, the safest response is to stop and verify the company through a trusted channel.

Developer tooling is now part of the attack surface

This campaign shows how attackers continue to move deeper into software development workflows. They are not only targeting browsers and email inboxes. They are targeting Git, package managers, IDE settings, test projects, and interview assignments.

That shift creates a challenge for security teams. Blocking known malware is not enough when attackers abuse trusted tools to trigger payloads at the right moment.

Organizations need security controls that understand developer behavior, not just traditional endpoint activity. That includes safe interview environments, repository review policies, developer-focused awareness training, and stronger monitoring around build tools and scripts.

FAQ