Advanced Approach to Wireless Penetration Testing

Wireless Penetration Testing - Advanced Techniques

Welcome to Pluralsight, my name is Ricardo, and if you're looking to expand your wireless penetration testing skills, you're in the right place. In this course, you'll be learning the same techniques attackers use to target their victims. We'll be discussing a measure of technical attacks, and social engineering techniques that are usually used by malicious hackers. This is a hands-on course, so I do recommend you to follow our demos and try to reproduce our test in your own test environment. you may be used to the regular wireless penetration testing, in which we only test for technical vulnerabilities, such as the use of a WEP protocol, or any other insecure configuration. The reality is that attackers are now focusing not only the technical vulnerabilities but also on human mistakes. Usually, in big corporations, their technology is up to date, and the environment is fairly patched, making it hard to compromise the network with conventional attacks. The solution for that? Attacking the weakest link, which is the user. You can have the strongest wireless protocol enabled, but if an employee connects to a rogue access point and types their password, your strong parameter will be useless. The idea of this course is to perform tests as if we were real attackers, using other available techniques to get our way into the network, even if you need to play with the users. As you may have noticed, this course is a continuation of a course called Wireless Network Penetration Testing, here on Pluralsight. If you don't have too much experience in wireless penetration testing, or if you haven't watched this previous course, I do recommend you check it out before jumping to this advanced course. In this previous course, we cover some basic concepts, such as network cards, antennae, monitor mode, and the wireless penetration test process, also information gathering in terms of wireless mapping, hidden networks, and rogue access points. Also, exploitation in terms of open networks, WEP protocol, WEP exploitation, WPS, and also a little bit of our reporting. So again, if you're not familiar with some of those concepts, I do recommend you check the first course so we can all be on the same page. So now let's take a look at what we'll be covering in this course. This course is divided into five modules, in the first one we'll be covering some concepts of red teaming. If that's a new word for you, don't worry, I'll be explaining what's the difference between a regular pen test, and a red teaming assessment. In the second module, we will be covering the test preparation phase, or in other words, what we should do before starting a test. Being prepared for your assessment and understanding the target before performing any attack is key to success. In the third module, we'll be covering non-disruptive attacks. Those attacks usually do not cause disruptions to the existing wireless connection. As an example, we will be learning how to set up a rogue access point, and how to create a fake captive portal so we can lure users into typing their passwords. In the fourth module, we'll be covering disruptive attacks, which in a position a previous module may cause disruptions on existing wireless connections. For example, in this section, we will learn how to perform some denial of service attacks in wireless networks. In the last module, we'll be learning some techniques used to cover your traces. It is important to understand what attackers do to stay stealthy, so you can perform attacks exactly in the same way malicious attackers would do. So for this course, you need three things, the first one is a Kali Linux VM. In theory, you can use the Linux 3 version you want, I like to use Kali Linux because it's open source, and it already has all the tools that we need for this course. The second thing you need is knowledge of Linux and wireless networks. Remember, that it's an advanced course, so if you're not familiar with the Linux command line interface, it may be a good idea to review some Linux and wireless concepts. Pluralsight has a very good course about Kali Linux, in it, you can also learn the main wireless penetration test techniques in the previous course that I mentioned a few minutes ago. The last thing you need is a compatible network card. By compatible I mean a network card that supports monitor mode and packet injection. We'll be discussing in the second module of this course, some of the models that we can use.

Red Teaming Concepts

You may be familiar with typical penetration testing, but there is a difference between a pen test and a red teaming assessment. In this section, we will learn what are the main differences between regular penetration testing, and a red teaming penetration test. So, let's start with a simple comparison. On the left side, we have the penetration testing to which we are used. This focuses on our technical vulnerabilities, for example, attacking a WEP protocol vulnerability. It also usually uses non-disruptive techniques, meaning that we try as much as we can to not bother users, and not interfere with their wireless usage. The goal of penetration testing is to identify technological vulnerabilities, and you need to report technical findings and fix their accommodations. On the other hand, we have the red teaming exercise, which is focused on the technical and social engineering techniques, meaning that it will be trying to exploit not only the technology but also exploit people by using wireless techniques in social engineering attacks. Those attacks can be disruptive, and the main goal is getting into the network and measuring the impact a real hacker could cause on the environment. So you may be wondering, why are you using social engineering techniques in wireless penetration testing? The reason is simple, hackers always go for the low-hanging fruit, meaning that if a wireless network is well protected, an attacker wouldn't spend days trying to crack the password if he or she can simply start a rogue access point and hope a user connects to it to collect the passwords. It's also important to notice that technology vulnerabilities are usually easily patched, but people cannot be patched. The only way that a company can become more secure in this case is by having a proper security awareness program. Even like this, almost always there will be one careless user that will be lured. In a red teaming exercise, we'll use all the techniques we learned in the first course of this series, which are analytical attacks on WEP networks. In addition to some more advanced techniques, such as eavesdropping, rogue access points, fake captive portals, man-in-the-middle attacks, and denial of service attacks. Of those attacks that we'll cover in this course, the green ones are usually non-disruptive attacks, while the red ones can cause disruption in existing connections. The red teaming exercise follows the same process as wireless penetration testing. We start with the initiation phase, where we define the scope with the client, and get a form authorization to start the test. And we move to the information gathering phase, where we discover all the targets of the client, being the targets of both wireless networks and human targets. In the third step, we will identify which vulnerabilities we could use against our targets. We can exploit them in the fourth phase of the process. As the last step, we'll get all the issues we found and put them in a report that'll be presented to the client. As I mentioned, those steps are the same as regular wireless penetration testing, the only difference is that I'll be incorporating some advanced techniques into it. So if you're excited about the advanced techniques, and the red team exercise, stay tuned for our next module in which we'll be learning how to prepare ourselves for a red teaming exercise. You will learn how to identify targets to be exploited, and it may surprise you that now the targets are not on only wireless networks, but also human targets that we can try to exploit with advanced wireless penetration techniques. I hope you are ready, I'll see you there.

Preparing for the Tests

Importance of Preparation

Being prepared before starting any test we'll be put a huge advantage. Knowing your targets will help you to plan the attacks, increasing your chance of success. Having a plan before starting any exploitation is what differentiates a mature pen tester from a professional pen tester. Information gathering and creating an attack strategy are keys to the success of a red teaming exercise. Remember, we are trying to exploit not only the technologies, but also the people that work in the company, so we need to understand both protocols, and also employees. In this module, we'll be covering the preparations for our tests. In the first section, we will learn about the pre-engagement phase, where we define the scope, define the attacks, and understand the targets. In the second section of this module, we will dive into the preparation for the test, including mapping of the targets, and necessary gear for the tests, such as network cards, and antennas.

Pre-engagement Phase

