Living-off-the-land (LOTL) is a sophisticated strategy adopted by cyber adversaries, emphasising the use of native resources found within the target environment to further their malicious objectives. This approach stands in contrast to more traditional methods where attackers would deploy and use external malicious tools or payloads. By opting for LOTL, attackers tap into the very utilities, scripts, and software that are inherently trusted and installed on the system for legitimate purposes.
A classic illustration of this tactic is the use of PowerShell, a powerful scripting and automation framework integrated into Windows. While PowerShell is designed to aid administrators in managing and automating tasks, its capabilities can be repurposed by attackers to run malicious scripts, often without triggering conventional security alerts. Similarly, Windows Management Instrumentation (WMI) is another built-in tool intended for administrative tasks like monitoring and managing Windows-based systems. However, in the hands of an adversary, WMI can be exploited to gather sensitive information about the system, its configurations, and its users.
A classic illustration of this tactic is the use of PowerShell, a powerful scripting and automation framework integrated into Windows. While PowerShell is designed to aid administrators in managing and automating tasks, its capabilities can be repurposed by attackers to run malicious scripts, often without triggering conventional security alerts. Similarly, Windows Management Instrumentation (WMI) is another built-in tool intended for administrative tasks like monitoring and managing Windows-based systems. However, in the hands of an adversary, WMI can be exploited to gather sensitive information about the system, its configurations, and its users.
The Microsoft Build Engine, commonly known as MSBuild, first made its debut in 2005 as a robust platform tailored for constructing applications. At its core, MSBuild harnesses the power of an XML schema, defining a project file structure that dictates the manner in which the build platform interprets and assembles software. This XML-based configuration provides developers with a granular level of control over the build process, allowing them to specify dependencies, order of operations, and other build-related parameters.
Originally, MSBuild was conceived as an integral component of the .NET Framework, serving as its default build system. However, with the evolution of the .NET ecosystem and the emergence of .NET Core, MSBuild's role has expanded. It has been seamlessly woven into the .NET Core Software Development Kit (SDK), reinforcing its position as the predominant build system for the platform.
While MSBuild is adept at processing standard project files with extensions like ".csproj" for C# or ".vbproj" for Visual Basic, its versatility doesn't end there. Developers have the liberty to craft custom tasks within XML files, offering a tailored build process that caters to specific project needs. This flexibility ensures that MSBuild can accommodate a wide array of build scenarios, from simple applications to complex enterprise solutions.
One of MSBuild's standout features is its adaptability to modern development practices, particularly Continuous Integration and Continuous Deployment (CI/CD). In today's fast-paced development landscape, automation is paramount. MSBuild seamlessly integrates with various CI/CD tools and platforms, facilitating automated builds and deployments of .NET applications. This integration ensures that code changes are continuously tested, built, and deployed to target environments, enhancing software quality and accelerating delivery.
Adversaries have found innovative ways to exploit the functionalities of MSBuild to further their malicious objectives. The primary appeal of MSBuild for attackers is its ability to process XML project files. By embedding malicious C# code within these ostensibly benign XML files, attackers can execute their code under the guise of a legitimate build process, often evading signature-based detection systems.
One of the most potent techniques involves fileless attacks. Instead of relying on traditional methods of writing malicious payloads to disk, which could be flagged by security solutions, attackers can use MSBuild to inject malicious shellcode directly into a system's memory. This approach leaves no persistent malicious file on the system, making detection and post-incident analysis significantly more challenging.
Pesky GPO blocked your PowerShell execution? Tried downloading the top "NoPowerShell" PowerShell execution tools? Why not build your own and run it with MSBuild? You'll still have to worry AMSI - but we have a blog post for that 'Bypassing AMSI to run Mimikatz'
Step 1. The skeleton xml file for MSBuild
Step 2. Fill in the C# code. This whole file was taken from the GitHub Repo (https://github.com/sparcflow/HackLikeALegend/ )- which is the repo that covers the brilliant book "Hack Like a Legend" by (https://twitter.com/sparcflow ). If you find this interesting, please go and buy a copy here (https://nostarch.com/how-hack-legend ) to support his work.
Step 3. Run the file with MsBuild. Make sure you are in the directory of the XML file.
Maybe you don't want PowerShell at all and would rather want to deploy an implant with features to make your post-exploitation life a little easier. With Meterpreter you can create a C# based implant and load it with MSBuild! You can do it with other frameworks too, but as the saying goes "Meterpreter is dead, long live Meterpreter!".
Step 1. Grab the skeleton XML file.
Step 2. Generate your Meterpreter Shellcode using the following command (for x64):
Step 3. Fill out your skeleton. There are many examples of process injection using C#. This fantastic blog shows you exactly how (https://www.ired.team/offensive-security/code-execution/using-msbuild-to-execute-shellcode-in-c ).
Step 4. Run it and PROFIT!
Author: G. Botha