Dragon Boss Solutions

Overview

Dragon Boss Solutions LLC is a registered commercial entity listed on CrunchBase as conducting "search monetization research," based in Sharjah, United Arab Emirates. In practice, the operation distributes browser-hijacking adware under a family of Chromium-based browser tools including Chromnius, ChromniusEdge, Chromstera Browser, Web Genius, and Artificius Browser, bundled into free software installers. Antivirus vendors had historically categorized Dragon Boss executables as PUPs with browser-hijacking functionality — low-severity classifications that generated suppressed alerts or no action at all in many enterprise environments. The Huntress Acknowledgments section also credits Lindon Wass and Michael Elford as contributors to the investigation.

The entity's public Facebook presence — which has not been updated since 2023 — lists its address as Sharjah Media City, the Emirate of Sharjah's Shams free zone, and a registered support email at support@dragonboss.com. Shams was established in 2017 under an Emiri Decree as a digital-first free zone aimed at media and creative ventures. Its onboarding model is precisely what makes it relevant to this case: 100% foreign ownership, fully remote incorporation with no physical UAE presence required, corporate directors permitted, company formation typically completed within 7 days, and setup costs starting around AED 11,500 (roughly $3,100 USD). An operator anywhere in the world can stand up a UAE-registered LLC in a media-category free zone, obtain a service license allowing "search monetization" as a listed activity, contract for a code-signing certificate against that registered entity, and begin distributing signed binaries — all without ever setting foot in the Emirates. This is the administrative substrate on which the Dragon Boss supply chain was built, and it is a reason the case has attracted specific regional press coverage in Arabian Post and Cryptika (Dubai) that the mainstream US infosec press largely did not convey.

What elevated Dragon Boss from a nuisance to a documented threat is a behavior change first observed from late March 2025 onward: an update pushed through the operation's own infrastructure deployed ClockRemoval.ps1, a PowerShell payload designed not to steal data or encrypt files, but to permanently eliminate the endpoint's ability to detect or block anything else. The AV killer is a means to an end. The end — ransomware, cryptomining, infostealing — was staged but never delivered. On the morning of Sunday, March 22, 2026, WMI persistence signals began triggering across environments managed by Huntress, prompting researchers James Northey and Ryan Dowd to trace the activity back through the infection chain to signed Dragon Boss executables — and ultimately to an unregistered primary C2 update domain. They registered chromsterabrowser[.]com before any other actor could, sinkholed it, and observed 23,565 unique IP addresses connect within 24 hours, all already running with antivirus disabled. Windows event logs on at least one victim host showed update-related activity dating back to October 2025, indicating some endpoints had been enrolled in the update channel months before the AV killer payload was delivered. BleepingComputer reported that Dragon Boss Solutions' website was no longer operational when they attempted to reach the company, and no response from the entity has been publicly documented.

The Huntress disclosure on April 14, 2026 was picked up rapidly across the threat-intelligence press. Within 72 hours the incident was covered by BleepingComputer, Infosecurity Magazine, Dark Reading, Cybernews, Cyber Security News, GBHackers, Cyberpress, TechNadu, and — significantly, given Dragon Boss's UAE registration — two separate Arabian Post articles examining the case from a regional business-registry angle. Threat-intelligence vendors Rescana and SOC Prime published technical analyses within 48 hours; SOC Prime released Sigma detection rules, an attack-path diagram mapping the chain to MITRE ATT&CK, regression test scripts, and a cleanup routine for affected systems. Dubai-based security firm Cryptika, German-language outlet CTRL Alt Nod, and Canadian MSP Happier IT also published independent analyses. The breadth of coverage — spanning vendor research, mainstream infosec press, regional business media, and MSP-focused publications — reflects the case's dual significance as both a technical incident and a broader policy story about the PUP classification grey zone.

Why This Case Sits Outside Existing Threat Taxonomy

Most threat actor profiles fit one of three categories: a nation-state APT pursuing intelligence, a financially motivated cybercrime collective pursuing ransomware or theft, or a hacktivist group pursuing disruption. Dragon Boss fits none of them cleanly, and that is the reason the incident is analytically significant beyond its 25,000 endpoint count. It is a commercially registered LLC with a stated revenue model (search monetization via hijacked Bing Rewards points), signed binaries issued against that corporate identity, and a product roadmap visible in the pattern of rebrands across five branded browsers between 2023 and 2026. At the same time, it operated a SYSTEM-privileged update channel with silent-install flags, a supply-chain architectural flaw that could have enabled mass remote code execution, and AV-destruction payloads targeting four named enterprise security products. The operation looks like a business from one angle and a threat actor group from another, and every defensive framework — MITRE ATT&CK groupings, NIST RMF controls, vendor threat-intel feeds — was designed on the assumption that those angles are separate.

Cyberpress framed this architectural threshold bluntly when reporting the incident:

"just adware" can cross into full-blown supply chain territory.

Cyberpress — "25,000+ Endpoints Left Exposed In Dragon Boss Solutions Domain Update Breach" (April 15, 2026)

That is the precise pivot that makes PUP deprioritization structurally unsafe going forward. A signed updater with SYSTEM privilege, once installed as harmless adware, is not harmless — it is an unattributed remote access channel waiting for someone to configure a payload.

Pre-Disclosure History (2023–2025)

The Dragon Boss brand was not new to the security community when the April 2026 Huntress disclosure landed. Malware-removal vendors and community forums had been tracking Dragon Boss products as aggressive browser-hijacking PUPs for at least three years before the AV-killer behavior was documented. Gridinsoft's trust-score analysis of the dragonboss[.]solutions domain, dated March 21, 2024, assigned the site a trust score of 5/100 and classified it as an "Adware distributor" based on hidden ownership details, limited website popularity, hosting infrastructure, and reputation signals across multiple threat databases. PCRisk published removal guides for Chromstera (August 2023), Chromnius (June 2023), Dragon Search Browser Hijacker (January 2024), Dragon Honey Browser Hijacker (March 2024), and Dragon Search Solutions (April 2024) — each describing redirects to the dragonboss[.]solutions domain and to third-party search engines such as Bing and Yahoo. HackerDose's June 2024 analysis of Artificius Web and Universal Browser established that the two products were renamed forks of the defunct Chromstera browser, with identical code, and that the monetization model revolved around hijacking Microsoft Bing Rewards points that users earned through forced search queries through the Dragon Boss infrastructure.

