CompTIA PenTest+ Certification: Basics of Information Gathering and Vulnerability Scanning

Topics:
Passive Reconnaissance
DNS Recon
OSINT
Search Engines
Active Reconnaissance
Host Enumeration
Service Identification and Fingerprinting
Web Content Enumeration
User Enumeration
Defense Detection and Detection Avoidance
Vulnerability Scanning and Analysis
Credentialed vs. Noncredentialed Scanning
Compliance and Configuration Auditing
Vulnerability Research Sources

- The difference between passive and active reconnaissance and vulnerability scanning, including the types of information to target
- Several tools used for information gathering and vulnerability scanning and analyze their output
- When to use passive reconnaissance, active reconnaissance, or vulnerability scanning during a pentest
- Identifying and analyzing use cases for Nmap

Collecting as much information as you can about the targets is referred to as reconnaissance (recon), or discovery. Pentesters do this during planning, initial access, and post-exploitation phases of pentesting. Recon identifies or confirms the target scope, finds potential weaknesses or vulnerabilities for exploitation, and locates other information related to the goals of the pentest.

Depending on the type of assessment, a good portion of scoping information may be already provided, such as IP addresses, e-mail addresses, domain names, etc. However, confirming the ownership of an IP range or application, for example, can be a good idea. You might also identify open services or versions of systems on your targets in order to identify exploitable vulnerabilities. You could look for various web URLs on a web server in order to find login forms or management interfaces that warrant closer examination. Your objective is to find information that helps you further your pentest goals. Filling knowledge gaps and establishing an understanding of what targets are available will help you manage your time more effectively and formulate a working plan of attack.

Here are some other examples of information you might target, which we will discuss in this guide: web sites (such as login forms or exposed management interfaces), user accounts and e-mail addresses, certificate data, what systems are online within a network range, business partner relationships, open services, OS and software versions, hosting providers and domain name service information, internal document templates, organizational information (such as job roles, policies, terminology, or technology in use), and even the kinds of defenses to expect. During post-exploitation, the information you collect may extend deeper into group, share, and token enumeration.

All of these activities can generally be broken into three categories of attack: passive reconnaissance, active reconnaissance, and vulnerability scanning.

For the CompTIA Pentest+ exam, you should have a firm understanding of the difference between each of these, when to use them, what tools will aid you with each task, and how to recognize and analyze the results from certain tools.

Passive Reconnaissance
Let’s say you need to hire someone to fix something in your house. But you don’t want to give them money or let them into your house before you find out more about them. Does the person or business have a criminal record? Do they even do good work? You might decide to ask your friends who have done business with this individual in the past or research them with a business bureau. You could look up their reviews in social media services. You may decide to ask for a criminal background check—all without engaging with the potential contractor directly.
In pentesting, this is passive information gathering. It is the process of assessing a target to collect preliminary knowledge about the system, software, network, and people without actively engaging a target or its assets. This form of information gathering is the least invasive, and it is the least likely to be detected by the target. It is appropriate to use these methods to verify scope and aid with planning a pentest, as well as initial discovery during your pentest. Both paid and public sources of information (open-source intelligence) can be used according to your budget and resources. Use passive information gathering when you cannot risk disruption or detection during the current phase of your pentest.

DNS Recon
Among other use cases, you can use DNS recon to expand your knowledge of hostnames in use, the breadth of the network, and even information about some technical contacts within the organization. DNS recon can be passive or active, depending on whether you are accessing your target’s systems directly (active) or not. Most testers assume that the volume of requests to DNS servers means that targets are not observing queries to DNS services, but that is not always the case. Secondary sources, such as name registrars, Internet registries, specialized search engines, or other web-based resources, allow purely passive information gathering in this area.
Let’s start by talking about IP ranges.

There are five regional Internet registries (RIRs) that handle allocation of IP addresses across the Internet: APNIC (for Asia), ARIN (for America), RIPE NCC (for Europe), LACNIC (for Latin America), and AFRINIC (for Africa). The idea is to prevent two parties from being assigned the same range of addresses for use. These registries contain information about what organization owns a particular range of IP addresses and sometimes information about technical and administrative contacts.

As you can see below, you can search for a point of contact (POC), network or ASN, or organization or customer name.


