Fake Job Interview Take-Home Projects Are Delivering Git Hook Malware

A developer recently discovered that a take-home coding challenge sent as part of a job interview was not what it appeared to be. After growing suspicious, they inspected the project's Git repository and found a sophisticated malware delivery operation hidden inside — complete with pre-configured .git/hooks/ scripts designed to execute silently the moment the repo was cloned and set up.

What Happened

The attacker posed as a legitimate employer and sent a take-home interview assignment. The project looked normal on the surface — realistic code, plausible structure — but the .git/hooks/ directory contained shell scripts wired to fire automatically during standard Git operations. When the developer followed the setup instructions, the hooks executed without any explicit prompt or warning. The write-up details that this was not a one-off attempt: the infrastructure behind it suggests an organized operation targeting multiple developers through the same method.

Why This Matters

Git hooks are powerful, run with the full permissions of the current user, and are almost never audited. Most developers do not inspect the .git/hooks/ directory of a project handed to them externally — it falls outside the usual mental model of "review before running." The social engineering pretext (a plausible job opportunity) actively discourages the extra scrutiny the situation warrants.

The payload could harvest SSH keys, API tokens, .env files, browser session cookies, or establish persistent backdoor access. Since interview assignments typically require running build tools and test suites, attackers get multiple hook entry points: post-checkout, post-merge, pre-commit, and post-clone are all viable trigger points.

This attack is particularly dangerous because it targets people already engaged in careful, deliberate technical work. Developers are conditioned to run git clone && npm install without a second thought. That reflex is the vulnerability.

What to Do

1. Never clone an external repo directly to your main machine. Use a disposable VM, a Docker container with no host mounts, or at minimum a network-isolated environment. This is now a baseline hygiene requirement for any third-party code you're asked to evaluate — interview project or otherwise.

2. Inspect .git/hooks/ before running anything. After cloning, run ls -la .git/hooks/ and read each non-sample file before executing build scripts, package installs, or setup steps. Hooks are plain shell scripts — they take ten seconds to read.

3. Clone with an empty template to strip hooks. Pass --template /dev/null on clone, or set core.hooksPath to a safe empty directory globally in your Git config:

git config --global core.hooksPath /dev/null

This prevents hooks from being installed at all. Re-enable selectively for repos you own and trust.

4. Treat elaborate interview setups as a yellow flag. Legitimate employers do not need you to run their internal tooling on your personal machine during an early-round screen. Complex multi-step bootstrap scripts from unverified senders warrant hard scrutiny before execution.

5. Report it. If you receive one of these, notify the platform where contact was made — LinkedIn, email provider, job board — so the account can be investigated and other candidates warned.

The technical sophistication here is low — Git hooks have existed for decades. What makes this effective is the social engineering wrapper. Treat any externally sourced repository as untrusted code, because that is precisely what it is.