I found a really cool thing several months ago. I was scanning my network from an external perspective (AWS specifically), and found a live host. The very odd thing about this finding is that there were no open ports, no listening services, and ICMP requests were disabled. I -nearly- chalked this up as a bug in the vuln scanner, but I don't like mysteries.
I actually figured this out halfway into a short write-up for our team. There was initially a lot of confusion though as to how I was getting a response, both because of the no open ports, and because there was no firewall entry for this host that should have allowed communication in the first place.
Let’s start with the inside. -PS does a host discovery TCP SYN/ACK scan. Note that this is for host discovery, and is not part of the port scan (not equivalent to -sT or -sS). If we use this with port 53 on a DNS server, Nmap receives a reply, indicating the system is alive, and then proceeds to do a service scan of the indicated ports (81) and finds nothing (no-response). This is the expected behavior.
If we try this on the same server with a closed port, we get no response (note: no RCVD from the target), and the TCP scan never kicks off. Again, expected behavior.
So now we understand the behavior of a typical server. Here’s the “odd” server. Any port that is scanned returns an ICMP host-prohibited message. Ok, so odd, but explainable, the server has just been configured (for whatever reason) to return this instead of dropping the packet.
Now let’s look at it from the outside, exact same scan, but originating from AWS. As expected, we receive no response because the perimeter firewall has no rules for this server. The TCP packet on weird port X is dropped before reaching the server.
However, a TCP packet on 80, AND ONLY 80, receives a response from the outside.
Again though, there are no perimeter firewall rules for this specific host. That must mean an entire range is opened up. TADA! The entire x.x.18.0/24 has port 80 inbound open, despite having no hosts listening on 80.
As another side note, the scan for this when you either specify multiple ports, looks VERY odd. You get a message such as:
All 1000 scanned ports on SERVERNAME (x.x.18.17) are filtered because of 999 no-responses and 1 host-prohibited
However, scrolling back through the logs, you don’t receive a single TCP packet back from the target, so it’s impossible to tell what port generated the 1 host-prohibited and which generated the 999 no-response.
Nmap is amazing, and if you're in infosec, you should read more than just the abbreviated --help page. In this case, the specific flags -v (verbose), -d 6 (debug level 6) and --packet-trace was amazingly useful. If you're ever not sure about what you're looking at, turn these on. -PS is also very useful for doing host discovery prior to a full scan, but giving a lot more options than the typical host discovery.