Downloading & Execution
The ability to download and execute files on our target systems is, of course, a necessary process in our quest to maintain footholds and persistence within a target network.
Being able to do so with tools that are already built-in to the operating system (i.e., Living off the Land) is even more important as it helps evade endpoint security measures and application whitelisting solutions by using tools that are likely already “trusted.”
Additionally, being able to download and execute files with PowerShell is even more advantageous in many cases, since we’re able to operate entirely within the memory process of PowerShell, and can avoid dropping artifacts to disk in many cases.
There are two primary ways we can download and execute code in regards to strictly using PowerShell and built in .Net classes or COM objects:
A summary of methods we can use for “In-Memory” execution with PowerShell version 2.0: (preferred methods)
A summary of methods we can use for “Disk-Based” execution with PowerShell version 2.0
These two methods (in-memory and disk-based) are usually accomplished using what are commonly referred to as “Download Cradles,” and use the “System.Net.WebClient” .Net System Class among other classes, COM objects or other Windows-native executables to achieve this.
Most of the time, we use the “New-Object” cmdlet. The New-Object cmdlet, as its name infers, allows us to create instances (objects) of either .Net or COM objects. Let’s take a look at several examples.
The most common download cradle we’ll see in the field uses the “iex” (Invoke-Expression) alias along with the Net.WebClient class and the “DownloadString” method, which downloads and executes a remotely hosted powershell script, and can be done with a command like the following:
We can run the same command from a standard windows command prompt:
We can also break the above PowerShell commands down and execute them directly via the console with something like the following as well:
The “DownloadString” method will execute our remote script in the PowerShell process memory, so in regards to not dropping an artifact to disk, it’s a great way to stay under the radar of endpoint security solutions that are not monitoring powershell memory.
Important: Evasion Tips
It should be noted that where possible when hosting your remote PowerShell script, to have an SSL certificate configured on the attacker machine. This helps in evading over-the-wire heuristics as our traffic will go over HTTPS. In the previous examples, we simply used HTTP, which could easily be detected.
Another trick we can use which might help in evading basic file extension heuristics is to give our PowerShell script a different extension, for instance, “Logo.gif.” PowerShell will still execute it as a .ps1 script.
There are many other ways we can decrease our probability of being detected, and we will cover some of those ways in following slides.
It’s also important to note that the Net.WebClient class allows us to specify a custom user-agent string when sending the request to our attacker URL.
This can help us evade detection mechanisms that are flagging on abnormal user-agent strings crossing the wire.
We can do that with the “Headers.Add” method:
We can see our user-agent string was sent as part of the Net.WebClient GET request ( Wireshark ).
======================================================================
Another Net.WebClient class method we can use is the “DownloadFile” method. This method will download your executable to disk. Although noisy and not recommended if trying to remain stealthy, it’s still sometimes a handy method to quickly download a file to the target system.
Executing the file once it’s on our target system can be accomplished using the call operator (&) and variable we created for the payload ($local_file):
It should also be noted that the Net.WebClient class methods can be configured to use the systems’ proxy and default credentials with the following commands:
Aside from the Net.WebClient class, we can also use the Net.WebRequest class to download and execute scripts on a target, in memory.
Similar to the Net.WebClient class, the Net.WebRequest class can also be configured to use a proxy as follows:
The “System.Xml.XmlDocument” class allows us to execute a powershell command (or any system command) contained within an attacker hosted XML document and is another great way to execute powershell code in memory, and in a way that is likely not detected, especially when combined with a server over HTTPS.
What we’ll want to do is create an XML file with the following contents, which we’ll host on our attacker machine:
The above xml file will simply list the system processes when executed.
Next, once our xml file is hosted, we can use the System.Xml.XmlDocument class with the “Load” method to download, and execute it:
We can also use COM Objects to both download and execute scripts on a target system. Some of the COM objects available to us for this purpose are:
Take note that all of the above COM Objects are proxy-aware, and will by default, use system configured proxies, except for the “WinHttp.WinHttpRequest.5.1” object, although that object can be configured to use one if needed.
We can utilize the COM objects in the same way we do with the Net.WebClient objects, by using the “New-Object” cmdlet, but with the “-ComObject” parameter. In the below, we’re utilizing the “Msxml2.XMLHTTP” object for executing a remotely hosted PowerShell Script:
And we can do the same with the “WinHttp.WinHttpRequest.5.1” object as well:
Keep in mind, that all of the previous slides and future multi-line commands we’re showing as examples, can also be done as oneliners, by using a semicolon (;) to break up the commands:
With all of these examples, when executing the download cradles from a windows command prompt or shell, or when launching the powershell.exe executable, make sure to include the – ExecutionPolicy Bypass and –Window Hidden options we covered in the Fundamentals module. This will ensure we can run our scripts and that the powershell window stays hidden from the end-user.
A great tool we can use to help us craft obfuscated download cradles is known as “Invoke-CradleCrafter” by Daniel Bohannon. We encourage you to explore that tool, in addition to getting familiar with the manual methods we covered.
Last updated