Null/FIN/Xmas/ACK Scans Demo
>> Let's take another peek at the help screen of Nmap.
What do you say we try the trio of null, FIN, and Xmas scans?
[silence]
I'm going to send a null scan to port 80 on my Windows host machine.
My Apache web server is running.
Listening on port 80.
But Nmap is saying the port is closed.
[silence]
Why is that?
Well, remember that Windows machines will always send an RST in response to null, FIN,
and Xmas scans, regardless if the port is open or closed.
You can see the same results when I change the n for null to an F for FIN.
[silence]
In Wireshark, we can see the results of both scans.
I'm using a display filter of ip.addr==192.168.1.104, and tcp.port==80.
This is the IP address of my Kali box, and traffic that's involving port 80.
[silence]
For the Xmas scan, we'll remove the port specifier.
And let Nmap scan the most common thousand ports.
Nmap says all 1,000 scanned ports on 192.169.1.101 are closed.
But we know better!
Let's take a look at these Xmas tree lights.
The FIN push and urge flags are turned on.
[silence]
I'm going to repeat this scan, this time on my router,
which is not running a Windows operating system.
It does have web access enabled.
We can see that both ports 80 and 443 are showing up as open or filtered.
We can continue sniffing Wireshark on the host since all traffic to and from the VM still has
to pass through the Windows host machine's physical nick [phonetic].
Changing our Wireshark display filter to the IP address of the router.
You can see the scans to my router on port 80 didn't return RSTs,
which means either the port is open or the port is filtered.
How can we tell which one it is?
That's where the AC scan comes into play.
The AC scan will identify a port as filtered or unfiltered.
Let's change the X to an A for an AC scan.
All 1,000 scanned ports on 192.168.1.1 are unfiltered.
Combine that with the logic from the Xmas scan, and we can conclude
that my router has ports 80 and 443 open for business!
In Wireshark, we're still using a display filter of my router's IP address
and TCP-related traffic on port 80.
Here's the AC scan.
You'll notice that the AC scan was responded to with an RST from my router.
That means the AC scan wasn't filtered, and it got there.
Then my router sent an RST.
If there was a firewall filtering the scan, my router would not have sent the RST
since it wouldn't have received the AC.
Changing the filter to just the IP address of my router, and TCP, on any port,
we can see all of the ACs and RSTs.
Wireshark captured them in groups of each.
UDP Scan Demo
Lets conclude with some UDP scans.
First we're going to ask Nmap to send a UDP scan
to port 99 of my router.
Nmap is reporting that port as closed.
A look at Wireshark reveals that the destination
sent an ICMP destination unreachable/ port unreachable
error message back to the Kali box in response to the UDP scan.
I'm using a display filter of udp.port==99
Let's start a new capture and filter by the IP address of my
Kali box ip.addr==192.168.1.104 and UPD.port==53
This will eliminate any DNS traffic to or from
my Windows host machine in the display,
zoning in on DNS traffic to and from my Kali box.
Now in Kali, we're going to ask Nmap to probe for a service
that uses UDP listening on port 53 of that box that
everyone simply calls "router"
Of course we're talking about DNS.
Low and behold, the UDP scan has identified a server
in that little box that everyone simply calls "router'
In Wireshark, we see that the server status request sent by
the Kali box, has received a server status request response.
Let's try a UDP scan with port 67 now looking for
a DHCP server in that little box called router.
Nmap now reports that port 67 is now open or filtered
In Wireshark, after changing the display filter from
port 53 to 67 we can see that Wireshark shows that there is no
response from the DHCP server like we got from the DNS server.
Since DHCP servers only listen on port 67 for UDP traffic
an ACK scan which uses TCP won't help here.