Hacker Tools and
Techniques Lab Guide

June 2026

Lab Objectives

• This lab aims to demonstrate the tools and techniques used by attackers to exploit systems. As you progress through the lab, note the ease with which activities can be performed and the maturity of the tools we are using.
• The lab is not designed to make you a professional penetration tester.
• You will observe that there are several design flaws built into the lab, and we will discuss how these design flaws are addressed by the ASD's Strategies to Mitigate Cyber Security Incidents.

Course content

Terminal Command Notation

• Key Formatting Rules:
  • The Terminal Prompt: The lab guide's prompt will appear before the command you need to type. It may end with either a # or > and will be in a white font.
  • Your Input: The actual command you must type will be presented in a dark box with Bold + Red font.

Example

• Here is a typical example you will see in the guide:

Lab #1 – > sudo switch_mindset --force

• All lab work is done in your web browser such as Chrome, Edge, or Firefox.

• You will need to do the training on a non-corporate network (such as a home network), as the links to the labs may be blocked by a corporate network.
• You will need to do the training on a non-corporate laptop (such as a personal laptop), as the links to the labs may be blocked by a corporate configured/hardened device.
• For best results Do not Copy/Paste. When typing, double check for accuracy.
• You have been provided a unique lab address which will be similar to this https://lab##.privuser.com/guacamole/ but will have an individual lab number.
• Remember to include the trailing backslash:

• Click on the OK button and your Kali Linux Desktop will appear.
• You may also get a pop up from the browser asking to allow clipboard access. Click on the Allow button.
• You will then be in the Kali Linux Desktop environment and ready to commence the Lab session.

Discovery

This lab aims to demonstrate the tools and techniques used by attackers to exploit systems. As you progress through the lab, note the ease with which activities can be performed and the maturity of the tools we are using.

• To save time, we are picking up after a vulnerability scan has been run against the EVIL.CORP webserver, found at IP address 10.0.0.40
• You can locate a copy of this scan report from the course materials website:
• https://course.privuser.com/vuln_scan.pdf
• The scan identified many vulnerabilities (see page 4 of the vuln_scan.pdf report).

• This scan was performed with no firewall rules in place to provide insight into some of the things this type of activity can detect if run internally.
• This information can also be used to identify issues requiring remediation.
• The screenshots here show an example of a vulnerability identified by the Automated Vulnerability Scanner tool – Tenable Nessus.

Discovery (continued)

• Multiple vulnerabilities relating to Apache Tomcat RCE were identified by the Nessus scanner, but vulnerability scanners, like any tool, are imperfect.
• Using a different Vulnerability scanner (OpenVAS) reveals that the vulnerability relates to CGI Servlets, and that the vulnerability allows for 'remote code execution', granting the ability to run arbitrary programs when successfully exploited.

Step One: Metasploit Framework - Open a Terminal Window

This lab aims to demonstrate the tools and techniques used by attackers to exploit systems. As you progress through the lab, note the ease with which activities can be performed and the maturity of the tools we are using.

Once a vulnerability is identified, the next phase is to exploit it to gain access. We will use the Metasploit Framework (msfconsole), a powerful tool for developing and executing exploit code.

We need to open a terminal to start inputting commands.

Step Two: Launch Metasploit

Start the Metasploit console.

Step Three: Search for an exploit

Once Metasploit has started, we will see whether there is an existing exploit already packaged for our use.

You can search for pre-packaged tomcat components through the command search tomcat.

Step Four: Search for and use an exploit (continued)

Several pre-packaged exploits are returned but noting that the exploit identified by the OpenVAS tool was related to 'cgi servlets' we can try a more specific search. Let's try the command search tomcat cgi

Searching the more concise list we see an exploit for tomcat_cgi_cmdlineargs which fits the description of that identified in the OpenVAS vulnerability scan results.

To use an exploit simply type the command use followed by the name of the exploit, in this instance it is:

Note: the terminal now reflects we are using the exploit. In addition, note that the exploit payload has automatically been selected. The 'payload' is the program that is run when the exploit completes successfully. We will select a different payload later.

Step Five: Configure an exploit

Now we are inside the exploit we need to determine its attributes to configure it correctly for running in a successful manner. We first do this by running the options command.

Note: The Required column tells us what information is required to be configured (everything with a Yes, requires a setting to be configured against the target). To configure these options, we use the set command.

If we wanted to set the rhosts to target the identified vulnerable webserver we would enter the command as follows.

Step Five: Configure an exploit (continued)

The vulnerability scan told us that the vulnerable webserver is running on port 8080 so there is no need to reconfigure that option as it is already set to 8080.

The scan results did not explicitly provide the path to the vulnerable script. However, through manual analysis (or an upcoming process to be explained), the vulnerable path has been identified as:

