Living Off the Land
With Windows Binaries
PreviousIf You're Not Doing Continuous Asset Management You're Not Doing Security | Daniel MiesslerNextLiving Off The Land: Part 2
Last updated
Was this helpful?
With Windows Binaries
Last updated
Was this helpful?
Oct 20, 2018
Posted in
A naturally-aspirated approach focusing on the use of native built-in binaries to exploit and persist on target systems. Avoiding detection is a constant battle, so what’s the harm in using trusted built in tools?
Although some binaries have little documentation and take a bit of massaging to work with, there are plenty of benefits, from application white listing to remote file retrieval. First, I’d highly recommend to checkout a few sources first.
A recent release of the
Solid intro into this approach –
Talk on LOLBins with some great examples -
A great blog showcasing LOLBins –
This approach sparked my interested, so I decided to map out a lab scenario. The primary goal of this post is to show off the capabilities of LOLBins vs the practicality of the scenario. PowerShell can accomplish most of the scenario objectives, but I’ll avoid this route as it’s already heavily documented and seems to be more commonly targeted by defensive countermeasures.
These LOLBin examples will be focused on persistence at a beginner/intermediate level.
You’ve gained access to a public facing IIS server with Domain credentials ran by ACME. From here, you wish to pivot onto the ACME CEO’s machine CALVIN. For simplicity we’ll assume we have a secure RDP connection to the IIS server. Again, these examples are simply showcasing what you can accomplish by Living Off the Land.
You’re on a webserver owned by ACME and you start poking around and find a locally hosted file share - \SUPERSTITIONS\share. In this example we will avoid digging around in the share, opening any files we don’t have permissions to.
One alternative option would be to capture packets on the local share using Netsh. This built-in binary provides significant capabilities to interact with the network, including packet capture locally or on remote file shares.
I didn’t have any luck capturing activity on a remote share, so in this case we’ll start out capturing local packets, outputting to an ETL file.
We are capturing on the local IIS box, and outputting as an ETL file to C:\Users\Public\file2.etl. To end the packet capture, execute netsh trace stop
MS Message Analyzer has some nifty bells and whistles, including filter capabilities. Diving into the functionalities and filtering options is out of scope for this blog post, but after a quick superficial glance, SMB2 is observed as a Module being ran.
Diving deeper into these SMB traces, a new source IP is found along with a file named accounts.txt. It seems this file is being opened and written to. Using a simple string in the “Find Message” text box as Summary contains accounts.txt we can investigate each message, checking for the buffer value…
One message in particular seems to stand out…
Do you see anything juicy in this message? The contents of the text file is being read by the buffer, including precious credentials. In reality the \SUPERSTITIONS\share\accounts.txt file was opened remotely from CALVIN’s machine.
We’ve gained valid user credentials and have “stealthily” RDP’d onto CALVIN’s machine. If we wanted to avoid RDP another option could be to check if WinRM is enabled. If so we could attempt to execute PowerShell Remotely (or wmi, psexec, etc) by using PSSession or Invoke-Command
So we’re on CALVIN and we are connected via RDP - what are the next steps? Maybe pivot some more, exfil data and/or maintain persistence? We’ll start by maintaining persistence.
PowerShell blues
Certutil is a great little binary that can download remote files, create certificates, or encode files. Not only can this built-in exe encode a file to base64, it can also encode into hex. When encoding to b64, it includes the certificate header and footer, which one may find convincing.
When decoding with certutil, it will remove the header and footer, providing you with the original file. Now, to obfuscate we’ll encode the payload locally (on attacking machine) through certutil as base64. Then again through hex and once again through base64.
This should give us a nice bogus looking “certificate.” It’s also worth noting I attempted to use assoc.exe to allow .crt to execute as PowerShell without luck. Would be nice if PowerShell could execute the encoded “certificate” .crt file.
Now that the encoded PowerShell payload is set on our machine, we’ll need to move it over to CALVIN. It’s worth noting, CALVIN is running Windows 10 with the latest updates from Windows Defender.
Using certutil we can test the waters by remotely downloading a simple file on CALVIN from the attackers IP.
After executing, Windows Defender catches this as malicious activity. Trying a few other extensions also fail, of course.
Nothing out of the ordinary, hh.exe process starts and calls out to the remote IP. It’s possible ie.exe may raise more red flags than hh.exe, so we’ll go with hh.exe - this time pointing to our payload.txt file
It’s a pretty large “certificate”, but may not raise any flags unless it’s manually viewed by a sysadmin. Now we can open notepad, copy the text and save as something unsuspicious. As to avoid any permission issues we’ll save as
Now that the payload is obfuscated on the target machine, we’ll need to find a way to execute it. Run keys, etc are an option, but netsh comes to mind again. NetSh loads helper dll’s to help its functionality.
In order to convert the bogus .crt file, the process to decode & execute can be all within the dll or externally like a batch file, reg key, etc. This example will include an all-inclusive dll. Realistically, an attacker may simply add the payload within this dll as to avoid dropping an extra file, except this isn’t the point of the blog post.
In the scenario of a C-level employee working from home, an attacker could load the dll(payload) » Execute payload on VPN start-up » Save sensitive files locally » Create script to exfil via home network once payload (netsh/VPN) disconnects, avoiding any corporate detection methods.
The source code executes certutil to run the decode process and powershell to execute the payload in memory. There could be a few other ways of doing this, but my focus was to execute all in-memory. The %YAH% file does not exist, and doesn’t write to the directory - at least according to a once-over within Event Logs.
When executing netsh or adding the helper, a powershell prompts briefly. I’m sure someone with better knowledge of C++ and/or PowerShell could stop this.
Nothing was flagged when scanning with Windows Defender or Malewarebytes, nor was the execution of the payload via netsh flagged.
An attacker could avoid sending the reverse shell directly back to its controlled ip, and configure port redirection via netsh portproxy to sieve through the web server. This may avoid network defense countermeasures as it’s a public facing server with plenty of traffic going in and out.
An attacker could go another route and exfil data from CALVIN onto the share, then pull from the web server via GET/POST requests.
It’s a definite challenge detecting and mitigating LOL-type attacks. Besides having proper NIDS, HIPS, etc configured, there are a couple extra options I’ll go over.
One method to detect non-default netsh helpers would be to hash the netsh registry keys and compare them to a secure baseline. The helper dll’s are listed in the registry here: HKLM\Software\Microsoft\NetSh
This batch script will create helpers.txt listing all of the loaded helper dll’s, along with a hash value of the helpers.txt in hash.txt using reg query and certutil. PowerShell also has a FileHash cmdlet which is commented in the script below.
This is simply an example. You could create your corps valid hashes, set them as variables, then run the hash.txt against multiple conditionals based off the Windows OS version. eg: if Hash.txt contains %varValidWin10Hash% echo valid»results.csv
Drilling down into whitelisting native apps/binaries could be a headache within a larger Enterprise, but seems to be the way to go if implemented properly.
In the case of our scenario, do users at ACME absolutely need powershell, certutil, etc? In some cases these built-in apps are necessary, but are all of them? Sounds like another case of Least Privilege.
In order to locally Deny CertUtil by an AppLocker Whitelisting rule:
Run » gpedit.msc
Computer Configuration » Win. Settings » Sec. Setting » App. Control Pol. » AppLocker
Right-Click » Properties » Enable all rules collections
Right-Click » Executable Rules » Create Default Rules
Add Exception to “All files locate in the Windows folder” » Add Path to certutil.exe
Apply, restart and make sure Application Identity Service is running
Although, a dedicated attacker could hack around application whitelisting….of course by using LOL bins, so look at whitelisting as another layer in defense in depth.
I’m new to drilling down into ETL files, and found the simplest way to investigate is through tool. Another option is to use logman.exe, or convert the etl to pcap for wireshark. In our case we’ll open the .etl in MS Message Analyzer.
There are methods to go “fileless”, , stored as objects, etc but in this example I’ll stick to a basic powershell reverse shell one-liner.
It’s fairly common for attackers and attacking frameworks to encode payloads with base64 in order to obfuscate itself from intrusion detection. As many know, PowerShell can encode, decode or execute an encoded command. This vector has become much more prevalent and
Another option besides using a conventional web browser, is . Using this binary we can go to a quick test page on our attacking machine to see what it’s made of.
Great, looks like this may be an option, but what’s really the difference besides using Internet Explorer? Luckily the target machine had installed. We open TCPView and execute hh.exe, pointing to our attacking machine once again.
Wait, what if we wanted to use a custom .EXE for our payload using C#? You could use the same hh.exe process, copy to a .cs file and use the to compile into an EXE (or DLL).
A malicious user could create a bogus dll and load it into netsh, causing this dll to run every time netsh.exe was executed - I recently about this process and created a basic - which the below .cpp is based off of.
One reason an attacker may use netsh helpers to maintain persistence is due to the prevalence of users working remotely. . Even if a user is working on-site, some networks may only allow a VPN to access other network resources.
:
Go through this process with other simple built-in binaries that aren’t needed. Otherwise you could within AppLocker.
There are incredible opportunities within LOLBins, and it appears these . More ways to hack these binaries are still being released, so stay privy of these vectors and open to alternate defense strategies.