Community forums flagged the family even earlier. A MalwareTips Forums discussion thread opened in late 2023 documented IOCs including persistent registry policies that restricted Google, Firefox, and Microsoft Edge browser settings, and flagged DisableAntiSpyware and DisableAntiVirus registry values in Windows Defender. One forum member observed that Malwarebytes itself was struggling to remove the infection because the extensions employed sophisticated techniques to evade detection. A Vivaldi Forum discussion in April 2023 established the company's location as Sharjah Media City, UAE, citing the scammer.info Chromnius thread and a Malwarebytes forums post where a user described Chromnius rerouting Chrome and DuckDuckGo queries through Yahoo while leaving Microsoft Edge unaffected. Arabian Post's April 2026 reporting explicitly acknowledged this longer pre-history, noting that earlier 2023 and 2024 public reports from malware-removal researchers had already documented Dragon Boss-linked products as browser hijackers — evidence that the company's software family had been drawing sustained suspicion from the security community well before the April 2026 Huntress findings tied that suspicion to a supply-chain compromise of global scale.

Target Profile

Dragon Boss infections are indiscriminate at the initial access stage — the adware installs on any Windows endpoint where a user clicks through a bundled software installer. The operation does not appear to select targets by sector or geography. However, Huntress's sinkhole data revealed that 324 infections resided on high-value networks, meaning that the mass deployment created high-consequence exposure as a side effect rather than by design. Huntress characterized the disclosure moment as observing a large-scale population of already-infected machines polling an unregistered domain for update content — a distribution channel that, under hostile control, could have delivered ransomware, infostealers, cryptominers, or any other arbitrary payload.

• 221 universities and colleges — academic networks across North America, Europe, and Asia carrying research data, student PII, and federal grant systems
• 41 operational technology networks — in the energy and transport sectors, and at critical infrastructure providers, where AV removal on adjacent endpoints removes the last layer of detection before threats reach industrial control systems
• 35 municipal governments, state agencies, and public utilities — entities subject to FISMA and NIST RMF compliance where silent AV removal constitutes a material control failure under NIST SP 800-53 SI-3
• 24 primary and secondary schools — K-12 environments handling minor student data under FERPA, where endpoint security posture is typically lower than enterprise networks
• 3 healthcare organizations — hospital systems and providers handling PHI under HIPAA obligations
• Multiple Fortune 500 companies
• General consumer and SMB endpoints — 53.9% of the sinkhole connections originated from US IP addresses (12,697 hosts); France (11.9% / 2,803 hosts), Canada (10.1% / 2,380 hosts), UK (9.4% / 2,223 hosts), Germany (8.7% / 2,045 hosts) followed

Tactics, Techniques & Procedures

Dragon Boss's TTPs are notable for relying entirely on legitimate mechanisms: a legitimate certificate, legitimate update tooling, and legitimate PowerShell. No vulnerability exploitation is involved at any stage. This is the operational logic of an actor that understands the code-signing trust boundary and exploits it deliberately.

This is not adware getting aggressive. It is adware with an evolving playbook.

James Northey & Ryan Dowd, Huntress — "When PUPs Grow Fangs" (April 14, 2026)

technique id	name	tactic	implementation
T1553.002	Code Signing	Defense Evasion	All Dragon Boss executables signed with legitimate Dragon Boss Solutions LLC Authenticode certificate — bypasses OS and AV signature checks at installation
T1210	Exploitation of Remote Services (update channel)	Lateral Movement	Per SOC Prime analysis: custom update mechanism contacts remote URLs to download and install malicious MSI payloads; functions as a one-to-many command-and-update channel against infected endpoints
T1562.001	Impair Defenses: Disable or Modify Tools	Defense Evasion	ClockRemoval.ps1: kills AV processes via 100ms polling loop at boot; strips registry service keys; runs vendor uninstallers silently; blocks vendor domains via hosts file; adds Defender exclusions for staging paths
T1546.003	WMI Event Subscription	Persistence, Privilege Escalation	Two WMI subscriptions: MbRemovalMbSetupKillConsumer (process name match) and MbRemovalMbSetupKillConsumerTrace (Win32_ProcessStartTrace — catches renamed AV installers); survive reboots and scheduled task deletion; self-recreated at boot
T1547	Boot or Logon Autostart Execution	Persistence, Privilege Escalation	Five SYSTEM scheduled tasks: ClockSetupWmiAtBoot (boot), DisableClockServicesFirst (startup), DisableClockAtStartup (startup), RemoveClockAtLogon (logon), RemoveClockPeriodic (every 30 min)
T1112	Modify Registry	Defense Evasion	Disables AV service Start values before boot; strips Run keys to prevent AV launch; executed by DisableClockServicesFirst scheduled task before AV processes attempt to initialize
T1601.001	Patch System Image (hosts file)	Defense Evasion	Invoke-MbRemovalAvHostsBlock rewrites Windows hosts file to redirect AV update/download domains to 0.0.0.0, blocking signature updates and vendor reinstallation servers
T1036.005	Masquerading: Match Legitimate Name	Defense Evasion	Binaries follow [Word][Word][Number].exe pattern (e.g. WinDefenseFive.exe, RaceCarTwo.exe); install paths mirror legitimate software directory structure
T1505	Server Software Component (update channel C2)	Persistence	Advanced Installer update mechanism functions as C2 — polls configurable remote domains for MSI payloads; CheckFrequency=1, NoDisableAutoCheck, PerMachine elevated; operates entirely silently with no user interaction
T1053.005	Scheduled Task/Job: Scheduled Task	Execution, Persistence, Privilege Escalation	Five SYSTEM-level scheduled tasks created in rapid succession post-payload delivery: ClockSetupWmiAtBoot, DisableClockServicesFirst, DisableClockAtStartup, RemoveClockAtLogon, RemoveClockPeriodic (30-min interval)
T1218.007	System Binary Proxy Execution: Msiexec	Defense Evasion	Setup.msi (the AV killer payload) is delivered and executed via msiexec.exe — a trusted, signed Windows binary. The MSI is fetched disguised as a GIF image and executed silently with elevated privileges, bypassing controls that restrict unsigned executables; flagged by only five VirusTotal vendors at time of disclosure
T1059.001	Command and Scripting Interpreter: PowerShell	Execution	ClockRemoval.ps1 is the entire primary payload — executed via PowerShellScriptLauncher.dll with Set-ExecutionPolicy Unrestricted forced at CurrentUser scope; all AV kill, persistence, registry manipulation, hosts file poisoning, and Defender exclusion logic delivered as PowerShell
T1497	Virtualization/Sandbox Evasion	Defense Evasion, Discovery	SoftwareDetector.dll queries AI_DETECTED_VIRTUAL_MACHINE registry key prior to payload execution — aborts destructive activity if a VM environment is detected, preventing analysis in sandboxed environments

