No Debugger, but a ton of "DbgUiRemoteBreakin" threads

Question

I noticed that just about every running process on my Windows 7 desktop - whether it be explorer.exe, lsm.exe, winlogon.exe, or firefox.exe has at least 1 (usually 6+) of the following thread: "ntdll.dll!DbgUiRemoteBreakin"

From what I can gather, "ntdll!DbgUiRemoteBreakIn is used by the debugger to break in to a process, and the debugger assumes that the local address of DbgUiRemoteBreakIn matches the remote address of DbgUiRemoteBreakIn in the target process. Kernel32 is required to be at the same base address because there are a number of internal kernel32 routines that, similar to ntdll!DbgUiRemoteBreakIn, are used in cross-process thread injection."

and, "the DebugBreakProcess API injects a remote thread into the address space of the target process."

I don't use or have any kind of debugger software/program that I know of, and the threads are active when no programs are running, right after the computer starts.

If I understand correctly, "ntdll.dll!DbgUiRemoteBreakin" are remote threads being injected into the computer. That doesn't seem good.

An example:

Any ideas on how to prevent it and/or figure out why it's happening?

Thank you!

Answer 1

I just run into this, and after reading trough all replies in DbgUiRemoteBreakin Technet thread I have found the answer at the end.

What you are looking at is not "ntdll!DbgUiRemoteBreakIn" but "ntdll!DbgUiRemoteBreakIn+0x50" which is a different address, but the debugger (process explorer) doesn't know/have the name for that address, because it's using outdated symbols.

To correct this go to Options->Configure Symbols..., Enter "srv*https://msdl.microsoft.com/download/symbols" into Symbols path (or download the symbols and use local cache instead of MS symbol server) and replace the dbghelp.dll with WinDbg version ("C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\dbghelp.dll"). You need to install WinDbg (part of Windows Driver Kit, Windows SDK) because the C:\Windows\System32\dbghelp.dll doesn't support symbol server and won't download the correct symbols.

Now it should show the correct name for the address, which is "TppWorkerThread".

Answer 2

The first explanation that comes to my mind for having applications being "debugged" mysteriously is that you are infected by some kind of malware that injects itself into other programs (this way, the malicious behaviour appears to come from these normal programs).

The way to prevent it would obviously be to remove such malware from your system. The hard part is identifying it. Did you look at the libraries loaded and startup processes?

Answer 3

Ignore the down votes. If it is not a "TppWorkerThread" it could be mimikats malware... you can mitigate against mimikats & other debugger attacks by disabling debugging as described here: https://medium.com/blue-team/preventing-mimikatz-attacks-ed283e7ebdd5 If you are missing the necessary group policies to disable debugging (as was I), follow the simple steps here (This is relevant to windows 7.) And for your convenience, so you don't have to install security compliance manager & SQL server express, you can just use this LocalGPO.msi

1. Run and install the file “LocalGPO.msi” on the workstation/server
2. Open command prompt and browse to : “C:\Program Files (x86)\LocalGPO”
3. Run following command “Cscript LocalGPO.wsf /ConfigSCE"
4. Now MSS Settings (and others) will be visible in Security Options in Local Group policy settings.

How to prevent this? Further Prevention: Keep on hardening your system and environment, including your router firmware & hardware... keep everything up-to-date... there are a million different ways for mimikats infections, probably the most common debugger type attack out there. This video is incredibly informative and is relevant to understand common methods a debugger attack could happen. In other words, keep your windows machine up-to-date & bear in mind mimikats is just one of hundreds of exploitation scripts in metasploit.

Run SFC /Scannow, and DISM at commandline to check for system corruption:

Dism /Online /Cleanup-Image /ScanHealth

If corruption detected, run:

Dism /Online /Cleanup-Image /RestoreHealth

As a last but often necessary resort for bad malware infections, you may want to consider doing an in-place dist-upgrade to clean up any hidden malware or changes that may have been done to the system and its permissions. Once a machine has been hit the damages may be irreparable without this. This is what I had to do to fix this exact same debugger problem.

Further Prevention: Just as one hardware example, if you are running an AMD Ryzen processor debugger exploits may be be taking place as an adjunct to hardware/chipset level exploits... be sure your motherboard firmware is up-to-date. Asus has told me personally, 2-3 weeks before the time of this post, they are still working on patching the following network/remotely exploitable hardware vulnerabilities threats:

1. CVE-2018-8930: The AMD EPYC Server, Ryzen, Ryzen Pro, and Ryzen Mobile processor chips have insufficient enforcement of Hardware Validated Boot, aka MASTERKEY-1, MASTERKEY-2, and MASTERKEY-3.
2. CVE-2018-8931: The AMD Ryzen, Ryzen Pro, and Ryzen Mobile processor chips have insufficient access control for the Secure Processor, aka RYZENFALL-1.
3. CVE-2018-8932: The AMD Ryzen and Ryzen Pro processor chips have insufficient access control for the Secure Processor, aka RYZENFALL-2, RYZENFALL-3, and RYZENFALL-4.
4. CVE-2018-8933: The AMD EPYC Server processor chips have insufficient access control for protected memory regions, aka FALLOUT-1, FALLOUT-2, and FALLOUT-3.
5. CVE-2018-8934: The Promontory chipset, as used in AMD Ryzen and Ryzen Pro platforms, has a backdoor in firmware, aka CHIMERA-FW.
6. CVE-2018-8935: The Promontory chipset, as used in AMD Ryzen and Ryzen Pro platforms, has a backdoor in the ASIC, aka CHIMERA-HW.
7. CVE-2018-8936: The AMD EPYC Server, Ryzen, Ryzen Pro, and Ryzen Mobile processor chips allow Platform Security Processor (PSP) privilege escalation.