The pre-engagement phase is where we discuss with the client the scope of the tests and agree on timelines. It is important to make clear to the client the potential impacts of the test and to get formal approval for any tests you'll be performing. The pre-engagement phase has five main goals, the first one we already talked about, is to define a scope. We'll be talking about the scope in the next slides, but basically, you want to define what and who will be tested in this engagement. The second phase is related to collecting environmental information. In most cases, the client provides you with the least wireless networks that can be in scope and the least of users that can be targeted. But in any case, I do recommend you you're running your own reconnaissance techniques, because in some cases, system administrators may not be aware of some wireless networks in their environment. The third phase is scheduling the tests. As the name says, you schedule a date for the test to be performed on the client. The fourth phase is to communicate to the stakeholders, which means informing all the affected parties about the upcoming tests. As a red teaming exercise includes testing human behavior, I recommend informing only the very necessary people inside of the client. For example, inform only the CIO and one system administrator. That's because if everyone knows that a test will be performed, people will be extra careful on the days of the tests. We want people to be tested on a normal day. The last phase is probably the most important one, which is getting the client formal sign-off. The difference between a criminal and a professional pen tester is this document, so make sure you have it signed before starting any test. To define the scope, we need to ask the client which areas of the company they want to be tested, which users can we target, how many days we can perform the test, and the kind of attacks that we'll be performing. Some of the clients may not be willing to have their wireless networks disrupted, so make sure you explain the impact of each attack, so the network administrator will not be surprised to say their wireless network is unstable. As you can imagine, it is important to have the scope well defined, to ensure you'll not be impacting any critical area of the company without any authorization. As I mentioned in a previous slide, it is important to agree with the client on which test will be performed. On the left side of this slide, we have the non-disruptive attacks, which you usually do not interfere with the existing wireless connections. Those attacks may lure users in to connect to the malicious wireless networks, but users already connected to the other wireless network will not be impacted. On the right side, we have disruptive attacks, which may lead to disruptions of the service. In such attacks, the target users, even if already connected to the wireless network, may experience slowness, and even faults, so make sure your clients are on board with this concept. Understandably, a client may not be willing to perform disruptive tests, but remember, an attacker will not have mercy with their wireless network, so it is important to perform the attacks exactly in the same way a hacker will do, so we can measure the extent of the impact. Another very important concept to understand in the red team exercise is the concept of targets. In normal penetration testing, we're used to the technology targets, such as wireless protocols, and encryption methods. Those targets are also important to the red teaming pen test, meaning that we need to identify the wireless networks, identify the technologies, and create a map of wireless networks. But as this course is about advanced penetration testing, we also cover social engineering attacks, meaning that we also need to understand the people that are working in the company. For example, we need to identify the key employees, and the shift hours, and even create a map of the departments. In the next section, we'll take a look at how to map those targets, and how to use those maps to improve our chances of success.

Preparing for the Test and Target Mapping

Understanding I have information about your targets will increase your chance of success. You also need to have the proper gear to perform the tests. In this section, we will take a look at target mapping strategies, and also which network cards and antennas can be used during your tests. So let's discuss the network cards that can be used for the test. The most important thing is that your network card supports packet injection and monitoring mode. There are several compatible models on the market, and here's a list of a few of them. I personally use the first one, the TP-LINK one, which is not expensive, and it can be easily found on Amazon, or in your local computer store. But feel free to use any network card that has the monitoring mode and the packet injection features. If you Google network cards that support monitoring mode, you find a long list of models, maybe even your laptop network card already supports it. Usually, when performing a network penetration test, you'll be inside the client's office, so the antenna that comes with your network card should be enough for the test, but if you want to get a professional and increase the range of your pen test, you can buy an external antenna. For example, if you want to conduct the pen test from the parking lot of your company, you may be considering buying an external antenna. Antennas are basically divided into three categories, the omnidirectional ones, meaning the antenna will capture and send traffic in all directions, the directional ones, where the antenna will be sending and receiving in one direction, and the highly directional, also called Yagi, which is very directional, basically if you want to create a wireless network in a straight line, point to point. As I mentioned, for most engagements, you probably do not need to buy an external antenna, but it's good to know the kinds of antenna you can buy if you need it one day. As I mentioned in the previous section, our target is not only the technology targets but also the human targets. For this reason, we need to map both kinds of targets. The wireless mapping can be done simply by walking around the building with your airodump tool and observing the wireless networks that show up. We covered this in the previous wireless penetration test course. If you have the budget, you can also use some proprietary software, such as Heatmapper, in which you can upload the floorplan, and go for a walk around the building. This software will detect the wireless and map the access points on your floor plan based on the sign of strength. We also need to map the human targets, and a good way for this is to map the departments across the building. A good practice is to ask the client where the departments are located, and who are the key employees. Or you can also simply walk around the building and try to identify which departments are in each region of the building. So let's take a look at some examples of target mapping. Here we have a wireless mapping. As you can see, we are using the floor plan as a base and using the wireless coverage as layers on the map. This can be very useful. Think about this scenario. I want to create a fake Wi-Fi to mimic the guest Wi-Fi. Where should I put it? Most likely, I would put it in the green area of this map since there is already guest Wi-Fi in this region. And here's an example of department mapping in which I'm using the floorplan and the information provided by the client to map where the departments are in the company. You may be wondering, why is that so important? So think about this scenario. I want to create a rogue access point that will have a fake captive portal in which users will be asked to type their credentials. In which area of the building would you create this rogue access point? Think about it. In my personal opinion, the chance of a known IT person getting lured into this type of attack is higher, so I would place my rogue access point in the top-left corner, close to the HR department, and the finance department. If I place it close to the IT department, the chance of getting caught is way higher. So to summarize this module, we discussed the importance of being prepared for an engagement- having a test planned with all the information we need is crucial for successful penetration testing. We also discussed the pre-engagement phase, and the scope definition, in which you make sure the client's happy with the tests, and define if disruptive tests will be included. We also discussed the importance of understanding the targets. Remember, now we are not only testing the technology, but also people, and to better understand our targets, we reviewed some target mapping techniques, and how to identify potential targets for the attacks that we'll be learning in the next module. So now that you know the pre-engagement steps, and how to prepare for advanced penetration testing, it is time to learn about advanced attack techniques. In the next module, we start the hands-on parts of this course, and I'm sure you will love it. We will cover the non-disruptive attacks, such as eavesdropping, and the creation of rogue access points. I'll see you there.

Advanced Penetration Testing Techniques – Non-disruptive Attacks

Non-disruptive Techniques

In this module will you be learning the non-disruptive attacks of this course? By non-disruptive, I mean attacks that do not affect users that are already connected to your company network. The test may lure users to connect to different networks, but it will not cause a denial of services in existing wireless connections. The attacks covered in this module are eavesdropping, which is listening to the traffic and trying to capture sensitive information, such as passwords or cookies, rogue access points, or also known as fake Wi-Fi which you will try to lure users to connect to, and fake captive portals, in which we will try to lure users to type their passwords.

