Hello, and welcome back to this course. In this video, we're going to be talking about scanning. We're focusing on reconnaissance right now, and so far we've been focusing on passive reconnaissance, so collecting information from other sources. Things like Shodan or the DNS infrastructure where our interaction with the target environment is fairly minimal. In this video, we're going to switch over to a little bit of active reconnaissance. The reason for this is that while passive reconnaissance can be more subtle and makes it harder to detect the ethical hacker's presence on the network and determine what they're doing. There's only so much information you can gather in that way. In this video, we're going to talk about how to gather a little bit of information actively, which can give us a more complete picture of what's going on on a target system at the cost of potentially revealing our presence. In our Python script called portscan.pie, we've got three different functions here. These are designed to collect certain types of information about a target system in a few different ways. Let's start out by talking about the first one, SynScan. SynScan is an example of a SYN scan, and you might be familiar with this if you've used Nmap, but it's one of a few different options for common scan types. Its name comes from the fact that we're working with TCP and to setup a TCP connection, we have the TCP handshake. It's a SYN, SYN-ACK, ACK. At the end of that, the connection is set up and we can start communicating. If you only send that SYN packet, you get a response from the server. You send the SYN saying, "Hey, I'd like to connect." The server sends a SYN-ACK saying, "Okay, I acknowledge your request for connection, and I'm also willing to start this connection." Then, in theory, you're supposed to send the ACK. But when we're trying to gather information about if a particular port's open, all we need to know is do you send that SYN-ACK back to me? Because if we get that SYN-ACK, it's acknowledged our willingness to open the connection and expressed its own willingness to connect. That means the port's open, and it's accepting connections on that port, which is all we really want to know right now. By tearing down the connection at that point, we've potentially evaded some security tools because they might be looking for a complete connection for analysis rather than a half-open connection. Not true of all tools, and this technique is known, so its stealthiness has been degraded over time. However, it's a good introduction to performing scans in Python using SCAP. Like I just said, we're going to be using SCAP for this, and the reason why is SCAP allows us to build custom packets. That makes it very easy to build a legitimate SYN packet for this testing. For this, we're going to be using the SR function in SCAP, which stands for send receive. We're going to send a packet and we want to listen for responses. The SR function is really useful here because it automatically matches up a response to the corresponding sent packet. We don't have to read through every packet that we see on the network and try to figure out which one we care about, all that's done behind the scenes for us, much, much easier. All we have to do is build the packet that we want to send out, and all we have to do there is define the fields we care about. A TCP SYN packet has quite a number of fields and we don't care about most of them. We need to say where it's going, and we need to say, we want it to be a SYN packet. That's actually fairly simple, as we see here in this line of code. One of the levels we need to define where it's going is the IP level. That means we're going to have to provide an IP address, which is what's stored in this variable host. What we're going to do here is we'll say, "Okay, this is our IP address that we want to use," and then everything else we want to fill out. We'll automatically fill out the RIP address and every other piece of information at the IP level based off of default values, and those defaults are good enough for us. Moving up a level to the TCP layer, we want to define two different things. The first is the destination port. If you're not familiar, TCP use the concept of ports to let a bunch of different services and listen on a single network interface card. The list of ports we're checking out is up here. These are just some of the more commonly used ports. We certainly could scan every single port but the more ports we scan, the higher our probability of being detected. This provides a bit of a balance between missing something important and scanning everything and making it obvious we're here. One of the nice things about Scapy is that it allows us to pass a list in for that d port. So instead of saying for port in list of ports and then write out the packet, we can just say ports. It will send one for each of them and it'll handle all the answers and unanswered packets for us. Makes it easier. Then finally, we need to define that we have a SYN packet here. All we have to say is flags equals S, and that builds a valid TCP layer for our packet. This makes it really simple because we've defined three fields in our packet and we have even defined all the layers. Notice that we don't have an Ethernet layer defined here. We're not going to bother, Scapy will take care of it. At these two layers, we only define what we really care about. There at the end, we're optionally going to define a timeout. Our timeout here will be two or two seconds. That's about enough time that the target computer will be able to receive the packet and respond without sitting us hanging there forever if it chooses not to. Then finally, we're saying verbose equals 0, which just means we don't want it to print a lot of information in the process. Scapy talks a lot and we don't really care at this point what it says. After we run that line of code, we're going to have two different variables; answered and unanswered. We really only care about the stuff that's unanswered here. What this should have is a pairing for each one of our request and received packets from the source and the destination. What we're going to do here is use a Python list comprehension to go through this. All this does is it compresses a for loop with some if statements down to something a little bit more compact. Here's the top of our for loop for s,r in answer. This says for each of our sets of sent and received packets, do something. Remember we have sets because we provided a list of ports so we have multiple different ones happening. One for each of these ports. For each of them, we're going to check to see if the destination port of the packet that we've sent equals the source port of the packet we've received, just making sure this is a good match for us. Because if we send to port 20, the only answers we care about, or if it comes from port 20. That should be true, but it's better to check. Then we also want to check the flags on this packet. In this case we want to look for flags SA. We sent S for SYN, we will look for a SYN-ACK. If that's the case, we've got an open port. If we've got an open port, we want to extract the destination port from our sent packet. We could also extract the source port from the received packet and that tells us this is a port that's open. We'll do this for all of our different ports and end up with a list of open ports hopefully, if there are any in this list that are open, and will return that. Let's give this a try in Python. We'll do from PortScan import star, which just means we're going to import all three of these functions here. Once we've imported that, I can say ports equals SynScan of, and we need an IP address so I'll use this virtual machine that I've got set up and it's running a couple of different services on it. We give this a moment to run and then if we print our ports, we see that we have three different ports open. We have port 21, 22, and 23 so FTP, SSH, and Telnet. That's great. We've learned out of this entire list of common ports that these are the three that we really want to focus on. It's entirely possible that ones outside of this list are running but we don't know that because we decided to take a little bit more stealth and exchange for a little bit less information. This answers one question for us, but we're actually going to be using scanning to answer another question. Beyond what port is there, also we're going to want to learn eventually what's running at those ports. I said, these are this, that and the other because they're common port numbers and you can guess. However, beyond that, if we really want to start performing ethical hacking against these ports, we need to know the program that's running there. One of the ways to learn a little bit about that is through banner grabbing. A banner grab is just where you connect to a particular service and see what it sends back. What it sends back can give you some hints about what that service actually is and can help inform some vulnerability analysis. We're going to do two different types of banner grabbing here. The reason why is for some services, it's better to use one form and for other, it's better to use a different. In this case, what we're going to do here is do a classic banner grab, which is grab information by just sending a packet to the port and seeing what it sends back. We could build that packet manually in Scapy, but there's an easier way, of course, and that's to use the socket library. If we do socket.socket, we can set a timeout on that socket, we can connect GitHub, request a certain amount of data back, in this case we'll read the next 1024 bytes, and then we're going to decode that using the UTF codec. This is just going to connect to a port, see what it spits out to us. Then whatever it spits out, we're going to save for later processing. We'll dive into that in later videos. Since I've already loaded that function in, let's do bannerGrab of our same IP address. Now that we know which ports are running on it, let's do port 21. This is the banner for this particular service. Looking at this, we see it's vsftpd, so we can guess it's an FTP service. Then we also can see the version number 3.0.3. This information is going to be very useful to us later on because we could go to something like a CVE list, type in vsftpd 3.0.3 and see if there are any known vulnerabilities for it. If there are, we've gotten a potential attack vector there. Even if not, FTP might require authentication. If it does, we have opportunities for credential stuffing and similar attacks. Just by simple bannerGrab, we've learned something about our target service. The other thing we can talk about here is HTTP headers, which are similar to banners in that they provide information about the target server. In this case, we're only going to really call it for certain reports that we believe are HTTP ports. Things like 80 and 443. When we do so, we're going to base the requests that we make off of the port number. If it's port 80, we're going to use HTTP because that's what normally runs on HTTP port. If it's port 443, we're going to use HTTPS because it should be running an HTTPS server. This is becoming more common, but there's a chance that we might have some port 80s left open. If I come over here, let's run this on some system. In this case, we can't use the same IP address that we just did because we'd see here that there is no port 443 or 80 listed here. What we could do is do response equals HTTPHeaderGrab. While this says IP address here, we also could do a domain name. It'll just look it up and convert it for us. Let's do www.google.com, and let's request port 443 because Google is very good about running HTTPS servers. If we hit "Enter" here, we get a couple of warnings. The reason why is that it's saying we're making an insecure request because we've turned verify equal false. What that means is we're not performing certificate verification, and we don't really care about the authenticity of the certificate here because we're not really trusting the website. We just want to learn what's going on there. It's better to be able to access sites that have more suspicious certificates like a self-signed one, than to not be able to access things like that at all. If we look at response, we see we get a 200 response. That's great. Then if we type response.headers, we can look at the headers that we actually requested. Here, we see that there's a bunch of different headers here. The reason why we're requesting this is because in here is a header called server. The server header here provides information about the software running on the HTTP server. In this case, we see Server gws, meaning that it's Google Web server. However, in other cases we might see something like Apache or something like that, which tells us information about that program that we're running and potential vulnerabilities on it. This demonstrates a couple of different scans that we'll be using in reconnaissance. We'll use the SYN scan to learn about ports. We'll use banner grabbing and HTTP header grabbing to start identifying information about the targets services, so we can start learning about potential vulnerabilities on them. Thank you.