Known Campaigns

Disclosure Timeline & Industry Response

The public disclosure cycle for Dragon Boss unfolded rapidly between April 14 and April 19, 2026. The timeline below is compiled from bylined reporting across the sources listed at the end of this profile and from the original Huntress publication.

• Late 2024: Dragon Boss loader and updater executables first observed on victim hosts. Operating as standard browser-hijacking adware; no AV-killing behavior yet.
• Late March 2025: AV-killing capability first deployed via the operation's existing update infrastructure to endpoints already enrolled. ClockRemoval.ps1 begins executing in production.
• October 2025: Windows event logs on at least one infected host show update-related activity from the Dragon Boss updater, establishing that some endpoints had been enrolled in the update channel months before the AV killer was delivered.
• Sunday, March 22, 2026: WMI persistence signals (MbRemoval / MbSetup consumer names) trigger alerts across multiple Huntress-managed environments. Investigation begins immediately under James Northey and Ryan Dowd, with contributions from Lindon Wass and Michael Elford.
• Late March 2026: Huntress registers the unregistered primary update domain (chromsterabrowser[.]com) and the fallback domain (worldwidewebframework3[.]com), pointing both to sinkhole infrastructure. A 24-hour monitoring window records 23,565 unique IP addresses attempting to download updates — representing 25,000+ compromised endpoints.
• April 14, 2026 (Tuesday): Huntress publishes "When PUPs Grow Fangs: Dragon Boss Solutions' $10 Supply Chain Risk" at huntress.com/blog/pups-grow-fangs. The post includes full technical analysis, IOCs, detection guidance, and sinkhole statistics.
• April 14–15, 2026: BleepingComputer, Cybernews, Cyber Security News, GBHackers, and Cyberpress publish coverage based on the Huntress research. BleepingComputer attempts to contact Dragon Boss Solutions and reports that the company's website is no longer operational.
• April 15, 2026 (Wednesday): Infosecurity Magazine and TechNadu publish independent write-ups. Rescana publishes a structured risk-management analysis. German-language outlet CTRL Alt Nod publishes regional coverage.
• April 16, 2026 (Thursday): Dark Reading publishes "'Harmless' Global Adware Transforms Into an AV Killer." SOC Prime publishes its Dragon Boss active threat page including Sigma detection rules, a Mermaid attack-path diagram, regression test scripts, and a cleanup routine. Arabian Post publishes its first regional UAE-focused analysis. Rescana's full incident report is dated this day. Cryptika (Dubai) and Happier IT (Canadian MSP) publish independent writeups.
• April 17, 2026 (Friday): Arabian Post publishes a second, broader piece placing the incident within the context of Verizon's 2025 Data Breach Investigations Report third-party involvement findings and CISA supply-chain guidance.
• April 19, 2026: NoHackie publishes full editorial analysis at nohackie.com/dragon-boss-adware-av-killer.html. The story continues to circulate across MSP, MSSP, and ICS-focused publications.

At time of writing, Dragon Boss Solutions has made no public statement. The company's website remains offline. The code-signing certificate used to sign the binaries has not been publicly confirmed as revoked by the issuing certificate authority. No MITRE ATT&CK group ID has been assigned.

Tools & Malware

ClockRemoval.ps1

The primary weapon. A PowerShell script deployed via MSI update, executing with SYSTEM privileges. The script's own inline synopsis describes its capabilities comprehensively. It writes itself to two redundant locations for resilience, establishes WMI and scheduled task persistence, runs a 100ms boot-time kill loop against AV processes, strips registry entries, executes vendor uninstallers, poisons the hosts file, and adds Windows Defender exclusions for staging directories that do not yet exist. It performs selective self-cleanup — removing most scheduled tasks once AV is confirmed removed — but permanently retains the boot task and WMI subscriptions to prevent reinstallation indefinitely.

Targeted AV products: Malwarebytes, Kaspersky, McAfee, ESET. Before the main payload runs, the MSI installer performs pre-execution reconnaissance: it checks admin status, detects virtual machines, verifies internet connectivity, and queries the registry for installed security products. Browser installers for Chrome, Edge, Opera, and Firefox are also targeted because legitimate browsers interfere with the adware's browser-hijacking revenue stream.

Dragon Boss Updater Executables