Eavesdropping

Eavesdropping consists of trying to listen to the traffic to capture sensitive information. In some cases, we may not even need to connect to a network to be able to listen to the traffic, thanks to our network card that supports monitoring mode. The previous wireless penetration test course here on Pluralsight covers some eavesdropping techniques, but in this course, we will cover some additional techniques, such as decrypting packets included with WEP or WPA, and a license to traffic with Wireshark. But first, let's understand what is eavesdropping. As I mentioned before, the objective of eavesdropping is listening to the traffic to capture any data that could be used in an attack, such as passwords, confidential information, or even authentication cookies that can be used in the replay attack. As we don't need to be connected to the network to eavesdrop on the traffic, it is virtually impossible to detect if someone is eavesdropping on the packets, and that's scary, right? So several tools can be used to eavesdrop on a wireless network, but I would like to show you my four favorite ones. The first one is the Airman and the Airodump tools, which probably you're already familiar with. Those tools can be used to leaf through the traffic, and if you wish, even save the capture in a file to be analyzed later. The second one is Kismet, which is a very popular packet capture and sniffing tool, and it has a common line interface, and a user interfaces as well. It is an alternative to Airman and Airodump tools. The third tool is the Airdecap, which is also part of the Aircrack suite. The Airdecap tool can be used to decrypt network-captured files encrypted with WEP or WPA. For example, let's say you capture traffic of a WPA2 network using the Airodump tool, and saved it in a file. If the network was encrypted using WPA2, the file would contain encrypted packets. If you know the WPA2 password, you can use the Airdecap tool to decrypt the packets, resulting in a clear PCAP file, which can be easily analyzed by Wireshark, or any other network analysis tool. And the last tool is probably my favorite one, which is the Wireshark. Wireshark is a very complete traffic analysis tool. It can also be used to capture traffic, but I personally like to use the Airodump for packet capture, and then analyze with Wireshark. As Wireshark has a lot of filters and options, in this course I will show you some features that are interesting for penetration testing. But if you're interested in network analysis, Pluralsight has a very good course only focused on Wireshark, so you should check it out. So now that you know the tools, it's up to you to decide which ones you prefer to use in your penetration test engagement. Personally, I prefer the way of performing eavesdrop attacks, it's capturing the traffic using the Airodump, decrypting it using the Airdecap, and then analyzing it using Wireshark, and that's what I'll be showing you in our next demo. So in this demo, I will be showing you how to decrypt PCAP files with the airdecap-ng, and will also show you a quick overview of the Wireless shark packet analyzer. Keep in mind that a Wireshark's a very powerful tool, it goes way beyond the features I will be showing. So, without further ado, let's go to our Kali Linux. So I'm guessing you're already familiar with how to capture wireless traffic using Airodump. If not, check out our previous wireless penetration test course here on Pluralsight, where we have a very detailed demo of capturing the traffic. In any case, let me quickly show you how to capture traffic from one wireless network. First, I check the name of my wireless network card, then I enable the monitor mode, and then we airodump, I take a quick look at the wireless environment around me, and I choose a target, for example, I've created this wireless network called WLAN_BE, which is WEP protected. So now I can stop this Airodump, and put some additional filters. So, using the airodump with the basic filter, and the channel filter, I can now collect packets for only one network. I'm also using the -w flag to specify the name of the file I want to save the capture. As we can see, even being password protected, I don't even need to be connected to this network to capture the traffic. I will let this run for a few hours to gather enough traffic. After a few hours, I can simply stop the airodump by pressing Ctrl+C. So now let's take a look at the files created by the airodump. As we can see, four files were generated. The one I'm interested in is the. cap file. This PCAP file contains all the traffic captured by the airodump. As the network is a WEP network, I can also use the same file to crack the WEP password. I've already done this a few minutes ago to save some time, but again, if you are not sure how to crack a WEP network using a PCAP file, check our previous wire penetration test course, where we have it explained on that course. Okay so now that we have the password and the PCAP file, we can use the airdecap tool to decrypt the packets and remove the wireless packets, leaving just network traffic for us. So let's take a look at the airdecap tool. As you can see, there are several options for both WEP and WPA captures. As the network is WEP, I will use the option -w to submit the password of the network, and then the name of the PCAP file. One very important thing to notice here is that an airdrop tool requires the password to be hexadecimal. When you crack the WEP password we're using the Aircrack, the Aircrack will give you the password both in clear text and hexadecimal, so we can just copy and paste it here. Okay so now we have it all set, all we have to do is press enter and wait a couple of seconds. As you can see, the tool already decrypted the packets, and also as mentioned, the recap does a very cool trick, it removes other wireless protocol packets, so we are left only with the important traffic packets in this file. After finishing the decryption, as you can see, the airdecap generated a file with a dec on the name. That's the file decrypted and clean for analysis on Wireshark. So let me quickly open Wireshark, and we can take a look at the traffic together. On the Wireshark, I just go on File, Open, and then select the PCAP file that was generated by the airdecap tool. Okay done, here it is. All the traffic. Now we can start to look for interesting things, like traffic on insecure protocols, such as FTP, Telnet, and HTTP. On Wireshark, you can simply type the protocol in the Search box, and press Enter. It will filter the traffic for you. So let's see, let's start with Telnet. Also nothing here. Okay, let's try HTTP then. Okay, here we go, we have some HTTP traffic. Now we need to look for clear text credentials, such as usernames, passwords, or cookies. So let's take a look here. Okay, this packet seems to be interesting, so let's see the whole TCP connection. And I have a very neat trick for you. Select the packet that you want to see the whole connection, right-click on it, and select Follow, TCP Stream. Now Wireshark shows the HTTP requests and responses related to this stream. As you can see in the GET request, there are some interesting cookies here, such as the session cookie. If you were a malicious hacker, you could use this session to authenticate into someone's account, even without knowing their password. But we aren't malicious criminals. We will just take a note of our findings, make a screenshot, and put this finding in our report.

Rogue Access Points

