Fake take-home job assignment hid malicious npm package with remote code execution

A convincing recruiting front

A developer writing on dev.to has described a supply-chain attack that reached them through what looked like an ordinary hiring process. According to the post, the author received a full-stack coding assignment from a company calling itself Antfarm DAO. On the surface, everything checked out: the organization had a professional-looking website at theantfarm.tech plus a DEV presence, and the person running the recruitment appeared to have long-standing profiles on GitHub, LinkedIn, Stack Overflow, LeetCode and Telegram. Messages were businesslike, and the task resembled a standard one-hour engineering exercise. The trouble only became visible in the repository's dependency tree.

The payload in the dependency tree

The project depended on animatecss-tailwind-adapter version 2.0.6, which in turn pulled in a scoped package named @aaron205whitmore/postcss-animate-utils at version 1.0.2. The dev.to account identifies that second package as malicious. It communicates with a remote host at 153.75.81.2 on port 1224, accepts a base64-encoded payload, and runs it through a Function constructor with Node's require in scope — in effect, a channel for executing attacker-supplied JavaScript on the victim's machine. The author publishes the SHA-1 fingerprint of the package version they recovered (183f39ef3531ad688f168c81e25b528b55630d67) and says the supporting evidence is preserved in a public repository named proof_of_dev.

A credential bundled with the repo

The post flags a second oddity: the repository shipped with an npm authentication token in its .npmrc file. A private scoped dependency arriving together with a repo-supplied credential is, in the author's assessment, a combination that deserves scrutiny before anything gets installed.

Containment and checks

Once the malicious package had been identified, the author stopped launching the application and instead investigated the machine. The checks included searching active network connections with lsof for the suspicious IP address, querying macOS unified logs covering the previous 24 hours, listing running Node and npm processes, and examining the npm cache alongside the package contents. No evidence of command-and-control traffic or persistence turned up, though the author is careful to note that these checks cannot rule out that a connection ever happened.

Lessons the author draws

Several practical points follow from the incident:

• An npm install delegates trust to an entire graph of packages and maintainers, so something hostile can arrive transitively even if you have never heard of it.
• For unfamiliar repositories, inspect the resolved tree with npm ls rather than stopping at package., and pay particular attention to private scoped dependencies.
• Treat a bundled .npmrc token as a signal to slow down.
• The absence of a suspicious postinstall script proves little; malicious code can just as easily run at import time, when a library is first used.
• Once something looks off, stop executing it. Rerunning suspicious code to see what happens only widens exposure.

The author's own policy for take-home assignments has hardened accordingly: read the code, the manifest and the lockfile before running any install.

Why it matters

This is a single firsthand report rather than a vendor-confirmed incident, and the account rests on the author's own evidence. But the mechanics serve as a useful warning regardless. Job take-homes are an almost ideal delivery vehicle: candidates expect to clone and run unfamiliar code quickly, and a plausible company with a real-looking web presence and established social profiles supplies exactly the social proof needed to lower a developer's guard. The target is valuable too — a developer workstation typically holds source access, tokens and cloud credentials. The identifiers published in the post, namely the two package names, the IP address and the evidence repository, give teams something concrete to search for in their own logs and lockfiles.