• /cgi/test.bat

This script is associated with the web page titled "Charges to dead customers". For now, use this identified path to configure the exploit module:

Step Five (a): Verification Step

To confirm its existence and basic functionality, you can manually test the script in a browser by opening the Firefox browser in Kali and navigating to the following URL:

(A quick explanation of how /cgi/test.bat was discovered in the first place will follow later.)

Step Six: Metasploit – Using an Exploit

We also need to change the payload, as by default Metasploit is a 32-bit application, but we need to configure the payload to reflect the architecture of our Target server. To do that, we need to run the following command:

Now if you re-run the options command, your complete configuration should list entries under the Current Setting column for:

• RHOSTS – 10.0.0.40
• RPORT - 8080
• TARGETURI - /cgi/test.bat

Your Payload options should also show that the x64 variant has been set.

Step Seven: Metasploit – Running the Exploit

We are now ready to run the exploit against the vulnerable webserver. This is performed by entering the command exploit:

Meterpreter Session: The Interactive Shell

Upon successful exploitation, you'll enter a Meterpreter session, indicated by the meterpreter > prompt.

This session acts as an interactive shell with the compromised host, like an SSH session and you can now issue commands directly to the target system.

Just as you can have multiple concurrent SSH sessions to different servers, you can also manage multiple Meterpreter sessions from Metasploit.

To effectively work with the compromised host and utilize advanced features (like privilege escalation or persistence), you often need to interact with the session from outside the interactive shell—that is, from the main Metasploit console (msf>).

Think of this as setting up or configuring an SSH tunnel before entering the session. This external interaction allows you to specify options, run post-exploitation modules, and manage the session's overall behaviour

Step Eight: Working with a Compromised Host

We can now start to interact with the compromised session.

Typing the command sysinfo from a meterpreter session reveals some information relating to our compromised system.

The command getuid can be used to show the compromised user context

Note that the getuid command informs us that we are connected as the local system account (NT AUTHORITY\SYSTEM).

With this privilege we can issue the meterpreter command hashdump to dump hashes stored in the local Security Account Manager database.

We recommend storing the hashes captured above in a notepad application, as we will use the Administrator hash to further network propagation shortly.

Step Nine: Network Propagation

Reconnaissance - the compromised host within the evil.corp network can be used to discover information about the internal network.

One of the options within a meterpreter session is to run a native shell on the compromised host. We do this via the shell command.

This will open a shell on our target to run commands as though we were on the webserver desktop.

We then run the command ipconfig /all and can identify that there is a second network interface card showing an internal network is 10.0.1.0/24. We also see the Fully Qualified Domain Name (FQDN) of evil.corp.

Exit from the shell interface by typing the command exit

This will put you back at the meterpreter > prompt. From here you want to issue the background command to put this session to sleep.

Now it is time to set up routing to the compromised network to further our incursion into the environment.

Step Nine: Network Propagation (continued)

To move laterally within the internal network, we want to set up rules which forward our traffic through to the compromised host network. We can do this via the autoroute command. We select to use autoroute and configure the required options.

Note we need to specify the session we are going to route the traffic through. It would be little use to forward traffic through the wrong session as it would not reach the desired network. In our case we want to route the traffic through session 1.

Note the required routes have been automatically created for us. We can run the command route to confirm the routes have been created.

Step Nine: Network Propagation (continued)

Initiating the Internal Network ARP Scan

From the compromised webserver, we'll use the native Address Resolution Protocol (ARP) scanner to map the internal network. Be aware that this scan can take up to two minutes.

Referencing the provided network diagram, you're free to cancel the scan (CTRL + C) as soon as you discover a sufficient number of target hosts.

There are a range of other scans we can run to find other information. The command set session 1 was run as an example to provide insight into how we might gather more information about the environment. This usually takes a very long time to complete and is optional, but the information acquired from the ARP scanner above can reduce the scan time by focusing only on systems we are aware of.

At the end of the scan process we will have identified five (5) IP addresses that may be useful to us:

• IP: 10.0.1.1 MAC 0a:1a:ed:ac:8c:47
• IP: 10.0.1.20 MAC 0a:cd:02:e9:05:47
• IP: 10.0.1.30 MAC 0a:d8:4c:3c:72:97
• IP: 10.0.1.40 MAC 0a:c0:1a:1b:97:df
• IP: 10.0.1.255 MAC 0a:c0:1a:1b:97:df

We already know that 10.0.1.40 is the webserver, so we can skip that. 10.0.1.1, and 10.0.1.255 are likely to be network devices, so we can skip those also.

However, 10.0.1.20 and 10.0.1.30 are in the same logical part of the range as the webserver and may be related to it.

