There is a new, increasing trend in contacting candidates profiles, mainly developers, usually through LinkedIn, with the intention of infiltrating malware in their computers.

The target

• A software developer.
• Someone with background in scripting languages, mainly Javascript and Python.
• Active within Web3/DeFi/Crypto.
• Senior or upper level contributor.

The more checks you meet, the more probable you’re of being contacted by a group doing this scam.

I’ve personally faced about ~9 attacks, 6 of them actually within the spam of two weeks, one of them in the same day of writing this post, lol.

The plan

The scam consists of presenting a good to outstanding job offer, intending to have you running the intended malicious code on your computer.

The (often) common patterns they all tend to exhibit are:

• Praising your profile (way more than your usual LinkedIn recruiter).
• Mentioning a very competitive or outstanding offer.
• Inviting you to collaborate on Slack, Google Docs, GitHub, GitLab, Bitbucket.
• Trying to behave as a normal recruiter, asking for your CV and Github, etc.
• Insisting on just “completing some assessment code”, or “running the project and sending an screenshot”.

The malware

Most of the time that JS code will come obfuscated in some way, by de-obfuscating it, we can deduce that:

1. Search, gather and upload any relevant browser data: Session, cookies, and browser extensions’ data, most importantly, those that are Crypto-related.

2. Pack it up in a zip file and upload it to a web server.

3. Check if you got Python installed, then download an obfuscated Python script that will run more malicious code. According to some sources, that Python script is basically a persistent keylogger that will also upload your clipboard to a remote web server.

The vectors

Within the NodeJS realm, attacks can be present

• A. Directly in the source code, as a long, one-liner, obfuscated script.
• B. Indirectly in the source code, by calling a remote server and using eval to run it.
• C. Indirectly in the source code, by calling a remote server, then writing the content to a file and dynamically require/import it.
• D. Embedded in the packages listed in package.json, and called in the source code.
• E. Embedded in the packages listed in package.json, then executed as a post-install script.

In the ~9 times I’ve been attacked, the ‘C’ and ‘E’ have not been used, but could be as well.

In case the source code does not directly contain the malware, the attack vector always resolves to one of the following to deferring the malicious code execution:

• Dynamic import (system library or script).
• Dynamic code evaluation.
• Spawning a child process.

Attacks in other runtimes

It would be just the same as in NodeJS, but this scam could work for any code or program if done with ‘A’. And for dynamic importing and executing code (B,C,D) basically anything that has an interpreter and can load external dependencies.

‘E’ will always depend on the package manager you use.

Another variation is to download/write a .dll in Windows, .so in Unix-like systems, then using dynamic linking as well.

Protecting yourself (and your company).

1. Don’t place personal phone numbers, complete addresses, or any other personal information that you won’t feel comfortable giving it to a totally random foreigner.

• They may use that information to scam you or your contacts in many other ways, phone numbers and SMS systems are not fully secure, but this is a topic for another post, but you may check this.

2. Don’t accept any coding challenge, before 1 or 2 meetings, if remote, make sure they have their cameras on.

• Even if the coding challenge is in a web, sandbox environment, you should always give your time when there is a minimum effort done by the evaluating party, completing a coding challenge before at least an initial interview is a good way to waste time, even more if you’re aiming for a senior+ role.

3. Don’t run any take home challenge that has simply too many files.

• A normal take home challenge will either start from scratch, and if a source code is provided, it must be narrowed down to the scope of the actual test. A half-complete project will only be either one of the two: 1) A terrible organization you don’t want to work for. 2) A scam trying to hide where the scam is.

If you ever need to execute any script code that you cannot simply fully read by yourself and be sure exactly what’s doing, then always run it into a sandbox.

If you don’t have or know how to set up a proper sandbox, or you just suspect, it just not worth the risk.

JavaScript sandboxing tips

For NodeJS, we might as well just use Deno.

Deno will by default ask permissions for:

• Reading and writing files (and you can define a scope, like ./).
• Reading environment variables (when accessing process.env).
• Connecting to the network (any call to a remote server).
• Executing child processes.

You can disable eval by passing down a v8 flag to Node or Deno:

• For Node: run it with --disallow-code-generation-from-strings
• For Deno: run it with --v8-flags=--disallow-code-generation-from-strings

In case you use Bun, and attackers targets it (extremely improbable but possible), other vectors are: FFI and Bun.Transpiler. Deno also have FFI, but must be directly enabled, at the moment of writing this post AFAIK Bun does not have any option to disable/forbid neither.

You may also use socket.dev to check package security report for NPM, PyPI, Gems and Maven. Also, GitHub Advisories offers a similar service, in case you wonder for other package managers like C# .NET’s NuGet.

If it is take home test it should be small enough so you can just swap to Deno, if that’s no possible, then simply forget about it and report them.

To avoid NodeJS install scripts to be executed when installing packages.

• npm install --ignore-scripts
• pnpm install --ignore-scripts
• yarn install --ignore-scripts

You may also install packages with socket.dev’s install, or also, deno install which by default forbids scripts and unintended file & network access.

Facts

• • It is NOT relevant whether the attack has 0.001% chance of landing, they just need to try 1000 times and will cause harm.
• • Most antivirus won’t detect all the attack’s surface. An attack can be as simple as sending over network your environment variables or looking for .env and similar files, then sending the text over an unsuspicious HTTP call.
• • Isolation »» active protection.

Stay safe, and thanks for reading!