Combining techniques to defeat Windows Defender and default Applocker rules
I recently completed Sektor7’s RED TEAM Operator: Malware Development Essentials and was amazed and enamoured by the C++ techniques and concepts taught therein. You can find my study notes on malware here.
Having been previously inspired by both Bobby Cooke’s aproach to applying course knowledge outside of a lab, in addition to the tradecraft of an ex-colleague and fantastic red-teamer by the name of Jayden Caelli. I decided to take a very basic concept and apply the knowledge I received from Sektor7 to create something that would both challenge me and lay the foundations for a red-teaming toolset.
For the basic technique I chose a standard XML shellcode runner which I would have to heavily modify in order to get past Defender.
This presented a huge obstacle for me personally, as the course taught C++, and the wrapper inside the XML was C#.
As a total C# noob, many hours were spent learning how to apply call obfuscation in C#, and frankly I do not have the time or the willpower to cover this little side quest, rest assured that many amusing little mistakes were made and I learnt a lot :)
Let’s jump into some obligatory screenshots of our environment shall we?
First we have our up-to-date windows VM, with both real time protection turned on and the default Applocker policy:
As well as our low-priv account, which will be constrained by Applocker’s default policy.
To begin, let us generate some contrived shelcode to pop calc.exe
Once we have done this, let’s grab the XML shellcode runner template from here and insert our shellcode.
(The above code in red is what we wil be aiming to obfuscate later on)
We run our malicious XML with MSBuild, and observe that defender catches it. surprised_pokeman_maymay.gif
Of note are the three Win32APIs being imported via PInvoke.
I knew I had to find a way to abstract away from this functionality, and my searches led me to delegation. This was still challenging for me, and after some tyre spinning I was suggested to take a look at this stackoverflow post, which gave me enough breadcrumbs to begin crafting some workable code.
During my initial testing, I chose MessageBox to ensure that as a proof of concept I could at least call a trivial Win32API.
After being sure that my code was correct I was plagued by null pointer errors. Through troubleshooting I isolated the issue down to either the dllname or the function name, well, we all know that user32.dll is a dll that…exists. So I decided to load it up in a debugger and visually confirm for my own sanity that MessageBox is indeed still present in user32.dll:
Lo and behold, it does not exist.
I felt like a fool! But was greatful for the learning experience.
After amending my code, I was able to confirm that my delegate code template is indeed good, and calls as it should.
Muuuchhhh better 8)
Having confirmed my template, I could now go on to replace using DllImport with delegates.
This was still caught by AV as I expected, however I had another trick up my sleeve thanks to the Sektor7 course work. I spend an amount of time creating a python script that would generate a malicious XML file containing shellcode supplied in the form of a .bin file as a script arg.
This script would also AES encrypt the names of the delegates, the shellcode itself, and multiple other strings and variables.
We can see that by simply applying a few basic techniques, we end up with a vastly different payload than we originally had, with the original on the right and our generated XML on the left:
I grabbed a raw https beacon payload from Cobalt Strike and threw it into my script.
The generated XML ended up too much of a challenge for Defender, and code execution was achieved, with the end result being a nice and shiny Cobalt Strike Beacon.
It is worth noting that care had to be taken when interacting with this session, and defender did detect any “noisy” activity, therefore, further tradecraft will have to be explored.
In future iterations I will refine how the shellcode is executed, in addition to sandbox evasion, and looking at obfuscating GetProcAddress and LoadLibrary through reflection.