The rogue access point is a powerful hacking technique used to intercept traffic between the victim and the real network. With the user connected to our wireless network, we are in full control of the traffic, facilitating several other attacks. In the demo of this module, you will learn how to create a rogue access point in a few easy steps. But first, let's understand what a rogue access point is. Any known authorized access point can be considered a rogue access point. For example, if a developer created an ad hoc wireless network without the consent of the network administrator, that can be considered a rogue access point. But in this case, we will be discussing malicious rogue access points, which usually are created by an attacker hoping that a victim will connect to them. With the victim connected to a malicious rogue access point, the attacker can eavesdrop on the traffic and manipulate the packets to perform more complex attacks. So first, let's understand the difference between an offline access point and an online access point. On our left side, we have the offline access point, which sometimes is also called the cold access point. In this case, we will create a wireless network that is not connected anywhere. The idea is to wait for the user to connect to it, and then redirect the users to a malicious page, such as a fake captive portal, or a malicious page that contains malware to infect the user. On the right side, we can see the online rogue access point, sometimes called a hot access point. In this case, we will create wireless that is connected to another network, which can be the internal company network or connected to the internet. In both cases, we bridge the traffic between the user and the destination network. So let's think of two scenarios here. Let's say I create a rogue access point that is connected to the company network. So when a user connects to this rogue access point, the attacker will be able to intercept the traffic and even modify the packets for malicious reasons. The other scenario would be to create a rogue access point called free internet for example. When the user connects to our malicious network, we'll be able to intercept all the traffic between the victim and the internet. We would be able to eavesdrop on the traffic, or even redirect the user to a fake malicious web page. So let's think about how we could use that in your penetration testing. Let's say you're pen testing a company called GBM, during your pen test, you find the network called GBM cafeteria on the building. The network is open and has no password. You could simply create a rogue access point in some other area of the building with the same name. Users would connect to the network thinking it's still the official company network. The issue here is that some wireless routers have rogue access point detection, so if the client's router detects your network with the same SSID, it will generate an alert to the assistant administrator. But in reality, most systems administrators do not pay attention to those alerts, but if you don't want to take the risk of being detected, you can simply change a few letters on the network name. So for example, instead of the GBM cafeteria, now we can create a GMB cafeteria. Hopefully the users will not notice this small change, and will connect to the network. Another thing to think about is the location of your rogue access point. I personally would recommend not creating rogue access points close to the IT department, since usually IT people are more aware of security threats. On the other hand, usually non-IT people are more likely to be phished in this attack. The location can also change depending on which information you are trying to get. For example, let's say you are trying to intercept financial information. So you could place your rogue access point close to the finance department. You can always decrease the strength of your signal to make sure your malicious rogue access point will not be visible around the IT area of the building. And that's one of the examples why we need to understand not only the technology of the company, but also the people that work there.

Creating a Rogue Access Point

Creating a rogue access point may be simpler than you think. In this demo, I will be showing you how to create a rogue access point manually, which means create an access point with the hostapd tool, then create a DNS and DHCP server using the dnsmasq tool. There are a lot of tools on the internet that does everything automatic for you. You may find some tools with graphical interfaces in which with a few clicks you start your rogue access point, but I prefer to set everything manually, so we can have full control of what is happening. Also, usually automated tools are detected more easily than manual attacks. And most important, we don't want to be script kiddies, correct? We are professional pen testers. We want to know every configuration available to tailor or attack to our targets. So okay, let's take a look on how to create a rogue access point. Let's go back to our Kali Linux VM. Okay so let's start this demo by something you guys are already familiar with, let's put our interface into monitoring mode using airmon-ng, and then let's set the IP of this monitor interface to 10. 0. 0. 1/24. To create this access point, we will need a few extra tools. You can simply get them using the apt-get function on Linux. I recommend doing an apt-get update if you haven't done it recently. As my Kali Linux is fully updated, I can run those command that you are seeing. It will download and install the hostapd, which is the software that generates the wireless access points, the DNS mask, which is a very popular DNS and DHCP server, and some other wireless tools. So let's wait a couple of seconds, and done. Everything downloaded and installed. Okay so now let's configure the DNS DHCP server first. The DNS mask comes with a configuration file with a lot of options, but it can be a little bit overwhelming, so I will create my own configuration file from scratch. You will see how simple it is. First, let's back up the regional configuration file for in case we want to use it later. Okay done. Now, let's create our own configuration file. All you need to do is create a file on the etc folder called dnsmasq. conf, and put the following content. So wait, before we get scared, let's read this configuration file together. The first line says where we want to store the logs. Those logs can be useful for troubleshooting if something goes wrong. The second and the third line are commented. See the hashtag in the beginning? That'll mean that is a comment. Basically, if you want to create a DNS entry, that's how you do. In the third line, I have an example where we redirect requests to Google. com, to our own machine, which is the IP 10. 0. 0. 1. The fourth line defines the name of our interface, which is wlan0mon. Make sure your interface, which is monitor mode, has the same name. They may be different. The fifth line defines a DHCP range, or in other words, which IPs will be designated to the clients that are connected to this network. The sixth line is the gateway. The DHCP option 3 means that's the gateway IP. The seventh line defines a DNS server, which in this case is their own machine. DHCP option 6 means the DNS server. The eighth line is commented, so we don't need to worry about it right now. And the last line enables the log for queries, meaning that when the client queries for a DNS entry, it will show in the log. That's interesting to keep track of what's going on on the network. Okay, so now we can save this file because it's completed. Next, we need to create the hostapd configuration file. Let's create a file in this location, as you see in this screen. This configuration file is also pretty straight forward, let's take a look together. In the first line, it defines the name of a wireless interface in monitor mode. Again, yours may have a different name. The second line defines a network card driver. Probably yours is the same as mine, but if you're having trouble starting the hostapd, it may be the driver name. The third line defines the SSID of the network that it will be creating. I will be creating a wireless called CafeteriaFreeWifi. The fourth line defines a channel, and here I'll be using the channel 1, just for example, but we can use any channel between 1 and 12. And the fifth line is commented, but basically camera mode is a technique where the hostapd creates several wireless networks, mimicking the name of networks in which your phone already had connected in the past. As this technique is easily detected, we will not be covering this course, but Google about the camera mode, it's an interesting technique. Okay, so now we can save this file because it also completed. And we are done with the configurations, which is good. Let's go for the action parts. I will start by staring the dnsmasq service. Done. Now let's tail the log files so we can see what's happening. I will use the tail -f options, which reads the log file in real time. Done. So we can see what's going on in our DNS server. Okay, so let's start our wireless network now. I can start the hostapd service, or if I want to run it just once, I use the comment, hostapd, and the configuration file name. I press Enter, and done. The access point is started. That was easy, right? In a few minutes, we are all set. So I will connect to this network using my phone, just so you can see how it looks like. First, do you see the hostapd connection request right here? Yes. That's my phone connecting to this network. Now take a look on the DHCP server, there was a DHCP request, and then an IP was assigned to my phone. Now my phone is already querying for things, for example, I have an Outlook app on my phone, and the app is already trying to sync with the Outlook server. Also, let me do a simple web request. Okay see, see the DNS logs here, it shows I'm requesting for the Pluralsight website. Now imagine how much stuff we can do with this, that's what we'll be covering in the next sections.

Fake Captive Portals