A family of signed executables using an Advanced Installer-based update mechanism. Each binary uses a pseudo-random [Word][Word][Number].exe naming convention with corresponding directory structures. Observed names include RaceCarTwo.exe, TableBoatThree.exe, WinDefenseFive.exe, WinDefenseThree.exe, WorldWideWeb.exe, ChromsteraUpdater.exe, ArtificiusUpdater.exe, and numerous additional variants catalogued in Huntress's observed-executables table. The update configuration files (.ini) specify remote update domains, poll frequency, and execution parameters. All are signed by Dragon Boss Solutions LLC. Huntress confirmed in lab testing that the updater will silently fetch and execute any MSI payload served from a domain matching the configured update URL, requiring only a valid TLS certificate from a trusted certificate authority — a self-signed certificate is insufficient.

Modified Chrome Binaries

Dragon Boss-signed copies of the Chrome browser binary configured with the flag --simulate-outdated-no-au="01 Jan 2199", which disables Chrome's auto-update mechanism permanently. This keeps users locked into a potentially vulnerable, modified browser version compatible with the adware's hijacking capabilities. These binaries have positive detections on VirusTotal.

Chromnius / ChromniusEdge / Chromstera Browser / Web Genius / Artificius Browser

The browser extension and modified browser components used for the adware's core revenue-generating function: search result manipulation, ad injection, and homepage hijacking. Dragon Boss operates multiple branded Chromium-based browser products — Chromnius, ChromniusEdge, Chromstera Browser, Web Genius, and Artificius Browser — all detected as PUPs by multiple security vendors. These are the visible "products" the operation uses to justify its search monetization business description. Chromnius[.]com now redirects to a malware removal guide. Each product shares the same underlying update infrastructure, meaning all variants are subject to the same supply chain risk created by the unregistered domain.

Extended Product Family (Pre-Disclosure Variants)

In addition to the five browsers named in the Huntress disclosure, the Dragon Boss Solutions product family includes several earlier and variant properties documented by malware-removal vendors between 2023 and 2025. All redirect search queries through Dragon Boss infrastructure or through intermediate domains owned by the same entity. PCRisk documented Dragon Search, Dragon Honey, and Dragon Search Solutions as browser hijackers redirecting to dragonboss[.]solutions between January and April 2024. HackerDose's June 2024 analysis identified Universal Browser as a direct rename of Artificius Web Browser, with identical code, SHA256, and installation directory paths — the rebrand appeared to be triggered by accumulating AV detections against the Artificius name. WorldWideWeb and WorldWideWebUniverse appear in Huntress's IOC list but the underlying product branding is shared with the other Chromium-based browsers. The variety of product names serves a practical function: each rebrand temporarily resets detection rates while the underlying infrastructure, signing certificate, and update channel remain the same. A defender who blocks only the currently-reported names will miss the next rename.

Bing Rewards Points Monetization

HackerDose's technical analysis documented the specific monetization mechanism used by the browser family. When a user installs a Dragon Boss browser and enters a search query, the query is redirected first to Artificius[.]com (or an equivalent Dragon Boss-controlled domain), then forwarded to Bing. Microsoft Bing awards Bing Rewards points for searches performed through its platform. Because the Dragon Boss browser is configured as the user's default search engine and the browser identifies itself to Bing as the querying agent, the Bing Rewards points accrue to the Dragon Boss operator's Microsoft account rather than to the user. These points can be redeemed for gift cards or cash equivalents via the Microsoft Rewards program. This model is identical to the "Simple New Tab" malicious extension documented by HackerDose in a prior analysis, suggesting a broader pattern of Bing Rewards abuse across multiple PUP families. The monetization model is relevant to the threat profile because it establishes a direct financial incentive to forcibly install and persist the browser on user endpoints — which in turn explains the aggressive uninstall resistance, the Defender policy restrictions on Google and Firefox, and ultimately the pivot to AV destruction as revenue protection.

Infrastructure: Advanced Installer Update Framework

Dragon Boss did not write its update mechanism from scratch. The operation uses Advanced Installer — a legitimate, commercial Windows installer authoring tool widely used by legitimate software developers — as its update delivery framework. The update configuration is embedded in an .ini file packaged with each binary and specifies: the primary update URL, a fallback URL, poll frequency (CheckFrequency=1, meaning every poll interval), AutoCheck behavior (NoDisableAutoCheck=1, meaning users cannot turn off update checks), scope (PerMachine, meaning the updater runs with SYSTEM privilege rather than per-user), and silent installation flags. When the updater polls an update URL, it fetches an updates.txt manifest file that points to an MSI payload. The MSI is downloaded, validated against the TLS certificate of the serving domain, and installed silently via msiexec.exe with SYSTEM privilege. Huntress confirmed in lab testing that no code-signing check is performed against the MSI itself — only the serving domain's TLS certificate is validated, and any certificate from a publicly-trusted CA is accepted. This is the architectural flaw that, combined with the unregistered primary domain, made the entire fleet of 25,000+ endpoints hijackable for approximately ten dollars in domain registration fees.

The Exact Failure Mode (Architectural Detail)

The technical specifics of the hijack pathway are worth spelling out because they determine what controls actually mitigate a future variant and what controls only appear to. The updater uses Advanced Installer's built-in update checker, which was designed for legitimate software distribution where the publisher controls the update domain permanently. In that legitimate use case, TLS validation of the domain certificate is sufficient — only the publisher can serve from their own domain. Dragon Boss's deployment violates that assumption in two ways.

First, the primary update domain was left unregistered, meaning there was no publisher-controlled TLS endpoint. Any third party who registered the domain could obtain a TLS certificate from any publicly trusted certificate authority — the kind issued routinely for any newly registered domain — and that certificate would satisfy the updater's validation check. Huntress confirmed in a controlled lab that the updater requires a trusted-CA certificate but does not require Dragon Boss's specific certificate; a self-signed certificate was rejected, but any valid CA-issued certificate was accepted. Second, the updater does not perform a code-signing check against the downloaded MSI payload. The MSI does not have to be signed by Dragon Boss Solutions, or by anyone in particular. It merely has to be an MSI file served over HTTPS from the configured domain with a trusted-CA certificate. In combination, these two design choices mean the hijack vector required no cryptographic compromise, no exploitation, and no social engineering — just a domain registration and a routine TLS certificate.

