1

I am attempting to debug a process with windbg (with admin privileges) and I am getting the following error:

Could not attach to process XXXX =, NTSTATUS 0xC0000022

{Access Denied} A process has requested access to an object, but has not been granted those access rights

I know some anti-debugging tricks are at play, but I am not sure where to start looking. This program is running multiple processes, including a few with interesting names such as InjectionService, I cannot attach to any of them. And the binaries themselves are obfuscated. I am wondering if someone can point me in the right direction to get started, for example by referencing some reading material.

Improve this question
6
  • This software has also installed some Kernel drivers which I believe is used in this anti-debugging trick. I think I have my work cut out for me here.
    – SivaDotRender
    Commented Mar 2, 2020 at 4:08
  • 2
    Processes and other kernel objects have ACLs attached. What exact symptoms make you believe there's more at play here than restrictive ACLs? You definitely give too little information altogether. What does that even mean that the binaries are obfuscated? From the PoV of a human every binary is an obfuscation layer. We know nothing about the targets which yould allow for more than pure guesswork. Please edit the question to add some information that may be relevant to everyone here who does not possess the power to read minds ;) Thanks.
    – 0xC0000022L ♦
    Commented Mar 2, 2020 at 7:17
  • @0xC0000022L I know the binary is obfuscated because the disassembly looks obfuscated. Can you point me some reading materials regarding restrictive ACLs? I thought that this could also be a protected binary: (docs.microsoft.com/en-us/windows/win32/services/…). I apologize for the lack of details, I am not very experienced with this. I will update the question as I get more information
    – SivaDotRender
    Commented Mar 3, 2020 at 1:55
  • what you pointed to in your comment describes something I am intimately familiar. I have implemented an ELAM driver from scratch in a previous employment. Provided Microsoft's implementation of it is flawless (I don't think it is, but let's use that as the premise), I don't see how you'd be able to circumvent this on a running system. The very purpose is that the ELAM carries public key material that allows usermode AM services to be secured. You won't get around static analysis unless you are the one to find a flaw in Microsoft's implementation.
    – 0xC0000022L ♦
    Commented Mar 4, 2020 at 7:42
  • @0xC0000022L I was under the impression that you can debug the protected userland processes using kernel debugging: docs.microsoft.com/en-us/windows/win32/services/…. In this scenario, it does not look like the process that is interesting to me is protected: ``` +0x6fa Protection : _PS_PROTECTION +0x000 Level : 0 '' +0x000 Type : 0y000 +0x000 Audit : 0y0 +0x000 Signer : 0y0000```
    – SivaDotRender
    Commented Mar 5, 2020 at 14:58

1 Answer 1

Reset to default
1

The information you provided is limited, however, if an acl is set by a driver (usually what is done by anto virus softwares) you can use this technique:

First you can have to study the composition of processes and drivers to find how they inyeract. This can be done by observing the system behavior and by dumping the kernel various times. Usually on-demand crash dumps are allowed.

Once you managed to understand it, you have to find your way in having your code executed at ring 0. I usually find library side loading or patching an easy technique to have my code loaded when the signature is not enforced.

Your code should be able to disable the ACLs that prevent you from attaching a debugger. Note that, at ring 0, you are at other side of the airtight and ACLs do behave differently. Just escalating your privileges to ring 0 is usually enough.

Just for reference, a couple of times, the processes to allow to attach a debugger where stored in a list on a kernel driver. The driver couldn't be touched as signed, therefore the patching was done in RAM.

Improve this answer
4
  • While there are a few gems in this answer, it also cripples certain aspects. ACLs in KM are completely irrelevant for calls hailing from KM. Checking is typically only done for calls hailing from UM. This explains why the "same" functions (ntdll.dll vs. ntoskrnl.exe) behave differently. The SSDT is the key here. Furthermore I think static analysis of the drivers is more likely to yield helpful pointers. The ELAM itself is probably no useful target as it has restrictions that make it unlikely that it contains additional functionality. Also, mastering dump analysis is no small feat either ;)
    – 0xC0000022L ♦
    Commented Mar 4, 2020 at 7:48
  • Indeed, you are right. Certain aspects are oversimplified. I was trying to give a quite complete overview without throwing too many details which IMHO would complicate the matter at expense of clarity. Could you amend the answer where you find it to be imprecise?
    – Yennefer
    Commented Mar 4, 2020 at 8:31
  • not sure that (editing) is possible without changing the angle of your answer (contradicting your intent). To give you an example: if a driver creates a DO oftentimes the ACL won't be explicitly set. It can be done, but the default is plenty restrictive. And a Win32 service - running in the TCB - will typically be able to deal with a restrictive ACL. Also, since the OP came forward with ELAM-related aspects, I don't think that ACLs alone suffice to cover the possible angles (initially I thought of typical run-of-the-mill software, not AV/AM).
    – 0xC0000022L ♦
    Commented Mar 4, 2020 at 8:37
  • Ok, I understand. Thank you for your point of view:)
    – Yennefer
    Commented Mar 4, 2020 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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