So we have a SYN. We have a ACK short for acknowledge that comes back. Every SYN must have an ACK in order to basically allow the circuit to be complete. So step one is SYN, SYN-ACK. So the target is going to acknowledge the first SYNchronized request, send its own, and then the recipient now that was the sender originally has to acknowledge the SYN and we go ACK. So it's SYN, SYN-ACK, ACK. This is the TCP three-way handshake. So a TCP connect scan is going to do a full three-way handshake in order to be able to probe and see whether the system is up and running, what kind of system it is. Because depending on the nature of the setup request, how it's handled, what packet information we get back in the exchange of those SYN and SYN-ACK requests, is going to tell us, is it a Microsoft system, is it a Linux system, we're going to learn a lot about it just by getting that basic information, at least if we know what to look for and know how to read that information. So we could do a TCP connect scan, the problem is the TCP connect scan as well we call noisy. It generates a lot of traffic that is obviously profiled and known to us. And again, a three-way connect from outside of the firewall is something we probably would not allow. We would allow it inside behind the firewall, but we may only allow that inbound connection to certain systems in the DMZ because those systems would be expected to be able to connect to outside resources and interact with them. That's the purpose of them being on the DMZ. So maybe I'm going to do that to a web server that sits in the periphery of the DMZ network. But we're not going to be able to do that all the way back to the database behind it. So there's going to be limits to what we can connect to and how we can use this particular kind of a network mapping technique. But again, it may yield results but it's incrementally moving us back towards where we want to be. We may use what's called a TCP SYN scan, it's called the half open scan. We send the SYN part of the connection request. So we send the initial request, the first part of a handshake. But instead of acknowledging it when it comes back and completing the conversation, as soon as the recipient sends the SYN-ACK, we send what's called an RST or a reset. The reset effectively cancels out the connection requests and says, oh I'm sorry, I didn't mean to do that. My apologies. Didn't want that. Wrong number, right? Just we hang up. But by getting that SYN-ACK back, what we've done is we validated that the machine is there, it's active, and we've probably figured out what kind of operating system is running, we've been able to learn some information about it, at least the general kind of information based on the structure of the information on the packet, and some information that comes back with it, we can tell if it's Microsoft or Linux for instance at a basic level. So a TCP SYN scan, is called a half scan or a half open scan. It sends the SYN but then it resets when we actually try to do the connection and start stage two, which is the SYN-ACK. We also can go ahead and do what's called a TCP FIN scan, the TCP FIN scan as you can see here, we send a TCP packet with what's known as the FIN bit on. This is a flag that we set, there are many flags we can set inside the header of the data packet, and the FIN bit is just simply one of them for the TCP flags, we send this to a specific port on the target host, if the target responds with an RST or a reset packet, we assume the target host is not using that port. The host does not respond, the host may actually be using the port that was probed. The FIN is the finalize packet, it's going to allow us to finish that connection. So it's going to be able to help us to understand by probing whether or not that system is using that or not. And if we get the reset as it says, then the target is not using the port, and we know that that particular service that would run on that port is not actively being used. Because the FIN allows us to say, hey we're done and the system says, okay no problem that we're targeting, let's reset that, right? So there's nothing going on there. But if we get the FIN packet going and that port is in use, there's a service actively using it. We're not going to reset it. So we're probing for services by doing a TCP FIN scan, and the FIN scan allow us to say, well, normally on port 53 we use DNS, on port 21 we use FTP, on port 80 we use HTTP, on port 443 HTTPS, right? Et cetera, whatever that may be. Kerberos goes on port 88. If we send a TCP FIN scan against the system, and we don't reset that connection, those ports are in use, those services are in use. And again, what we'll be using port 88, well, we know it's Kerberos traditionally, and we know that that's most likely going to be a Windows machine using Kerberos. So we can begin to map out not just the system, but the functionalities that that system may have going on within it, the services it provides, and understand more about the network. It becomes very important again because we want to know what kind of traffic is there, because that indicates what kind of functionality we're looking at. Then we can also use what's known as the TCP XMAS scan, the XMAS scan is going to light up all of the flags, send them all out to see what's going on. So I would call it an XMAS scan. Looks like a Christmas tree because everything is turned on, but because it is stealthy, right? But because all the flags are set, we turn on what's called the URG, URG urgent flag, and the PSH or push flags in addition to the FIN, and we're going in and trying to see what the behavior will be based on receiving these flags at the target system. Again, systems will behave a certain way based on the software they run and the services that are using them. Because of the fact we can profile this, we can understand this, we know ahead of time what to expect when the system gets back certain responses, the automated system says, oh this or that must be used, must be in use, or must be working, and we know that we can start to begin to pinpoint what services are running. Again, tools like Angry IP Scanner, Ultra Port Scanner, there's a whole bunch of them out there that will do this, those two happen to be free, will be able to execute these kinds of scans. Now in addition to the last two that are up here, the TCP NULL scan and UDP scan, we'll talk about those in a minute. Just to understand that some of these scans will work, some will not. Some are protected against now so the systems will not respond anymore, because either the configuration of the networking stack has changed, so they no longer will respond the way that we assume they would, or firewalls or Gateway devices are blocking these scans. There's all these variables that we would have to take into account. But the ideas that we try them with automated software that runs through them, to see how lucky we get. Because chances are good that if left to their own devices, network administrators are not going to configure every machine the same way, they're not going to block every port, they're not going to block every open avenue to approach the network. And if we're patient and we're smart, we'll probe enough that we'll figure out where the cracks or the weaknesses are. And this is what this kind of technique's all about. The TCP NULL scan is similar again to a FIN, but we turn off all the flags. So instead of setting certain flags, we send a scan in with no flags set. How does the system respond to that? Again, we would have certain templates and parameters that we know ahead of time would be the expected responses or expected behavior that we would get, and we would then be able to record that. And then finally, UDP scans, a UDP scan will determine which UDP service ports are going to be opened and running on the host. All the other scans until now have used TCP, the transmission control protocol, which is a connection oriented protocol heads the concept that the three-way handshake. Hey you want to do business? How are you, my name's Adam. Yes, I want to do business. My name is John. Thank you, Adam. Oh, thank you, John. And the three-way handshake allows us to effectively interact and exchange information. Without that three-way handshake, we're not sending and receiving anything. And for every packet we send, we have to acknowledge the packet that's part of the deal with TCP. With UDP, quite the opposite. It's what we call a connectionless protocol. Often referred to as send and forget. As a result of that, we don't expect or nor do we require a handshake. We just send traffic. If you want to respond, you respond. If you don't, you don't. Burdens on us the sender to get that information to you. The rest of it's on you, if you miss a packet, if you don't get something, you've got to make a request to have it resent. We're not going to resend that automatically. Whereas with TCP, if we don't get a response to that packet within a certain amount of time, we assume it's lost because we don't have an acknowledgement, we resend that packet. We do that automatically, it's part of the way the protocol works. So with UDP scans, we're looking for systems that are using the UDP protocol to drive services. For instance, remember, both Kerberos and DNS and NTP, network time protocol, all run on UDP or these can use UDP anyway. They also at least in the case Kerberos and in the case of DNS run on TCP but they can use both. So when we're probing and looking for what UDP services are in play, we're looking to see what system services are running, because again that tells us potentially the kind of the operating system and the function of the server, what it's designed to do. So I want to make sure we understand that and we can, again, see all these scans as being different approaches, different techniques, different opportunities within the general concept or network mapping, to understand how to execute this phase of the penetration test, phase two, that we're taking.
