CompTIA Pentest+ PT0-002 – Section 10: Network Attacks Part 1

84. Network Attacks (OBJ 3.1)

In this section of the course, we’re going to discuss network attacks. As we move into this section, we’re going to continue our exploration of various attacks and exploits that we can use during the third stage of our engagement. As we move through this section, we’re going to be focused on all of the different types of attacks and exploits that we can conduct against the different networking technologies at different layers of the OSI model. This section of the course will contain everything you need to know about network attack vectors and exploits to fully cover objective 3.1 for the exam.

This objective states given a scenario, you must research attack vectors and perform network attacks. Network attacks are critical to understand because so much of our enterprise data is set and received over a network connection as opposed to traditional media sources, like external hard drives, CDs, DVDs and USB drives. In fact, with cloud storage and storage area networks, most of the data that we touch on a daily basis actually transits the network at some point. So in this section, we’re going to fully discuss network attacks. First, we’re going to discuss a special type of test that you may conduct in your engagements. This is known as a stress test.

While stress testing isn’t considered an attack per se, if you do it wrong, it can cause a denial of service condition against the target server or network. So it’s going to be covered in this section of the course. Next, we’re going to discuss exploit resources, things like the Exploit Database and Packet Storm, which can be used to find the code for known exploits that you can utilize during your network attacks. Then we’re going to cover the concepts of ARP poisoning, DNS cache poisoning, and LLMNR and NBT-NS poisoning. After that, we’re going to move into MAC spoofing, VLAN hopping and network access control bypass. Next, we’ll cover the concept of an on-path attack and how to perform one on a network.

And finally, we’re going to move into password attacks, including dictionary attacks, brute force attacks, hash cracking and password spraying. Remember, local area networks are inherently less secure than a wide area network since they’re considered part of the enterprise’s trusted zone. So if you can gain access to their local area network, these attacks that we’re going to cover are going to become even easier to perform. That said, you can also perform many of these attacks remotely as well if you gain an initial foothold into that network and then use that victim as a pivot point to launch other attacks against the network. All right, let’s continue our coverage of domain three, attacks and exploits with network attacks in this section of the course.

85. Stress Testing (OBJ 3.1)

In general, you’re not going to be conducting a denial-of-service or distributed denial-of-service attack against your target during a penetration test or engagement. The one exception to this rule is when the engagement specifically includes stress testing as part of the assessment. Now, stress testing is a software testing method that evaluates how software performs under extreme load. And this can also be applied to different systems and web servers as well. Now, that extreme load can actually come as a lot of different things. It might be extreme processor load, extreme memory load, extreme network load. It’s really up to you and what you’re trying to stress inside of that stress test. Because you’re attempting to determine the limits of what a given target can support, though, in terms of that load, of processors, memory, network, or storage, you can trigger a denial-of-service during your stress testing if you’re not careful. Now, for example, when I was setting up a new website for my company, we conducted a stress test by using a large number of bots that could access our site, access our course materials, and then start going through them as if they were actual students.

This let us identify how many users we could support before our servers would become overloaded and essentially crash. For example, if I set up my website on an inexpensive virtual private server, like a low level plan on Amazon Web Services Lightsail service, I could find that I might only be able to handle about 10 concurrent students before that server became overloaded by all the requests and essentially fell victim of a denial-of-service attack. Now, as I vertically scaled up that virtual private server from a $5 month plan to a $40 per month plan, I can then find out if I can handle maybe 100 concurrent students. The difference is that that $5 per month plan only includes a virtual server with one virtual CPU and one gigabyte of memory while the $40 per month plan allows for two virtual CPUs and eight gigabytes of memory. As the number of students rises, though, I’m going to be able to continue scaling vertically to larger and larger virtual servers with more processors and more memory to support more students. But eventually I’m going to hit that top tier plan they offer at around $160 per month that has eight virtual CPUs and 32 gigabytes of memory. At this point, I can’t vertically scale anymore and I would be at my upper limits.

