TLDR; I have built a simple cursor skill https://reposafety.com for scanning take home interview tests. So far it seems to do a pretty good job.
What a Job Take-Home Taught Me About npm Supply-Chain Attacks
I recently received a full-stack coding assignment from Antfarm DAO.
At first, the company and recruiting process seemed genuine.
The company had a polished website: theantfarm.tech, a DEV.to presence, and what appeared to be a normal engineering recruiting process.
The person who sent me the assessment also appeared to have an established online presence, with profiles on:
The communication was professional and the assessment looked like a completely normal one-hour engineering task.
Then I looked at the dependency tree.
The dependency that changed everything
The repository pulled in:
[email protected]
↓
@aaron205whitmore/[email protected]
Enter fullscreen mode Exit fullscreen mode
The second package contains malicious code.
It contacts:
153.75.81.2:1224
Enter fullscreen mode Exit fullscreen mode
and can receive a base64-encoded payload and execute it with Node’s require available:
new Function('require', dynamicCssRules)(require)
Enter fullscreen mode Exit fullscreen mode
That provides a mechanism for arbitrary remote JavaScript execution.
The exact 1.0.2 package I recovered has SHA-1:
183f39ef3531ad688f168c81e25b528b55630d67
Enter fullscreen mode Exit fullscreen mode
I’ve documented the investigation and preserved the relevant evidence here:
https://github.com/naval200/proof_of_dev
What I learned
npm install is not just package installation
When we run:
npm install
Enter fullscreen mode Exit fullscreen mode
we’re trusting an entire dependency graph.
A developer may never have heard of the malicious package, yet it can still arrive through a transitive dependency.
Check the dependency tree
Don’t only look at package.json.
For an unfamiliar repository, inspect:
npm ls
Enter fullscreen mode Exit fullscreen mode
and investigate unfamiliar packages, particularly private scoped dependencies.
Pay attention to .npmrc
This repository also contained an npm authentication token.
A private dependency combined with a repository-provided npm credential is something I’d investigate before installing anything.
Install scripts aren’t the only threat
Even if a package has no suspicious postinstall script, malicious code can execute when a library is imported or used.
So:
No malicious install script ≠ safe package.
Don’t rerun suspicious code
Once I identified the malicious package, I stopped running the application and investigated the machine instead.
I checked for active connections:
sudo lsof -i -n -P | grep 153.75.81.2
Enter fullscreen mode Exit fullscreen mode
macOS logs:
log show --predicate 'eventMessage contains "153.75.81.2"' --last 24h
Enter fullscreen mode Exit fullscreen mode
running Node/npm processes:
ps aux | grep -E '[n]ode|[n]pm'
Enter fullscreen mode Exit fullscreen mode
and inspected the npm cache and package contents.
I found no evidence of C2 communication or persistence, although these checks cannot prove that no connection ever occurred.
The broader lesson
The interesting part of this incident wasn’t just the malicious npm package.
It was how normal everything looked beforehand.
A credible-looking company website, professional communication, GitHub access, a realistic technical assignment, and an apparently established online presence can all lower your guard.
For take-home assignments, I’m now treating the repository itself as untrusted software:
inspect first → install later.
If you’ve encountered any of these identifiers:
@aaron205whitmore/postcss-animate-utils
animatecss-tailwind-adapter
153.75.81.2
antfarm-tech/proof_of_dev
Enter fullscreen mode Exit fullscreen mode
I’d be interested in comparing evidence.