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:


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:

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:


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:

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:

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:

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