Now, once I get to those upper limits, if I do a stress test there, I’m going to see the true limits for that particular website based on that vertical scaling. And when I’ve done this experiment, I saw that with our configuration, it was roughly 500 to 1,000 students accessing our courses at the same time. Now, for my business, that simply isn’t enough. So we had to redesign our entire website to be able to scale horizontally instead of vertically in response to this stress test. Now, this is much more complicated to do but it does provide us with essentially an unlimited capability to handle as many students as we need to by simply spinning up more virtual servers and balancing the load across all of those virtual servers.

This is why stress testing is so important though to your business, because it helps you to understand your limits, and if your architecture can support the expected business needs that you’re going to have. Now, to conduct stress testing, you can create scripts using Python or PowerShell to create a simulated load on a web server and then measure its responsiveness. You can also download open source tools like Grinder that are going to allow you to stress test both the usability and functionality of your websites. Alternatively, though, there are many software-as-a-service solutions out there online that you can use to conduct stress testing for your clients, including things like LoadView, LoadNinja, Loader, and many others that make running web application stress tests extremely simple to perform. Remember though, a stress test is very likely to cause a denial-of-service condition if you’re testing a server’s limits. And because of this, you should always ensure that your target organization is aware of if and when you’re going to be conducting your stress test so they can be prepared for any any negative side effects that could occur. Now, if you’re using a tool like Grinder, this is going to be run from a single machine, and is the equivalent of conducting a denial of service attack against a web application, since it’s coming from a single host.

Now, if you’re using one of the software-as-a-service tools online instead though, this is more like a distributed denial-of-service attack because they’re sending lots of requests from many different servers or bots to simulate hundreds or thousands of users who are trying to access that web application concurrently. Another great resource when you’re conducting a stress test is to create a sudden flood of traffic directed at a web server, a network device, or an end user client to see if it’s able to mitigate a denial-of-service attack. Now to do this, you’re going to want to launch a packet storm. Now a packet storm is also known by the name of broadcast storm or network storm, and it’s essentially any large increase in network traffic that’s directed at a given target. To create the traffic that’s going to become part of this packet storm, you can use any random data sequence. But many penetration testers like to use the Character Generator Protocol as part of their attack. This is commonly called the CHARGEN attack. Basically, the Character Generator Protocol is an older legacy protocol that was initially developed back in the TCP/IP protocol stack for use in testing, debugging, and measuring the network. CHARGEN is going to operate over either TCP or UDP using port 19.

And when the TCP connection is made, the server is simply going to send arbitrary characters to the host that’s going to be connected to it until that host terminates that connection. This can then be used to count how many characters were sent and in turn, how much data was actually sent and processed, because each character is eight bits in length. If you’re using CHARGEN over UDP, though, it’ll actually send a random number of characters every time it receives a datagram from the targeted host. Because the CHARGEN can send data forever from a given server, it is a great source of randomized traffic that you can use to send when you’re trying to flood a given target during a denial-of-service attack or for stress testing purposes. For a denial-of-service attack, for example, it’s going to be very common to use UDP when using CHARGEN, because this is going to send back 200 to 1,000 times as much data as it receives from the host. So as a penetration tester, you can send a request to a CHARGEN server while spoofing your source IP to that of your victim server. And then you can let the CHARGEN server flood that victim server with endless amounts of randomized ASCII characters to be able to determine how much stress that server can handle.

86. Exploit Resources (OBJ 3.1)

As you prepare to conduct your attacks you need to identify possible exploits then you can leverage against a target or victim. Backing your information gathering and vulnerability scanning phase, you should have identified potential victims that you can attack and some of their potential weaknesses. Now you need to take it a step further and identify the exact exploit that you want to use to take advantage of that weakness. Two great sources for this, are the Exploit Database and Packet Storm. Now the exploit database is a complete collection of public exploits and vulnerability software, that’s kept in a fully searchable database. This is hosted@exploit-db.com, where you can search based on the type of exploit, the platform affected by the exploit and the versions of software affected by those exploits. As of this recording, there are currently 44,899 total entries in this database. So let’s take a look at how you can use this in your engagements. For example, if I found a web server that was running PHP version 7.4 during my reconnaissance and fit fingerprinting, I could then search the exploit database for that version, to see what node exploits exist for it.