This is why Huntress's pre-emptive registration of chromsterabrowser[.]com is material to the story rather than just an after-the-fact mitigation. Had the domain been registered by any other party — a criminal actor, an opportunistic squatter, a state-affiliated group — before Huntress reached it, that party would have had a 24-hour window to push arbitrary MSIs through the update channel before any public disclosure existed. Tens of thousands of endpoints, all with AV already disabled, would have received whatever was served. Huntress's lab confirmation — that a benign MSI served from a CA-signed domain was accepted and silently executed as SYSTEM — verifies this was not a theoretical risk. The controls that would have prevented the hijack architecturally are not IOC-level blocks or certificate revocation: they are application allowlisting that denies Dragon Boss-signed binaries regardless of domain state, and organizational policy that treats SYSTEM-privileged update channels on non-enterprise software as always-in-scope risk, not background noise.

Indicators of Compromise

IOCs sourced from Huntress research (James Northey and Ryan Dowd) published April 14, 2026. The sinkhole observation period recorded 23,565 unique IP addresses over 24 hours, representing 25,000+ total endpoints. Verify currency before operational use — public disclosure accelerates domain takedown and certificate revocation timelines. Huntress characterized the sinkhole data as a population of endpoints, already running with AV disabled, polling an update domain under Huntress's control — the same domain an adversary could have claimed for the cost of a routine registration.

Mitigation & Defense

Dragon Boss exploits the PUP grey area — software that is signed, loosely consented to, and historically deprioritized by security teams. The attack chain requires no CVE, no phishing link, and no user with elevated awareness. Every technique it uses is a legitimate Windows mechanism that most organizations never monitor. Effective defense is therefore not about patching a vulnerability: it is about closing visibility gaps that standard AV and EDR tools were never designed to cover, and changing the organizational posture toward PUP detections entirely. The guidance below is divided into immediate detection and hunting steps (what to do right now if you have not already) and longer-term hardening (what to put in place to prevent recurrence and catch the next variant).

Immediate Detection & Hunting

• Hunt for Dragon Boss WMI event subscriptions — this is the highest-priority action.

  Why: ClockRemoval.ps1 installs two WMI permanent event subscriptions — MbRemovalMbSetupKillConsumer and MbRemovalMbSetupKillConsumerTrace — in the root\subscription namespace. These survive reboots, survive scheduled task deletion, and self-recreate at every boot via the Invoke-MbSetupWmiBootEnsure function. Standard antivirus tools do not enumerate WMI subscriptions. An endpoint can be fully "cleaned" of visible artifacts while the WMI subscriptions remain and immediately re-deploy them. This means WMI must be cleared before any AV reinstallation will hold.

  How: Query the subscription namespace directly from an elevated PowerShell prompt:

  Get-WMIObject -Namespace root\subscription -Class __EventFilter | Where-Object {$_.Name -match "MbRemoval|MbSetup"} Get-WMIObject -Namespace root\subscription -Class __EventConsumer | Where-Object {$_.Name -match "MbRemoval|MbSetup"}

  To remove a confirmed malicious subscription: Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding | Remove-WMIObject — then remove the corresponding Filter and Consumer objects individually. Alternatively, use Autoruns (Sysinternals) with the WMI tab to enumerate and delete subscriptions visually.

  For SIEM detection: Windows Event ID 5861 in the Microsoft-Windows-WMI-Activity/Operational log fires on subscription creation by default — no additional audit policy configuration is required. Alert on any 5861 event where the consumer name contains "MbRemoval" or "MbSetup." Also monitor Sysmon Event IDs 19 (WMI filter), 20 (WMI consumer), and 21 (WMI consumer binding) if Sysmon is deployed. Note: Sysmon does not capture timer-based WMI events, which is why 5861 monitoring is essential even when Sysmon is present. New WMI permanent event subscriptions are rare on production endpoints; any unexplained 5861 event should be treated as suspicious regardless of the consumer name.

  Caveat: If an infected endpoint has had its event logs cleared by an operator, 5861 will show no history. In that case, examine the WMI database directly — the OBJECTS.DATA file at %SystemRoot%\System32\wbem\Repository\ stores compiled WMI subscriptions persistently and survives log clearing. Tools such as PyWMIPersistenceFinder can parse this file offline.

• Inspect all five Dragon Boss scheduled tasks.

  Why: ClockRemoval.ps1 creates five SYSTEM-level scheduled tasks: ClockSetupWmiAtBoot, DisableClockServicesFirst, DisableClockAtStartup, RemoveClockAtLogon, and RemoveClockPeriodic (runs every 30 minutes). These tasks re-run the AV kill and registry-stripping routines continuously. Removing AV software without first removing these tasks means AV will be disabled again within 30 minutes of reinstallation — or immediately on the next reboot. The script performs selective self-cleanup (it removes some tasks once AV is confirmed gone) but the boot task and WMI subscriptions are intentionally left permanent.

  How: Get-ScheduledTask | Where-Object {$_.TaskName -match "Clock|WMILoad|ClockRemoval"} — then verify the task action points to a ClockRemoval.ps1 path. Also check %SystemRoot%\System32\config\systemprofile\AppData\Local\WMILoad\ for the script itself. To remove: Unregister-ScheduledTask -TaskName "ClockSetupWmiAtBoot" -Confirm:$false (repeat for each task name). Delete the WMILoad directory after the tasks are removed.

  Caveat: Task names may vary across Dragon Boss variants. Hunt broadly for any scheduled task whose action path references a WMILoad directory or a PowerShell script in the SYSTEM profile's AppData, not just the specific names above.

