Home Blog When PUPs Grow Fangs: Dragon Boss Solutions Left an Open Door on 25,000+ Endpoints Published: April 14, 2026 When PUPs Grow Fangs: Dragon Boss Solutions Left an Open Door on 25,000+ Endpoints By: James Northey Ryan Dowd Acknowledgments: Special thanks to Lindon Wass and Michael Elford for their contributions to this research and blog. Background Early in the morning on Sunday, the 22 March, what appeared to be standard adware started triggering alerts across multiple environments managed by Huntress. The executables were using an update mechanism to conceal a multi-stage attack chain designed to systematically disable security tools. These executables were signed by Dragon Boss Solutions LLC, a company claiming to conduct "search monetization research." The signed software silently fetches and executes payloads capable of killing antivirus products, all while running with SYSTEM privileges. Huntress observed the antivirus killing capability starting in late March 2025, although the loaders/updaters dated back to late 2024. The operation uses an off-the-shelf software update mechanism to deploy these MSI and PowerShell-based payloads. Establishing WMI persistence, it disables security applications, and blocks reinstallation of protective software. More concerning is it turned out to have an open door baked right into its update configuration, one which anyone with $10 could have walked straight through. Attack flow overview Figure 1: Diagram showing attack path Setting the stage Most adware/potentially unwanted programs (PUP) don’t get a blog post written about them, because they are extremely common and, frankly, boring. At face value this is aggressive adware protecting its revenue stream, however in this case, the combination of AV killing focus and some unregistered domains stood out to us and prompted us to dig in further. The update mechanism can deploy any payload. At the moment it's an AV killer, but tomorrow it could be ransomware, a cryptominer, or an infostealer. The infrastructure is already in place and now there's no AV watching. What increases this risk is the primary update domain baked into the operation - chromsterabrowser[.]com - is unregistered. Anyone who registers it gains the ability to push updates to hosts running Dragon Boss Solutions software. This transforms a PUP infection into a potential supply chain compromise. Fortunately, Huntress found this domain first. So we registered it ourselves, pointed it to a sinkhole, and within hours watched tens of thousands of compromised endpoints reach out looking for instructions that, in the wrong hands, could have been anything. Initial discovery Our investigation began with two WMI persistence signals. The naming convention raised concerns: "Mb" refers to Malwarebytes, and "Removal" speaks for itself. Figure 2: Initial detections for persistence The next clue was a burst of scheduled task creation events just prior to the WMI detections. Four tasks were registered in rapid succession, all pointing to the same PowerShell file: Figure 3: Further detections for deployed payloads Digging deeper and tracing the activity back, we identified the source: a signed executable ( RaceCarTwo.exe ) from Dragon Boss Solutions LLC running an install command. Figure 4: Process history for the executable signed by Dragon Boss Solutions LLC Looking at child executables revealed Setup.msi . Figure 5: MSI execution to deploy an “update” Looking at that task creation again, we see that it’s running out of msiexec and running a script called ClockRemoval.ps1 . Figure 6: Payload execution post “Update” Variations of executables Notably, the executables and their install paths follow a pseudo-random naming pattern. However, common similarities can be observed. Names are structured as a [Word][Word][Number] combination (e.g., TableBoatThree , WinSupportNine ). World Wide Web was also very commonly observed. Next, the file paths were consistent double-encapsulation. The parent folder appends a suffix ( Solutions , or Workstation ), while a subfolder follows the pattern C:\Program Files (x86)\[Name][Suffix]\[Name]\[Name].exe . This repetition across the majority of samples suggests an automated installer generating both the name and directory structure. Executable Name Path WorldWideWeb.exe C:\Program Files (x86)\World Wide Solutions\World Wide Web UniversalUpdater.exe C:\Program Files (x86)\Web Genius Solutions\Web Genius ChromsteraUpdater.exe C:\Program Files (x86)\Chromstera Browser Solutions\Chromstera Browser ArtificiusUpdater.exe C:\Program Files (x86)\Artificius Browser Solutions\Artificius Browser ReadySpaceThree.exe C:\Program Files (x86)\FutureSpaceThreeSolutions\FutureSpaceThree WinDefenseThree.exe C:\Program Files (x86)\WinDefenseThreeSolutions\WinDefenseThree SistemaTownOne.exe C:\Program Files (x86)\SistemaTownOneWorkstation\SistemaTownOne TableBoatTwo.exe C:\Program Files (x86)\TableBoatTwoWorkstation\TableBoatTwo RaceCarTwo.exe C:\Program Files (x86)\RaceCarTwoolutions\RaceCarTwo WaveTownFive.exe C:\Program Files (x86)\WaveTownFiveWorkstation\WaveTownFive WinSupportFive.exe C:\Program Files (x86)\WinSupportFiveSolutions\WinSupportFive WinDefenseFive.exe C:\Program Files (x86)\WinDefenseFiveSolutions\WinDefenseFive ProductSetupTwo.exe C:\Program Files (x86)\ProductSetupTwoSolutions\ProductSetupTwo Table 7: Observed executables at time of investigation The grandparent process RaceCarTwo.exe (SHA256: 909539d3ef8dedc3be56381256713fa5545cc7fd3d3d0e0428f7efb94a7e71cb ) had been present on the affected host since 2024. Windows event logs revealed executions of Setup.msi from C:\\Program Files (x86)\RaceCarTwoolutions\RaceCarTwo\updates\Update\ dating back to October 2025. These files are old, so what changed to put this on our radar? The update mechanism With the MSI file no longer present on disk (a common challenge when investigating installer-based threats), we turned to a configuration file left behind: RaceCarTwo.ini. This file revealed that the PUP uses Advanced Installer , an off-the-shelf update mechanism to poll remote servers for installers: Figure 8: Configuration .ini for the update mechanism Several configuration flags caught our attention: Flag Implication NoUpdaterInstallGUI No user interaction required; completely silent PerMachine Runs with elevated privileges CheckFrequency=1 Polls frequently for new payloads NoDisableAutoCheck User cannot disable automatic updates This is where we made a concerning discovery: the first URL domain ( worldwidewebframework3[.]com ) is unregistered, which piqued our interest. Reviewing the configurations on another host, we identified a second unregistered domain, chromsterabrowser[.]com . But this time the unregistered domain wasn't a fallback: it was the primary update URL. That's a meaningful distinction. With the fallback domain on RaceCarTwo, an attacker would only gain execution capability if the primary domain was unavailable or blocked. With chromsterabrowser[.]com , anyone who registered it would be first in line, no filtering or blocking required. Every host running that variant would reach out to this domain for updates, you’d just need to register the domain and serve a malicious payload. Back to our original host: the main domain ( worldwidewebuniverse3[.]com ) was active and the response pointed to a file named Setup.msi hosted at dl.isready26[.]online and masquerading as a GIF image. Figure 9: Update pointed to https://dl.isready26[.]online/image/ldk4945jfds.gif - VT Payload analysis We now have the MSI file (SHA256: 40ac30ce1e88c47f317700cc4b5aa0a510f98c89e11c32265971564930418372 ), and unzipping it we see it contains several components: Figure 10: Extracted MSI file contents Most of these are default files for an Advanced Installer MSI, but a few stand out. Binary.PowerShellScriptLauncher.dll - VT Binary.SoftwareDetector.dll - VT Binary.AICustAct.dll - VT !_StringData - This includes the instructions/script for the installer to run. SHA256: 26ddd0712a101b27b018658b4072ad56bb4083026c797b0345b2cce43862fc83 !_StringData analysis Before deploying the main payload, the installer conducts reconnaissance: Environment detection ( SoftwareDetector.dll ) Checks admin status ( AI_DETECTED_ADMIN_USER ) Detects virtual machine ( AI_DETECTED_VIRTUAL_MACHINE ) Verifies internet connectivity ( AI_DETECTED_INTERNET_CONNECTION ) AV product reconnaissance ( AI_DetectSoftware ) Queries registry for Malwarebytes, Kaspersky, McAfee, and ESET installations Sets PowerShell execution policy ( AI_DATA_SETTER_6 ) Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser -Force Executes boot-time WMI script ( AI_DATA_SETTER_1WMI ) Runs ClockRemoval-WmiBoot.ps1 Executes main AV killer ( AI_DATA_SETTER ) Runs ClockRemoval.ps1 via PowerShellScriptLauncher.dll Spawns 6-minute self-termination timer Start-Sleep -Seconds 360 then kills .tmp processes ClockRemoval.ps1: The AV killer The malware author (or more likely AI) that wrote this nicely provided a synopsis and comments throughout the script detailing its capabilities: Figure 11: Synopsis at the start of !_StringData/ClockRemoval.ps1 The script writes itself to two locations for redundancy: %SystemRoot%\System32\config\systemprofile\AppData\Local\WMILoad\ClockRemoval.ps1 A user-profile equivalent path (i.e., C:\Users\JohnDoe\AppData\Local\WMILoad\ClockRemoval.ps1 ) Targeted security products The script maintains an explicit kill list targeting specific security vendors and browser installers: Figure 12: Processes targeted by ClockRemoval.ps1 The browser installers are likely included because legitimate browsers would potentially interfere with the adware's browser hijacking capabilities. Persistence establishment The script creates five scheduled tasks running as SYSTEM: Task Name Task Type Purpose ClockSetupWmiAtBoot Boot Task Runs ClockRemoval-WmiBoot.ps1 to ensure WMI subscription is active + 30s tight poll-kill of AV processes DisableClockServicesFi