Tag Archives: information gathering

Active Information Gathering for Windows with Superscan

You can get a surprising amount of information from a Windows machine if it has port 445 open, especially if you happen to have a working user account on the machine (such as an account credential grabbed from another machine on the same domain).

Setup Your Testbed

All you need to do is take any Windows host, and share something.  For example, create a new folder on the desktop.  Then right click on that folder, and click Properties.  There is a Sharing tab.


Make sure you have also created a user with a password on this machine.


How do you find a vulnerable host?

Any Windows host with file sharing will do.  These hosts are usually pretty obvious when running a nmap port scan.  Ports 135, 139, and 445 will most often be open.

How do you attack that host?

There are a number of tools and metasploit modules that do smb enumeration (try out auxiliary/scanner/smb/smb_lookupsid).  However, there is an older tool that seems to work the best called superscan.  It still works fine on all modern Windows operating systems, but you need to run it as an Administrator (right click, run as administrator).

Superscan gives you a number of tabs with tools (lets be honest – these other tools aren’t all that useful), but we’re going to look at the Windows Enumeration tab.  Simply type in the IP of the machine you setup, and click Enumerate.



It’ll run all the modules, and most likely it’ll come back only with information on the NULL session connection and the RPC services.  However if you can run an authenticated scan, it is a gold mine of information.  Click on Options and enter your credentials and run the scan again.

Now you’ve got all sorts of information on the remote system, including all the groups (who are the administrative users? very useful), usernames, other shares available, uptime, account policies, who logged in last, etc.  This is great, especially when you can’t access this information through RDP or anything else.

Hacking and Active Information Gathering with SNMP

SNMP can be a valuable information gathering resource.  The very purpose of SNMP is to give information about the system to whoever queries it.  Sometimes SNMP is not adequately locked down, and anyone can grab information from it.  For example, a router with SNMP on can give up its full configurations, including passwords to other services, open ports, etc.

A quick note on SNMP.  You’ll see SNMPv2 and SNMPv3 used.  SNMPv3 is newer and better secured.  You can use encryption, full username/password, etc.  SNMPv2 is older, but more widely used (and easier to implement).  As the password to get into the system, it uses what it calls the community string.  By default, that string is often simply “public”.

Setup Your Testbed

Unfortunately, Metasploitable does not already have SNMP enabled, so we’ll have to do with a basic Ubuntu install.  Simply install the SNMP services:

# apt-get install snmpd

Then edit the configuration file located in /etc/snmp/snmpd.conf.  Right at the beginning of that file is an agentAddress option.  By default, it will allow local connections only (good security), but we want to allow connections from anyone (bad security).  So comment out the first agentAddress option, and uncomment the second agentAddress option as shown.

snmp config

Finally, restart the SNMP service:

# /etc/init.d/snmpd restart

And you should be all setup with your testbed.


How do you find a vulnerable host?

The easiest way is a simple port scan on UDP port 161:

$ nmap -sU -p161

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-04 14:57 EST
Nmap scan report for ubuntu.home (
Host is up (0.010s latency).
161/udp open snmp
MAC Address: 00:0C:29:AE:92:10 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

You can also just try one of the tools listed below, but they can a while to timeout.  Sometimes the TCP port 161 is also open, which gives you a good clue during a normal TCP nmap scan.  There are also nessus plugins and metasploit modules (auxiliary/scanner/snmp/snmp_login) to help.

msf > use auxiliary/scanner/snmp/snmp_login
msf auxiliary(snmp_login) > set RHOSTS
msf auxiliary(snmp_login) > set THREADS 10
msf auxiliary(snmp_login) > run
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[+] SNMP: community string: ‘public’ info: ‘Linux ubuntu 3.2.0-29-generic-pae #46-Ubuntu SMP Fri Jul 27 17:25:43 UTC 2012 i686’
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[*] :161SNMP – [001/118] – – SNMP – Trying public…
[+] SNMP: community string: ‘public’ info: ‘Brother NC-200w, Firmware Ver.0.09 ,MID 8CA-J15-001’

As you can see, the scan found our vulnerable host we just setup ( as well as a printer of mine ( – which I had no idea used SNMP until just now).  Both use the public community string.

How do you attack that host?

There are lots of tools you can use.  You can (very tediously) use manual command line syntax, which I will not go over.  An upgraded version of that is to use a MIB browser.  iReasoning has a great one that is freely available for personal use.  Download and install the application.  Then on the toolbar, enter the host you are targetting under Address, and then change the Operations dropdown from Get Next to Walk.  Then click Go:

mib browser


Full use of this tool is beyond the scope of this post, but you can see that you get back lots of valuable information.

Backtrack also comes with a number of tools, located under /pentest/enumeration/snmp.  The snmpcheck tool will give you the same information, just formatted in a different way by typing:

$ ./snmpcheck-1.8.pl -t

snmpcheck.pl v1.8 – SNMP enumerator
Copyright (c) 2005-2011 by Matteo Cantoni (www.nothink.org)

[*] Try to connect to
[*] Connected to
[*] Starting enumeration at 2013-02-04 15:19:02

[*] System information
——————————————————————————- —————-

Hostname : ubuntu
Description : Linux ubuntu 3.2.0-29-generic-pae #46-Ubuntu SMP Fri J ul 27 17:25:43 UTC 2012 i686
Uptime system : 1 hour, 04:13.84
Uptime SNMP daemon : 58 minutes, 31.08
Contact : Me <me@example.org>
Location : Sitting on the Dock of the Bay
Motd : –

[*] Network information
——————————————————————————- —————-

IP forwarding enabled : –
Default TTL : –
TCP segments received : –
TCP segments sent : –
TCP segments retrans. : –
Input datagrams : –
Delivered datagrams : –
Output datagrams : –

[*] Enumerated in 0.37 seconds

The public community is used by default here.  There isn’t a whole lot of real useful information in our test system, but other systems could contain a wealth of additional information.  For example, even my printer gave pages of information on its interfaces, routing tables, other open ports, etc.

Hacking and Information Gathering with DNS Zone Transfer Attacks

Information gathering is one of the first phases of a penetration test.  A wealth of information can be found in DNS records – if you can get them.  DNS records can give you an idea of the IP schema used, important servers, etc.  This information can be used to intelligently guess other IP spaces, and know what other servers you can focus on.

An unsecured DNS server will allow anyone to perform a zone transfer, allowing you full access to the records stored on there.

Setup Your Testbed

Setting up an entire DNS system is beyond the scope of this blog.  This particular attack can be performed safely against nearly any domain on the internet.  Most domains should fail a zone transfer, but you may find one that works.  If you do want to setup a DNS server, opening yourself up to a zone transfer is pretty simple.  Below is an example of a DNS entry for in your named.conf file for example.org:

zone “example.org” {
type master;
allow-transfer {;};
also-notify {;};
file “/etc/bind/pri.example.org”;

In this setup, is the slave DNS server.  If you want to open yourself up to a zone transfer from anyone, simply remove the allow-transfer line and reload bind.  You will find you are now open to a zone transfer.


How do you find a vulnerable host?

The easiest way is just to try the attack.  If you run an nmap scan on a host and find port 53 open, try a zone transfer against that host.

How do you attack that host?

I’ll go over 3 ways to do it, using 3 different utilities.  I’ll use avhackers.com, which is just a parked domain as of this writing, but does have zone transfers enabled.  For each way, you first need to find the name servers of a domain, and then query that name server to do a transfer for the domain.

The first way is using the DNS tool, dig.  First query the domain for the name servers:

$ dig ns avhackers.com

; <<>> DiG 9.7.0-P1 <<>> ns avhackers.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35312
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 6

;avhackers.com. IN NS

avhackers.com. 84804 IN NS ns2.sedoparking.com.
avhackers.com. 84804 IN NS ns1.sedoparking.com.

ns1.sedoparking.com. 1066 IN A
ns1.sedoparking.com. 1066 IN A
ns1.sedoparking.com. 1066 IN A
ns2.sedoparking.com. 1329 IN A
ns2.sedoparking.com. 1329 IN A
ns2.sedoparking.com. 1329 IN A

;; Query time: 41 msec
;; WHEN: Fri Feb 1 14:33:16 2013
;; MSG SIZE rcvd: 175

You can see the answer section contains 2 name servers.  I’ll just pick one of them (doesn’t matter which), and query that name server directly, asking for a zone transfer of the avhackers.com domain:

$ dig @ns1.sedoparking.com avhackers.com axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.sedoparking.com avhackers.com axfr
; (3 servers found)
;; global options: +cmd
avhackers.com. 86400 IN SOA ns1.sedoparking.com. hostmaster.sedo.de. 2007021501 86400 10800 604800 86400
. 86400 IN NS ns1.sedoparking.com.
. 86400 IN NS ns2.sedoparking.com.
. 600 IN A
avhackers.com. 86400 IN SOA ns1.sedoparking.com. hostmaster.sedo.de. 2007021501 86400 10800 604800 86400
;; Query time: 280 msec
;; WHEN: Fri Feb 1 14:35:49 2013
;; XFR size: 5 records (messages 3, bytes 294)

This particular domain doesn’t have anything exciting (the . IN A basically means there aren’t any subdomains), but you can see the zone transfer was successful.  Just to contrast, here is an example of a failed zone transfer:

$ dig @ns1.google.com google.com axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.google.com google.com axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

Now for method #2.  This is using the host utility.  First find the DNS servers for the domain:

$ host -t ns avhackers.com
avhackers.com name server ns2.sedoparking.com.
avhackers.com name server ns1.sedoparking.com.

Then pick a DNS server and request a transfer:

$ host -l avhackers.com ns2.sedoparking.com
Using domain server:
Name: ns2.sedoparking.com

. name server ns1.sedoparking.com.
. name server ns2.sedoparking.com.
. has address

As you can see, this is the same information as from dig, but formatted differently.  Finally, you can try the dnsenum tool that comes installed with Backtrack.  This tool does it all in one step:


Once again, all the same information, but formatted differently.  Good luck with your DNS zone transfers!