Step Nine: Network Propagation (continued)

Following the initial network discovery, we'll now focus on determining the services running on the newly identified hosts, 10.0.1.20 and 10.0.1.30.

A crucial first step in any internal penetration test is locating systems running Server Message Block (SMB), as misconfigurations in this protocol often lead to significant vulnerabilities.

To do this efficiently, we will leverage the Metasploit Framework's auxiliary modules, specifically an SMB scanner like (auxiliary/scanner/smb/smb_version).

This targeted scan will check both hosts for active SMB services and attempt to fingerprint the operating system and version, providing us with the critical information needed to plan our next steps: credential brute-forcing, exploiting unpatched vulnerabilities, or attempting NULL session access.

Now that we have enumerated our internal network and have a basis, let's utilise the other information we have to make our attack happen.

Step Ten: Pass the Hash – Workstation Access

Recall earlier we recovered hashes from the local SAM database on the webserver. If the same credentials are used elsewhere in the network, we will be able to pass the hash to gain access.

A real-world scenario of this is the local admin account on PCs within an enterprise environment. We will use a tool called psexec to pass the hash. We will target the accessible workstation on the network and see whether the same local account is in use. We will use the administrator account.

Note that when we are successful in passing the hash our meterpreter session will need to be tunnelled from our hacker workstation, through the compromised web server to the newly compromised workstation. Our hacker machine address is not routable from the perspective of the workstation, so we need to set up some sort of reverse port forwarder. Sounds hard! Fortunately, it's already built into Metasploit. So, all we need to do is set the lhost to the compromised webserver and the magic will just happen.

