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 DcomLauncha few artifacts exist under C:\Windows\System32 (in my case: svctrl64.exe, svcinsty64.exe, wsvcz\wlogz.dat, and a DLL matching the service name) a randomly named Windows service that looks like u###### (example: u952451) u###### u952451 that service name is in the svchost group membership list called DcomLaunch 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) C:\Windows\System32 svctrl64.exe svcinsty64.exe wsvcz\wlogz.dat 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. For security and privacy reasons, remediation is optional. 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: svchost.exe HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost 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). deep dive documents What’s inside DcomLaunch? My first check was just this: what does DcomLaunch contain? DcomLaunch reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v DcomLaunch 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. 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,}$ suspicious if it matches ^u\d{6,}$ ^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 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. u##### DcomLaunch Then I rebooted. After the reboot, a new u###### service appeared in the same place, with a different number. new u###### 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. generator So, the loop became: detect the persistence objectremove it cleanlyrebootre-checkif it reappears, assume a generator is still present detect the persistence object remove it cleanly reboot re-check 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 directoriesIt puts a shortcut (.lnk) in front so people click itthe shortcut launches a script chain (often VBS/BAT) and still opens a folder so it doesn’t look suspicious 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 .lnk 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. write-up u###### 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 defaultremediation only happens if you pass -Remediateyou can dry-run everything with -WhatIfregistry changes are preceded by a registry export backupkilling processes and deleting System32 artifacts are opt-in (because that’s the risky part) detection-only by default remediation only happens if you pass -Remediate -Remediate you can dry-run everything with -WhatIf -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 supports -WhatIf -Confirm SupportsShouldProcess Remediation If you run it with -Remediate, it does the minimum required to break the persistence technique: -Remediate stop / disable / delete the serviceremove the service name from DcomLaunchoptionally kill case-study processes (opt-in)optionally delete case-study artifacts under System32 (opt-in) stop / disable / delete the service remove the service name from DcomLaunch DcomLaunch optionally kill case-study processes (opt-in) optionally delete case-study artifacts under System32 (opt-in) System32 How I ran it 1. Detect only (no changes) .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 2. Validate that candidates exist as services .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -ValidateServices .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -ValidateServices 3. Dry-run remediation .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate -WhatIf .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate -WhatIf 4. Apply remediation (service + registry) .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate .\scripts\detect-and-remove-dcomlaunch-u-services.ps1 -Remediate Only after that would I consider: -KillProcesses-DeleteArtifacts -KillProcesses -KillProcesses -DeleteArtifacts -DeleteArtifacts Deleting under System32 is not something I want happening unless I’m confident. System32 Double checking After remediation and a reboot, I re-check the same things that flag the malware: DcomLaunch doesn’t contain the suspicious entrysc query <service> fails (because it’s gone/disabled)the service registry path is gone DcomLaunch doesn’t contain the suspicious entry DcomLaunch sc query <service> fails (because it’s gone/disabled) sc query <service> 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 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. u###### 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). DcomLaunch 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 Script + notes (this case study): https://github.com/arizh0/windows-u-service-miner-eradicationCase-study reference on CoinMiner campaigns: https://asec.ahnlab.com/en/91415/svchost grouping / Svchost registry key: https://techcommunity.microsoft.com/blog/askperf/getting-started-with-svchost-exe-troubleshooting/372644MITRE ATT&CK – Windows Service persistence (T1543.003): https://attack.mitre.org/techniques/T1543/003/PowerShell SupportsShouldProcess / -WhatIf / -Confirm: https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-shouldprocess?view=powershell-7.5 Script + notes (this case study): https://github.com/arizh0/windows-u-service-miner-eradication https://github.com/arizh0/windows-u-service-miner-eradication Case-study reference on CoinMiner campaigns: https://asec.ahnlab.com/en/91415/ https://asec.ahnlab.com/en/91415/ svchost grouping / Svchost registry key: https://techcommunity.microsoft.com/blog/askperf/getting-started-with-svchost-exe-troubleshooting/372644 https://techcommunity.microsoft.com/blog/askperf/getting-started-with-svchost-exe-troubleshooting/372644 MITRE ATT&CK – Windows Service persistence (T1543.003): https://attack.mitre.org/techniques/T1543/003/ https://attack.mitre.org/techniques/T1543/003/ PowerShell SupportsShouldProcess / -WhatIf / -Confirm: https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-shouldprocess?view=powershell-7.5 SupportsShouldProcess -WhatIf -Confirm https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-shouldprocess?view=powershell-7.5