• Audit the Windows hosts file for AV domain blocks.

  Why: ClockRemoval.ps1 rewrites %SystemRoot%\System32\drivers\etc\hosts to redirect AV vendor update and download domains to 0.0.0.0, using an embedded JSON list of vendor domains. This is maintained by the function Invoke-MbRemovalAvHostsBlock and re-applied at every 30-minute interval. Even if AV software is reinstalled, it cannot download signature updates or reach vendor servers while these blocks are in place. The reinstalled AV will appear functional but be blind to new threats.

  How: Open the hosts file in a text editor or run Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String "0.0.0.0". Dragon Boss entries are bracketed by the marker comment # BEGIN AV-UPDATE-BLOCK-v1 (ClockRemoval.ps1) and are trivially identifiable. Remove all entries between the Dragon Boss markers. After cleaning, verify AV vendor connectivity before declaring the endpoint remediated.

  For ongoing monitoring: File integrity monitoring (FIM) on the hosts file is the most reliable long-term control. Any write to %SystemRoot%\System32\drivers\etc\hosts should generate an alert. In a SIEM, a string match on AV-UPDATE-BLOCK-v1 in hosts file content provides a near-zero false-positive detection rule. Note that standard AV does not monitor the hosts file for malicious content — FIM must be a separate control.

  Caveat: Cleaning the hosts file without removing WMI subscriptions and scheduled tasks first is pointless — the blocks will be re-added within 30 minutes. Remediation order matters: remove persistence mechanisms first, then clean artifacts.

• Audit Windows Defender exclusions for pre-staging indicators.

  Why: ClockRemoval.ps1 adds Defender exclusions for directories that do not exist at the time of infection — %LOCALAPPDATA%\DGoogle, %LOCALAPPDATA%\EMicrosoft, %LOCALAPPDATA%\DDapps, %ProgramData%\Chromnius, and %ProgramData%\ChromniusEdge. These paths are staging directories reserved for follow-on payloads. Exclusions for non-existent paths serve only one purpose: ensuring that any file placed there later will not be scanned. No legitimate software adds Defender exclusions for directories that do not exist on the system.

  How: From an elevated PowerShell prompt: Get-MpPreference | Select-Object -Property ExclusionPath, ExclusionProcess, ExclusionExtension. Review each ExclusionPath entry; any path containing "DGoogle," "EMicrosoft," "DDapps," "Chromnius," or "ChromniusEdge" is a Dragon Boss indicator. Remove with: Remove-MpPreference -ExclusionPath "C:\Users\[user]\AppData\Local\DGoogle". Repeat for each malicious entry.

  Caveat: In enterprise environments managed via Group Policy, Intune, or Configuration Manager, locally added exclusions may be visible through PowerShell but overriding them requires removing the malicious entries at the management layer as well. Also note that automatic server-role exclusions on Windows Server 2016 and later are not visible in the Windows Security app or via standard PowerShell — use Get-MpPreference for the complete picture. Microsoft's current guidance recommends periodic exclusion audits as a standing security practice, not only in response to incidents.

• Hunt for Dragon Boss-signed binaries across the environment.

  Why: The entire Dragon Boss attack chain is initiated by signed executables. The Authenticode subject name "Dragon Boss Solutions LLC" appears on all confirmed malicious binaries — updater executables, modified Chrome binaries, and MSI installers. If any of these remain on an endpoint after initial cleanup, the update mechanism can re-deploy ClockRemoval.ps1 the next time it polls its configured domain. Removal of artifacts without removal of the signed binaries themselves leaves the infection mechanism intact.

  How: Search for processes and files signed by "Dragon Boss Solutions LLC" using EDR telemetry, Autoruns (check all tabs), or a manual file search. Known binary names include RaceCarTwo.exe, TableBoatThree.exe, WinDefenseFive.exe, WinDefenseThree.exe, WorldWideWeb.exe, ChromsteraUpdater.exe, and ArtificiusUpdater.exe, but the naming convention ([Word][Word][Number].exe) means variants exist with different names — do not rely solely on filename matching. Verify the Authenticode signature on any suspicious executable: (Get-AuthenticodeSignature "C:\path\to\file.exe").SignerCertificate.Subject.

  Also check for Dragon Boss-modified Chrome binaries running with the flag --simulate-outdated-no-au="01 Jan 2199". These have positive VirusTotal detections but may not be caught by endpoint AV that has been disabled or excluded. Any Chrome binary signed by Dragon Boss Solutions LLC should be removed and replaced with an official Google-distributed binary.

  Caveat: The Dragon Boss Authenticode certificate had not been revoked at the time of public disclosure (April 2026). Microsoft and the issuing CA should be expected to revoke it following the Huntress disclosure, but certificate revocation timelines vary, and timestamped binaries may continue to appear valid even after revocation depending on how revocation checking is enforced in your environment. Do not rely on certificate trust status alone — use hash-based detection from the IOC list alongside certificate subject matching.

• Verify AV and EDR agent check-in from all enrolled endpoints.

  Why: Silent AV removal does not generate an alert. The endpoint does not phone home to say its security tool is gone. The only way to detect a host where ClockRemoval.ps1 has succeeded is to notice the absence of expected check-ins from that host in your EDR or AV management console. Dragon Boss specifically targets Malwarebytes, Kaspersky, McAfee, and ESET — if your organization uses any of these, endpoints that have stopped reporting to the management console are the primary signal of active infection. This is consistent with NIST SP 800-53 SI-3 (Malware Protection), which requires organizations to verify that malware protection is operating correctly, not merely that it is installed.

  How: In your EDR or AV management console, filter for endpoints that have not checked in within your expected heartbeat window (typically 24–48 hours for managed endpoints). Any endpoint that goes silent unexpectedly — particularly one that was previously healthy — should be investigated before being assumed to be offline or decommissioned. Pull the last-seen timestamp and cross-reference with user activity logs to determine if the machine is still in use.

  Caveat: Check-in gaps can have legitimate causes — offline laptops, VPN issues, maintenance windows. Threshold tuning matters: too short a gap and you generate false positives; too long and you miss infections. The recommended approach is to correlate silent check-in with other signals (recent user logon, network activity) before triaging. Organizations with no centralized AV management console face a harder problem — standalone AV with no management plane provides no visibility into silent removal at all, which is a structural gap worth addressing independently of this incident.

