Over the past year, we have seen a lot of research come out which highlights several of Microsoft’s native binaries which can be leveraged by an attacker to compromise or gain access to a system. One of these binaries, msbuild.exe, has proven very reliable in allowing us to gain a shell on a host in a post-exploitation scenario.
Casey Smith (@subtee) wrote several articles on how a person can execute code from a .csproj, or .xml, file using msbuild.exe. Casey identified that there are a couple of sections which allows someone to add whatever code they want and when msbuild.exe analyzes the file, it will execute those code blocks. This allows a person to add any C# code to the csproj or xml file.
Two TrustedSec team members, Larry Spohn (@spoonman1091) and Ben Mauch (@ben0xa), decided to take Ben’s Not PowerShell (nps) and Dave Kennedy’s unicorn and mash some of the functionality together with Casey’s sample and they came up with a new tool called nps_payload.
This second way is to host the msbuild_nps.xml file on a SMB share and use UNC path with the msbuild.exe command to point to the xml file.
This will run the encoded PowerShell payload using nps and will return a shell to the attacker. Once the attacker migrates to a new process, msbuild.exe will exit. It is important to note that nps executes the PowerShell code without invoking powershell.exe and will not show up in Event ID 4688 (New Process Created).
For Defenders, you can detect this attack by monitoring Event ID 4688 events for any invocation of msbuild.exe and then to check the command line arguments for any reference to UNC or local files. You can also enable PowerShell logging and monitor Event ID 4104 Events and look for any PowerShell code which is encoded.
You can download nps_payload on TrustedSec’s GitHub at https://www.github.com/trustedsec/nps_payload