Stories from the SOC: Mystery of the postponed proxyware install

SOC · 7 MIN READ · BEN NAHORNEY AND SEAN SCULLY · NOV 24, 2025

TL;DR 

• A suspicious PowerShell alert revealed an attack chain using a download cradle and in-memory execution to install proxyware on a compromised system.
• The investigation traced the infection back three days to the installation of a disk-cleaning utility that bundled malicious scripts and beaconed a C2 server.
• The SOC team detected and stopped the attack before the proxyware installation completed, breaking the chain at a critical point.

It started like many incidents, with an alert flagging suspicious PowerShell activity. It’s the sort of thing we see on the daily. PowerShell is integral in managing modern-day Windows endpoints, and is the primary delivery vehicle for configuration management and task automation. 

The frequent use of PowerShell in Windows environments can make it difficult to separate the routine from the concerning. Even with alerts for suspicious PowerShell activity it’s common to investigate, only to find that the cause was someone in IT solving a problem in an unconventional manner.

On the surface, the command that was flagged was a web request, the sort of thing any connected application might do. But as we dug deeper, what initially appeared to be straightforward revealed itself as something more—a protracted process for installing proxyware. And as it turned out, the supposed threat had been here for a while, but only now starting to carry out suspicious behavior.

A bad branch in the process tree

As we jumped in to investigate, the first sign something wasn’t right was in the way the command was executed. It was launched by Node.js, a common endpoint application that can run JavaScript outside of a browser. Node.js had in turn been launched by SvcHost, a Windows process typically used to run shared Windows services—think UI management, networking, audio services, etc.

Since SvcHost is meant to run Windows services, and Node.js isn’t one, seeing this behavior is a huge red flag. Normally if a user launches an application utilizing Node.js, then either that application or a process like Explorer would call it. In short, SvcHost shouldn’t be involved when running Node.js under normal circumstances.

A (Power)Shell game

From a high level, the PowerShell command launched by Node.js opens the Windows command-line interpreter (CMD) to run a second PowerShell command that connects to a URL to get a third PowerShell command. 

That’s a lot of PowerShell. Let’s start off by looking at the command that triggered the alert: 

There are several run-of-the-mill things going on here, but also several that are suspicious and worthy of a closer look.

First off, the command invokes the /d flag when launching CMD, which disables Autorun commands that may be set to run when CMD is called. Sometimes administrators configure systems with extra instructions, guiding it on how to run CMD commands. This could cause a command like this one to malfunction or lead to extra logging, drawing further attention to it in this case. This flag stops those scripts from being run prior to command execution.

CMD then runs another instance of Powershell. The inclusion of -ExecutionPolicy Bypass is designed to get past PowerShell security policies that are designed to prevent running untrusted scripts. Administrators rarely, if ever, need to do this in a production environment, making this another red flag.

This second PowerShell command includes a URL that connects to a PowerShell file  named lnksdfoifwe.ps1, located in a public Cloudflare bucket.

The last part of this command (| iex) retrieves the contents of the lnksdfoifwe.ps1 PowerShell file located at the URL, not actually downloading the file itself. The PowerShell instructions sent back are subsequently run by the current PowerShell instance in memory, never touching the disk. 

Download cradles lead to sleepless nights

When all is put together, Node.js kicks off an attack chain that retrieves a PowerShell script from the internet and immediately executes it. No files are saved to disk, legitimate Windows tools are used, and everything happens in memory, all of which makes this fast and challenging to detect. 

This technique is often called a “download cradle” and is extremely popular because it’s easy to deploy and evades file-based detection. The malicious payload, stored at the location in the URL, can also easily be changed and adapted to suit the threat actor’s needs.  

The malicious “child” in the cradle

So far the PowerShell activity seen was suspicious—clearly working hard to hide its tracks—but a payload has yet to arrive. The set of PowerShell instructions were retrieved from the Cloudflare bucket and run in memory were about to change that. 

The PowerShell script that was pulled down was much larger than the command that triggered the initial alert. You can check out the full script on VirusTotal, but here is an overview of what it does: 

1. Sets up the following service:
   • Name (note the typo):
     Network Perfomance
   • Path (creates it if it doesn’t exist):
     %LocalAppData%\Microsoft\Performance