Longer-Term Hardening

• Implement application control that does not rely solely on code-signing trust.

  Why: Dragon Boss demonstrates precisely why code signing alone is insufficient as a trust signal. The entire attack chain is built on a legitimately signed certificate. Any application control policy that trusts all signed binaries will not block Dragon Boss. NIST SP 800-53 CM-7 (Least Functionality) and MITRE ATT&CK mitigation M1038 (Execution Prevention) both recommend application allowlisting — permitting only explicitly authorized software to execute, rather than blocking only known-bad software.

  How: Microsoft's current recommended approach is Windows Defender Application Control (WDAC), which supersedes AppLocker (AppLocker is no longer receiving new features). WDAC enforces at the kernel level and can block executables by hash, file path, publisher, or combinations of these. Critically, WDAC can create a deny rule for the specific Dragon Boss Solutions LLC certificate subject name, which blocks all binaries signed by that entity regardless of filename or location. Start WDAC deployment in audit mode first — this logs what would have been blocked without actually blocking it, allowing you to tune the policy before enforcement. A policy that blocks execution based on specific denied publisher certificates is lower-friction to deploy than a full allowlist and directly addresses the Dragon Boss vector.

  Caveat: Full application allowlisting (block-by-default) is operationally complex and should be approached carefully. Organizations with diverse, user-managed software inventories may find a targeted deny rule for Dragon Boss more practical than a full allowlist as an immediate step. Also note that timestamped Dragon Boss binaries may bypass revocation-based blocks depending on how Authenticode revocation checking is configured — hash-based deny rules are more reliable than certificate-based revocation alone.

• Classify PUP detections as incidents, not maintenance tasks.

  Why: The central operational failure that allowed Dragon Boss to persist across enterprise environments is that PUP detections were deprioritized or silenced. AV tools flagged these binaries as browser hijackers and generated low-severity alerts that many organizations suppressed, deferred, or handled via automated cleanup without investigation. A Dragon Boss detection is not a browser hijacker cleanup. It is evidence that a SYSTEM-privilege update channel is running on that endpoint, actively connected to attacker-controlled infrastructure, with AV potentially already disabled. The Huntress Managed Service Provider (MSP) environment detected Dragon Boss precisely because WMI persistence signals were escalated — not because AV caught something new.

  How: Update your incident classification policy to treat any detection of Dragon Boss Solutions LLC-signed binaries, Chromnius, ChromniusEdge, Chromstera Browser, Web Genius, or Artificius Browser as a Severity 2 or higher incident requiring manual investigation. The investigation checklist should include: verify WMI subscription state, verify scheduled tasks, verify hosts file, verify Defender exclusions, verify AV check-in history, and verify whether any payloads beyond ClockRemoval.ps1 have been deployed. Do not close the ticket until all five of these checks are clean and AV has been verified as reinstalled and checking in.

  Caveat: Not every PUP detection warrants the same response — escalating all PUP alerts equally would create unsustainable alert volume. The Dragon Boss-specific indicators (WMI consumer names, scheduled task names, hosts file markers, Defender exclusion paths) should be the trigger for escalation, not the PUP classification alone. However, any PUP installed with SYSTEM privilege via a signed updater should automatically be treated as higher severity than a browser extension.

• Enforce NIST SP 800-53 SC-18 (Mobile Code) to cover bundled PUP installers.

  Why: SC-18 requires organizations to define acceptable and unacceptable mobile code, authorize its use, and implement technical controls to prevent execution of unacceptable code. NIST defines mobile code broadly — any program, application, or content that can be transmitted across a network and executed on a remote system. Bundled free software installers that include PUPs meet this definition. However, SC-18 implementations in most organizations focus on browser-delivered scripts and active content, not on standalone installer bundles. Dragon Boss arrived via installer EULAs that technically obtained consent but delivered SYSTEM-level execution capability. SC-18 should explicitly classify PUP-bundled installers as unacceptable mobile code and implement technical controls — such as software restriction policies, WDAC, or endpoint DLP rules — to prevent their execution.

  How: Review your SC-18 policy documentation and add explicit language covering bundled installer packages, EXE and MSI installers downloaded from non-approved sources, and software that installs components signed by entities not on an approved publisher list. The technical control tier should include: (1) blocking execution of MSI and EXE files from user download directories via WDAC or AppLocker path rules; (2) requiring all software installation to go through an approved software catalog or deployment system; and (3) periodically auditing installed software against the authorized software list per CM-8 (System Component Inventory).

  Caveat: SC-18 is primarily a compliance framework control applicable to federal agencies and organizations following NIST RMF. Non-federal organizations may not be subject to SC-18 directly, but the underlying principle — formally defining what mobile code is acceptable and technically preventing unapproved code from executing — applies to any environment. The practical implementation via WDAC, AppLocker, or equivalent tools is the same regardless of whether SC-18 compliance is a formal requirement.