As of this recording there are currently 12 exploits available against PHP 7.4. Next I could select one that seems like a good candidate. For example, PHPLib less than 7.4-SQL Injection, is an exploit that’s listed here. When I select that it opens a page with a lot of information about this specific vulnerability and the exploit code that can be used to attack it. This particular vulnerability has been identified as CVE 2006-008 and CVE 2006-2826. And this applies to any PHP version that is 7.4 or older. Now this may sound really old because PHP 8 was released back in November of 2020 but I can tell you from experience PHP 7.4 is still considered usable and supported until November of 2022. So at the time of this recording many websites are still using PHP 7.4 because PHP 8 is not fully supported by all WordPress plugins yet. And this causes a lot of website developers to postpone updating to PHP 8 on their systems because WordPress runs about 40% of the internet. Now going back to the vulnerability, we can see that it’s a vulnerability that can be exploited and would give the attacker or penetration tester the ability to conduct an SQL Injection, and in the worst cases the ability to conduct remote code execution. Then the exploit database gives you the exact code that shows how this vulnerability was exploited and explains how it works.

Now I’m not going to go through this particular vulnerability and exploit here line by line and explain the code to you. The reason for this is that PHP is not one of the covered languages on the pen test plus exam. But if you’re looking for some good code examples to go through as you begin preparing for the scripting and coding part of the exam, which is covered by domain five the exploit database is a great resource for that. We’ll come back and look at other code samples later on when we get to domain five. Now the second exploit resource you should be aware of is known as Packet Storm. Now packet storm is a website that’s locate@packetstormsecurity.com. And it contains use articles advisories, white papers, tools and exploits that you can review and use in your penetration tests and engagements. These are listed in chronological order showing the most recent and up to date items at the top of the list. These feeds are also available using an RSS reader. So you can keep up to date with the latest exploits in the cyber security world using your RSS reader at any time. Now pack storm also does a great job of linking the exploits back to the CVE advisories. This way you can use those CVE numbers that you found during your vulnerability scans to identify tools and code that could be used to exploit them during your engagements. Often though, you’re not going to use just a single exploit to break into a system. In most cases, you’re going to need to use exploit chaining. Now exploit chaining combines multiple exploits to form a larger attack.

As network defenders have begun to create more complex systems of defenses by combining different layers to create a defense in depth, attackers and penetration testers, also need to identify exploits that it can work their way past each of those layers inside of that defense. And if we combine all these exploits together, we create what’s known as a chained exploit. Now for example, let’s say you need to get past the firewall, that might take one exploit. Then gaining access to the user system is a second exploit and then escalating privileges that will take you a third exploit. By putting these three exploits together we can chain our way through each layer of defense and ultimately break into that target system. Now when you use exploit chaining the attack can either be run simultaneously and parallel or they can be run sequentially one after the other. This really depends on the defenses you’re trying to bypass and the specific exploits that you’re going to be using. Now when you think about exploit chaining, I want you to remember that this is where we combine different things to create a holistic attack. And these don’t always have to be technical in nature either.

For example, let’s pretend that during an engagement I snuck past the security guards by using piggybacking. Then I use my lock picking set to open a door to a network communication’s closet. And then I pull out a wireless access point and connect it to the sperm port of that company’s edge switch creating a rogue wireless access point. Now that would be considered a chained exploit because I combined three different exploits or attacks to reach my final goal of connecting that rogue wireless access point to their edge switch, so I can have remote access wirelessly from their parking lot. Similarly, I might run an SQL Injection attack against an organization’s web application.

Then I can use that access to elevate my privileges and then upload a file that might contain a keylogger and install that on a domain controller. By combining all those multiple exploits into a chain exploit, I might be able to automate that entire process and do all of it with a simple script. And that script would be able to go through each layer of security and achieve my final goal of collecting any keystrokes that were entered on that domain controller. This is the way you could start automating some of your task as you start using different tools like Python and Powershell and multiple commands within them to chain your exploits.

• Category: Uncategorized