Fake captive portals are one of the easiest ways to harvest credentials. It is a very powerful methodology, and it can easily lure users into typing their credentials into a site in which we will control. In the demo of this module, you learn how easy it is to create a fake captive portal, and harvest credentials. But first, let's understand what a fake captive portal is. Fake captive portals are usually used in conjunction with rogue access points. The intent here is to create a fake webpage to where the users will be redirected. This page will ask users to enter their credentials, or, if you are more aggressive, could be a webpage with some piece of malware, or a code that exploits the browser of the user. One very interesting thing we can do is cloning the real captive portal of a company, and modifying the code to send the passwords to us. There's a very interesting tool called Social-Engineering Toolkit, or SET Toolkit, which does the job for us. It clones the page, and changes the code to save the credentials in a file which you have access. If you don't want to clone a captive portal, or if your company doesn't have such a thing, you can create your simple page in PHP, that saves the typed credentials into a file. So here is an overview of how the fake captive portal works. The users connect to our rogue access point, our rogue access point redirects the users to our fake captive portal, and the users type the username and password, which then I save in a file so we can read later. Seems easy, right? The key here is creating a convincing rogue access point, and a convincing captive portal, so the user will type the credentials.

Creating a Fake Captive Portal

So let's take a look at how to create a fake captive portal. The first thing we need to do is configuring your rogue access point to redirect the users to a captive portal. Then, we need to clone a captive portal, or develop our own one. And with that done, we just need to wait for a user to connect, and send me their credentials. Okay, so we are back to our Kali Linux VM. The dnsmasq and the hostapd are already running on the background, so my rogue access point is ready. Let me start by creating a fake captive portal manually. This is very simple. All you need to do is to view the HTML with a form to receive the data, and one PHP file to handle the data and save it in a file. Let me show you what I created. I already put it in my web server directory, which is /var/www/html. Let me first open the index file. Just as a side note, I'm not the web developer, so bear with me. This is a very simple HTML, it contains some text, and a form that posts information to a file named save. php. This form contains two fields, one for the username, and one for the password. It also contains a button that submits the content, and it's simple as that. Now let me show you the php file. It has a lot of lines, but the most important part are those two lines, in which we save the username and the password in a string, and then save the string in a file called creds. txt. The rest of the code are just some integrity checks, and some error handling. Feel free to pause this video to take a better look on the code if you need. So now we just need to create the blank file on which we will receive the credentials. If you remember from the php code, this file is named creds. txt. To create a blank file, I use the command touch, and then the name of the file. We also need to add in the permissions of this file to allow the apache user to edit this file. You can transfer the ownership to the file to www-data user, but just to be simple, and not to spend too much time in here, let's use a chmod 777, and the name of the file. This means that any user has full ownership of the file. It's not a secure best practice, but here it's just an example, right? So all we have to do now is to start the apache server. Okay, done. And just to be sure, let's test the site. I will open my Firefox and access the local host. Awesome, it works. Let's type anything here and see if you can save in the file. That's perfect, it works. Also, this message here can be changed to something more convincing, such as welcome to the internet, or anything else. So now let's check the creds file. Here we go, it's right here, everything's working Now that we have a fake captive portal sorted, all we need to do is ensure when a user tries to access through any website, he or she will be redirected to our fake captive portal. To do that is very simple, let's edit the configuration file of our DNS server. Remember those two commented lines that I mentioned before, we will be using them now. Those lines have basically the DNS entries. This line here says that for any DNS query, we will redirect the user to our machine IP. The hashtag in the middle means any site, so we can just uncomment this line, and everything will be sorted. If you want to be more specific, for example, only redirect your request for the Google website to your computer, you can use the other commented line. Just uncomment it, and change the site, and you're good to go. But in this case, I wanted to redirect all of the traffic, so I'll be using the first comment line. Okay I already removed the hashtag in the beginning, so it means that it's not commented anymore. All I have to do is save the file. As I already have the dnsmasq service running, I will restart the service to make sure that my DNS configuration will be valid. You should never forget to restart your DNS server when you change any configuration file. You should never forget to restart your DNS server when you change any configuration file. Okay, so these all said no. Let me open the DNS logs and the hostapd logs, which we're running in the background, so we can see everything working. Okay here we are, let me connect to this network using my phone. Okay now I'm connected with my phone. Let me access a website, for example mycompany. com. See the DNS request here? And see it being redirected to 10. 0. 0. 1, that means our redirection works. Let me use my laptop to connect to this network so you can see what a victim would see. Okay welcome to my laptop. I'm already connected to this rogue access point, and I will use my Google Chrome to access the mycompany. com website. As we can see, what I get here is my fake captive portal. Let's type some credentials. Alright, done, it works. Let's check our credential file. Awesome, it is here, everything working perfectly. So, just out of curiosity, let me quickly show you how to use the use the Social-Engineering Toolkit, or SET Toolkit, to clone a website, in case you don't want to develop your own PHP website. So first, let's open the SET Toolkit, and then use the following options. The first options a 1, for social engineering, then option 2 for website attacks, then option 3 for credential harvester, then 2 again or site cloning. As you can see that is a lot of options. Perfect, now the set is asking us where the data should be posted. I will use my own machine, which is 10. 0. 0. 1. Now it's asking which website we want to clone. Here we can put any website we want. The toolkit will download everything from the site, including images, and it will modify the HTML to save the content of the site into a file when a user posts something. I will use the website that I just created as a test, so in theory I'm cloning my own website. So to put here just the localhost. Perfect. And then in a few seconds we'll have the site cloned, and saved into the apache folder. If you have some time, check out the options in the SET Toolkit, it's a very complete social engineering tool, and does way more than just cloning websites. We would need a course just for this tool, to cover everything you can do. So okay, so just to finish, let me go to the apache folder to show you what the SET Toolkit has done. See these three files here? The index, the post, and the harvester? Those are the three files created by the tool. We can even check the post. php file, which is very similar to the one I created. Now let me open the cloned website. As you can see, it is identical to my original website. It looks exactly the same. And the SET Toolkit will do the same for any website, even if the website has a complex layout with images and other things. So you see, harvesting credentials is very easy, and I'll think twice before I test in free Wi-Fi hotspots. It could be your password being harvested here. So, to summarize this module, we've learned about the non-disruptive attacks, which are attacks that do not affect the existing wireless connections. Meaning that if an employee is already working on his laptop connected to the Wi-Fi, he or she will not be affected. We also learned about one of the most common non-disruptive attacks, which is eavesdropping. We learned in our first demo how to capture and decrypt traffic using the Kali Linux. This can be very useful for when you crack wireless passwords using the traditional penetration testing techniques, and it wants to decrypt the traffic to find sensitive information. And we also learned about rogue access points, which is a very powerful hacking tool. Rogue access points can be used to intercept traffic, and redirect users to malicious pages. And as an example of a malicious page, we learned in the last section of this module how we fake captive portals, which can be used to harvest credentials of the users. So if you enjoyed the demos of this section, you will love the next module. It has a lot of demos in which you'll be learning about disruptive techniques, such as denial of service attacks. I hope you are ready, I'll see you in the next module.

Advanced Penetration Testing Techniques – Disruptive Attacks

Man-in-the-middle (MITM)

