The malware was not in the app. It was in .git/hooks.
My first job hunt taught me to inspect the repo before trusting the task
I am currently looking for my first job So when a recruiter messaged me on LinkedIn and sent over a take-home repository, I treated it seriously. This was one of the first real task-based opportunities I had received, so I wanted to do everything properly.
I reviewed a take-home repository that came through recruiter outreach.
It was a web3 front end with WalletConnect, Transak, Uniswap widgets, Infura, Etherscan, and configuration driven REACT_APP_* env vars. The kind of stack you would expect from a real production app. That was exactly why I almost missed the part that mattered. Before running anything, I started checking the repo structure, package scripts, and Git metadata. I did not run install commands. I did not start the app. I did not assume the repository was safe just because it came through a recruiter.
At first glance, it looked normal enough for a production web3 front end. WalletConnect. Transak. Uniswap widgets. Infura. Etherscan. Vercel Analytics. Env-driven config for chain IDs, contract addresses, fees, and backend URLs.
That part did not bother me.
The red flag was lower level.
Inside the repo-local .git/hooks directory, I found executable pre-commit, pre-push, and post-checkout scripts. They did not validate code. They did not format files. They did not run tests.
They fetched remote content from a hardcoded IP address and piped it into a shell or command interpreter.
That is not a build step.
Actual Screenshot of post-checkout, pre-commit, pre-push file
That is a downloader.
Git hooks matter because Git runs them automatically on specific events. pre-commit runs before commits. pre-push runs before pushes. post-checkout runs after a checkout. Git also allows
hooks to live in .git/hooks or in a configured core.hooksPath, and git init can copy hook templates into a repo.
So if a malicious hook sits in the repo, the attack surface is not just the app. It is the developer workflow.
That is the part people miss.
The workflow pattern Here is the basic flow I observed:
- The candidate is approached like a normal hire The conversation starts like a standard recruiter or hiring process. The task is framed as a practical engineering evaluation, not a public challenge.
https://docs.google.com/document/d/1UTEmB8WRIEP1XQb9R2kVhCNLPkqxBo37WhS2unfhYJQ/edit?usp=sharing
This lowers suspicion because it feels like a legitimate private assessment.
The Person or Profile that blocks me after I confirmed it;https://www.linkedin.com/in/paula-andrea-díaz-loaiza-481ba9232/
![](align="center")
The time I get blocked or they delete?
2. The project is shared as a zip file Instead of a clean private GitHub repository, the project is delivered as a Dropbox package.
https://www.dropbox.com/scl/fi/3bb255hoju2sxh9k7ml2h/datalake-token-app.zip?dl=0&e=2&file_subpath=%2Fdatalake-token-app&rlkey=jpk7vaw2n8kqrbzk8u3e8otcj&st=cmh3zbzg
That matters because:
it removes the normal protections and visibility of a repo,
it makes the workflow feel “local and manual,”
and it encourages the candidate to unpack and inspect the code on their own machine.
The codebase looks real The project itself is not empty or fake-looking. It contains a real frontend app, real Web3 integrations, real environment-driven configuration, and even sensitive-looking .env material.
That is important because a believable app builds trust.
1. The assignment asks for Git-based work The candidate is told to:
create a new branch,add a review file,push the project, and return the GitHub URL.
This is where the workflow becomes interesting.
It makes the candidate behave like a normal developer:
clone or unpack,inspect,branch,commit,push.
That is exactly the behavior malicious hooks are waiting for.
2. Malicious hook files sit in .git/hooks Hidden in the repo are hook files like:
pre-commit,pre-push,post-checkout.
Minimize image Edit image Delete image
Add a caption (optional) These are not ordinary project files. They are execution points Git can trigger automatically.
The scripts I found were not harmless automation. They used a pattern like:
detect the OS, fetch a remote payload from an IP address,pipe it directly into sh or cmd,hide output, and run in the background.
Minimize image Edit image Delete image
Add a caption (optional) That is a classic downloader-style execution chain.
- The payload is triggered by normal Git actions The dangerous part is not just that the scripts exist. It is that they can fire during ordinary Git operations:
commit,push,checkout.
So the candidate does not need to do anything unusual.
A normal workflow action can become the trigger.
Why this scheme works This workflow is effective because it mixes trust and routine.
It succeeds when:
the task looks professional,the app looks real, the instructions sound standard,
and the candidate follows normal Git behavior without checking hook files first.
The candidate thinks they are doing an interview task. In reality, they may be executing a hidden payload.
What makes it dangerous The risk is not just “bad code.”
The actual danger is the combination of:
social engineering, believable delivery, hidden Git execution points, and remote code download.
That means the workflow itself is the attack.
They inspect src/, package.json, and the dependencies. They forget that Git metadata can execute code before the app ever starts.
I did not treat this lightly. I checked the package scripts first. I did not run install commands, startup commands, or any Git action that could trigger hooks. The application itself did not show obvious preinstall or postinstall trickery. The dangerous behavior lived in the Git layer. That distinction matters.
What made this worse is that Git hooks are not decorative files. Git runs them automatically at specific events. A developer can trigger them just by committing, pushing, or checking out code. So if a malicious hook is sitting inside the repo, it does not matter that the app code looks clean. The attack path is already in place.
This was the first time I had to think about a job task in two layers at once.
The visible layer was the app.
The hidden layer was the repository itself.
And that changed how I now review any take-home assignment. I no longer start by asking, “Does the app work?” I start by asking, “What executes before the app even opens?”
This repo contained hook-based remote code execution behavior. And that pattern is not hypothetical. Security writeups have documented Git-hook abuse in fake interview and recruiter-style campaigns, especially where the target is a developer working in crypto or web3. Detection content from security vendors also treats Git-hook execution and hook-origin network egress as suspicious.
So the practical lesson is not "never trust web3 projects."
The lesson is "never trust a repo until you inspect the parts outside the app."
If you receive an interview task or a code sample from a stranger, check these before you run anything:
If a hook reaches out to the network and executes what it gets back, stop there. That is not a hook anymore. It is a launcher.
I now treat interview repos as hostile until proven otherwise.
Not every repo with hooks is malicious. Normal hooks exist. But normal hooks do not phone home and execute remote payloads.
That is the line.
I am publishing this because the defensive habit matters more than the story itself. Read the metadata. Check the hooks. Do not assume the dangerous code will be in src/.
If you review take-home repos, have you ever looked past the app code and found something in Git metadata?
Sources I checked included Git's hook documentation, recent threat-intel reporting on Git-hook abuse, and vendor detection guidance for hook-based persistence and egress.
Core incident pattern SocPrime — Git hooks used to hide malware in fake interview workflows: https://socprime.com/active-threats/lazarus-group-uses-git-hooks-to-hide-malware-dprks-contagious-interview-and-taskjacker-campaigns/socprime
OpenSourceMalware — Lazarus / Contagious Interview using Git hooks: https://opensourcemalware.com/blog/lazarus-group-uses-git-hooks-to-hide-malwareopensourcemalware
Andrii.ro — Investigating malware spreading through Git repositories: https://andrii.ro/blog/investigating-malwareandrii
Microsoft Security Blog — Contagious Interview fake developer job malware: https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/microsoft
Detection and security references Elastic detection rule — Git Hook Command Execution: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/linux/persistence\_git\_hook\_executionelastic
Elastic / Detection FYI — Git Hook Egress Network Connection: https://detection.fyi/elastic/detection-rules/linux/persistence\_git\_hook\_netcon/detection
Elastic hunting query repo reference: https://github.com/elastic/detection-rules/blob/main/hunting/linux/queries/persistence\_via\_git\_hook\_pager.tomlgithub
SonarSource — Securing developer tools / Git integrations: https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/sonarsource
Fake recruiter / fake interview campaign coverage BleepingComputer — Fake job recruiters hide malware in developer coding challenges: https://www.bleepingcomputer.com/news/security/fake-job-recruiters-hide-malware-in-developer-coding-challenges/bleepingcomputer
BleepingComputer — New wave of fake interviews use npm packages to spread malware: https://www.bleepingcomputer.com/news/security/new-wave-of-fake-interviews-use-35-npm-packages-to-spread-malware/bleepingcomputer
The Hacker News — Fake Next.js job repos targeting developers: https://thehackernews.com/2026/02/fake-nextjs-repos-target-developers.htmlthehackernews
CSO Online — North Korean cyberspies trick developers via fake job interviews: https://www.csoonline.com/article/3479795/north-korean-cyberspies-trick-developers-into-installing-malware-with-fake-job-interviews.htmlcsoonline
CyberSecurityDive — State-linked hackers deploy malware in fake job interviews: https://www.cybersecuritydive.com/news/north-korean-hackers--fake-interview/739165/cybersecuritydive
CybersecurityNews — Beware of fake job interview challenges attacking developers: https://cybersecuritynews.com/beware-of-fake-job-interview-challenges/cybersecuritynews
Economic Times Tech / Graphalgo coverage: https://techmonk.economictimes.indiatimes.com/news/cybersecurity/graphalgo-security-alert-fake-job-interviews-are-dropping-rat-malware-on-developer-machines/118188688techmonk.economictimes.indiatimes
Dev Popper / Bluegrid — Social engineering via fake job offers: https://bluegrid.io/blog/dev-popper-how-social-engineering-exploits-developers-with-fake-job-offers/bluegrid
Git hook hardening / disabling Stack Overflow — Disable Git hooks for security reasons: https://stackoverflow.com/questions/35997624/how-to-disable-git-hooks-for-security-reasonstackoverflow
Stack Overflow — How to globally disable Git hooks: https://stackoverflow.com/questions/48135161/how-to-globally-disable-git-hooks
