EH-Net

here is a new tool i made for network recon. Basically it brute forces subdomains like any DNS analysis tool would but what makes dns2geoip.py different is the fact that it then geolocates the subdomains it finds and outputs their location to a kml file that is compatible with Google earth. This tool is ideal for wireless penetration tests where you want to know what services they run in house and which services they run out of a data center, but it is useful for scoping a normal network penetration test too.

https://github.com/thsle3p/code-for-pentesting

Interesting looking script, thanks for sharing.

I'll definitely keep it in my bag of tricks for a rainy day and let you know how it goes.

When looking at the code, I just heard Vivek's voice, "Try making it multithreaded!" Maybe I need a break from SPSE :)

Nice work. Thanks for sharing.

I would have made it multi-threaded, but the thing with brute forcing DNS is it's noisy-ish, not as noisy as a Zone-transfer but even a half-assed IDS would pick up multi-threaded DNS brute force. also in my Experience python does not do multi-threading well.

<grin> bwahahaha!

Oh, I wasn't giving you a hard time. It's just a common next-step-challenge for some of the things you do in SPSE.

On a serious note, the effectiveness of threading depends on what you want to do. The interpreter itself only has one CPU thread (http://docs.python.org/2/glossary.html#term-global-interpreter-lock), so trying to thread CPU-intensive tasks like password cracking won't be very effective. However, for things like network-based tasks where you have to deal with latency, waiting for responses, etc., multiple threads can speed things up significantly. It really depends on where your bottleneck is.

Also, you could query another DNS server, such as OpenDNS, Google, etc., instead of using the target's own DNS servers. They would certainly still see the requests coming in, but it wouldn't give you away.

Against a modern IDS i am not so sure they would not notice and do you really want to risk ending a pen test during the recon phase, because you got caught? I would rather deal with a slightly slow stealthy scan then a fast loud and noticeable scan.

Just to be clear, I'm really not encouraging you to try to multithread this. That was only a joke for others that are doing the SPSE.

Regarding stealth, I honestly wouldn't consider hundreds or thousands of failed queries to be stealthy in the first place, even if they are performed serially, unless maybe you put a substantial delay between each one.

I'd be curious to see how many organizations actually have enabled signatures for failed DNS queries. That seems like a signature that would be constantly alerting due to regular internet noise.

I just looked at the Snort rules, and they have several that can alert on excessive queries/responses, but these are not enabled default. It looks like the default signature set doesn't even alert on zone transfer attempts either.

If you wanted to be extremely stealthy, you could query popular DNS servers (such as the ones I mentioned before), and disable recursion. That way, you're reviewing the cache of your specified DNS server, and never sending a packet to the target. Granted, the trade-off is you'd miss anything that wasn't queried recently.

Dig's +norecursive option will do this. I just glanced at the dnspython library, but it doesn't look like they support this option. Unlike multithreading, extending a class to provide this capability would probably be an interesting addition :)