Disruptive attacks are attacks that can affect the performance of a wireless network. Even though clients usually don't like to perform test that can affect the performance of the network, it is still important to perform those attacks to understand the impact an attacker could cause on the network. Remember, in this course we are trying to perform the same techniques a malicious hacker would perform. So in this module, we'll be covering two main types of attacks. The first type is the man-in-the-middle, which is used to intercept and modify traffic of a user. The second type are the Denial of Service attacks, in which there are several techniques that can be used to fully disconnect someone from a wireless network. Man-in-the-middle, as the name suggests, is an attack in where we force someone's traffic to go through our machine, so we can intercept the traffic and modify it as we want. You may be familiar with some of the man-in-the-middle techniques, such as air poisoning, but as this is a wireless penetration test course, we will be focusing on wireless techniques to perform man-in-the-middle. For this attack, we will be using our online rogue access points to intercept the traffic. The idea is intercepting and eavesdropping on the traffic to capture sensitive data, but we can also use it to block access to specific resources. For example, to block a user from accessing their email, or even inject and modify traffic. If you really want to get aggressive on your testings, you can use the tools such as BeEF, to inject malicious JavaScript into HTTP traffic. The step by step of the attack consists in first, creating a rogue access point, as we saw in the previous modules, connect the rogue access points to a real network, wait for the users to connect to our malicious rogue access point, monitor or eavesdrop the traffic with Wireshark, and if you want, modify and inject packets using tools such as MITMf, but that's optional.

Creating an Online Access Point for MITM

So in this demo, you are learning how to configure rogue access points to perform a man-in-the-middle attack. We will also listen to the victim traffic, which is flowing through our machine, using Wireshark. So let's go to our Kali Linux. Okay, so let's start this demo by showing you how my VM's currently configured. On the right side, you can see my rogue access point up and running, currently waiting for connections. It is exactly the same setup we had before. The DNS and DHCP servers are also running the configuration we created initially, without any DNS rule configured. As we can see, my DNS redirection rules are commented. Also, let me show you my network configuration. Basically, I have two network cards, the wlan0mon, which I'm using for for my rogue access point, and the eth0, which is currently connected to the internet. To make it more easy to understand, take a look at this diagram. It is a simple design, one ethernet network card connected to the internet, and one wireless network card hosting the access point. What we want to do now is to allow traffic to flow from one network card to another, allowing the users to access the internet, but with the traffic flowing through our machine. This sometimes is also called online rogue access point, since the user will have access to the destination network normally. Also, the destination network can be anything, not only the internet. For example, if you are inside the client's building, you can connect your ethernet cable to the internal corporate LAN, so the users that access your access point will be able to access the company's internal systems, and the traffic will be flowing through your machine. Or if you have the Wi-Fi password, you can use an additional wireless network card to connect to the internal network through Wi-Fi. And from personal experience, I see a lot of internal services, or also called intranet, using insecure protocols, such as HTTP and FTP. So if the user connected to the internet through our machine, we can easily eavesdrop on the traffic, and capture the credentials. Sounds interesting, right? So let's see how it's done. The first thing I like to do is to flush any nat configuration preconfigured in your machine. So I used this comment you see on the screen. Basically, it says we are talking about the nat table, using the -t and nat, and that we want to flush it, using -F. Perfect. Now just in case, let me flush any routing configuration you may have. I use the same comment, but now only with the option, -F, which will flush any routing rule I have. Perfect. Now we are all clear and we can start fresh. First thing we need to do is create the nat rule for the interface which is connected to the output network, which in my case is the internet on interface eth0. I will use this command that you are seeing on the screen. As mentioned before, the -t specifies that I'm creating a nat rule. The -A specifies with chain we will append. In this case, is the POSTROUTING chain. The -o defines the output interface, and the -j defines a jump of the rule, or, what we'll be doing. In this case, it will MASQUERADE. We'll press Enter, and that's done. The second step is to add a rule that will forward the packets from the user to the destination network. So take a look in this iptables comment. The -A specifies the chain that we are appending the rule, which is forwarding chain, meaning that the rule is to forward packets. The -I specifies the input interface, which is a wlan0mon in my case. The -o specifies the output interface, and you already know that this is the eth0 interface. And the -j specifies the jump, or the action, in this case it's to ACCEPT the packets. We press Enter, and that's done. Last thing we need to do is to enable to ip_forward on Linux, and for this, I use this command. All we need to do is write the number 1 on this location you're seeing. Done. We are all set. The forwarding is completed. Just as a side note, if you want to remove all this routing and net configuration, you can just use the two iptables flush commands I showed before. It will reset your nat table, and also your routing configuration. But okay, we have everything configured. So now the users connected to my rogue access point have access to the internet. Remember, I could have used the client's internal network as the output network if I wanted to, so I would be able to intercept traffic to the internet. Let me show you from a user perspective. I have my laptop connected as the wireless network. Let me access Google here. See here, I'm browsing the internet, and it is working fine. Even my Google Chrome doesn't detect what is going on here. So you may be wondering, what can I do with this? Well let me show you. Let me open my Wireshark. As the traffic's flowing through our two interfaces, I can listen to any of those. So you see here, I've eavesdropping all the traffic. If the person used any insecure protocol, such as HTTP or FTP, we'll be able to see here. And if we were a malicious hacker, we could even intercept the traffic using the man-in-the-middle proxy. The idea is pointing the wlan0mon to a proxy, and then pointing the proxy through their output network. In this way, the hacker would be able to inject and modify packets. For example, a hacker could inject malicious JavaScript into HTTP traffic to poison the victim browser. But that's a malicious technique. There is no reason to execute it on a pen test engagement. Just with the Wireshark we can already get all the information we need to put in our finding report.

Denial of Service Attacks

A denial of service attack can be performed in several ways. In this section we'll be discussing two main techniques to cause users to lose their connectivity to the wireless network they are already connected. The objective of a denial of service attack is to cause a malfunction on the wireless environment, targeting one or more users, making them lose connectivity to a wireless network. This can be used as a distraction for bigger attacks. For example, you can run a series of denial of service attacks to make a network administrator busy, so you can perform more complex attacks without being noticed. Another example would be creating instability on the wireless network that the user's connected, so the user will look for another wireless network to connect to. And if you have your rogue access point active, the user will probably connect to it. Malicious attackers can also use denial of service attacks to request ransom from the companies, but as you may imagine, that's totally illegal. For wireless networks, there are two ways of causing a denial of service scenario. The first one, is in the deauth attack, in which you will be sending deauthentication packets to the router, as you were the client disconnecting from the network. The router would then terminate your wireless session. The key here is that you need to send deauthentication packets with the MAC address of the victim, so the router will disconnect the victim, but not you. We will take a look on how this attack works on our next demo. The second technique is using signal jammers. Those devices create a lot of noise on the wireless frequency, making it virtually impossible to establish a connection. Those devices usually don't target a single user, but a whole area. But before buying your signal jammer on eBay, check your local laws. In some countries, it is illegal to use the devices in public places. In some other countries, it's illegal even having one of those, so make sure you check your local laws before buying anything. But the interesting part is that police use those devices in some crime scenes, for example, the police can use this device in an ongoing crime scene to prevent the bad guys to communicate to anyone else.

