Nmap Scan Techniques - NULL, FIN, Xmas, maimon, Idle Scan, IP protocol
Back in Nmap help.
And we can see here, we've got the TCP NULL, the FIN and XMAS scans with the S N F X or these three scan types are exactly the same in behavior, except for the TCP flags set in the pro packets, which are different.
So in the NULL scan does not set any bits.
The TCP flight header is zero.
Then we have the fin, which sets just the TCP fin bit.
Then we have the Xmas scan.
This sets the fin, psh and U R G flags lighting up the packet like a Christmas tree.
Hence the name Xmas or Christmas.
These three scan types, exploit a subtle loophole in the TCP RFC to differentiate between open and closed Poles.
The key advantage to these scan types is that they can possibly sneak through certain non stateful, firewalls and packet filtering routers.
And that's pretty obvious. You can see here, the -S capital N which is the TCP NULL scan.
We have the fin scan here and we have the XMAS scan here.
Then we have this Maimon scan.
They certainly exists exactly the same as the NULL, FIN and XMAS scan, except that the probe is a fin ACH.
Cause that's according to the RFC 7, 9, 3 TCP RFC, a reset packet should be generated in response to such a pro. where the port is open or closed.
However, a guy called URL Maimon notice that many BSD derived systems simply drop the packet.
If the port is open, so can be useful on BSD systems.
And then if you want with the scan flags, you can customize the TCP scan, flags yourself to whatever it is that you want them to.
Here we can see the minus S capital I, this is the zombie scan or idle scan.
They believe it or not with a little trick with a right sort of host right.
Type of host. It's possible to bounce a scan off that host off another host.
And that's what you call the zombie so that you can scan a target.
And that you're scanning comes from that zombie and not you a machine.
Now these days. It's not easy to find the zombie, which this technique will work off.
So for that reason, it's not really that worth covering.
But if you do want to know about the exact details of the technique, just for the sake of what used to be possible, then check out this link here for the idle scan.
But as I said, not really too possible nowadays, but it is a method of bouncing a scanner.
Off or the host, if the host is a specific type and responds in a specific way.
So that's the idle scan.
The SCTP scans we've talked about.
There's the -S -O, which is the IP protocol scan.
If we jump over to here and we specify nothing other than the -S -O, it will do the defaults.
If we look at the results, when they come up, we can see that it's telling us that this host is responding to ICMP, which is essentially ping and search and TCP and UDP.
So these protocols are being used and SCTP is not being used.
We can get a little bit more specific.
So if we go onto this one, we can actually specify the IP protocols that we actually want to check for as opposed to going for the default.
And if we click return on there, we'll see that IGMP, which is number two and number three, which is GGP and IPV four, which is here.
These all identify as open filtered, but the ones that we would expect, ICMP, TCP and UDP, those are all ARK and they are functioning on this device.
This is a way another way of identifying if a host is ARK and what protocols is running.
Let's pop back to help again.
We'll see. Minus B, this is the FTP relay host.
So it's an FTP bounce scan.
This exploits, a feature of the FTP protocol, RFC 9 5 9, where supported by so-called proxy, FTP connections.
Now this vulnerability isn't widespread at all anymore.
So pretty much you can ignore that one because it's not usable either.
So that's a Roundup of all the scan techniques that I've gone through there.