DEV Community

Cover image for Job Scams: How Developers Are Tricked into Running Data-Stealing Code, and How to Spot It
Vardan Hakobyan
Vardan Hakobyan

Posted on • Originally published at Medium

Job Scams: How Developers Are Tricked into Running Data-Stealing Code, and How to Spot It

I recently shared a story about a scam job posting on Codementor where the goal was to trick developers into running malicious code on their machines. Fortunately, I discovered the issue before executing the code, and the account of the job poster has since been suspended.

However, it turns out this wasn’t just a one-time occurrence. I received a similar request yesterday. The “client,” who was looking for a developer to add new features to his project, shared a private GitHub repository and asked me to run the project to verify that it worked correctly, as “it was last developed about three months ago.” When I checked the repository, I found the last commit was made just 18 hours ago. The one before that was indeed a few months old.

This was the first warning sign: The author, who did the last commit yesterday, didn’t run the code before/after the commit? The commit included changes to 89(!) files.

I tried to find out what was in that commit. The commit message was “Style js files” and was mostly about file formatting changes (as if someone ran prettier on the entire codebase). After looking into bunch of files, I didn’t find anything immediately suspicious.

Next, I checked the entry point of the application. The App.js file looked like a plain React component with routing and a simple useEffect — nothing dangerous there. While there could be malicious code buried deeper in the project, going through every file could take hours…

What I learned from my last experience is that if there is something malicious, it will most probably run when you start the app. Since I didn’t find anything suspicious in the top-level file, I decided to check what happens when I want run the app. So I opened package.json and inspected what’s in the scripts section. Here’s what I found:

"start": "npm run config && react-scripts --openssl-legacy-provider start || exit 1",
"build": "npm run config && react-scripts --openssl-legacy-provider build || exit 1",
...
"config": "node src/check_node_version.js",
Enter fullscreen mode Exit fullscreen mode

That config script stood out, so I opened the check_node_version.js file.

check_node_version.js

At first glance, nothing seemed off — until I noticed the “Symbols” panel on the right side. Aha! Functions with cryptic names started showing up. But wait, where did these functions come from? The file is only 14 lines long… I clicked on one, and a mysterious ellipsis icon appeared at line 10, which looked empty at first.

Image description

Hmm, very strange. What if I check the DevTools - will it show anything else? Strange. Could there be hidden code? I checked the DevTools, and sure enough, more information appeared there. The DevTools revealed code that wasn’t visible on GitHub. I didn’t clone the repository, so I’m not sure if it would have been visible locally either. And here is what I found there:

DevTools reveals much more information

And here is our hidden code! I’m not sure why it isn’t visible on GitHub, anyway I didn’t clone the code to my machine to see if it would be visible there.

The next thing to do is to try to understand what the code is doing. I deobfuscated it using Deobfuscator and ran it through Gemini to explain its functionality. Here is Gemin’s answer:

This code is obfuscated Javascript and it appears to be malicious. Here’s a breakdown of its functionality:

1. Function Definitions:

The code defines several functions with cryptic names (_0x11bb, _0xc5de3a, etc.). These functions are likely used to perform specific tasks within the script.

2. String Decoding:

The function _0x11bb seems to be responsible for decoding obfuscated strings. It takes two arguments: an encoded string and a key. The function uses the key to shift characters in the encoded string, revealing the original text.

3. File System Interaction:

The code utilizes functions from the fs module to interact with the file system. It can access, read, and copy files.

4. Browser Extension Data Collection:

Functions like _0x4574da and _0x589215 seem to target specific browser directories (Chrome, Firefox) and search for local storage files associated with extensions. It then attempts to read these files, potentially gathering sensitive data.

5. System Information Collection:

The code retrieves information about the system, including hostname, platform, home directory, and temporary directory.

6. Solana ID Extraction (Optional):

It checks for the presence of a file named id.json in the Solana configuration directory and attempts to read it if found.

7. Data Exfiltration:

The collected data (potentially browser extension data and system information) is uploaded to a remote server using the request library.

In summary, this code appears to be designed to steal data from web browsers, potentially including login credentials or other sensitive information stored in extensions. It also gathers system information and might attempt to extract data related to Solana cryptocurrency wallets.

It’s important to never run such scripts as they can compromise your system’s security.

Bingo! Once again, this attack involved stealing system information and browser data, along with targeting Solana files.

I first read about such scam attempts just a month ago. And in less than 2 weeks I personally encountered 2 similar attempts. This seems to be a growing trend of targeting developers to steal their information.

To help protect against these types of scams, I’ve put together a list of precautionary actions. If you have more ideas, feel free to add them in the comments!

How to Minimize Risk from Scam Attempts:

  1. Check the repository. Look at the commit history. Does it contain just 1 or 2 commits pushing an entire codebase for a large application?
  2. Examine critical files. Focus on entry files (like app.js or index.js) and `package.json. Be on the lookout for suspicious dependencies or scripts.
  3. Use a Virtual Machine or Docker. If you’re uncertain about the code’s safety, run it in a VM or Docker container to isolate your main environment.

That’s it, stay cautious and safe!

P.S. For more context, you can read my previous article on a similar scam attempt.

If you want to stay updated with the latest JavaScript and software development news, join my Telegram channel: TechSavvy: Frontend & Backend.

Top comments (0)