EH-Net

Port scanning is obviously the most common approach for determining what service daemons exist on a host, but it isn't the only way. An IDS that detects portscans might be a helpful tool to give an admin a headsup in SOME scenarios, but depending on a hacker to portscan is like picking low-hanging fruit.

As researchers, we should be aware of all possible avenues for an attacker to accomplish a goal.

So how else might an attacker enumerate which service ports are available on a remote server?

If SNMP is available and the community strings are default/guessable, often this can provide an interface for listing listening ports. This is interesting because we can often retrieve the entire TCP connection table (including all established connections/listening ports) using only SNMP. This could allow an attacker to glean even MORE information than a portscan would if there was a firewall in place.

Another way would be through a zone transfer. Often times DNS names clearly indicate a service. If zone transfers aren't disallowed to the attacker, this could be a useful feature:


These are only a few. Can anyone else think of uncommon methods for accomplishing common hacker tasks? portscanning or otherwise?

I don't think that DNS records could be used in this situation. Just because there is a DNS record and also because the appropriate port is open, doesn't mean that the server is up and running. I know this for a fact from my work experience.

The best way to determine the service is to telnet to it. This will usually also give you a banner with the type of service running, i.e. Apache webserver or Microsoft Exchange etc.

Another way would be to use vulnerability scanners like Nessus.

i guess i appreciate you using LSO as an example :- ???

a real "old school zone transfer" would have shown the mappings to our internal and external facing boxes.  what you put would be necessary for normal functioning of those services...

Well If you are on a LAN, a sniffer will tell you which Servers are running which applications as long as somebody in that VLAN/switch communicates.

I should have indicated 2 things, first that allowing zone transfers doesn't necesarily indicate bad security (for instance, in the LSO example nothing is being displayed that wouldn't be available normally), and second that these alternative methods sometimes produce false positives, as negrita indicated, however they do still give an indication of certain probabilities.