Check our options command to make sure we have everything checked. Note – ensure that lhost is set to 10.0.1.40 and that unlike rhosts, there is no plural on lhost (because we can have multiple targets, but only one listening host.

Step Ten: Pass the Hash – Workstation Access (continued)

Let's begin our attack.

We should now have a meterpreter shell again on the WKSTN-01 host. Let's confirm by running the sysinfo command again.

Hopefully, we still have the high privilege level from before, let's run the getuid command to check.

Stealing Credentials for Pass-the-Hash with Mimikatz

Now that we have command-line access to the compromised workstation (10.0.1.30, WKSTN-01), our objective is to extract cached credentials from the system's memory to facilitate a Pass-the-Hash (PtH) attack against the domain controller. We'll achieve this by loading the Kiwi module, which integrates the powerful Mimikatz tool directly into our Meterpreter session. First, load the tool using the command load kiwi.

Once loaded, you can check the available options by running the command help kiwi.

This will allow us to execute Mimikatz commands like the creds_msv command to retrieve the stored LM/NTLM hashes.

These stolen hashes are the key to escalating our privileges and gaining access to other systems, including the domain controller (WIN-DC-01), without ever needing to crack the passwords.

Step Eleven: Pass the Hash – using Mimikatz

Note that because a domain administrator is logged onto the host, we can recover a domain administrator hash and use this to authenticate to the domain controller.

With the domain administrator hash we can now access the domain controller. We will again use psexec. One important thing to note is that if only the NTLM hash is available, we need to provide a place holder for the LM hash component (so we pad with 32 zeroes before the NTLM hash).

We begin by once again placing our meterpreter session in the background.

Now we're back at the Metasploit prompt, readying our fortitude to attack the DC. So, let's start configuring our system:

Check our options command to make sure we have everything checked. Note – ensure that lhost is set to 10.0.1.40 and that all 32 zeroes and the hash have been input correctly.

Now we exploit

Step Twelve: Domain Dominance – Golden Ticket

We should now have a meterpreter shell and be on the Domain Controller (WIN-DC-01).

Again, check to make sure our privilege level is still high.

Creating the Golden Ticket

To create the Golden Ticket on the Domain Controller, you need to use the kiwi Meterpreter module, which integrates Mimikatz functionalities.

Load the kiwi module: Since this is a new Meterpreter session, the module must be loaded first.

Execute the Golden Ticket command:

Once the module is loaded, you can run the command to create the Golden Ticket golden_ticket_create.

Golden Ticket Creation Parameters

To generate the Golden Ticket, we require the following parameters:

We know from earlier in the lesson running the ipconfig /all command gave us the FQDN of evil.corp

Now, the Domain SID is acquired via a shell command executed through the existing Meterpreter session on the Domain Controller WIN-DC-01.

Step Thirteen: Domain Dominance – Golden Ticket (continued)

Enter shell: meterpreter > shell

We will now be at the CMD terminal on the DC host.

Execute WMIC command to retrieve user SIDs: C:\Windows\system32> wmic useraccount get name, sid

The numbers following the final hyphen ('-') in a Security Identifier (SID) represent the Relative Identifier (RID), which is the unique user ID within a domain. For example, the built-in account KRBTGT typically has a RID of 502.

The common prefix for all SIDs within this environment is the domain SID: S-1-5-21-60724019-3617488015-2841620851.

We will now have a list of all SIDs, let's copy and use the KRBTGT account one.

Close the interactive Windows command shell to return to the Meterpreter prompt:

Execute the hashdump command via the Meterpreter session on the domain controller to extract and display password hashes from the Security Account Manager (SAM) database

Step Thirteen: Domain Dominance – Golden Ticket (continued)

Here are the stored hashes off the DC.

Unlike previous use, we are only going to use the NTLM hash of the KRBTGT account, and you will notice that the -k flag requires the use of the windows backslash \. The reason for the backslash is that is the standard Windows convention for separating a Domain Name from a User Account Name. Mimikatz commands often require this format to specify which domain the credential or hash belongs to.

In the context of the KRBTGT hash, while you usually use the /domain:<Domain_Name> switch for Golden Tickets, other Mimikatz commands or underlying Windows API calls require the DOMAIN\USER structure to correctly identify the context of the credential.

So, let's put it all together and see if can create our golden ticket:

Upon successful completion in our home folder should be a file called "goldenticket.txt".

We will see later in this course how to restore this session as part of a spear phishing attack.

Addendum to Lab 1

So, if you have finished early, and just want a little additional work to do, let's walk through the automated way to find scripts and other resources of interest on a website.

• Using a proxy tool, /cgi/test.bat can be discovered by an automated discovery process, so let's take a detour and hunt for the CGI Script.
• Our detour requires us to use a proxy tool called ZAP.
• In our hacker machine, click on the dragon symbol (which is our effective START) button, then move your mouse to 03 – Web Application Analysis.
• When the submenu opens, hover over the ZAP tool icon and select it. The ZAP application will start to load.
• We don't want to persist our session, so ensure No is selected and then click on the Start button.
• Close the Manage Add-Ons screen that pop-up 30 seconds after ZAP starts.
• By default, there are no Sites in the ZAP proxy so we need to open and configure our web browser first.
• Open Firefox and navigate to http://10.0.0.40:8080 — the proxy is now pre-configured by the script below.

• We will receive a warning about an untrusted certificate, for now it is ok to click on Advanced – then click on "Accept the Risk and Continue"
• In the ZAP tool you will now notice that the Sites list knows about the http://10.0.0.40:8080 location.

Addendum to Lab 1 (continued)

So, if you have finished early, and just want a little additional work to do, let's walk through the automated way to find scripts and other resources of interest on a website.

• We right click on the http://10.0.0.40:8080 location, select Attack, then Spider
• Click on the Start Scan button to continue
• Our site is now scanned automatically for links, and we can see that a cgi folder is discovered
• Inside the cgi folder, is the /cgi/test.bat needed for the TARGETURI requirement.
• Right click on the GET:test.bat(dir) and select the submenu item Open URL in System Browser
• This addendum exercise is now complete

Lab #2 – Log File Analysis

Lab 2 - Post-Exploitation & Log Analysis

After gaining access, an attacker will try to understand the system and cover their tracks. As defenders, we can analyse system logs to uncover their activity. The grep command is essential for searching through log files for specific keywords.

• Time to Complete: 10 Minutes
• Log into your hacker machine from earlier.
• On the Kali Desktop is a folder called Home, double click to open it.
• Locate the folder inside the Home folder called Logs Lab 1, right click on it and select the 'Open Terminal Here' option.

Key Investigation Questions

We need to answer these questions by analysing the logs:

• How was our system compromised?
• Was there one attacker or multiples?
• What did they do once they were on the system?

Technique 1: Find Failed Password Attempts

Search all files in the current directory for lines containing "failed password for" to identify failed account logins.

Technique 2: Find Accepted Password Attempts

Search all files in the current directory for lines containing "accepted password for root" to identify successful root logins.

Lab #2 - Post-Exploitation & Log Analysis (continued)

Technique 3: Look for New Users

Search for evidence of new user creation, which could indicate an attacker creating a persistent backdoor account.

• UID 0: Reserved for the root user, also known as the superuser or administrator.
• UIDs 1 to 999: Reserved for system users and processes.
• UIDs 1000 and above: Typically assigned to regular user accounts.

Technique 4: Check for Installed Packages

Check for newly installed packages. Comparing this against a system baseline and system build documents (such as the System Security Plan) would certainly help here, but even without one, suspicious packages can be identified.

Technique 5: Inspect Firewall Rules

Look for changes to iptables (the system firewall). Attackers may modify firewall rules to allow their traffic in or out.

We should now be able to successfully answer the initial questions asked and determine what has happened in our environment.