Disconnecting a Machine with the Deauth Attack

So, let's go for a demo. In this demo, we will take a look on the deauthentication attack, using the aireplay tool. So, if you're ready, let's go to our Kali Linux. The deauthentication attack is one of the most simple attacks, and also one of the most dangerous, since it disconnects the person in a few seconds. So, let me show you how to perform it. I have here my Kali Linux VM, with nothing running on it. For this attack, we don't need a rogue access point, or nor DHCP servers. First, let me put my network interface into monitor mode. Oops, take a look here. I got an error saying there are a few applications already using my wireless network card. This is a very common error if you have the default network administrator tools on Linux. All you have to do is use the airmon-ng check kill. This will check all the applications using your network card, and it will kill the conflicting applications. Okay, done. Now we can try again to put our interface into monitor mode. Done. All good. So let's quickly run an airodump to see what's going on around here. Okay see this Florida - WiFi? This is my home WiFi. Let's use some BSSID and channel filters on the airodump to capture traffic only for this network. So far, what I have done should not be new for you. If you need more details, check the previous modules of this course, or the previous wireless penetration test course here on Pluralsight. Perfect, so there's one machine connected to this network, which is my personal laptop. I will attack this machine to cause a denial of service, or in other words, I will make my laptop disconnected from the wireless. For that I use the aireply-ng. As you can see, there are a lot of options available on this too. We will be using the first one, which is the deauthentication attack. Just so you can understand how the deauthentication attack works, let's think in the remote user scenario. When you are using your Wi-Fi and decide to disconnect from the network, you click on the disconnect button, and your laptop sends a deauthentication packet to the router. Basically, these attacks create similar deauthentication packets with the source as the victim. So for the router, it's like the victim is clicking on the disconnect button. To perform this attack, we use the following syntax. Starting by the aireplay, then the name of our network interface in monitor mode, then the option deauth, then the number of deauthentication packets we want to send, which in this case I put 30, just an example, then the MAC address of the router, then finally the MAC address of our target, which in this case is my laptop. So let me first show you my laptop. See, my internets working fine. As soon as I press Enter, these tools start to send the deauthentication packets to the router. Around one packets per second. So let me show you my laptop now. See, it's trying to load the page, but it can't. Now it shows that we are disconnected, awesome. We just caused a denial of service in my laptop. After the 30th packets been sent, my laptop can now connect again, and we will not be disconnected any more. I can now access the internet again. I could change a number of packets to a way higher number, so now the wireless network will be unavailable for a long time. And if I want to stop the attack, I can just use Ctrl+C to stop the script, and everything goes back to normal, as nothing had happened. Try this at home. Try to disconnect your own phone. You see how easy it is. In an advanced penetration test engagement. If the client agrees with denial of service attacks, you could have used these to cause instability on a few users so they would be looking for another wireless network to connect, and then, if you have your rogue access point created with a convincing name, people would connect to your rogue access point. Interesting, right? So in this module we discussed what a disruptive attack is. It is important to keep in mind that those kind of attacks will cause performance issues on the wireless connection of your users, so your client may not want to include those attacks in this scope. On the other hand, performing those attacks will give you a true picture of what damage a malicious attacker would have if they wanted to. So discuss with your client about that. In terms of attacks, we learn too many techniques, the first one being the man-in-the-middle type of attack, in which it allows us to intercept the traffic. In the demo of this attack, we saw how to use this method to listen to packets, but a malicious hacker could use the same technique to inject malicious traffic into a network. As an example, an attacker could use this man-in-the-middle technique to inject malicious JavaScript into the HTTP packets in an attempt to compromise the client browser. We also discussed about denial of service attacks, that can be used to distract network administrators during complex attacks, or it can be used to force users to reconnect to a malicious hotspot. In a few cases, malicious hackers can also use denial of service attacks to request ransom, or hacktivist groups can use denial of service as a form of protest. The impact that those attacks could cause is the reason why we should be testing disruptive attacks, because we need to understand how much of our business could be impacted if a malicious attacker wanted to affect our business. So if you enjoyed the attacks that I presented, you'll love the next module. We'll be covering some techniques to cover your trace. You'll be able to understand what a malicious hacker does to prevent forensic specialists to figure out who their attackers are. So, stay tuned. I'll see you in the next module.

Covering Your Traces

Why Cover Your Traces?

Dr. Edmond Locard was a very prestigious forensic specialist. He was also known as the Sherlock Holmes of France. He formulated the basic principle of forensic science, which is every contact leaves a trace. In this module, we'll be discussing about some techniques to help you to cover your traces, and also, some pen test best practices that will step up your penetration testing skills. Even in the case you have no reason to hide your traces, it is important to understand how malicious attackers would do it, so you can think as an attacker. So you may be wondering, why should I cover my traces if I'm not a criminal? Your thoughts totally make sense, but as in the red teaming, we are looking from an attacker's perspective. It is important to perform the attacks as an attacker. Remember, we are trying to follow the same steps that an attacker would perform, and that it can also be interesting to test the forensics capabilities of your client. For example, after the attack, would the network administrator or digital forensic investigator be able to trace you? Also, does the client have the capabilities to identify who the attacker was? Those are the questions that may be interesting for the client, so trying to cover your traces can be interesting on your engagement. Also, on certain circumstances, you may want to cover your traces to preserve your identity. For example, if you're performing a red teaming penetration testing that would last one month, you don't want the users to know that you are a pen tester in the first day. Otherwise they may be in knowledge mode when you are around. Another reason to cover your traces is to avoid data leakage. In this module, we will discuss about some techniques to ensure your client data is totally isolated from other clients, and some techniques that are insured that the information gets through it, will be destroyed after the engagement. So in this module we'll be covering the three main topics. The first one is the use of disposable virtual machines, in which it will help you to isolate your client data, ensuring that never data from one client will be mixed with another client. It also helps with data destruction. The second topic is about changing your MAC address, that will help you to cover your traces. In our last section, we will discuss about some of the wireless penetration test accessories, such as remote wireless devices, and out of the box wireless hacking devices.

Disposable VMs