• Block Dragon Boss network indicators at the perimeter — but do not treat this as a primary control.

  Why: The active C2 domains used by Dragon Boss (listed in the IOCs section) can be blocked at DNS, firewall, or proxy layers to prevent infected endpoints from polling for updates. However, this is a secondary control, not a primary one. Domain blocking is effective only as long as the specific domains remain in use and the sinkholed domains remain sinkholed. Dragon Boss can change its update URLs in any future payload. An endpoint that has already received ClockRemoval.ps1 is compromised regardless of whether the update domain is blocked — the AV-killing capability is already deployed and the WMI/task persistence remains active.

  How: Block the following at DNS or firewall: worldwidewebuniverse3[.]com, worldwidewebframework2[.]com, artificialupdates[.]com, dragonstraffic[.]com, updaterituals[.]com, chromsteraupdates[.]com, isready26[.]online. Note that chromsterabrowser[.]com and worldwidewebframework3[.]com are sinkholed by Huntress — blocking them is still appropriate but connections to those domains now reach Huntress infrastructure, not the threat actor. Cross-reference the IOC list against your SIEM for any historical outbound connections to these domains; historical hits indicate endpoints that should be prioritized for investigation.

  Caveat: IOCs burn quickly after public disclosure. New Dragon Boss variants can be configured to poll entirely different domains. Treat network blocking as an IOC-level control that needs periodic refresh, not a durable architectural defense against this threat actor class.

Sources & Further Reading

Sources below are organized by category for operational reference. Primary research is the original Huntress publication; all other entries either derive from that research, provide independent verification or commentary, or document the pre-disclosure history of the Dragon Boss product family.

Primary Research

• Huntress (James Northey & Ryan Dowd) — When PUPs Grow Fangs: Dragon Boss Solutions' $10 Supply Chain Risk (April 14, 2026) — the original technical disclosure; acknowledges Lindon Wass and Michael Elford as contributors
• Huntress — James Northey author page

Mainstream Infosec Press Coverage (April 2026)

• BleepingComputer — Signed Software Abused to Deploy Antivirus-Killing Scripts (April 15, 2026) — includes the detail that Dragon Boss's website was offline when BleepingComputer attempted to reach the company
• Infosecurity Magazine — Signed Adware Operation Disables Antivirus Across 23,000 Hosts (April 15, 2026)
• Dark Reading — 'Harmless' Global Adware Transforms Into an AV Killer (April 16, 2026)
• Cybernews — Trusted adware app left 25,000+ systems open to a $10 supply-chain hijack (April 15, 2026)
• Cyber Security News — 25,000+ Endpoints Exposed by Dragon Boss Solutions Update Domain Supply Chain Attack (April 15, 2026)
• GBHackers (Mayura Kathir) — Dragon Boss Solutions Supply Chain Attack Exposes 25,000+ Endpoints (April 15, 2026)
• Cyberpress — 25,000+ Endpoints Left Exposed In Dragon Boss Solutions Domain Update Breach (April 15, 2026)
• TechNadu (Lore Apostol) — Dragon Boss Solutions Malware Exposes 25,000 Endpoints (April 15, 2026)

Threat Intelligence & Detection Engineering

• SOC Prime — Dragon Boss Exposes 25,000+ Endpoints via PUP — includes Sigma detection rules, Mermaid attack-path diagram, regression test scripts, and a cleanup routine
• Rescana — Dragon Boss Solutions Signed Software Abused to Disable Antivirus Protection in Global Malware Campaign (April 16, 2026) — structured incident analysis with sector impact breakdown
• Cryptika (Dubai) — 25,000+ Endpoints Exposed by Dragon Boss Solutions Update Domain Supply Chain Attack

Regional and MSP/MSSP Coverage

• Arabian Post — Dragon Boss breach widens supply chain alarm — regional UAE business angle; contextualizes within Verizon 2025 DBIR
• Arabian Post — Signed adware campaign strips endpoint defences
• CTRL Alt Nod (German) — Signierte Malware-Kampagne deaktiviert Antivirus-Software weltweit
• Happier IT (Canadian MSP) — 25,000+ Endpoints Exposed in Dragon Boss Solutions Update Breach
• BackBox.org News — 'Harmless' Global Adware Transforms Into an AV Killer (April 16, 2026)

Pre-Disclosure History: Dragon Boss Product Family (2023–2024)

These sources predate the April 2026 Huntress disclosure and document the Dragon Boss browser family as browser-hijacking PUPs. They establish the operation's pre-existing presence, product naming conventions, monetization model, and the sustained suspicion from the security community referenced by Arabian Post.

• Gridinsoft — dragonboss.solutions trust score analysis (March 21, 2024) — trust score 5/100, classified as Adware distributor
• Gridinsoft — What is Chromstera Browser? Unwanted App Analysis & Removal
• HackerDose — Artificius Web Universal Browser (Rogue App) - Chromstera Uninstall (June 17, 2024) — documents the Bing Rewards points monetization model and the Artificius/Universal Browser rebrand
• PCRisk — Chromstera Unwanted Application (August 28, 2023)
• PCRisk — Chromnius Adware (June 9, 2023)
• PCRisk — Dragon Search Browser Hijacker (January 3, 2024)
• PCRisk — Dragon Honey Browser Hijacker (March 28, 2024)
• PCRisk — Dragon Search Solutions Browser Hijacker (April 8, 2024)
• MalwareTips Forums — Chromstera browser and malicious extensions (December 30, 2023) — forum discussion with IOCs, registry policies, DisableAntiSpyware evidence
• MalwareTips — Remove Dragon Boss Search [Virus Removal Guide] (January 26, 2026)
• Vivaldi Forum — Chromnius identified as Dragon Boss Solutions LLC product (April 25, 2023) — places the company in Sharjah Media City, UAE

MITRE ATT&CK References

• MITRE ATT&CK — T1562.001: Impair Defenses: Disable or Modify Tools
• MITRE ATT&CK — T1546.003: Event Triggered Execution: WMI Event Subscription
• MITRE ATT&CK — T1218.007: System Binary Proxy Execution: Msiexec
• MITRE ATT&CK — T1553.002: Subvert Trust Controls: Code Signing
• MITRE ATT&CK — T1210: Exploitation of Remote Services

Frameworks & Compliance

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NoHackie — The Adware That Ate Your Antivirus: Inside the Dragon Boss Supply Chain Trap (April 19, 2026)