I'm currently in the process of learning different techniques malware use to prevent debugging, and I came across an issue I can't seem to really understand. This piece of malware that I am currently trying to figure out and debug uses some kind of anti-debugging technique that doesn't allow me to attach a debugger in the first place. I have tried using things such as Scylla-hide, I've also tried manually going in and hooking common anti-debugging API calls to see what is going on, but no luck so far. I also tried with WinDbg hoping it would give me some error message I can go off of, and it gave me this: WinDbg output when trying to debug program
So this got me thinking that it was doing something to prevent a thread being started and that is what is causing any debugger from being able to attach. I also tried injecting a DLL with the typical LoadLibrary CreateRemoteThreadEx technique and seems it doesn't allow me to create a thread that way either. I've looked at as much as possible on anti-debugging and can't seem to find an answer to this. Any nudge in the right direction would be greatly appreciated.
I'm hoping to be able to circumvent this in user-mode, as I'm trying to understand what exactly it is doing to stop me from debugging rather than simply bypassing it. This is my first time asking a question so sorry if anything was hard to understand.
This is the defacto antidebug reference by Peter Ferrie, it's an amazing resource: https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf
It contains almost every known anti-debug method, you can use this reference and tick each method off your list until you find the ones that are implemented, the book should also help you easily mitigate each method as well.
Per our conversation in the comments, the answer to your question was that the process was hooking both DbgBreakPoint and DbgUiRemoteBreakig. Patching them enabled you to then attach a debugger.
