![]() The risk for us here is obviously that a security product can load its DLL into our migrated process (shown here as Internet Explorer) and review our activity.īridging this gap however is relatively straight forward using the code shown above along with the PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON mitigation option. In red we can see processes which do not benefit from blockdlls protection, whereas in blue we see each child spawned process from Cobalt Strike is protected with a mitigation policy. Let’s look at a common phishing scenario where we are attempting to deliver a Cobalt Strike beacon via a macro enabled document: So we now know just how Cobalt Strike achieves its protection, but during a typical engagement there is still a gap where arbitrary DLL’s may trip us up. If we wanted to recreate this within our own tooling, we can simply use code such as: Bridging The blockdlls Gap So what Cobalt Strike is doing here is using a CreateProcess API call along with a STARTUPINFOEX struct containing a mitigation policy which, in this case, is being used to block non-Microsoft signed DLL’s. The Attribute parameter of 0x20007 actually resolves to a definition of PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, and the value of 0x100000000000 resolves to PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON. So how does Cobalt Strike go about implementing this functionality? Well if we hunt through a CS beacon binary, we see a reference to UpdateProcThreadAttribute: With the mitigation flag set, if a DLL which has not been signed by Microsoft is attempted to be loaded into the process, we find that this will fail, sometimes with a nice verbose error such as: Once our child process has been spawned, we can see the resulting protection within something like ProcessHacker: To leverage this functionality, we simply use the blockdlls command on an active session and spawn a child process (for example, using the spawn command): ![]() blockdlls Internalsīlockdlls was released with version 3.14 of Cobalt Strike and is used to protect any child processes spawned by a beacon from loading non-Microsoft signed DLL’s. This is of course a method of blocking endpoint security products from loading their user-mode code via a DLL with the purpose of hooking and reporting on the execution of suspicious functions.Īfter a few discussions and tweets looking at just how this is implemented, I was asked some additional questions from people who wanted to use this themselves outside of Cobalt Strike, so in this post I will explore this functionality a little further by showing just how blockdlls works under the hood, how you can use it to protect your malware before a beacon is launched, and look at an additional process security option which could help us to deter endpoint security products from listening in so easily. In an update to Cobalt Strike, the blockdlls command was introduced to provide operators with the option of protecting spawned processes from loading non-Microsoft signed DLL’s. Tagged in cobalt strike, redteam, windows, vba « Back to home Protecting Your Malware with blockdlls and ACG
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |