Elastic found malware hidden in SVG flags. The working coding test was the real trap

Elastic Security Labs published details on July 18 of a DPRK-aligned campaign that approached developers with job offers and then sent them take-home coding tests. The projects worked. They were also backdoored.

The campaign, which Elastic tracks as REF9403, came to light after a user posted a job offer in the company's community Slack workspace on May 26. Interested developers were moved into direct messages and given an e-commerce coding challenge. Running the project launched malware that could steal browser credentials, cryptocurrency wallet data and files, monitor the clipboard, and open a Socket.IO-based remote-access channel.

The distinctive part was where some of the payload was stored. The attackers split Base64-encoded fragments across HTML comments inside ordinary SVG country flags. A file named serverValidation.js read the images, sorted them, extracted the comments, joined the fragments and passed the decoded result to eval().

At the time of Elastic's analysis, the collected project archives had no antivirus detections. That matters, but the more useful detail is that the applications behaved like normal coding assignments.

A working application became part of the disguise

One of the projects was based on GoCart, a public Next.js e-commerce template. The attackers kept the application functional and inserted small pieces of malicious code around it. Someone checking whether the interface loaded or whether the assignment looked technically plausible would not necessarily see anything wrong.

This was not an SVG browser exploit. Merely previewing one of the flag images was not the infection path described by Elastic. The malicious code ran because server/index.js called runServerValidation() after its initial middleware setup, triggering the reassembly logic in serverValidation.js. Both npm run dev and npm start launched server/index.js, so the payload executed as part of an ordinary development workflow.

That is a more awkward problem than a visibly broken repository asking someone to run an unexplained shell command. Developers expect a take-home assignment to contain unfamiliar code. They also expect to install its dependencies, start its development server and debug whatever does not work. The attacker only needs those normal actions to happen on a useful machine.

Microsoft documented the broader Contagious Interview campaign in March, describing fake recruitment processes that lead developers to clone repositories or execute npm packages. Elastic says this particular SVG-based infection chain had not previously been documented.

Elastic links REF9403 to DPRK-associated Contagious Interview activity through similarities in code, behaviour and infrastructure, rather than direct confirmation of who operated these repositories. It describes the four-stage payload as aligned with OTTERCOOKIE, but also notes that OTTERCOOKIE and BEAVERTAIL capabilities have begun to overlap enough that the malware-family boundary is no longer clean.

The target was the developer environment, not only a crypto wallet

Elastic found four main capabilities in the payload. One module collected browser credentials and wallet extension data across Windows, macOS and Linux. On macOS, it also attempted to take the login keychain database.

Another module searched for files and directories that tend to hold developer secrets, including .env files, shell histories, .ssh, .aws, .azure, configuration files, documents and source code. A Socket.IO-based RAT gave the operator an interactive shell, while a clipboard component monitored copied text on Windows and macOS. The Windows path also attempted to download additional executables, although Elastic could not retrieve those files because the server was unavailable during analysis.

This makes the blast radius depend heavily on where the project was run. A throwaway environment with no useful credentials is one problem. A normal workstation with an active SSH agent, cloud CLI sessions, browser passwords, repository access and production-adjacent tokens is quite another.

Take-home projects need an isolation rule

The r/webdev discussion quickly arrived at the practical point: running an unknown take-home project on a normal development machine is no longer a reasonable default. The comments were brief, but the concern fits the attack better than treating eval() or SVG files as the whole story.

A coding assignment from an unfamiliar recruiter should be handled like other untrusted code. A disposable virtual machine or isolated development environment should not contain personal browser profiles, wallet extensions, password managers, SSH keys or logged-in cloud tooling. Reviewing package.json scripts and server entry points before execution can still catch crude attempts, but it cannot establish that a larger unfamiliar codebase is safe.

For someone who already ran a suspicious project, deleting the directory is not enough. The safer response is to isolate the machine, identify which accounts and credentials were accessible, invalidate active sessions where appropriate, rotate exposed keys and tokens, and review repository, package-registry and cloud audit logs for unexpected activity.

The SVG trick will probably change once defenders start looking for it. The durable part of the campaign is the workflow: a plausible recruiter, a working repository and a developer machine that already contains the access an attacker wants.