2. Decodes an encoded string in the script that points to the following URL:
   https[://]featherstorage[.]com/1637[.]exe
3. Downloads the file at the URL and saves it as the service executable in the following location:
   %LocalAppData%\Microsoft\Performance\NTService.exe
4. Creates a scheduled task for the service that runs five minutes later, then runs once an hour, ensuring that the service will keep running.

This executable appears to be a proxyware application that’s part of a monetization scheme. Proxyware is software that allows a user to share a portion of their internet bandwidth with a third party and get paid as a result. 

This appears to be the end goal of this attack—forcefully downloading and installing software on compromised computers, allowing the threat actor to get paid. It’s debatable whether this software is malicious in-and-of-itself, but it’s certainly not being installed with the consent of the user or the organization responsible for the computers.

Thankfully the alert brought attention to the activity, which we managed to identify and stop before the affiliate software could be successfully installed. 

Before the alert

We became aware of this activity thanks to the abnormal and aggressive nature of the PowerShell activity. But how did the PowerShell command that triggered an alert get kicked off in the first place?

Digging further into the customer’s logs, we discovered it began when a user installed a free disk-cleaning utility, which happened to have been bundled with a file named temporary.ps1—more PowerShell, which started the whole process. However, running alongside the utility installation, this PowerShell file had largely gone unnoticed. 

That’s because this initial PowerShell file didn’t immediately kick off the process to install its ultimate payload, the affiliate software. Instead it just downloaded a legitimate copy of Node.js alongside a JavaScript file named 954a8ea9-8cbe-4848-b4d5-d11ccc173058.js. It then set up a scheduled task named “HybridDriveStatus” with SYSTEM level privileges to run the JavaScript file every hour, connecting to a C2 server and awaiting further instructions. 

In most cases, a JavaScript file running every hour isn’t going to get flagged by detection software, and if it does, it’s likely to be flagged as low priority. So the threat ultimately sat and waited for further instructions.

The instructions came three days later, when the C2 server sent back the PowerShell command that ultimately triggered the alert, bringing this to our attention.

From the top

Since we’ve now come full circle with this attack, let’s play it through from start to finish.

1. A user installs a seemingly innocent freeware application, which includes a hidden install script.
2. The install script does two things: 
   1. Downloads a legitimate copy of Node.js and a JavaScript file. 
   2. Sets up a scheduled task to run as a SYSTEM user to check in with a C2 server every hour.
3. Three days later, the C2 server provides a PowerShell command which the system runs.
4. The PowerShell script downloads and executes commands in memory that lead to the installation of proxyware software. 

This attack chain assumes that the process completes without a hitch. Fortunately, we were alerted to the activity at step three, isolated the compromised computer, and successfully broke the chain before it could complete its task.

Implications of unauthorized proxyware

Recently there have been several reports of attack chains resulting in the installation of proxyware. Researchers at AhnLab SEcurity intelligence Center (ASEC) published an analysis of a campaign this summer that closely mirrors what we saw here. Jason Reaves at the Walmart Global Tech Blog has published an additional deep dive on these campaigns, further detailing the steps in this attack chain.

Proxyware sits in a grey area between semi-legitimate software and malware. In circumstances where a user would install proxyware on their own computer, they would get paid as a result. In this case, the attacker is installing the proxyware without the consent of the user and profiting instead.

In addition to this, when an actor has SYSTEM level control over the computer, there’s nothing stopping them from installing other, more dangerous payloads, such as malware. In short, just because the system isn’t being harmed today doesn’t mean it can’t be harmed tomorrow.

Avoiding this attack

This attack began when a user attempted to install a disk-cleaning utility on their system. These tools can be used to speed up a sluggish system, but can also result in a system not working properly if the wrong files are deleted, or settings reconfigured. There’s also the risk that some “disk-cleaning utilities” are really designed to destroy evidence or remove forensic artifacts from a system, making use in a corporate environment concerning. 

Users installing arbitrary software to carry out a task usually points to a gap where IT-sanctioned software may not be fulfilling the needs of those users. There are several controls available that can prevent users from installing software like this, such as Microsoft’s AppLocker or Windows Defender Application Control (WDAC).  

It’s also important to limit which users can run PowerShell on endpoints. Generally speaking, there’s no need to use PowerShell in a user’s day-to-day activity, meaning that it can be limited to users in IT roles needing to make changes across network endpoints. To this end, it’s important to restrict PowerShell access, set up execution policies, and enable comprehensive PowerShell logging to catch suspicious activity.

Appendix: IoCs 

Files

Hashes (SHA-256)

• Setup.exe: 9e694f03742aa171cc0d4c84127e4fc8d3ae187ebb1c6905f144a744ce030577
• Burnbytes.exe: f05a06f1d20f437764fbdf1e8ed205b1702751e1319f128f8fba9be07f9e4413
• 954a8ea9-8cbe-4848-b4d5-d11ccc173058.js: 3e131fe553009de2645b0c68a4a731114973ddef040d313028499972d127182d
• 1637.exe/NTService.exe: 58a02a4563a875f8f5304d72371e90f1a3a997579c54bd59b69e0ecb9b3b375d

Network IoCs (Domains)

• Stage 3 (Downloader): filerit.com
• Stage 5 (C2 Ping): ilesystemwcm.com
• Stage 5 (C2 Ping): diskcleanu.com
• Stage 5 (C2 Ping): devicesetupx.com
• Stage 5 (C2 Ping): maintenancesat.com
• Stage 7 (Payload): pub-bfc34934a91a4893817098f73415917a.r2.dev
• Stage 8 (Final Payload): featherstorage.com

Persistence (Scheduled Tasks)

• Task 1 (Primary):
  • Name: HybridDriveStatus
  • Path: \Microsoft\Windows\Sysmain
  • Action: Runs the 954a8ea9-8cbe-4848-b4d5-d11ccc173058.js script.
• Task 2 (Attempted):
  • Name: Network Perfomance
  • Path: \Microsoft\Windows\Performance
  • Action: Intended to run 1637.exe / NTService.exe.

Registry (Defense Evasion)

• Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CD45BC04-FEE6-41E9-A979-1632B8F82758}
• Value: SystemComponent
• Data: REG_DWORD = 1