Disposable VMs is a very common practice across penetration testing. It helps you not only to cover your traces, but also in your general pen test workflow. Using disposable VMs is considered a best practice in any penetration test engagement, from wireless pen tests, to web application pen tests. The main idea of disposable virtual machines is having one virtual machine per engagement. This makes your penetration testing workflow way easier, since every time you start the penetration testing, you will have a fresh, new virtual machine, and without any confirmation from previous client. And when you finish your penetration test engagement, you can simply archive the virtual machine, or destroy the data by deleting the virtual machine. As your data will be all contained inside one VM, you don't need to be hunting files in your system for deletion, everything is in one place. Also, disposable virtual machines provide client segregation, which you will avoid cases in which you mix data from two clients. You don't want the data from the company A being in the same machine where data from company B is stored. Having disposable VMs will avoid data contamination, meaning that each VM will have the data from only one client. Also, the use of virtual machines make the process of data destructions way easier, since all the data is contained and encrypted in one place. So let's take a look at some good practices when working with disposable VMs. As mentioned before, it is important to have one VM per engagement. Never use the same virtual machine for more than one client, since you don't want to mix up data from different clients. It is also a good idea making this a habit. Whenever starting a new project, create a new VM. Whenever finishing some project, archive or delete the VM. To make this process easier, you may create a few virtual machine templates. Personally, I have three or four templates that I use. For example, for my wireless penetration testing template, I basically took a version of Kali Linux VM, and copied all the custom scripts that are I use to the desktop. I also made sure the network card was working, and the drivers were installed. With that done, I saved the VM and I put that in my template library, so now every time I have a new client, I simply copy the virtual machine, modify the passwords, and start to use it. And also remember, each virtual machine should have its own passwords, do not use the same password for all your clients. And talking about passwords, one very important thing to do is to encrypt the hard drive of your virtual machine. If your virtual machine player doesn't have this feature, you can simply encrypt the virtual machine files with some encryption tool, such as TrueCrypt or VeraCrypt. Never leave the virtual machine unencrypted, and always use one password for each client. Never reuse passwords. To make sure you never lose through your work in progress, create off-device backups. I personally have an encrypted hard drive, where I keep all my VMs from previous clients. It is a double layer encryption, because the external hard drive is fully encrypted, and the virtual machine files are also encrypted with different passwords. So I was a little bit paranoid, but if you're in the security field, you need to be. Other good practices in terms of data destruction is whenever you finish engagement, if you don't require the data anymore, make sure to delete the VMs you were using. There are some open source tools for Windows and Linux that does secure deletion, but if you keep everything encrypted, even if someone is able to recover the file, they will be encrypted, and that's why it's important to keep everything encrypted, including your reports and notes.

Changing MAC addresses

MAC address changing is a common practice to avoid traceability, since the MAC address is a unique identifier of your network card. Changing the MAC address is a very common practice by hackers. MAC address is considered a unique identifier. Each network card has their own specific address. Due to this fact, it can be traced in its supply chain. For example, from the MAC address you can track the vendor, from the vendor, you can track the network card produced, and to each store it was distributed. From the store, you may be able to track who bought it. Again, it may sound paranoid, but in theory it can happen. Even if you're not worried about police tracking down on you, MAC address is usually used to correlate events in a digital forensic investigation. For example, if they see a MAC address doing something wrong on the network, and in the next day the same MAC address is accessing a Gmail account, they would be able to correlate the owner of the Gmail account with the actions of the previous day. So you may be wondering, as we are not a malicious hacker, why should I do this? And the answer is, because we may want to test the forensics capabilities of your client. We want to see if your client would be able to figure out who the attacker was, even if he changed the MAC address. You want to perform the attack exactly as an attacker would do. As I mentioned before, the MAC address is a unique identifier. It is composed by six octets, being the first three octets related to the vendor, and the last three ones are related to a specific network card. Just out of curiosity, if you have a MAC address and want to find which vendor is responsible for it, you can use some websites such as macvendors. com. You simply insert the MAC address, and it shows you the information about the vendor. And finally, to change your MAC address is fairly simple. On Kali Linux, there is a script called MacChanger, in which you just need to specify a new MAC address, and the interface you want to change, and then press Enter. This script does all the magic for you.

Wireless Penetration Testing Accessories

So you may have seen over the internet several devices for wireless penetration testing. From modified routers, to small Raspberry Pis customized for pen testing. In this section, we'll take a look at some of the devices that can step up your wireless penetration test game. The first type of device I want to present to you is a remote wireless device. Those devices allow you to reach a wireless network, even without you not being physically on the client office. So you may be wondering, how can have contact with the wireless environment if I'm not physically on the client all the time? And that's where the remote wireless devices start to get interesting. Those devices are small computers with a wireless network card. Those devices can be hidden anywhere in office, and it can be accessed remotely. Think like you have your laptop in the client, but accessing your laptop though SSH, it is the same thing, but with a device way smaller than a laptop. Those devices can also be called wireless backdoors. Also, keep in mind that you need to have foremost authorization from a client to use those devices. The interesting thing is that you can create your own remote wireless device using a Raspberry Pi and a USB wireless network card. There are several tutorials on the internet how to build your own Raspberry Pi hacking device. I will let you research more about the topic, but just to give an overview of how to make your own remote wireless device, here is the step by step. Basically, you need the Raspberry Pi, a USB wireless card that supports monitor mode, and a command and control server. You may want to have a 3G modem so that you can easily access it remotely. The step by step is seen on the screen on the right side. First you need to install the Kali Linux on your SD card, then you configure your USB network card and the 3G modem, and with that done you configure the script to run every 5 minutes on your Raspberry Pi to connect your device to the command and control server. And this is more optional for a wireless penetration test. I will let you research more about this topic, but you can easily find tutorials all over the internet. On the internet, you also find a lot of out of the box wireless hacking devices, such as the Wi-Fi Pineapple. Those devices have most of the tools necessary for a wireless penetration testing. People used to call those devices as hacking in a box. With those devices, you don't need to worry about buying a network card with monitor mode, or spending time configuring a DHCP server for a rogue access point. You can simply plug them on USB, and they will provide a very interactive user interface in which you can perform several attacks. For example, with two clicks you can set up a rogue access point with interception capabilities. In my opinion, those devices are very handy, but at the same time, you shouldn't rely only on them. Any wireless pen tester needs to know the details of an attack and how to perform them manually, without automatic tools. So before buying any kind of out of the box wireless hacking device, make sure you know how to perform all the tests manually, using your Kali Linux VM. So let's a moment to summarize what we learned in this module. We started by discussing the importance of being stealthy. We mentioned that even though we are not criminals, it is interesting to perform the attacks exactly as an attacker would do, so we can test the instant investigation capabilities of your client. The second topic we discussed was about some pen test best practices, such as using disposable VMs, and changing out the MAC address. And in the last section, we talked about devices that can be used to exploit wireless networks remotely, and some out of the box wireless hacking devices, which are very handy, but should be used only after you're mastering all the wireless penetration test techniques manually. And with this, we end our Wireless Penetration Test Advanced Techniques course. I really hope you learned some new techniques to use in your future pen test engagements. As the advice on the beginning of this course, it is very important to try to practice our demos in your own test environment. So feel free to go back through the previous modules and practice the techniques you learned. Thank you, and I hope to see you soon.