CompTIA PenTest+ Certification: A Simple Guide To Network-Based Attacks

Topics:

- How to research attack vectors and perform network attacks
- Exploiting name resolution vulnerabilities
- Stress testing for availability
- Password attacks
- Researching exploits based on vulnerabilities
- Various types of layer 2 attacks
- Understand how to use tools to conduct network packet manipulation
- Identify common protocol and file-sharing exploits

- Name Resolution Exploits
- DNS Spoofing and Cache Poisoning
- Attacking LLMNR and NetBIOS
- Password Attacks
- Brute-Force and Dictionary Attacks
- Password Spraying
- Hash Cracking
- Stress Testing Applications and Protocols
- Network Packet Manipulation
- Analyzing and Inspecting Packets
- Forge and Decode Packets
- Layer 2 Attacks
- Attacking the Spanning Tree Protocol
- VLAN Hopping
- Bypassing Network Access Controls
- Researching an Attack
- An Attack on FTP
- An Attack on Samba and NFS\

This guide will expand on the many ways to attack and exploit network-based vulnerabilities during a pentest. For the PenTest+ exam, CompTIA has grouped various operating system services and layer 2 attacks into the network-based category. Network-based vulnerabilities can lead to compromise of the target operating system, privilege escalation, or even loss or degradation of service performance. Most network-based vulnerabilities can be identified during a vulnerability assessment, using a vulnerability scanning tool like Nessus, or by conducting vulnerability research. The Metasploit Framework (https://www.metasploit.com) or SearchSploit (https://www.exploit-db.com/searchsploit) can be used to validate public exploits for vulnerabilities identified during the vulnerability assessment. We will use these tools and more as we investigate various types of network-based attacks.

Name Resolution Exploits
Different host- and network-based protocols and services offer name resolution capabilities. A protocol is a set of formal rules that describe the functionality of how to send and receive data, while a service is a software implementation that executes the formal rules of a protocol for a specific computing platform. Many protocols apply to name resolution, but we’ll talk about Domain Name System (DNS), Link-Local Multicast Name Resolution (LLMNR), and NetBIOS, which offer hostname-to-IP resolutions, depending on where the lookup occurs. DNS works at the application layer and provides essential lookup services for devices connected to the Internet or a private network. LLMNR and NetBIOS are used by Microsoft operating systems to allow clients to help improve network communication efficiency and not send lookup requests outside of the network that can be resolved internally on the local area network (LAN). NetBIOS and LLMNR are implemented on behalf of the TCP/IP stack as part of the legacy computer name registration and resolution service called Windows Internet Name Service (WINS). The Active Directory Domain Services (AD DS) is Windows implementation of a DNS server, and the DNS client is the service that supports client hostname resolution lookups; it is installed by default in later versions of Windows. Linux implements protocols such as DNS through the use of daemons. For example, UNIX/Linux systems using BIND for DNS run a daemon called named. Named runs as a service and can be used to translate domain hostnames to IP addresses for both internal and external networks. DNS clients will send a query over port 53/udp to a DNS server in hopes of receiving an answer with a corresponding IP address or fully qualified domain name (FQDN). A DNS forward lookup will ask the DNS server to provide the IP address for a  FQDN, and a reverse lookup will ask the DNS server to do the opposite and provide the FQDN for an IP address.

These types of lookups are the most basic, and the figure below shows an example of a DNS reverse lookup request for example.com captured in Wireshark. In the figure, you see a DNS “Standard query” from an internal source IP address to the external DNS server to resolve the domain name example.com. The DNS server replies with the corresponding IP address for example.com, using a “Standard query response.”



Figure:  DNS forward lookup request

After the DNS server answers the request, it will cache the result with a time to live (TTL) value, so it doesn’t have to keep submitting the same request to its DNS root server. Once the TTL expires, the server will resubmit the request to its DNS root and cache the request once again. DNS cached requests can leave DNS clients susceptible to cache poisoning and spoofing attacks if not properly configured.

DNS Spoofing and Cache Poisoning
The Nmap enumeration script (dns-cache-snoop.nse) can assist with conducting cache snooping against an internal DNS server. The idea behind cache snooping is to see where the targets are browsing on the Internet. This type of information disclosure can help aid in various attack scenarios to include

- Waterholing  If an attacker knows the websites an organization frequents, the attacker could infect the web pages in the site with malware.
- DNS spoofing  An attack method used to impersonate a victim’s DNS server, forcing them to navigate to a malicious website.
- DNS cache poisoning  The DNS resolver cache is overwritten on the DNS server with a malicious web address, and the user will receive the malicious site instead of the intended one.

DNS spoofing is accomplished using on-path attack (previously known as man-in-the-middle [MITM]) techniques to monitor and impersonate response messages to spoof legitimate hosts. The goal is to exploit the target with a malicious redirect or steal sensitive information from a fake web page, such as impersonating a Facebook login page.

Ettercap (https://www.ettercap-project.org) is a tool that pentesters can use to conduct on-path attacks against various protocols, to include DNS. Follow along with this exercise as we impersonate a local gateway host to force a target to visit a malicious web page that executes JavaScript to hook the browser exploitation framework (BeEF). You will need a Kali host, Ettercap version 0.8.2 (other versions may work with these instructions as well), and access to a local area network with a target to test with (i.e., Windows, Linux, iOS, Android, etc.).

Note: : Ettercap is installed by default in Kali Linux. BeEF can be installed by typing sudo apt install beef-xss in Kali.
1.: The first step is to modify the /etc/ettercap/etter.dns and add an entry to the file for the domain name “example.com” and have it point to your malicious host. In this case, we use our Kali host IP: 192.168.48.128.



2.: Next, create the web page named index.html in the /tmp directory to load a JavaScript BeEF hook using the hook.js file. This will be the web page the user will be directed to when they try to connect to example.com. The content should look like the following:



3.: Now, use the Python http server module to host the web page on port 80:
python -m SimpleHTTPServer 80
4.: Then, launch BeEF from a terminal window using the command sudo beef-xss. Once the web page loads, log in using the credentials you created for BeEF.
5.: Next, we need to identify other hosts on the network. We can use Nmap to identify other hosts by just using ARP packets by specifying the -sn flag to disable port scanning and using the -n flag to stop IP address resolution.
$ sudo nmap -n -sn 192.168.48.128/24
6.: In our case, we identify one other host: 192.168.48.129. Now that you have a target, find the gateway address for the local network using the ip route command.




Note: : You can launch a graphical user interface (GUI) for Ettercap using the command ettercap -G. But most attackers prefer command-line tools because a GUI isn’t always available. Therefore, understanding the command-line options can be important.
7.: We want to establish an ARP poisoning session between our gateway (192.168.48.2) and our target (192.168.48.129). The -M flag sets up the MITM (on path) technique. In this case, we are using the remote arp technique. The -T argument puts it in text-only mode. The -q argument prevents Ettercap from printing the full packet contents, so the output will be more readable. The last part is our gateway and target. These can be .jpg" width="400px"> in the format: MAC address/IPv4 addresses/IPv6 addresses/Ports. Note the slashes! In our example, we’re not using the MAC or ports, so there will be blanks by the slash delimiters.
$ sudo ettercap -M arp:remote -T -q /192.168.48.2// /192.168.48.129//
8.: After running the ettercap command, you need to enable the DNS plugin. When Ettercap launches, it gives you the option to access a help menu to figure out how to do this. One of the options on the help menu is for plugins. By typing p, you can list the plugins. We’re going to use the dns-spoof plugin.



9.: Once the DNS spoofing plugin is active, when the victim navigates to the web page http://example.com/index.html, they will see your hooked page. Inside Ettercap, you will see the spoof succeed.



To exit Ettercap, press q in the window where you’re running it.

Caution: ARP (Address Resolution Protocol) poisoning/spoofing is a type of attack where a malicious device sends false ARP messages to other hosts on the network in an attempt to impersonate another machine, thus linking its MAC address with another host IP on the network. If you ARP-spoof your local network to make them think you are the gateway, your device could get flooded with requests and cause other hosts to become unresponsive over the network. For these exercises, we recommend using a lab environment.
10.: In BeEF, you can now see the target device under the Online Browsers tab. From this point, you can use BeEF to exploit the target.




Tip: Operating systems and browsers typically cache name resolution information to improve network efficiency. If the DNS spoofing attack fails, first try clearing the browser cache from the target. If you are using a Microsoft Windows operating system as your target, try using the nbstat command to clear the cache.

Attacking LLMNR and NetBIOS
Have you ever wondered what happens behind the scenes when you map a network drive or attempt to access a Microsoft Windows–based resource over the network? Well, if it requires authentication, it is bound to pass some credentials for convenience. If it’s easy for the user, it’s easy for the bad guy. NetBIOS (Network Basic Input/Output System) was developed back in the 1980s under RFCs 1001 and 1002 and helps facilitate the communication of Microsoft applications over a network. NetBIOS operates within the transport and session layers of the OSI model (layers 4 and 5), providing services such as protocol management, messaging and data transfer, and hostname resolution.

NetBIOS communicates over TCP/IP (NetBT) and listens on ports 137/UDP, 138/UDP, and 139/TCP. Figure 3-2 is an illustration adapted from the Microsoft TechNet Library describing NetBT in the TCP/IP protocol suite. NetBIOS ports are typically found on LANs, as NETBIOS relies on a great deal of trust being implemented and controlled through physical security boundaries and isolation (achievable through firewalls and access control lists as well), since it is a very chatty protocol and can expose a great deal of sensitive internal information, such as network domain information.



Figure: NetBT components in the TCP/IP protocol suite

LLMNR is a protocol that mimics the functionality of DNS for IPv4 and IPv6 hostname resolution for hosts operating on small networks (LANs). RFC 4795 was published in January 2007 and addresses LLMNR protocol functionality. Microsoft introduced the protocol in later releases of the Windows operating system to include Windows Vista; Windows 7, 8, and 10; and Server 2008 and 2012. Just like DNS, LLMNR and NetBT components are subject to spoofing by poisoning name service components, by impersonating legitimate hosts listening on the network, and by responding to target service requests, such as mounting a network drive. The bigger issue is that services that implement user access controls on the network (like mapping a network drive) will require authentication. A malicious user can spoof an authoritative source by responding to LLMNR (5355/UDP) and NetBT (137/UDP) requests, informing the victim, “Hey, I know where that host is.” The target will send an authentication reply to the malicious host, thus compromising the username and NTLMv2 hash. Then the malicious user can crack the hash offline to recover the plaintext password.

Tip: Windows isn’t the only OS that uses LLMNR and NBNS. But traffic from these protocols is not universally visible. LLMNR traffic is only visible from the same multicast group. NetBIOS traffic is only visible within the same subnet because it’s broadcast. In other words, if no one else shares your logical location, your Responder will be sad and lonely.

Using Responder to Gather Hashes
Responder is an LLMNR, NBT-NS, and MDNS poisoner that can aid pentesters with poisoning name resolution services and compromising usernames and hash values with a rogue authentication server. Responder is a Python script that was developed by Laurent Gaffié and comes preinstalled in later versions of Kali Linux and can be found in /usr/share/responder. For your convenience, a bash script (responder) is available in /usr/bin to ensure it is included in your $PATH. The configuration file that gets read when executing the command is located in /etc/responder and can be tailored to your needs for the engagement.

To see a list of command options, type responder -h in a terminal window. To start Responder, you can execute the following command, as shown in Figure 3-3, where -I wlan0 specifies your network interface to listen on.



Figure: Starting Responder

Note: : To see if Responder is installed in your Kali release, open a terminal window and try locate responder or which responder to see if it is currently in your $PATH. You can download the latest release from the developer’s GitHub page (https://github.com/lgandx/Responder).
You will see a list of poisoners, servers, and options that are loaded after starting Responder. For each of the servers that are listed as “on,” a Python listener has started to poison client requests and answers replies over ports specific to each service.

When you look up the process ID (PID) for Responder and grep for listening ports under the corresponding PID, you will see a list of TCP and UDP ports Responder is listening on, as shown below.



Figure: Ports and services started by Responder

Now that Responder is listening over the network, we can try and poison LLMNR requests and compromise hashes over the network. In the figure below, the Administrator user is attempting to map the $HOME share from SERVER1 over the network.



Figure: Mapping a Windows network drive

Note: : Most hosts tend to follow a certain sequence for hostname resolution. Windows hosts will first try DNS to resolve the hostname. Then they will try LLMNR, and if that is unavailable, they will try the NetBIOS Name Service (NBNS). Responder works best for intercepting invalid hostname requests across the wire, and LLMNR/NBNS is a race condition otherwise. The order of resolution your target ends up following could affect the time and complexity for successful exploitation.
Once the Administrator user clicks on the Finish button, a request is sent over the network to resolve the hostname SERVER1. If the host cannot be resolved through DNS, the request is sent as an LLMNR/NBNS query. The malicious host responds and basically says, “I know where you can map that drive” and tells the target where to go. The target sends the authentication reply with the username and SMB-NTLMv2 hash value in an effort to map the network drive. Unfortunately for the Administrator user, the drive can’t be mapped; however, now we have the Administrator’s SMB-NTLMv2 hash, as shown below, that we can try and crack offline.



Figure:  The captured NTLMv2 hash in Responder

Using WPAD Attacks with Responder
Another popular on-path technique using Responder is the Windows Proxy Auto-Discovery Protocol (WPAD) attack. Microsoft Windows clients connect to the WPAD server to obtain and configure the automatic web proxy settings for Internet Explorer. This functionality is enabled by default on most versions of Windows. In the event the Windows host cannot resolve the WPAD server hostname through DNS, it will send LLMNR and NBNS queries over the network. Responder can be configured to start a WPAD listener, force basic HTTP authentication (no encryption), and prompt a user to enter a username and password before browsing to the website. When Responder sees a request for “wpad,” it will poison the answer sent to the Windows host. The user will be prompted to enter a username and password, and when the user clicks OK, the credentials will be captured by Responder.






The Microsoft Security Bulletin MS16-077 was published on June 14, 2016, to help mitigate how Windows handles proxy discovery and WPAD automatic proxy detection. Two solutions that could help mitigate the WPAD attack are to create an entry in your DNS server to point to the organization’s proxy server. The other solution would be to disable Automatically Detect Settings in Internet Explorer. If the hosts are managed through Active Directory, then a group policy could be used to disable the default setting.




NTLM Relay Attacks
You can see how we can capture NTLM hashes for offline cracking using multiple techniques within Responder. But what if you can’t crack the hash or don’t want to bother with it? By poisoning the response, we can entice the target to try to connect to us. But instead of delivering the resource ourselves, we can forward that request to the host that originally requested it or to a different target host, effectively sitting in the middle of the connection. This lets us deliver much more than the requested object. We can also inject malicious payloads and issue commands using the context of the user who made the request we poisoned. Maintaining access this way can be tricky, but it’s a valid option if you can poison responses and can’t crack the hash.

Note: : Responder has a built-in tool called Multi-Relay that allows you to perform relay attacks against NTLM. You can read more about it on the creator’s blog here: http://g-laurent.blogspot.com/2016/10/introducing-responder-multirelay-10.html and here: https://g-laurent.blogspot.com/2017/03/multirelay-20-runas-pivot-svc-and.html

Password Attacks
From a network attack perspective, we assume you have no access to the systems, only to the network. This means you may see login interfaces to applications or operating systems and choose to attack them in order to gain access to the systems and the data they protect. Ideally, you’ll enumerate target users before attempting to guess their passwords, so we’ll operate on the assumption that you are targeting known users in this section. We’ll talk about three ways of going about this: password spraying, brute-force and dictionary attacks, and hash cracking. Before we do, we need to be clear about what you need to consider when choosing which of these to do.
Defenders look for attacks against authentication systems based on things like the source of the request, the number of attempts (including failed versus successful attempts), and the accounts targeted. As a deterrent, they may implement account lockout policies to temporarily or permanently suspend an account based on a number of failed logins, or they may enable automated blocking for a source that makes too many attempts. As a pentester, you will need to understand these concepts so that you can prevent unnecessary disruption to your client and avoid detection when necessary.

Brute-Force and Dictionary Attacks
Brute forcing is probably the oldest method of attack. Generally, you find a user and try every possible combination of letters and numbers to guess the password. Try a. Then try aa. Then try ab. Then try ac… and so on. The pros of this method are it’s simple and, if having enough time, you’re guaranteed to succeed. The cons are the time required is likely to exceed the heat death of the universe, and you’re probably going to trigger automated blocking defenses and set off every possible alarm while you do it.
A modification of this is to use a dictionary of known words people like to use for passwords and guess only that list. It’s not guaranteed to succeed eventually, because if the password isn’t in your dictionary of guesses, you’re out of luck. But it will take less time to make some educated guesses. You’ll still trigger automated blocking defenses and set off alarms unless your dictionary is very good (or lucky), but you’ll succeed or fail more quickly than a brute-force approach.
Many tools will let you do this, such as Metasploit, Hydra, Medusa, and Nmap. In our example, we’ll show Nmap performing a dictionary attack against SSH. These examples were done in Kali Linux. Our users.txt contains one entry: bob, which we assume to have been previously enumerated.



There are, of course, combinations of this as well. You can generate dictionaries based on rules that will try “Password” as well as “password” and “Passw0rd,” for example. You can even generate dictionaries that will guess combinations of words. The longer your dictionary, the longer the attack will take. The more users you target, the longer the attack will take. The more guesses you make, the more likely you are to get caught or trigger a control. This is important. If the client has an account lockout policy that locks an account after four incorrect guesses, you will create a denial of service condition for any accounts you target with four or more incorrect guesses.

Password Spraying
Password spraying addresses this problem by targeting many users with a single well-known password, like Winter2021.

The theory is that out of 1,000 users, at least one of them might be using this password. The advantage of this approach is that you’re less likely to trigger account lockouts. It’s also faster to go through 1,000 accounts with one (or two) passwords than to attempt to try a dictionary of 100 guesses against the same number of accounts. The disadvantages are that it relies heavily on luck and good educated guesses about how people think, and you still risk alerts based on targeting many accounts from a single source or over a small amount of time.
Here’s an example attacking multiple users with a single password using Hydra using Kali Linux:




Hash Cracking
Passwords may be sent over the wire or stored in hashed format. You may intercept one or more of these hashes while pursuing other network attacks, for example, with Responder. Unlike password spraying, you do not risk account lockouts or alert triggers by cracking a hash offline. It is much faster than interacting with a service for the full login exchange, so your time limitation is often driven more by the hardware that you have available to dedicate to cracking than by the speed of the network or the authentication system being attacked.

Note: : Windows generates hash values of the account passwords in NT or NTLM format: [:]. These hashes are stored in the Security Account Manager (SAM) database on the local computer or in the NTDS.dit database on the domain controller. An NT or NTLM hash can be used for remote authentication, which is permitted with relay or pass-the-hash (PtH) methods of attack. NTLMv2 hashes are used for network authentication. These hashes are based on a user’s NTLM hash and derived from a challenge/response algorithm. These hashes cannot be replayed over the network.
In the /usr/share/responder directory in Kali, there are log files where Responder keeps tabs on its activity. The Poisoners-Session.log is used to document each poisoned answer sent back to targets over the network for a specific service. The Responder-Session.log documents the responses from the targets for each protocol that was poisoned. If successful, the username, hostname, and hash values will also be documented. The nice thing about the logs is that they keep a historic record of all events, with date timestamps. This is useful when troubleshooting or correlating specific attacks with customers during or post-engagement. Another convenient feature of Responder is that it will record the compromised hash values or credentials in a text file, which is already in a format John the Ripper (JTR) can understand.

The figure below shows how easy it can be to execute brute-force attacks against NTLMv2 hash values to recover the Administrator’s plaintext password.



Figure:  Cracking NTLMv2 hash with a wordlist in JTR

There is a clear distinction between hashing and encryption. A cryptographic hash function is a type of algorithm that takes variable-length strings (message) of input and turns them into fixed-length hash values (message digest). The primary objective is message integrity, such that the hash value cannot be returned to its original string value. This makes hashing an ideal candidate for storing passwords. The most common hashing algorithms today are Message Digest 5 (MD5) and Secure Hash Algorithm (e.g., SHA-1 and SHA-256).

Note: : Hash values are not just for security. Vendors compute hash values for software releases to provide consumers with confidence that the software they are downloading originated from a trusted source. Malware research organizations, such as Virus Total (https://www.virustotal.com), compute hash values for identifying known malware. This allows malware analysts to distinguish between similar kinds of malware, regardless of whether the name of the executable has changed.

Unlike hashing, encryption is reversible. By using a key, encryption allows plaintext data to be encrypted into ciphertext and decrypted back to plaintext. Symmetric key encryption relies on the same cryptographic key to both encrypt and decrypt the data. Common types of symmetric key encryption are listed in Table 3-1. Asymmetric key encryption uses two different keys for both encryption and decryption. The secret key is only known by the author, and the public key is shared to anyone wishing to decrypt the messages. This is mostly found in client-server models for authenticating access using digital certificates (X.509) or a public key infrastructure (PKI).



Table:   Common Hashing and Encryption Algorithms

Tip: This section merely provides a basic introduction to various encryption and hashing technologies. To further your understanding of cryptographic algorithms, check out the Federal Information Processing Standard (FIPS) Publication 140-2 (FIPS PUB 140-2). This publication provides an in-depth look into U.S. government standards for compliant algorithms and technologies.

The hash-identifier (https://code.google.com/archive/p/hash-identifier) Python script, also available in Kali Linux, helps fingerprint various hash types by evaluating characteristics from the known hash value. Modern-day UNIX and Linux passwords are protected using a password hashing function called crypt(), which is based on the Data Encryption Standard (DES). The default hashing function for later revisions of the Linux operating systems is sha516crypt. Each hashed value is accompanied by a randomly generated 8-byte salt value in order to lower the probability of the hash value being found in a precalculated table, such as a rainbow table.

The figure below provides an example of using the crypt() function in Python to compute hashes with a predefined salt value. However, the hash is only as good as the plaintext value it is protecting—or is it? Legacy hashing algorithms, such as MD4 and even MD5, are susceptible to collision attacks, where two unique inputs can produce the same hash value. In situations where security is not of primary concern, these hashing algorithms may be good enough for day-to-day use, depending on the organization’s security requirements.



Figure:   Crypt hashing function

Earlier, we mentioned rainbow tables. A rainbow table computes all of the possible hash values for plaintext values, up to a certain length. Regardless of your computing power, these tables can become massive and require hefty storage capacity—some over 300GB in size. Each table is usually strategically designed for a specific hash requirement, such as MD5, SHA-1, the Windows LAN Manager (LM), and NT Lan Manager (NTLM), which is used in various Microsoft network protocols for authentication. RainbowCrack (http://project-rainbowcrack.com) is a popular open-source tool that cracks password hashes using rainbow tables. RainbowCrack utilizes a time-memory trade-off algorithm to increase memory usage based on the time consumed with conducting a task. Essentially, it provides a happy medium where software and hardware can work together, instead of against each other.

Tip: The LAN Manager (LM) hash is a legacy fixed-length password hashing function, which has been deprecated and disabled since Windows Vista. It is unlikely you will see any questions regarding LM on the exam.

Brute-force password attacks are very inefficient and are typically a last resort. However, tools like JTR, Cain and Abel, and Hashcat (https://github.com/hashcat) help increase the chances of successful password exploitation. JTR can conduct both dictionary and brute-force password attacks against common hashing algorithms. If you don’t have a high-performance computing system composed of graphics processing unit (GPU) clusters for Hashcat or RainbowCrack, using wordlists is a quick and dirty way to find out what you are working with in regard to overall security.

The figure below shows an example of using JTR with a wordlist to crack a captured password. During a pentest, if you find the organization is using passwords vulnerable to dictionary attacks, it should tell you a little about what you are up against and the maturity level of the organization’s security controls. One of the hardest things to overcome as a pentester is to not overthink the problem. In some cases, admin/password is all you need.



Figure:   John the Ripper

Stress Testing Applications and Protocols
A company may need a pentester to evaluate their capabilities to thwart denial of service (DoS) attacks or to examine how a system fails under stress. US-CERT defines a DoS attack as “an attacker attempting to prevent legitimate users from accessing information or services.” DoS attacks typically occur when an adversary consumes all available resources of a target using rapid methods of attack.

The table below shows the Common Attack Pattern Enumeration and Classification (CAPEC) mapping of the four members of the DoS family of attacks.



Table:   DoS Attack Patterns

US-CERT states that the most common method used is flooding. CAPEC identifies flooding as attack pattern ID 125. If an attack is successful, user connectivity will be limited or could even cause the target to crash. CAPEC-125 identifies other related attack patterns that fall into the flooding category.

The table below provides attack definitions for each flooding technique from the CAPEC knowledge base.



Table:   DoS Flooding Techniques

DoS attacks use a single network connection, whereas with a distributed-denial-of-service (DDoS) attack, adversaries launch DoS attacks across multiple network connections, thus magnifying the level of impact of a target’s availability. The primary objective for a DDoS attack is to intentionally disrupt services to an online network to prevent users from accessing the resources.

The Imperva website (https://www.imperva.com/?redirect=Incapsula) provides a more thorough look into the DoS and DDoS attack techniques. Imperva organizes DoS and DDoS attacks into three categories:
- Volume-based attacks  Saturate the bandwidth and are measured in bits per second (Bps)
- Protocol attacks  Consume server resources and are measured in packets per second (Pps)
- Application-layer attacks  Crash a service and are measured in requests per second (Rps)

Various open-source tools are available to execute DoS attacks in all three categories. Hping (hping3) (http://www.hping.org) is a TCP/IP packet assembler/analyzer installed in Kali Linux that can be used to conduct DoS attacks against TCP, UDP, ICMP, and RAW-IP protocols. Figure 3-10 shows an example of using hping3 to flood a target using a random-source IP address with ICMP echo requests. The result of the flood attack is an increase in the ICMP reply response time (measured in milliseconds, or ms) from the target.



Figure:   An ICMP flood in hping3

The status of the ping command shows typical response times from sequence 1 to 6. Then sequence 7 to 14 shows the response time after the ICMP flood was initiated. If we were to conduct the same hping3 scan across thousands of IP addresses, using a botnet, the results could be catastrophic for the target host.

Note: : A botnet is made up of many Internet-connected computing devices that are used in conjunction to carry out coordinated tasks, such as DoS attacks.

Network Packet Manipulation
During an engagement, a pentester may identify targets protected by a firewall or network access controls that restrict access to authorized devices on the network. An Nmap port scan may show a host as down or all of the ports as “filtered,” which limits the pentester’s ability to troubleshoot why the connection attempts are not working. Analyzing and inspecting packets over the network can help provide some insight as to what is actually going on with the connection attempts.

Analyzing and Inspecting Packets
Wireshark and tcpdump are two tools already installed in Kali that can help a pentester analyze and inspect network packets.

The figure below shows an Nmap scan of the top TCP 1,000 ports and only 4 ports open, with 996 filtered and 10 marked as host-prohibited.



Figure:   Nmap TCP scan of top 1,000 ports

So, what does host-prohibited mean? If we run the same port scan and capture the traffic using tcpdump and save the results to a file in pcap format, you can then load the pcap file into Wireshark for analysis.

When you find a TCP port is open and reachable over the network, you will get a [SYN, ACK] back from the target. If the port is filtered, you may see a solicited response from the target such as “Destination unreachable (Host administratively prohibited).” This response is configured in the firewall rules to inform the connecting host that it is not authorized to communicate over this port. For instance, in the iptables firewall chain policy of a Linux host, the firewall could have a REJECT statement that responds to all requests not covered in the policy with an icmp-host-prohibited message, as shown here:

These types of messages are transmitted using ICMP. If we filter the packets in Wireshark using the filter “icmp,” as shown below, we can view the ICMP responses received from the target.



Figure:   Analyzing ICMP host-prohibited messages in Wireshark

If we look into the fourth layer of the packet “Internet Control Message Protocol,” we see the ICMP Type is “3” (Destination unreachable) and the code is “10” (Host administratively prohibited) for the SMTP port 25/tcp. The ICMP parameters (e.g., types and codes) can be found on the IANA website at https://www.iana.org; click on Protocol Assignments. Some firewalls are configured to just filter the packet and not respond at all. Analyzing and inspecting packets will help troubleshoot connection failures during a pentest engagement.

Forge and Decode Packets
In some cases, you may find a port is filtered or restricted to only authorized hosts on the network, and you may need to spoof the source IP address of an authorized host. Scapy (https://scapy.net) is a Python program that can assist with packet manipulation by forging and decoding packets. Scapy supports many use cases; however, for this section we will focus on its ability to assist with spoofing legitimate hosts on the network. Take the use case of log injection (CAPEC-93: Log Injection-Tampering-Forging). The objective for this type of an attack is to mislead an audit or cover traces of an attack.

Log injection can also expose other types of vulnerabilities, such as local file inclusion (LFI), cross-site scripting (XSS), cross-site request forgery (CSRF), or even remote code execution, when malicious log entries are not validated and processed in web-based log management systems.

Note: : This tactic is really only good for “spray and pray” exploits. For example, if you spoof your IP from outside a target’s network in an effort to bypass a firewall filter, you’re not going to get back the responses.

Let’s take a log management server such as Nagios (https://www.nagios.org), listening on port 5544/udp for Syslog data from only authorized hosts on the network. Syslog messages sent via UDP are not validated and can easily be spoofed over the network. Some legacy operating systems and devices do not support TCP-based logging, which would make spoofing log messages from legitimate hosts more difficult, as you would need to be able to spoof the TCP sequence numbers, which are exchanged between hosts while communicating over the network. Using Scapy, we can create a Python script to spoof a legitimate host on the network, like the gateway, and send a Syslog-like message to the logging server to invalidate the integrity of a customer’s auditing capability.

The Python code shown below will generate a spoofed Syslog request from the gateway (srcIP) and send a message (msg) to the central logging server’s (dstIP) designated port for processing Syslog messages (dstPort). The spoofed_syslog variable defines the payload and protocol to use for transferring the message (UDP). The send() function tells Scapy to send the packet, using the information defined in the payload.



Figure:   Using Scapy to spoof Syslog traffic

Tip: The Scapy documentation located at https://scapy.readthedocs.io is a good reference for learning how to use the interactive Scapy shell, how to use the built-in functions, and even how to build or extend upon your own suite of tools.

When the Python script is executed, the message will be sent to the Syslog server for processing. The Nagios Syslog listener processes the message as Syslog-formatted data, parses the contents, and stores the record in the index.

The figure below shows the malicious message we crafted using Scapy in the Nagios log management interface.



Figure:   Malicious log entry in Nagios

Note: Syslog is a protocol that is used to define a standard for how operating systems, processes, and applications generate messages. RFC 5424 (https://tools.ietf.org/html/rfc5424) outlines the requirements for implementing Syslog and how the messages should be formatted.

Layer 2 Attacks
As we have learned so far, there are many nefarious things a pentester can do to attack network protocols and authentication schemes (i.e., ARP spoofing and name resolution) that can aid in successfully exploiting specific attack scenarios. CompTIA covers a few specific layer 2 attacks in the PenTest+ exam objectives. In this section, we will cover those exam objectives in greater detail and discuss how a pentester may leverage these attacks within their customer networks during an engagement.

Attacking the Spanning Tree Protocol
In switched networks, when two network segments are connected by more than two layer 2 switches, this creates a physical loop in the topology. Interconnecting the switches with redundant links helped improve availability in the network should one of the other links fail. However, this design has inherent side effects, as it creates transmission loops on the network.

The Spanning Tree Protocol (STP) is a layer 2 protocol that runs on network devices such as bridges and switches. The primary function of STP is to prevent looping in networks that have redundant paths by placing only one switch port in forwarding mode, and all other ports connected to the same network segment are configured in blocking mode.

The table below shows the three different forms of STP.



Table:   Spanning Tree Protocols

STP helps monitor the topology of the network and optimize a standard communication path for transmitting Ethernet frames, thus removing redundant links and setting up a preferred link between the switches. The preferred link, which is the link with the highest bandwidth, is used until the link fails, at which point a nonpreferred link will be used to carry the traffic. This process is made possible through the root bridge. The root bridge is a reference point for all switches in a spanning tree topology. Switches in the topology will hold a root bridge election process, where the switch with the lowest Bridge ID is elected as the root bridge. The Bridge ID is generated on each switch using a priority number and the switch’s MAC address. Each switch is configured with a default bridge priority ID (most switches default to a priority ID of 32768), and the value that is configured must be a multiple of 4096. During the election process, the priority ID is compared to the other switches. If a switch on the network has the same priority number as another switch, then the MAC address is compared. The switch with the lowest Bridge ID priority or MAC address will be the designated root priority.

In a switched network, Ethernet frames have no TTL value and are broadcast to all ports on a switch, with the exception of the sending port.

Layer 2 switches are designed to flood frames when they don’t find the frame’s destination MAC address in the MAC address table. By eliminating redundant paths, STP helps prevent broadcast storms caused by loops in the network, where a broadcast frame is bounced back and forth between switches due to redundant paths. A broadcast storm could cause entire segments of the local network to become unavailable should one of the redundant links fail. Eliminating the redundant loops can also help prevent MAC address table thrashing, which is caused by two different ports on a switch broadcasting the same source MAC address.

Most newer devices run RSTP, as it has many advantages over the legacy STP. You can use Wireshark to capture STP packets on the LAN. Wireshark will provide you with the version of the STP type (STP, RSTP, or MST) by inspecting the Bridge Protocol Data Units (BPDUs), which are the update frames that are multicast between switches over the network every so often to determine if a port is in a forwarding or blocking state (prevents looping) and to determine the root bridge during the election process. The root bridge election process must be repeated when or if there is a fault in the network. For STP, protocol version ID equals “0” and version ID “3” equals RSTP/MST. So STP is good for LANs, but how do you test it?

The biggest threat to STP is a DoS attack. STP does not use an authentication process to determine the root bridge; thus, an attacker can craft malicious BPDUs of a nonexistent switch to elect it as the new root bridge. Repeating this step over and over again will cause the LAN to be in a constant election process, saturating the network with Ethernet frames and causing a broadcast storm. Proof-of-concept code and an additional demonstration can be found at www.tomicki.net/attacking.stp.php.

VLAN Hopping
Virtual local area networks (VLANs) are broadcast domains used to provide logical separation on the same physical network segment. A VLAN is referenced under IEEE 802.1Q. A network switch groups ports together into a VLAN group and uses a VLAN ID to identify the VLAN. On a switch, a port can either be an access port or a trunk port. A trunk port is designated on a switch to carry VLAN-tagged traffic between switches. An access port sends and receives untagged traffic and is assigned to a single VLAN (access ports are typically for a host-to-switch connection). VLAN tags restrict access to tagged traffic to only ports designated to a particular VLAN group. VLAN hopping is an attack vector used to gain access to resources on another VLAN. Two methods are used to accomplish VLAN hopping: switch spoofing and double tagging.
 

Switch spoofing is a type of VLAN hopping attack that occurs when an attacker can emulate a valid trunking switch on the network by speaking 802.1Q. This is a result of either a default configuration or an improperly configured switch. The default mode assigned to ports on a Cisco switch is configured as “dynamic desirable,” which means that the switch will negotiate the port mode as either an access port or trunk port. Once the attacker announces that his workstation is a trunk port, the switch will trunk all VLANs over the switch port that the attacker’s workstation is plugged into. The attacker will now have access to all VLAN traffic destined for the valid switch. This can be mitigated by preventing ports on the switch from negotiating trunks and configuring the ports to be access ports. Double tagging is a result of a switch port being configured to use native VLANs, where an attacker can craft a packet and prepend a false VLAN tag along with its native VLAN. The native VLAN tag (i.e., VLAN 1) is not forwarded (since it is the native VLAN), but the false VLAN tag is forwarded to the next switch and sent to the target host as if it originated from the target’s native VLAN.

This type of attack can be used to bypass layer 3 access controls, where only certain hosts on the local network can access sensitive/secure resources. This is another type of configuration weakness on switches and can be mitigated by not associating any hosts in the native VLAN or by disabling the native VLAN on all trunk ports.

Bypassing Network Access Controls
Organizations may use Network Access Control (NAC) either in hardware or software to quarantine rogue devices that are not identified in a network security policy, provide a BYOD (bring your own device) model that can also support guest network access and isolation for vendors or customers, or profile users and devices to mitigate network threats. In cloud-based environments like Microsoft Azure, a customer can use

Network Security Groups (NSG) to enforce and control Internet or intranet communications across different workloads within virtual networks. As an example, a DHCP-based NAC solution uses a proxy server to intercept and validate DHCP requests from the client. If the client is authorized according to a list of MACs or a set of other criteria identified by a profiling process, the client is assigned an IP address and connected to the network. In essence, an NAC is an enforceable security boundary that provides another layer of protection to the overall security stack.

There are three methods a pentester can use to bypass NAC:
- Violating trust relationships  An example would be spoofing a source IP or MAC address of a valid device (e.g., legacy printer) controlled in a distinct NSG that doesn’t support 802.1x authentication. You can do this with the macchanger application in Kali Linux, for example:



- Exploiting implementation weaknesses  This includes weak authentication mechanisms in wireless protocols or even DHCP-based NAC solutions, where the attacker can possibly bypass the NAC protection altogether by assigning a static IP address on the network instead of trying to get one through DHCP.
- Taking advantage of configuration weaknesses  An example would be if NAC enforces policy on IPv4 addresses but is not configured to protect IPv6 addresses.

Researching an Attack
You’ll need to take what you see on the network and turn it into usable intelligence to attack. Let’s follow two examples, one using FTP and another using SMB and NFS.

An Attack on FTP
Many applications make use of File Transfer Protocol (FTP) for transferring files to and from hosts over the network. The FTP server provides read/write access to files and directories for remote users and inherited authentication and file sharing permissions from the local operating system. To detect the presence of anonymous FTP, a pentester can use the ftp-anon.nse script, as shown below.



Figure:   Identifying FTP servers that allow anonymous login with Nmap

Tip: The Metasploit auxiliary module called ftp_login is another useful way of detecting anonymous FTP servers on the network.
Using the example provided in Figure 3-18, the ftp-syst.nse script was able to detect the version of FTP running on the server to be vsFTPd 2.3.4. In Kali, you can use the Exploit-DB (https://www.exploit-db.com) command-line interface (CLI) search tool called searchsploit to look for known exploits. The result of running the CLI search tool shows that the version of vsFTPd running on the server is susceptible to backdoor remote code execution vulnerability, as shown below.



Figure:   Searchsploit vsFTPd

The unix/ftp/vsftpd_234_backdoor Metasploit module can be used to exploit the vulnerable service and obtain root access to the device, as shown in Figure 3-17. Many other types of vulnerabilities plague FTP applications other than backdoors, including directory traversals, DoS attacks, buffer overflow attacks, local and remote file inclusion (LFI/RFI) attacks, and authentication bypass attacks, to name a few. FTP has been around for many years and will likely stick around for some time until organizations phase out legacy devices with modern-day technology.



Figure:   vsFTPd backdoor command execution in Metasploit

An Attack on Samba and NFS
In heterogeneous environments, it may be necessary for Windows, UNIX, and macOS users to share files and collaborate among each other. Samba is the implementation of the Common Internet File System (CIFS) protocol that enables file and print sharing among Windows and UNIX hosts over the network. Linux/UNIX servers use Samba to communicate with Windows clients to support their file and print sharing needs.
Certain releases of Samba contain a vulnerability in the LSA RPC service that, if exploited, can trigger a heap overflow and allow an unprivileged user to execute arbitrary code on the system as the root user. The Metasploit module Samba SetInformationPolicy AuditEventsInfo Heap Overflow is an example that will attempt to exploit this.

Caution: You can look at the full source of this module in the Metasploit GitHub: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/samba/setinfopolicy_heap.rb. The module will run for some time and may take a while to complete. The Metasploit module does allow you to define your start and stop addresses in case your operating system is not defined within the module.
NFS is another file sharing capability that provides a means for privileged execution. To see a list of file systems shared out to the UNIX environment, you can use the showmount -e command or you can use nmap, specifying port 111/tcp (RPC port) and using the nfs-showmount.nse script, as shown below. The RPC port specifies the versions of NFS that are supported by the server (i.e., v2, v3, and v4), as well as the NFS port 2049/tcp or 2049/udp and the mount ports.



Figure:   Using the NFS showmount script in nmap

Note: : The rpcinfo output can be quite important, especially when mounting an NFS open share through an SSH tunnel or proxy when file systems are only shared within the local area network. Typically, NFS will make the RPC call to the server and acquire the appropriate ports to mount the remote file system; this all happens behind the scenes during the connection. When you establish the reverse tunnel with your external target, you will need to specify the mount port within the mount option in your command syntax when mounting through the tunnel.

Once your tunnel is configured to forward all mount traffic to the SSH target, you can mount the file system using the forwarded mount ports (e.g., mount -o port=2049,mountport=44096,proto=tcp 127.0.0.1:/home /home).

During a pentest engagement, you may come across NFS file systems that are shared out to everyone on the network and have little to no protection against remote attacks. In this section, we will provide some examples of how to exploit NFS file systems that are exported with root access and leverage those permissions to escalate privileges against an NFS client.

To follow along, you can assume we have the following level of access on the network:
- Root-level access to an attack laptop on the internal network
- NFS server that shares out a file system to everyone (no access controls)
- Compromised user-level access to an NFS client on the network

Using the information provided below, we can see that the /home file system is shared out to “everyone.” Next, we can mount the /home file system using the mount command and mount it to an unused directory on our local file system, as illustrated below. In order to mount file systems in UNIX, you must be a privileged user (i.e., root). Now, in the home directory, there are four potential user accounts. The question is: Did we mount the file system with root privileges? In Figure 3-20, we created a file called “am-i-root” and listed the directory contents and see that we created the file as UID “0.”



Figure:   Mounting the /home file system and verifying file system privileges



Figure:   Setuid nmap executable

Tip: NFSv3 and earlier will map numeric UIDs and GIDs to files and directories on an NFS file system. When you mount an NFS share from a client using NFSv3, you may see a UID or GID in place of a username or group because your local operating system cannot map to them, either because you are not on the domain (i.e., LDAP) or the user does not exist. During an engagement, if you are able to mount an NFS file system and you see UID values instead of usernames, you can create a user account on your local host with the same UID value and navigate around the file system impersonating the victim username. In NFSv4, the UID and GUID mapping feature can be disabled, since the client and server can now be configured to exchange user and group names over the network.

From our testing laptop, we can now conceivably modify arbitrary files and move tools to anywhere we wish on the remote file system as root. Using user-level access on the NFS client, we copy over a binary so we can change the ownership of the program to root and apply the setuid bit from the attacker laptop, so when the program executes, it runs with root privileges (owner of the file). We choose to use the nmap binary, as the version on the NFS client still supports the interactive feature that will allow us to bypass the Bash and Bourne Shell setuid shell program restrictions. After we copied the nmap binary into the user’s home directory on the NFS share, from our attack laptop we changed the ownership of nmap to be root:root, then used the chmod command to apply the sticky bit with 4777, as shown below.

Then from the NFS client as the user account, we executed the setuid nmap binary using interactive mode, which allows you to interact with the shell from within Nmap. From the Nmap prompt, we executed !/bin/sh to drop to a shell prompt with root privileges, as shown below, under the effective user id (EUID) value, then read the /etc/shadow file for good measure. Imagine if the user were an LDAP user account with remote login access to all of the LDAP clients on the network and the /home file system were mounted on each host. The impact of the vulnerability would be even more significant, as the user could conceivably obtain root privileges on every host on the network.



Figure:   Nmap interactive mode

The attack laptop provided the ability to change the owner and execution bit of the nmap binary to root. Without root access to an attack platform that could mount the NFS /home file system, this attack would not have been possible. Some NFS file systems are exported with nosuid, root squash, or restricted root access to only certain hosts, as these are recommended best practices for NFS and mitigations to defeat these types of privilege escalation attacks. Essentially, this can take away the ability to execute setuid programs and force NFS to map the root UID to user nfsnobody. However, as we mentioned previously, you may still be able to create local accounts on the attack laptop (where you have root privileges) with UIDs that the NFS server knows about and impersonate the user in order to access directories and files from the NFS file system.

Tip: Instead of exploiting the interactive feature of Nmap, you could use some shell escape techniques to bypass the shell setuid program restrictions. A few of them consist of using built-in programs like vi or awk. From the NFS client, you would copy the program from your file path over to the NFS file share. Then from the attack laptop, apply root ownership and the setuid bit. Then you should be able to execute the programs with root privileges.




 

Review
Network-based attacks such as name resolution exploits can help aid a pentester with conducting on-path attacks against organizational assets. 
These types of attacks aid the pentester once a presence within the local network has been established. 
This process usually entails spoofing legitimate hosts listed on the network.
Exploiting exposed file shares on the network is a method for escalating privileges from either anonymous access on the network or basic user access on the target host. 
These techniques provide the ability to test inconsistencies in network configurations and protocol weaknesses that lie behind the external firewalls of the organization.