How I Removed a Rogue "u######" Service Hiding in DcomLaunch

Written by arizh0 | Published 2026/02/16
Tech Story Tags: windows-security | crypto-miner-malware | malware-detection | threat-hunting | windows-malware | usb-malware-infection | windows-registry-persistence | powershell-remediation-script

TLDRA friend's laptop became noticeably slow and she asked me to take a look. What I found was a specific persistence pattern: a randomly named Windows service. I turned the manual steps into a single workflow script that detects this pattern.via the TL;DR App

A friend of mine recently told me her laptop had become unusually slow, and asked me to take a look. There were no useful antivirus alerts and nothing obvious like a single process name I could immediately flag as malware. It was just busier than it was supposed to be.

Given the unknowns, I didn’t try to identify a threat by label - I tried finding what was surviving reboots to keep slowing down the laptop.


What I ended up finding was a pretty specific persistence pattern:

  • a randomly named Windows service that looks like u###### (example: u952451)
  • that service name is in the svchost group membership list called DcomLaunch
  • a few artifacts exist under C:\Windows\System32 (in my case: svctrl64.exe, svcinsty64.exe, wsvcz\wlogz.dat, and a DLL matching the service name)


While this can be done manually, given you know the steps for detection and remediation, I decided to put this into a single script that does so automatically. For security and privacy reasons, remediation is optional. The repo is here.


Why svchost groups are a good hiding spot

svchost.exe hosts a lot of Windows services. Those services are grouped, and the group membership lists live here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost


So, if something slips an extra service name into a legit group list, it can easily blend into normal Windows behavior. Microsoft’s svchost deep dive covers the group model and why that Svchost key matters. Also, this "make a service and make sure it sticks around" is a standard persistence technique. MITRE documents it as Windows Service (T1543.003).


What’s inside DcomLaunch?

My first check was just this: what does DcomLaunch contain?

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v DcomLaunch


In doing this, I was looking for entries that don’t feel like normal Windows service names.


In my case, the weird one looked like u952451.

That pattern (letter + lots of digits) isn’t automatically malware, of course, but it’s unusual enough that you can suspect the file. Mine is:

  • suspicious if it matches ^u\d{6,}$

That’s intentionally narrow because the goal is to reduce false positives.


Does that service actually exist?

A stray string in a svchost list could be junk or a leftover. So next I just checked whether Windows actually knows about this service:

sc.exe query u952451

If it exists, it’s now a real persistence object and not just a weird registry string.


Removal worked… then it reappeared

At first I treated it like a one-off: remove the u##### service, remove it from DcomLaunch, clean what I could find.

Then I rebooted.


After the reboot, a new u###### service appeared in the same place, with a different number.


That was the moment it stopped looking like "one bad service" and started looking like a generator somewhere else on the system, something that was recreating persistence (like a dropper, installer, or secondary mechanism). In other words, I removed a symptom, not the root.


So, the loop became:

  1. detect the persistence object
  2. remove it cleanly
  3. reboot
  4. re-check
  5. if it reappears, assume a generator is still present


What it turned out to be: a USB-spread coinminer pattern

Now, the story made more sense: it lined up with coinminer campaigns that spread via infected USB flash drives.


The idea is simple:

  • The flash drive hides real files and folders by changing their attributes, and moving things into hidden directories
  • It puts a shortcut (.lnk) in front so people click it
  • the shortcut launches a script chain (often VBS/BAT) and still opens a folder so it doesn’t look suspicious


AhnLab has a write-up that matches this style and even shows the “USB Drive.lnk” + hidden folder setup, plus scripts with u######-style naming.


Now we automate

I didn’t want this to be a fragile checklist where one typo deletes the wrong thing, or leaves the malware intact. So, the script is designed around a few rules:

  • detection-only by default
  • remediation only happens if you pass -Remediate
  • you can dry-run everything with -WhatIf
  • registry changes are preceded by a registry export backup
  • killing processes and deleting System32 artifacts are opt-in (because that’s the risky part)

PowerShell supports proper -WhatIf / -Confirm flows via SupportsShouldProcess


Remediation

If you run it with -Remediate, it does the minimum required to break the persistence technique:

  1. stop / disable / delete the service
  2. remove the service name from DcomLaunch
  3. optionally kill case-study processes (opt-in)
  4. optionally delete case-study artifacts under System32 (opt-in)


How I ran it

1. Detect only (no changes)

.\scripts\detect-and-remove-dcomlaunch-u-services.ps1

2. Validate that candidates exist as services

.\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -ValidateServices

3. Dry-run remediation

.\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate -WhatIf

4. Apply remediation (service + registry)

.\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate

Only after that would I consider:

  • -KillProcesses
  • -DeleteArtifacts

Deleting under System32 is not something I want happening unless I’m confident.


Double checking

After remediation and a reboot, I re-check the same things that flag the malware:

  • DcomLaunch doesn’t contain the suspicious entry
  • sc query <service> fails (because it’s gone/disabled)
  • the service registry path is gone
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v DcomLaunch
sc query u952451
reg query "HKLM\SYSTEM\CurrentControlSet\Services\u952451" /s

If a fresh u###### appears after a reboot, I assume something is still on the machine generating these, and the cleanup isn’t actually done yet.


Limitations and when I’d reimage

Even if you remove the service and fix DcomLaunch, you haven’t proven the machine is clean. There could be other persistence (scheduled tasks, WMI subscriptions, drivers, whatever).

If this is a high-trust machine, or if you keep seeing the service regenerate and you can’t quickly find the generator, reimaging is often the fastest way back to certainty.


References



Written by arizh0 | cybersecurity fan!
Published by HackerNoon on 2026/02/16
ABOUTHow hackers start their afternoons. We publish tech stories and build publishing software.

READEntirely free library read by hundreds of millions to learn anything about any technology.

WRITEHackerNoon elevates quality technology writing far and wide across the interwebs.

PARTNERHackerNoon works directly with tech companies to place ads by content relevancy