Figure:   ARIN advanced search (https://whois.arin.net/ui/advanced.jsp)

This information is tied to domain name registration entries as well via the WHOIS service. Assume we search for CompTIA by selecting POC and checking Domain to search based on domain registration records, and enter comptia.org to look up the domain. This returns names for people who are responsible for the domain according to the RIR. For each name returned, you can click to get more details, including mailing addresses, e-mail addresses, phone numbers, and even related organizations. You could then use this to search social media or other open-source information for social engineering. If we click Related Organizations, we are seeing a list of organizations for abuse, tech, and admin purposes. Click on the link to the right of the organization name, and you will see a link for “See Also Related Networks,” as in Figure below. This is a list of IP addresses that the organization owns.


Figure:   ARIN organization related networks

You could validate ownership of an IP in your scope list by searching ARIN for the specific IP address as well. Enter the IP address in the search dialog at the top right of the page, and you will get the network range to which that IP belongs, as well as the ownership records. This can be useful in identifying cloud and third-party hosted assets. We’ll circle back to this in a moment.
There are other ways to access information from DNS, such as using dig or the whois command-line tools to investigate domain name ownership. The whois command, available in most distributions of Linux, allows you to retrieve information about a system using the domain name.

Figure below is an example command output using the whois command to query example.com.


Figure: WHOIS
The output can provide useful information that can help identify domain creation date, when it was last updated, associate a company and business location for the domain, DNSSEC information, and in some cases, contact information of the registrar. When you see multiple IP addresses returned for a single hostname, as with the nslookup command in the figure, that may be an indicator that load balancing is in use. This is a common configuration in high-traffic environments. 

Using a tool like nslookup to resolve the name of the domain to an IP address is called a forward DNS lookup. A reverse DNS lookup is the opposite—this process resolves the IP address to the domain name.


Figure:   nslookup

Now, back to our cloud asset discovery. Assume you have identified a bunch of servers belonging to a company. You use nslookup to find their IP addresses. Then you look up the IP addresses in the RIR and find that those IP ranges do not belong to the company in question. Instead, those IP addresses are in a netblock belonging to Microsoft or Amazon, or some other hosting provider. Your approach to pentesting those assets may differ based on where these are hosted.

Cloud providers will often publish their cloud hosted ranges, such as https://www.microsoft.com/en-us/download/details.aspx?id=56519 for Azure or https://ip-ranges.amazonaws.com/ip-ranges.json for AWS, and the RIR will reveal other information about the ownership of an IP range that may be useful during your research.

You can also use MX records from DNS to identify cloud services in use. Using nslookup, you can set the record type to MX to identify the mail server. Look for entries like google.com, googlemail.com, outlook.com, or others to indicate cloud-based e-mail. Here’s an example with dig using a google name server to get information about comptia.org:



Tip: It’s useful to know the different types of DNS records and what information they contain, as you may be asked about specific record types.

Pay special attention to NS, TXT, CNAME, and A records. Rather than reproduce them all here, you can read more at https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4.

Recon-ng
If you want a framework to help with this kind of search, Recon-ng is a powerful recon framework. It’s written in Python, and its interface will be familiar if you have ever used Metasploit. It includes independent modules, a database for storing engagement information, and much more. You can supply a domain and have Recon-ng identify IP addresses and hostnames on the domain and search for e-mail addresses, contacts, and leaks related to the domain using OSINT resources. Recon-ng is open source and included in the installation of Kali.

Launch a terminal window from Kali and follow the steps here to get started with using Recon-ng:
1.   The tool is executed from the command line by typing recon-ng. To get a list of commands, execute help from the framework prompt.
2.   By default, no modules are installed with Recon-ng in Kali. To install them, you may need to type marketplace install all at the Recon-ng prompt. After you have done this, the startup screen shows the total number of modules that are supported for each category. The

Recon-ng module categories are:
- Recon modules  Reconnaissance modules.
- Disabled modules Modules that are disabled based on your system configuration. If you have none that are disabled, this may not show up.
- Reporting modules  Compile a report in various formats.
- Import modules  Import target listing using supported formats.
- Exploitation modules  Supported exploitation modules.
- Discovery modules  Informational discovery modules.
 

3.   To get a list of supported modules, execute modules search from the framework prompt with no arguments.
4.   The first thing to do is create a workspace to manage information collection. The workspace and information gathered during module execution will be stored in the database.


 

5.   To see a list of workspaces in the database, execute:



Tip: Black Hills Information Security hosts a Recon-ng cheat sheet with numerous useful commands: https://www.blackhillsinfosec.com/wp-content/uploads/2019/11/recon-ng-5.x-cheat-sheet-Sheet1-1.pdf
 

6.   To run a simple WHOIS query and pull contact information for a domain, load the whois_pocs module:
[recon-ng][example] > modules load whois_pocs
7.   Once the module is loaded, you can see more information about the module, including configurable parameters, by typing info. You can also show the current context variables by typing options while the module is loaded. This also lets you set values. In this case, set your search target:
[recon-ng][example][whois_pocs] > options set SOURCE comptia.org
8.   Of course, you’ll want to set a real target. We’re only using this as an example. When you execute the module using the run command, the discovery process could take a few minutes, as Internet speeds vary. But the figure below shows an example of what you might see when it runs.


Figure:   Recon-ng module execution
 

9.   Once the collection process has completed, the show command can be used to display the results stored in select tables within the database. For a list of all tables, type show with no arguments.
10.   The whois_pocs module populates the Contacts table. To get a list of contacts that have been collected, execute show contacts.
11.   The Recon-ng dashboard (Figure below) shows the total number of records stored in each table of the database. To display the dashboard, execute the dashboard command. These metrics provide valuable information about the target environment and the organization’s exposure to the public Internet.


Figure:   Recon-ng dashboard
 

CAUTION: ome Recon-ng modules require API keys. Follow the instructions under “Acquiring API Keys” on the usage guide of the developer’s website at https://github.com/lanmaster53/recon-ng.

theHarvester
Another tool for DNS recon is theHarvester. You can also use it to gather information from various web pages (such as search engines) in order to discover domains, subdomains, and e-mail addresses. The latest version of the tool can be found on the developer’s GitHub page at https://github.com/laramies/theHarvester, and it is included in Kali Linux. The Python-based framework is simple to use and includes options to allow either passive or active queries to gather target information. Passive sources include various search engines and social media accounts such as Google, Yahoo!, or Bing.

Table below provides syntax options for theHarvester.


Table:   theHarvester Switches

Figure above shows the results of a passive search against comptia.org using the Google search engine. You can see theHarvester returns multiple e-mail addresses and hosts associated with the domain. These results may not be totally accurate, so you should verify them. During an engagement, it is important to analyze this information carefully and in some cases vet the information with the customer prior to executing further testing.


Figure:  theHarvester -d comptia.org -b google
 

CAUTION: There are a few modules that require API keys to work, such as googleCSE, shodan, and bingapi. You will need to register for a key through the vendor’s website. The API key needs to be added to the appropriate discovery script in theHarvester before you can use it. Refer to theHarvester GitHub page for more information.

OSINT
There are many public and paid resources on the Internet that can be used to passively gather information. These sources may also contain information about the company, including document templates, employee lists, and other technology information. Through data mining, you can analyze large data sets to reveal patterns or hidden anomalies. An open-source framework that pentesters can use to aid in the data mining process is called the OSINT Framework (http://osintframework.com), shown in Figure below.


Figure: OSINT Framework

The OSINT Framework is a static web page focused on information gathering and provides web links and resources that can be used during the reconnaissance process. The website is broken out into various nodes that offer unique paths for collecting information regarding a specific subject, such as usernames, e-mail addresses, social networks, IP addresses, etc. The OSINT Framework helps point users in the right direction to find useful intelligence from various public and paid resources.

Social Media
Social media allows us to publish our names, our e-mail addresses, our resumes for job hunting, our preferences and hobbies, and undertake numerous other electronic interactions. For pentests, this information is often valuable for targeting individuals for phishing or other social engineering efforts, but we can also use it to find out more about the organization itself. Look through technology job postings to identify the company’s technology stack based on what skills are required and what jobs are posted.

You may find the internally used names for departments (e.g., Human Resources vs. People Operations) to add credibility to your pretexts.

Other items of interest include names of managers, people in key positions, and how the organization works based on details in a job posting. Scraping LinkedIn for employee names and job titles can help you build targeting lists and a web of trust that you can attack. Some of these services require you to register an account in order to access useful information, and some of these will report your activities to your target (“Stranger Danger browsed your profile!”). So, be careful about your approach when indulging in passive information gathering. Remember, passive information gathering means no direct target interaction.

Working with Maltego CE
An interactive data mining software tool that can help users visualize and analyze relationships using publicly accessible data from the Internet is called Maltego. It is a framework that can rapidly expand the open-source knowledge of a target during a pentest. Before we begin, there are a few important concepts to understand about Maltego. Maltego uses different views to display data, such as a list view (table of entities) and a graph (background) to plot entities (node) during an online investigation. Entities are icons that represent a name in Domain Name System (DNS), website, file, IP address, etc. An entity is discovered through the use of a transform, which is a piece of code that queries a data source (i.e., search engines, social networks, DNS servers, etc.) to identify relationships with publicly searchable data and returns the results as new entities that are plotted on the graph. A machine can chain multiple transforms together in order to automate tasking.

Note:  The version of Maltego we refer to in this guide is Maltego CE, the community edition. More information about the versions of Maltego that are available is on the company website: https://www.paterva.com. The steps provided in this guide are a quick introduction to get you started with Maltego CE. Paterva provides an official user guide for Maltego, video tutorials, and other useful documentation on their website at https://docs.maltego.com/support/home.
Before using Maltego, you will need to create an account and register for a Maltego license. A free community edition account should be sufficient to follow along with this guide. Be aware that other online resources may reference transforms or functionality that is only available with payment.
Setup of Maltego is fairly straightforward. If you launch Maltego from the Kali main menu, you will see the splash screen appear as the application is loading. Then the Welcome to Maltego setup wizard, shown in Figure 2-9, will guide you through the process of setting up Maltego for first use. When you click Next to continue with the wizard, you will be prompted to enter your Community Edition account (Figure 2-10) and solve a captcha. Once you have done this, you should be able to click Next and follow the rest of the steps to complete the setup wizard.


Figure:   Welcome to Maltego


Figure: Maltego login screen

Inside the interface, as shown in the Figure, the Home tab provides access to the Transform Hub tab, which displays common transforms that are available in Maltego. To install, hover your mouse over the top of an item and click Install. You can do a lot with Maltego, including gathering information about target organizations and their websites based on network addresses or ranges, domain names, or even the names of people who work there.


Figure: Maltego Transform Hub

Many blogs cover ways to use Maltego for finding e-mails and social media accounts based on a name or a domain name (https://www.maltego.com/blog/beginners-guide-examining-your-digital-profile/, for example, or https://www.maltego.com/blog/how-to-conduct-person-of-interest-investigations-using-osint-and-maltego/). You can even use information from these exercises along with the Haveibeenpwned transform (https://www.maltego.com/transform-hub/haveiben-pwned/) to search for data dumps and leaks of passwords involving the users you find in order to build dictionaries for your password spray attempts.

We simply do not have the space to cover every possible use case here. In the interest of exposing you to some of the possibilities for passive recon using Maltego, though, let’s explore how to gather information about a network.
 

TIP: When working inside of Maltego, the keyboard shortcut to create a new graph is CTRL-T.
In this exercise, we want to footprint a domain. There are three different footprint levels to choose from, ranging from L1 (basic), L2 (mid), L3 (intense), and XXL (large targets). Each level takes into consideration time, which transforms are executed, and the amount of information collected. The higher the level, the more data you will ultimately accumulate. You may want to start with a level 1 search, then work your way up the ladder, depending on the size and maturity level of the organization.
 

CAUTION: The L3 footprint can take a while to execute and can consume a great deal of resources. Careful consideration should be made before using this machine.
1.   To start mining some data, click the Maltego icon in the top left, and select New to start a new graph.
2.   You can then click on Machines in the top menu to get the Machines toolbar to appear. Select Run Machine to choose an existing machine (Figure).


Figure:   Start a Machine page
 

3.   For this exercise, choose Footprint L2 and select Next.
4.   The Footprint L2 machine requires additional inputs. Enter in a domain name to use for the online investigation and then click Finish. Once the initial collection is complete, you should see some entities displayed on the graph (Figure).


Figure:   Completed investigation

The Entity Palette describes each type of graphical icon and what it represents. Maltego allows you to toggle between layouts (how entities are represented) or if you want to list entities in the list view or graph view. An important aspect from the data collection when using the graph view is the lines drawn from one entity to the next. This illustrates entity relationships. When you hover the mouse over the top of an entity, you will see the relationship definition and information sources listed in the Detailed View window. You can use this information to draw conclusions about the network configuration, such as subdomain information, IP address assignments, etc. When you right-click on an entity on the graph, you can configure and run any number of applicable transforms to extend the search criteria and build upon established relationships (Figure below).


Figure:   Run transform

Maltego allows the user to visualize hidden relationships and define attack paths that fall in line with the scope of the engagement by showing clustering of entities. The ability to visualize opportunities and integrate other data mining capabilities into the framework, like special search engines (i.e., Shodan and Censys), make Maltego a one-stop shop for conducting reconnaissance.

Another interesting way of conducting open-source intelligence gathering is through metadata analysis. This type of analysis can be conducted by searching through documents hosted on websites for hidden information. Files created in Office products store hidden properties within the file that may contain sensitive information, such as the author name (username), e-mail address, etc. If you open up a Microsoft Word document, then click Info (or the File tab, depending on the version of Word you are using), you will see the property information stored for the document, similar to Figure below. Fingerprinting Organizations with Collected Archives, or FOCA for short, is a Microsoft Windows–based tool used to automate this discovery process.

The latest version of FOCA can be downloaded from the developer’s GitHub page at https://github.com/ElevenPaths/FOCA. FOCA uses the Google, Bing, and DuckDuckGo search engines to find and analyze common document types, such as Microsoft Office, Open Office, and Adobe PDF.


Figure:   Hidden properties

Search Engines
Search engines are another place to seek OSINT about your targets. Web indexes like Google and Bing are well known, but there are also custom search engines built by organizations that scan the Internet and gather data about systems outside of web content, too. Source code repositories like GitHub also have search functions! So, we’re going to explore some of those here and talk about what role these take in passive information gathering.
Dorks are queries that you can use to find data about your target. Some search engines, such as Google, allow advanced query parameters to find information that a normal query might bury under thousands of results. The two cases we’ll cover are GitHub dorking, to recon source code, and Google dorking. Then we’ll address two specialized search engines: Censys and Shodan.

GitHub
Companies who embrace open source may use a public source code repository like GitHub to share source code and collaborate with the world. Given the popularity of this approach and the accessibility GitHub offers, other organizations have also adopted the platform for code sharing, typically on a more private basis. However, mistakes happen, and code gets published that shouldn’t be shared with the world. As a pentester, you might get lucky and find private keys, authentication data, hard-coded passwords, system configuration data, and even code vulnerabilities that could be useful during an engagement.

Table below contains a few GitHub dorks examples. You may be able to further limit the results to your target by including keywords about your target’s organization name, a target contributor, or the software you are targeting.


Table:   GitHub Dorks

Note: You can find many more GitHub dorks online. Here are some examples: https://github.com/techgaun/github-dorksand https://github.com/obheda12/GitDorker/blob/master/Dorks/alldorksv3

This is far from a comprehensive list, but it should give you an idea of the kind of power that search capability gives you within source code repositories. Searching for projects by company name or contributor may find repositories that are used in the target organization’s environment. Searching those for common insecure implementations can help find weak login forms or other data handling issues, for example. You may also find references to other software that is in use that allows you to identify internal technologies, like database versions, or even vulnerable dependencies that you might exploit during your test.

Google Dorks
Exploit Database hosts the Google Hacking Database (https://www.exploit-db.com/google-hacking-database), which is filled with dorks that work in Google. Uses range from identifying login portals based on your company’s domain to searching for web cameras or other devices that are exposed to the Internet. You can also fingerprint web applications and web servers that have been indexed by Google or search social media that has not been made private.

Table below contains a few examples. You can limit the results of these searches by adding the site: or inurl: search components:


Table:   Google Dorks
 

ext:log site: your-domain-name.com
or
ext:log inurl: your-domain-name.com

Okay, so that last one hopefully won’t find actual leaked penetration testing reports for your organization. These should at least give you an idea of what is possible with a search engine. Additional Google operators include allintitle:, allinurl:, allintext:, intext:, cache:, related:, and filetype:. You can also add logical operators, such as OR, AND, and – (not), as well as wildcards (*). For example, this would search for pets that are cats, dogs, or chickens and blue, red, or black with the objective of returning all results about pets that are blue cats, blue dogs, blue chickens, red cats, red dogs, red chickens, black cats, black dogs, or black chickens, but not blue owls, yellow chickens, or white anything:
pets (cats OR dogs OR chickens) AND (red OR blue OR black) -white

Censys
Censys was created in 2015 at the University of Michigan by the same security researchers who created ZMap. Censys lets you query host and certificate information from Internet-wide scans using full text searches or field-based searches with regex (in the commercial version) and logic operators for enriching your queries. In 2021, Censys released version 2.0 of their search, simplifying search terms and moving the search tool to https://search.censys.io. In Censys, you can search either by host information or by certificate information, as shown in below.

For hosts, Censys collects information about network addressing, vendor, operating system or software names, services, geographical location information, and information about technology used in web pages, among others.

For certificates, it collects details such as cipher data, subject and issuer data, and validity of publicly visible certificates.


Figure:   Censys Search 2.0 main page

Take the example of using Censys to perform passive recon using certificate data. Suppose you suspect your target has a lax approach to maintaining their web certificates. Maybe this has led to lowered security awareness and more click-throughs for websites with self-signed or invalid certificates. You might be able to take advantage of this in a phishing attack if that were the case. Pull down the option for certificate search, then use the following search to find hostnames with expired certificates using the certificate name and the “expired” tag as search parameters:
parsed.names: domain-name AND tags.raw: "expired"

Of course, you would replace “domain-name” in this example with your targeted domain of choice. What if you wanted to identify weak keys in use, perhaps for PCI compliance concerns? You could use this query against certificates to get results:
parsed.names: domain-name AND parsed.subject_key_info.rsa_public_key.length: [ 0 TO 2047 ]
You could even make a host search for a range of IP addresses. Then, using the report function as shown, you can show a summary of the reported products for each open port detected in that range. For this, we entered the data definition services.software.product for the report to summarize, and then clicked Build Report. Similarly, you could request all of the domain names associated with systems in the range that are using certificates by reporting on the data definition services.tls.certificates.leaf_data.subject.common_name. You could then search for each of these under the certificates search and report based on using the data definition parsed.names.raw. Since this returns all of the hostnames with your searched domain string in them, including third-party servers that may be hosting content on behalf of your company, be sure to verify ownership of any domains you find this way before attacking a site.


Figure:   Censys reporting based on host search results

Censys is a flexible search tool that can help you identify system vulnerabilities, web infrastructures, and network footprints without ever querying your target directly. The Explore function makes pivoting even easier. Once you run a search, click on one of the results. Here, you will see information such as the open ports, network information, OS, and geolocation for the target. As in Figure above, you will also be able to select Explore from the top navigation bar. Choosing this will display a relationship graph showing your searched target with host, certificate, and domain name information in a clickable graph. When you click and hold a node, you are  seeing additional search options, such as Explore Hosts, Explore Domains, Explore Certificates, or View, to see more information about that node. At the bottom of the page, you are seeing an Available Pivots table with the data definitions you can use to manually search for additional data. Further documentation about the query language for Search 2.0 is available on the Censys documentation site: https://support.censys.io/hc/en-us/articles/360059608451


Figure:   Censys target exploration

The Shodan search engine also scans the entire Internet, parsing banners for services and categorizing the data returned by each device. The main page provides a search box that can be used to examine content to find keywords or phrases. Advanced queries enable users to apply filters and boolean logic operators to drill down into the results. It works similarly to a typical web search engine such as Google, Yahoo!, or Bing.

In Figure beow, we are looking for any data results that return with the keyword “telnet.”


Figure:   Shodan basic search

As you can see, a substantial number of results were returned and categorized under Top Countries, Top Services, Top Organizations, Top Operating Systems, and Top Products. If you click on one of the summarized categories, it will apply the appropriate filter in the search box and execute a new query. One of the most useful features with Shodan is the ability to apply filters with the search criteria.

If you wanted to find data with the keyword “telnet” along with any ports that have port 23 open and are located in the United States, we could apply the search phrase telnet port:23 country:"US" in the search box to narrow the search (Figure).


Figure:   Shodan filters

The Reports button on the top menu bar provides a quick and painless way to generate a report based on the search criteria. This report is linked to your account and can be accessed once it is successfully generated by Shodan. Another useful feature is the Explore button. Here you can investigate potential use cases through popular searches and shared results.

Web Archives
Another approach to identifying web vulnerabilities is to use web archives. The most popular of these is probably The Wayback Machine (http://web.archive.org/), but some search engines, like Google, also offer the ability to pull up an older cached version of a site that shows up in search results. Occasionally, people will put a website online accidentally or publish information unintentionally on a website. Web archives are useful for examining whether any of those conditions apply, because they allow you to look at earlier versions of the site. With Google, you can use the cache: operator in search to examine the last cached version of a site, but to go back further or to select the page from a particular date, The Wayback Machine allows you to search for a particular URL, and if it has collected it, you can click on a date to examine the page as it was when it was collected.

As shown in Figure below, the calendar view on the bottom of the search results page shows bubbles to indicate how many snapshots were taken of the site on that particular day, and the color indicates whether the collection was redirected. A snapshot, however, does not indicate that the site was changed, only that it was collected.


Figure:   The Wayback Machine

Active Reconnaissance
Passive reconnaissance has its limits. If we extend our earlier example for home maintenance, you will eventually need to engage with the contractor directly. You need to know when they are available, if they have the tools and expertise to perform your specific house repair, how much they charge, or even if they’re willing to do the work! You’ll probably have to interact with them directly at this point and have conversations and other interactions to get more information.
In pentesting, this would be active information gathering. You are actively engaging the target in order to do things like detect open ports, web pages, services, and identify exploitable weaknesses you can use during the pentest. These actions may show up in logs, monitoring systems, or affect bandwidth utilization of the target. You should use this method carefully during a pentest unless you are not concerned about being detected, causing a disruption, or triggering incident response. Taking these actions outside of your contract may be prohibited or discouraged by local or regional laws. Port scanning, for example, has resulted in civil lawsuits or complaints to Internet service providers which may cost time, money, or resources for the pentester. For this guide, we will focus on active information gathering techniques that occur pre-exploitation. 

Host Enumeration
One of the most famous open-source network security scanning tools known to pentesters is the Network Mapper (Nmap). Nmap is a command-line tool that utilizes various network protocols and advanced features for surveying hosts for open TCP and UDP ports, fingerprinting operating systems, extracting service banners, and much more. Let’s talk about how Nmap and other tools can be used for these activities. Enumeration is the process of establishing active connections to target systems in order to find potential attack vectors. This includes attempting to find hosts, services, domains, URLs, and valid users to attack. Let’s start with host enumeration. Host discovery is an active scanning technique used to aid in the process of information gathering. The goal is to identify hosts alive and listening on the network.

Table below lists the common Nmap flags that are generally used to conduct information gathering exercises about hosts.


Table:   Nmap Host Discovery Options


Tip: Nmap is an important tool for the pentester and will be covered in the exam. Make sure you understand its various uses, options, and scan output. The various Nmap flags and options covered in this guide are listed on the PenTest+ exam objectives. However, for a full list of command options, execute the nmap command with no arguments, or use nmap -h.

Ping Scan
An Nmap ping scan (-sn or -sP flag) is a simple method of determining if a host is alive on the network. Whenever possible, Nmap will use an ARP scan. You can specify --send-ip to force a ping scan to use the Internet Control Message Protocol (ICMP) instead. This sends probes to hosts over the network. Hosts communicate over the network using ICMP messages, which are defined as specific types and codes that determine the state of the communication. A ping scan will send a type 8 message (ECHO request) to the target host. If a host is alive, it will respond to the source of the request with a type 0 message (ECHO reply).

Table below covers some of the control messages from ICMP common use, and Figure below shows a ping scan against a remote network using ICMP.


Table:   Nmap Host Discovery Options


Figure:   Ping scan

Nmap output can be exported into different formats. The grepable format is very useful when working with Nmap scan data from within the Linux operating system. The grep command (along with some help from awk) can be used to search for patterns from the scan output and dump the results to STDOUT. We can also pipe the returned output from the grep command into awk and print only the fields that are relevant for our search criteria. In this case, we want to investigate all of the hosts that are “Up” (alive) on the network.

Figure below shows how to use grep and awk to print IP addresses found alive on the network. The list of IP addresses returned from the search can be put into a text file and used with subsequent Nmap scans to target only those hosts that are alive on the network.


Figure:   Alive hosts on the network

Address Resolution Protocol (ARP) Scan
On local subnets, machines are addressed by MAC addresses instead of IP addresses. In order to determine the correct destination MAC address for a packet, ARP checks a local cache of known IP address and MAC address pairings, and if it doesn’t exist, it tries to resolve it. To resolve it, a packet is sent out to the broadcast address (FF:FF:FF:FF:FF:FF) on the network to ask “who has this IP, tell my IP.” The host that owns that IP sends a directed ARP reply back to the requestor with the correct mapping. The requestor adds it to their cache so that they can remember it for a fixed period of time. Until it expires, the host doesn’t have to re-resolve that pairing on the network.
As a pentester, you can use this to discover other hosts on a network. Suppose you have compromised a Windows system and you want to identify other targets. From the system console, you might issue the arp -a command to get a list of IP addresses and MAC addresses that system has communicated with. From the network, you could send out ARP requests using a tool like arp-scan in Linux.

As you can see next, by asking who has an IP for a range of IPs, any responses with a valid MAC address are probably real targets on the network.


 

Host discovery can be a difficult task to complete. However, Nmap provides more options for discovery that leverage other protocols and techniques, such as disabling ping (-Pn) and using other protocols such as TCP and UDP in the event a firewall is blocking ICMP packets, or even just using a list scan (-sL). The Nmap list scan is a useful technique for enumerating every possible IP address within a netblock and then conducting a reverse-DNS lookup to see if the host is registered in DNS with a fully qualified domain name (FQDN). Knowing that an IP address is registered in DNS is useful information, as it is an indicator that the IP is likely a valid host on the network, since someone cared enough to register it in DNS.
 

TIP: Nping (https://nmap.org) is another tool that is available in Kali that provides advanced options for using ICMP, ARP, and other protocols to probe hosts over the network. This tool is not covered in the CompTIA PenTest+ exam; however, it provides additional features outside of Nmap for complex host discovery and defeating network-layer defenses.

Other Protocols
On a network, anything that is broadcast is fair game for a pentester to collect. Identifying targets by passively collecting broadcast traffic is another valid way to enumerate host resources. As long as you aren’t sending traffic back, many would consider this to be passive information gathering, but as it requires a connection to the network, you are still technically interacting directly with your target at some level.

Figure below shows an example of using Responder in Analyze mode to observe active hosts on the network based on broadcast protocol traffic.


Figure:   Responder.py -I eth0 -A (analyze only mode)

Service Identification and Fingerprinting
Service enumeration occurs much the same way as host enumeration, in that you attempt to connect to a listening service, or you listen for traffic from that service. What if you want to know more? Service scanning simply asks a series of questions to elicit a response from a host over the network. The way that a service responds, including timing, protocol implementation, and banners, may tell you more about the version of software and the device behind the service.

Port Scanning Methods
The purpose of port scanning is to evaluate the state of a port. Once you have identified a list of open ports and services, you can figure out what your plan of action should be. A port can be open, closed, or filtered (possibly blocked by a firewall). Connection-oriented scans use the TCP protocol and evaluate the state of TCP-based ports and services and are the most reliable. UDP scans follow a less advantageous pattern of success, as they offer little to no reliability as to whether a port is available over the network. UDP ports that are open do not respond to a scan request. Closed UDP ports respond with an ICMP type 3 “port unreachable” message. Nmap will infer that the port is either open or filtered in the event it does not receive a message from the target host.
 

TIP: Services listening on UDP ports do not typically send a response to acknowledge that the port is open, but on occasion, they do send a response, which helps validate that the port is open. However, if nothing is returned, Nmap will show the port as open|filtered. It is possible that the port may be open, or possibly packet filters applied at a firewall are blocking the communication. Regardless, the version detection option (-sV) can be applied to the command syntax to help ascertain open ports from closed ports.

Different scan options can help improve the overall performance of the port scan. During a pentest engagement, time is of the essence. Adding scan overhead, like version detection (-sV), will likely increase the amount of time to complete a scan. However, Nmap provides timing and performance options to help improve scan efficiency. These options enable a user to specify the number of probes sent to a target or to reference timeout parameters, which by default are measured in seconds. A more straightforward approach would be to use the timing template (-T<0-5>) and allow Nmap to determine the timing values. The paranoid (0) and sneaky (1) templates are used to evade IDS and firewalls, while the polite (2) template is used to conserve bandwidth and resource utilization on the target machines. Templates aggressive (4) and insane (5) are used for speed, not accuracy. The normal (3) template is the default template when scanning with Nmap. Any other performance-based options will take precedence over the template that was selected.

Table below describes a list of scan methods that are both common and relevant for discovering open ports and services for hosts over the network. The last rows in the tables are related to performance-based scan options.


Table: Nmap Port Scanning Options

Common Ports and Protocols
Pentesters should familiarize themselves with common system, registered, and dynamic ports. System ports are any port between 0 and 1023. These ports require root- or system-level privileges within the operating system to run and host standardized application services across operating system platforms. Registered ports between 1024 and 49151 are user-level ports that host application services that do not require elevated privileges to run. Dynamic ports are any ports higher than 49151 and are in the private allocation range; they are not typically found in the user range.

Table below provides a list of common ports and protocols that are common in organizational networks.


Table: Common Ports and Protocols
 

CAUTION: Leaving unused ports and services open and available to untrusted hosts over the network is poor network security hygiene. Encouraging customers to follow the principle of least privilege can go a long away to reducing overall network security risk to an organization. Most mitigations found in a pentest report can likely be mitigated by disabling or applying better access control to a network resource.

TCP Scan
TCP (RFC 793 – Transmission Control Protocol) is connection oriented and offers reliable data exchange between two network hosts. This type of scan is referred to as a full connect scan and uses an operating system’s network function to perform the TCP three-way handshake with a target host. The TCP scan is the default scan method when using Nmap if no other scan option is specified. It is the most reliable scan type; however, it provides low-level control and may take more time to complete on larger networks, which makes it very inefficient.

Figure below shows a logical TCP three-way handshake between an attacker and a target.


Figure:   TCP scan

When a scan is executed without service detection but with the --reason or -vv flags, Nmap provides the reason as to why it listed a port as open, closed, or filtered. However, we know a SYN-ACK response from a target will typically mean that the port is available over the network. Operating system detection using Nmap can be a bit finicky to the point that it is a best-guess scenario. Using your knowledge of common ports and services and which operating systems they are associated with can go a long way when deciphering if a target is a Linux host or Windows based. For instance, seeing a host with port 22/tcp open would typically mean the target is a Linux-based host.

Figure below shows an example of a full connect scan. If a host had 3389/tcp (RDP) open, it would probably mean the target is a Windows-based host. This knowledge would provide nothing more than the instinctive ability to validate Nmap operating system fingerprinting.


Figure:   Full connect scan

Half-Open Scan
The TCP SYN scan is the most popular scan method, as it provides fast and effective scanning of thousands of hosts simultaneously. This scan method is commonly referred to as the “half-open” scan, as it never completes the three-way handshake.

Figure  above shows a logical example of the communication that occurs between an attacker and target during a half-open scan. The SYN scan provides full control over the packets it generates and allows the user to control timeout response times to speed up the performance of the scan. The user must have root or administrator privileges in order to execute a SYN scan.


Figure:   TCP SYN scan
Unlike in the previous TCP scan, the version detection flag provides valuable information from the target host, as the banner was provided with the reply message. Nmap will disclose the banner received from the target under the Version column.

Figure below shows an Nmap SYN scan with version detection. In some cases, the service banner will disclose the operating system, which is common with the SSH service. This makes operating system fingerprinting even easier.


Figure:  SYN scan with version detection

Note:  A SYN flood (half-open attack) is a form of denial of service attack where a malicious user will send a series of SYN requests to a target to make the service unresponsive to legitimate traffic.

UDP Scan
UDP scans are connectionless and can be very unreliable. However, UDP services are commonly deployed to support services that require the need for distributing information to hosts within a broadcast domain. Common services such as DNS, DHCP, and NetBIOS rely on broadcast messages, as the intended recipient of the message may not be known. In any case, a pentester should target UDP ports that are common within an organizational network first, and later after enumerating further information from the network, possibly target additional UDP ports of interest.

Figure below shows a UDP port scan for typical NetBIOS ports.


Figure:   UDP scan
In most cases, if a port is found to be open, Nmap will display a default service identifier if a banner was not attained through service version detection (-sV flag). Nmap has over 2,200 known services listed in the nmap-services database, which is included with the installation of Nmap and periodically updated as new services can be fingerprinted.

The Nmap Scripting Engine (NSE) is an extended framework for Nmap written in Lua to help automate a variety of networking tasks, including the ability to write scripts to tinker with and finagle network services. Certain scripts have the ability to perform specific tasks, such as extract version information and if a service is configured to allow anonymous login.

Figure below shows the output of an anonymous FTP Nmap script that verified anonymous logins are enabled on the remote host. In Kali, all of the scripts are located in the /usr/share/nmap/scripts directory. Each NSE script provides a head, rule, and action.


Figure:   Nmap script

The head provides metadata information, such as argument information, description, and dependencies for execution. The rule is a Lua method that determines if an action should be executed or not, and the action is the functionality of the script. Most NSEs that are deemed safe for execution can be included with a typical scan, using the -sCflag. However, if you wanted to perform a DNS cache snooping scan against an organization’s internal DNS server to uncover possible social networking sites, you would have to invoke the script specifically from the command line.

Figure below shows this type of scan.


Figure:   Nmap DNS cache snooping
 

TIP   You can find more information about the Lua language and NSE at https://nmap.org. Creating your own NSE is fairly straightforward, and the Script Writing Tutorial page on the Nmap website can get you started.

Web Target Identification
The most basic way to identify a web server is to look at the Server field in the HTTP response header—no sophisticated algorithm needed. Netcat, which is undoubtedly one of the most useful and underrated tools available, can be used to open a TCP connection to a remote host:


Netcat can also be used to open up a TCP connection with a database server, such as MySQL, in order to extract banner information from the corresponding service:


Based on the server responses, we see the host is running Apache and MySQL on the Ubuntu Linux operating system. Using just this information, we can investigate possible vulnerabilities and associated CVEs for the identified service versions.

Web Content Enumeration
Once a web server has been identified, you’ll want to enumerate the resources available, including web pages and filenames. Two ways to do this are by crawling or brute force.

Crawling and Scraping
Crawling (or spidering) is the process of ingesting a web page and following all of the links from that web page, and then crawling the links from that page, and so on. Of course, you can do this manually, but that’s called browsing. Crawling is a more automated approach to this problem. Two tools that can do this: CeWL and Burp Suite. For now, understand that crawling a website can help you find forms, login interfaces, and other testable content. Burp Suite will attempt to automatically evaluate the content for possible vulnerabilities and highlight those items for manual inspection.
Where crawling attempts to find new pages, scraping looks at the contents of a known web page. Its objective is to fetch the web page and gather terms and information from the site for analysis. This can be used to attempt to automatically identify web pages based on common terms, or you can feed a selection of scraped terms into a dictionary and use them to attempt to brute-force more pages, sites, or files.

Brute-Forcing
When you have a web page to start with, crawling is fairly simple. However, this misses any content that isn’t directly linked by the page that you do know. A host of documents, portals, and forms may be inaccessible from the path you crawled and may not be indexed in public search engines. To find other pages, you can use a dictionary or wordlist populated with common names found in most web technologies to enumerate the information. A popular tool of choice is called DirBuster, which is a Java-based framework. In addition to being integrated into Burp Suite via plugins, DirBuster is included in Kali Linux. Kali Linux also provides a common wordlist found in /usr/share/dirbuster/wordlists.

Figure below provides an example of using DirBuster to test for known directories and files on a web server.

A full report of the scan results can be produced in .txt, .xml, or .csv.


Figure:   OWASP DirBuster

Manual Inspection
Since scanners are limited in their ability to understand context and interpret responses, you will need to manually inspect the results of a vulnerability scan and take a look at the website yourself. As an example, scanners can’t determine the relevance of forms or pages they identify. How you choose to approach a login portal may differ from how you choose to approach a mail form. Another example is the robots.txt file.
The robots.txt file is found at the top-level directory of a host. It’s used to restrict web indexing capabilities for web crawlers like Google and Bing. Web crawlers look for this file first for instruction before traversing through a website. But this provides a list of possible uniform resource identifiers (URIs) that could help discover hidden directory and file listings. Site map files (sitemap.xml) and cross-domain files (cross-domain.xml) are two other examples of information disclosures found on sites with a large number of dynamic pages that provide site information, hyperlinks, and metadata. General rule of thumb: If it’s easy for you, it’s easy for the bad guy too. While many automated scanners will note that these files exist and even take the initiative to add the targets to their scanner lists, it’s up to the pentester to establish the relevancy of the content therein.

Analyzing Errors
Web servers, web applications, and databases produce error codes and stack traces when they receive a request that cannot be processed. Oftentimes software is developed to hide or mask the existence of these errors with exception handlers, as the internal error could lead to information disclosures, version information, or even more serious vulnerabilities. Web servers have five status code families with many different individual status codes that fire off, depending on how the request was received or processed by the server (Table below). You may be able to use differences in application response to enumerate valid users, for example, looking for a difference in the response between when a bogus user is supplied, versus a valid one. 


Table:  HTTP Status Codes

Database errors follow the same mentality—if it can’t respond to a user’s request, it will produce an error for interpretation. SQL databases such as Oracle, MySQL, and Microsoft SQL (MSSQL) have common errors that can stimulate the curiosity of a pentester to investigate possible SQL injection flaws. MySQL errors start with a four-digit error number followed by a “-” and the error description. MSSQL errors contain the error number, severity, error message string, line number, procedure name, and state, which can provide the location in source code that is throwing the error. Oracle errors contain a prefix with the error code (i.e., ORA-0001), followed by a description of the problem.
Organizations that are operating legacy networks may have low-bandwidth connections, which are in greater risk of service interruption when scanning. Most security scanning tools have options to throttle the scan performance to alleviate the burden on affected network segments. APIs are used within software applications to receive requests and send responses.

Figure below provides the three basic types of APIs. Software developers can impose rate limiting against certain API methods to help improve application performance and reduce the likelihood of denial of service (DoS) attacks. Ensure you have a good understanding of the APIs you may be testing, as it may be necessary to request or purchase an API key to enable additional queries in order to complete the vulnerability scan. For example, Amazon Web Services (AWS) (https://aws.amazon.com) enables developers to use a secure API gateway when accessing RESTful services within the cloud. Without an appropriate key, testing of the API services would be limited to publicly accessible methods that do not require authentication. A vulnerability scanner that enables authenticated scanning is best served for those remote services that require authentication.


Figure:  Application programming interface

User Enumeration
You might target login interfaces that you identify with a user enumeration attack. The idea is to see whether the response you get back from a login attempt is different when you use a valid user versus an invalid one. A web application might respond with a different web page, a service might take longer to respond for an invalid login,5 or a system might show a different response code or screen. OWASP documents this attack method for web applications,6 but this also applies to other exposed login and authentication interfaces, especially in the cloud.
Suppose you discovered a cloud e-mail in use during passive recon. Some cloud providers may allow user enumeration using login portals, such as seen in Figure 2-34, or at login endpoints, like https://login.Microsoft.com/common/oauth2/token for Microsoft services. You can use cloud-provider endpoints to attempt to enumerate valid users or to confirm the existence of users identified in OSINT searches using these URLs:


Figure:   Google Mail user enumeration

- Microsoft Online: https://login.microsoftonline.com/[email protected]&xml=1
- Microsoft O365: https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/[email protected]?Protocol=Autodiscoverv1

Note:  To use these endpoints, you will need to change “[email protected]” in the above examples to the value you are attempting to investigate.
If you have access to a network but not to any active systems, you might attempt to enumerate users or shares using Nmap enumeration scripts. Nmap crafts networking packets for target addresses destined for specific ports and services and monitors responses from each host. The tool is situationally aware—by monitoring for changes in networking speeds and latency—and will adapt to the environment accordingly. Nmap supports extended capabilities through the NSE. These scripts (.nse extensions) come natively with the installation of Nmap and provide support for additional network service and vulnerability detection.

Nmap has several user enumeration scripts for different protocols, most denoted by “enum.”

For example, krb5-enum-users attempts to discover valid Kerberos users by brute-forcing usernames against a Kerberos service. An example usage with output would be:


There are also Nmap .nse scripts for enumerating users in drupal, oracle, SIP, SMB, and SMTP. For share and file enumeration, Nmap offers guessing of tftp shares, for configuration files of network devices, for example.

The tftp-enum script execution and output might look like this:

You might also attempt to enumerate mainframe transaction IDs with the Nmap cics-enum script, or Citrix applications with the citrix-enum-apps script. For shares, smb-enum-shares will work for servers with SMB enabled. Enumeration isn’t exclusively about Nmap, however. There are other tools that will check exposed services for users. One example is Metasploit, which has modules such as auxiliary/admin/mssql/mssql_enum_sql_logins that will enumerate logins from exposed services.7

Defense Detection and Detection Avoidance
At some point, you’re going to hit a security control that gets in your way. If you end up inadvertently attacking a defense rather than your target, you might get confusing, inconsistent, or bogus results. For example, load balancers will typically be in place for high-traffic sites. These may serve traffic across multiple servers in the back-end. If any of these servers is differently configured, your attack may get a different result each time you request the resource.

Detection
These controls are not always reliably detectable through automated means, but some things you can look for are differences in HTTP headers across requests (their ordering or content), differences in HTTP response codes across requests, unexpected HTTP headers, cookies that indicate a defensive control, or differences in the timestamp from time drift between systems. As seen in the figure, the tool lbd (included with Kali) checks several of these characteristics to attempt to detect load balancers, but these methods aren’t guaranteed to be reliable. Tenable’s Nessus, a vulnerability scanner, also offers plugin ID 1224 to attempt to detect load balancers based on some of these characteristics. We’ll talk more about Nessus later on in this guide.


Figure:   Output from the lbd tool

Web application firewalls (WAFs) are designed to intercept web requests and block common attack patterns. As an example, Amazon gives advice to customers using AWS WAF for customizing responses on their blog: https://aws.amazon.com/blogs/security/customize-requests-and-responses-with-aws-waf/. In practice, WAFs can be difficult to detect because it is sometimes hard to differentiate WAF blocks from proper application validation. Tools like Wafalyzer8 and wafw00f9 can attempt to identify a WAF by sending requests and looking at headers, cookie values, and error messages. If the systems have not been heavily customized, then these tools will make identification easier. If they have, then the rules will likely not match and you will have to manually determine if a WAF is at play.
The easiest way to do this is to pick some obviously malicious strings and put them into a URL using fields that won’t have any application logic behind them. For instance, if there isn’t a field named “likebear” in the URI, you can add &likebear= and see what kind of error it generates. Repeating this and varying the types of strings you use will help you identify if there are rules assessing your submissions. It may not help you identify the specific version of WAF, but the error condition should be informative. The HTTP return code, redirect URL, or even response body may provide additional details. Watch the traffic using a proxy tool, such as Burp Suite or ZAP to see if headers, redirectors, or other information is sent but not visible to the end user.
Firewalls are typically easier to identify. Some firewalls drop traffic that isn’t allowed, in which case if you send a message, you won’t get a success or ICMP message back. If the firewall is returning ICMP messages and you have one good port for a host and one bad port, you can look at the TTL on the packet to determine the differences. Let’s take a look at three examples using scanme.nmap.org.
In this first example with port 22, we see a SYN-ACK packet (SA) come back, meaning the port is open. It has a TTL of 48. Nothing has interfered with this traffic. It’s normal.


In this second example, we send a packet to port 25 and nothing responds. Because no ICMP message is returned, this means the traffic is blocked due to an explicit blocking rule for some kind of firewall.


For the third request we send, we see two things. The RST-ACK flags are set. This means the port could be blocked by a firewall or the target device isn’t listening for that port. But the TTL is 50, which is interesting. The success was 48 and the block was 50, which suggests there is likely some device in front of this system. Since TTLs decrease with every hop, this means the traffic was blocked before it reached the server itself.



Evasion
Bypasses for network-based controls are heavily dependent on both the control’s tuning and the platform running it. Let’s look at two ways load balancers work: round-robin and persistent load balancing. Round-robin–based load balancing takes the requests and sends them to pool of systems, one at a time, in round-robin fashion. Depending on how this is implemented, users aren’t guaranteed to end up on the same system each time. This means you’ll either need to compromise all the systems in the pool or compromise one and then make many requests until you are once more routed to the exploited system. With persistent load balancing, the device frequently generates and stores some form of session variable and uses that to determine the target system for a .jpg" width="400px"> session. While this guarantees session consistency, this can be abused. If this session variable is part of a cookie, for example, can it be replayed or manipulated in order to target specific systems behind a balancer?
Another reason you might care is that exploits can be used to compromise the load balancer and then change the configurations to benefit the attacker. One such attack that has been publicly abused is the Big-IP RCE that takes advantage of an exposed management interface and then lets the attacker gain RCE and either tunnel through the device or take it over (https://support.f5.com/csp/article/K02566623).

WAF bypasses are also heavily dependent on the software being used, but WAFs are frequently minimally configured in order to save time and not prevent legitimate attacks, so typical attack patterns such as