Following up from the previous post, which ended up with a 4/25 detection rate – one that I would say decent but not perfect. Today, we will be applying a few extra techniques that hopefully will further help us with the detection, and that is encryption.
For now, we will be implementing a simple XOR encryption on our Mimikatz payload. As you can see from my previous post, we are currently importing mimikatz.dll into our injector as a resource, and then read that resource byte code into memory and inject it into notepad.exe. While this gave us exceptionally good result on dropping a 17/25 into a 4/25 – we still have the exact Mimikatz.dll binary sitting in our injector. Therefore, this post will be about how I encrypt the Mimikatz.dll binary with XOR and then decrypt it on run time as the injector is running. This will result in Anti Viruses not being able to detect our binary as it sits on Disk due to it being encrypted.
This is our encryption file. It just open the executable file, in our case mimikatz.dll and just XOR the entire file byte by byte. It then write it back out as mimikatz_hidden.dll.
Notice that the EncryptExecutable is your typical XOR function, nothing too special and it is the heart of the program. Same, applying the XOR function to our resource after we load it with the same key will work the same way due to how XOR functionality work.
Now, let’s compile it and see what is our new result.
1/25, wow. So this is actually a reoccurring theme in the malware/cryptor world. Eset NOD32 somehow, always is the only one that detects any sort of encryption. Apparently, Eset32 is doing something that no one else does, but given Eset is not a very well known-well used AV – we can call this a win for now. I will go deeper into reversing Eset32 and see what they are detecting our Mimikatz by. For now, I am happy with a 1/25. Thanks a lot for reading.
Zer0C00lSecurity 