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: enter image description here

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

Thank you!


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?

  • I'm not sure how to see what libraries are loaded - but if you could let me know I can share that. As for startup processes, I haven't been able to tell that any have changed. Here are the startups: i.imgur.com/q7znjKL.png – Noles Jan 25 '18 at 23:58
  • @Noles I think left screenshot is from ProcessExplorer? There should be a tab showing the modules (dlls) loaded by the process. – Ángel Jan 26 '18 at 0:02
  • Right, sorry. Keeping with lsm.exe, these are its DLLs: i.imgur.com/sKdL29W.png - and these are the handles: i.imgur.com/ZlzGGFl.png – Noles Jan 26 '18 at 0:04
  • As an update, I've restored the system to a week prior, and its still there. I've scanned using Malwarebytes and Security Essentials, and they found nothing. I also started up in Safe Mode and they were there. – Noles Jan 26 '18 at 1:59

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.

Configure Symbols

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



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.
  • mimikatz and Metasploit are two separate tools. This answer appears to be entirely unrelated to the actually question. – David Feb 2 at 22:54
  • Metasploit has decided to include Mimikatz as a meterpreter script to allow for easy access to its full set of features without needing to upload any files to the disk of the compromised host. It is entirely relevant; debuggers could be coming from hardware level exploitation vectors as well. – Tyler Feb 2 at 23:01
  • Perhaps try a search for DbgUiRemoteBreakin in the mimikatz source code. There are an infinite number of interesting security things to think about, but most of them are not a correct answer to this question. StackExchange is a Q&A site, not a discussion forum. – David Feb 3 at 20:40
  • "ntdll!DbgUiRemoteBreakIn" could be due to [mimikatz] (medium.com/blue-team/preventing-mimikatz-attacks-ed283e7ebdd5) or some other 0day malware, most users who search and arrive here will either be dealing with a security issue or a missing symbol issue, My response, while exhaustive, is relevant as the user asked for means for preventing ntdll!DbgUiRemoteBreakIn threads from appearing. In the case of actual malware, by disabling debugging it will 100% prevent "ntdll!DbgUiRemoteBreakIn" threads from appearing. As will protecting the system, and hardware. – Tyler Feb 4 at 4:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.