Learning remote enumeration (Part 1)

When many people hear the term “enumeration”, they think “port scanning.” But enumeration is so much more than that.

There are two major categories of enumeration:

  • Remote enumeration
  • Local enumeration

To properly perform remote enumeration on an unknown target, I prefer the following steps:

  1. Quickly determine what hosts are on the network
  2. Quickly port scan the discovered hosts for low-hanging fruit
  3. Perform a more thorough port scan of the discovered hosts
  4. Begin enumerating the hosts via the various available services
  5. Start looking for possible remote vulnerabilities

1. Quickly determine what hosts are on the network

The typical way people tend to look for hosts in a subnet is a ping scan. This is a Layer 3 scan that relies on ICMP. The problem is that it’s somewhat slow, and somewhat unreliable, as hosts may be behind a firewall that may prevent an incoming ICMP packet from reaching the host, and/or prevent the host from sending a response.

Some people prefer to use Layer 4 approaches, like TCP SYN scans, to get around this issue. However, this is somewhat slow, and also requires the attacker to perform a separate UDP scan of the target.

I prefer an ARP scan. This can be done either using netdiscover or nmap (there are a few other tools that are useful for ARP scanning, but I won’t be discussing them here). A typical nmap ARP scan looks something like:

root@kali:~# nmap -sn -n -T4 192.168.17.0/24

The output will resemble:

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:05 EDT
Nmap scan report for 192.168.17.1
Host is up (0.00054s latency).
MAC Address: 00:50:56:C0:00:01 (VMware)
Nmap scan report for 192.168.17.129
Host is up (0.00015s latency).
MAC Address: 00:0C:29:B0:08:FC (VMware)
Nmap scan report for 192.168.17.254
Host is up (0.000047s latency).
MAC Address: 00:50:56:E5:E4:39 (VMware)
Nmap scan report for 192.168.17.128
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 1.71 seconds

If we want to make this a little more useful, we could just grab the IPs and put them in a file. Then we can edit the file to remove the low and high IPs (and our own, if it winds up in there):

root@kali:~# nmap -sn -T4 -n 192.168.17.0/24 |grep report |awk '{print $5}' >hostlist.txt

2. Quickly port scan the discovered hosts for low-hanging fruit

Now that we have a list of targets, we can do a quick port scan with version identification to determine what low-hanging fruit exists. Ideally, a script would run the ARP scan, grab the IPs from the discovered hosts, filter out the first and last addresses (in the case of a /24, .1 and .254), and supply them to this command.

This will take the IPs from the list we generated above (after editing to remove the irrelevant ones), skip checking to see if they’re up (we’ve just done that), and perform OS detection, version detection on any open ports in the top 1000 most popular ports, default NSE script scanning, and traceroute:

root@kali:~# nmap -A -Pn -iL hostlist.txt 

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:12 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00031s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
|   1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
|   1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_  1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp   open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp  open  rpcbind     2 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100024  1           1024/tcp  status
|_  100024  1           1026/udp  status
139/tcp  open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp  open  ssl/http    Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Not valid before: 2009-09-26T09:32:06
|_Not valid after:  2010-09-26T09:32:06
|_ssl-date: 2016-08-05T16:13:30+00:00; +1m03s from scanner time.
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC2_CBC_128_CBC_WITH_MD5
|_    SSL2_RC4_128_EXPORT40_WITH_MD5
1024/tcp open  status      1 (RPC #100024)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100024  1           1024/tcp  status
|_  100024  1           1026/udp  status
MAC Address: 00:0C:29:B0:08:FC (VMware)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop

Host script results:
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

TRACEROUTE
HOP RTT     ADDRESS
1   0.31 ms 192.168.17.129

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.23 seconds

3. Perform a more thorough port scan of the discovered hosts

Now we have a MUCH more detailed look at what’s running on that particular target. From here, we could run the same scan on all 65,535 ports, just to make sure we didn’t miss anything. The reason we don’t do this right off the bat is because it took 30 times as long to scan this one host as it did to do an ARP scan of the entire subnet. We want to fire off the complete scan in the background while we work on some of the information we’ve already uncovered about this target. The scan would look something like:

root@kali:~# nmap -A -Pn -p- -iL hostlist.txt 

The only thing we changed was the addition of -p- which is shorthand for telling nmap to scan ports 1-65535. We should probably redirect the output to a file for later perusal (this should, in fact, be the default for every scan you run. Keeping these things in your notes, well-organized, will form the basis of the report you’ll need to turn in at the end of the course).

4. Begin enumerating the hosts via the various available services

As you can see from the output above, this scan not only gave us version information for the services it discovered, but did some further enumeration on those services: it grabbed the SSH hostkey, it enumerated the HTTP methods available on port 80, grabbed the HTTP header information, the HTTP title, grabbed the rpcinfo information from port 111, the workgroup name from the SAMBA server on port 139, the HTTP methods available on port 443, the SSL cert information, the SSL implementation details, and the NetBIOS data.

All of that information is enumeration, too. And now that we have this detailed information, we can go through some of the nmap NSE scripts that aren’t part of the default set of scripts run by the -A option and enumerate even further.

To see the list of NSE scripts available, you can look through them all in /usr/share/nmap/scripts in Kali Linux. To find out what each does, you can run the command:

root@kali:~# nmap --script-help="*" >nse-scripts.txt

And then read the nse-scripts.txt file you just created. This is the help output for every available NSE script installed in your VM. As you read through them, pay particular attention to those that might prove useful against the targets you just scanned. For example, the target above has:

OpenSSH 2.9p2
Apache 1.3.20 with mod_ssl 2.8.4 and OpenSSL 0.9.6b
rpcbind
Samba

What would be useful here? NSE scripts like…

http-enum
root@kali:~# nmap -Pn --script="http-enum" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:31 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00019s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
| http-enum: 
|   /test.php: Test page
|   /icons/: Potentially interesting directory w/ listing on 'apache/1.3.20'
|   /manual/: Potentially interesting directory w/ listing on 'apache/1.3.20'
|_  /usage/: Potentially interesting folder
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
| http-enum: 
|_  /test.php: Test page
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 28.14 seconds
http-comments-displayer
root@kali:~# nmap -Pn --script="http-comments-displayer" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:32 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00011s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
| http-comments-displayer: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.17.129
|     
|     Path: http://192.168.17.129:80/
|     Line number: 6
|     Comment: 
|_        <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
| http-comments-displayer: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.17.129
|     
|     Path: https://192.168.17.129:443/
|     Line number: 6
|     Comment: 
|_        <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 6.90 seconds
http-sitemap-generator
root@kali:~# nmap -Pn --script="http-sitemap-generator" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:37 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00014s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; png: 1
|     /icons/
|       gif: 1
|   Longest directory structure:
|     Depth: 1
|     Dir: /icons/
|   Total files found (by extension):
|_    Other: 1; gif: 1; png: 1
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; png: 1
|     /icons/
|       gif: 1
|   Longest directory structure:
|     Depth: 1
|     Dir: /icons/
|   Total files found (by extension):
|_    Other: 1; gif: 1; png: 1
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 6.92 seconds
http-userdir-enum
root@kali:~# nmap -Pn --script="http-userdir-enum" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:38 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00012s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
|_http-userdir-enum: Potential Users: root
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
|_http-userdir-enum: Potential Users: root
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

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

There are a lot more http-* scripts, many of which I skipped over because they weren’t applicable or yielded no results.

5. Start looking for possible remote vulnerabilities

There are all the smb-vuln scripts:
root@kali:~# nmap -Pn --script="smb-vuln-*" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 13:01 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00014s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

Host script results:
| smb-vuln-cve2009-3103: 
|   VULNERABLE:
|   SMBv2 exploit (CVE-2009-3103, Microsoft Security Advisory 975497)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2009-3103
|           Array index error in the SMBv2 protocol implementation in srv2.sys in Microsoft Windows Vista Gold, SP1, and SP2, 
|           Windows Server 2008 Gold and SP2, and Windows 7 RC allows remote attackers to execute arbitrary code or cause a 
|           denial of service (system crash) via an & (ampersand) character in a Process ID High header field in a NEGOTIATE 
|           PROTOCOL REQUEST packet, which triggers an attempted dereference of an out-of-bounds memory location, 
|           aka "SMBv2 Negotiation Vulnerability." 
|           
|     Disclosure date: 2009-09-08
|     References:
|       http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3103
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3103
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: SMB: ERROR: Server returned less data than it was supposed to (one or more fields are missing); aborting [14]

Nmap done: 1 IP address (1 host up) scanned in 11.90 seconds
…and all of the SSL scripts:
root@kali:~# nmap -Pn --script="ssl-*" 192.168.17.129

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-05 12:51 EDT
Nmap scan report for 192.168.17.129
Host is up (0.00020s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
443/tcp  open  https
| ssl-ccs-injection: 
|   VULNERABLE:
|   SSL/TLS MITM vulnerability (CCS Injection)
|     State: VULNERABLE
|     Risk factor: High
|       OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h
|       does not properly restrict processing of ChangeCipherSpec messages,
|       which allows man-in-the-middle attackers to trigger use of a zero
|       length master key in certain OpenSSL-to-OpenSSL communications, and
|       consequently hijack sessions or obtain sensitive information, via
|       a crafted TLS handshake, aka the "CCS Injection" vulnerability.
|           
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224
|       http://www.openssl.org/news/secadv_20140605.txt
|_      http://www.cvedetails.com/cve/2014-0224
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Issuer: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: md5WithRSAEncryption
| Not valid before: 2009-09-26T09:32:06
| Not valid after:  2010-09-26T09:32:06
| MD5:   78ce 5293 4723 e7fe c28d 74ab 42d7 02f1
|_SHA-1: 9c42 91c3 bed2 a95b 983d 10ac f766 ecb9 8766 1d33
|_ssl-date: 2016-08-05T16:52:31+00:00; +1m03s from scanner time.
| ssl-dh-params: 
|   VULNERABLE:
|   Transport Layer Security (TLS) Protocol DHE_EXPORT Ciphers Downgrade MitM (Logjam)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2015-4000  OSVDB:122331
|       The Transport Layer Security (TLS) protocol contains a flaw that is triggered
|       when handling Diffie-Hellman key exchanges defined with the DHE_EXPORT cipher.
|       This may allow a man-in-the-middle attacker to downgrade the security of a TLS
|       session to 512-bit export-grade cryptography, which is significantly weaker,
|       allowing the attacker to more easily break the encryption and monitor or tamper
|       with the encrypted stream.
|     Disclosure date: 2015-5-19
|     Check results:
|       EXPORT-GRADE DH GROUP 1
|             Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
|             Modulus Type: Safe prime
|             Modulus Source: mod_ssl 2.0.x/512-bit MODP group with safe prime modulus
|             Modulus Length: 512
|             Generator Length: 8
|             Public Key Length: 512
|     References:
|       http://osvdb.org/122331
|       https://weakdh.org
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4000
|   
|   Diffie-Hellman Key Exchange Insufficient Group Strength
|     State: VULNERABLE
|       Transport Layer Security (TLS) services that use Diffie-Hellman groups of
|       insufficient strength, especially those using one of a few commonly shared
|       groups, may be susceptible to passive eavesdropping attacks.
|     Check results:
|       WEAK DH GROUP 1
|             Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA
|             Modulus Type: Safe prime
|             Modulus Source: mod_ssl 2.0.x/1024-bit MODP group with safe prime modulus
|             Modulus Length: 1024
|             Generator Length: 8
|             Public Key Length: 1024
|     References:
|_      https://weakdh.org
| ssl-enum-ciphers: 
|   SSLv3: 
|     ciphers: 
|       TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 1024) - F
|       TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D
|       TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - D
|       TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - D
|       TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D
|       TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E
|       TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - F
|       TLS_RSA_WITH_DES_CBC_SHA - F
|       TLS_RSA_WITH_RC4_128_MD5 - F
|       TLS_RSA_WITH_RC4_128_SHA - F
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Insecure certificate signature: MD5
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 1024) - F
|       TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D
|       TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 - D
|       TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 - D
|       TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D
|       TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E
|       TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - F
|       TLS_RSA_WITH_DES_CBC_SHA - F
|       TLS_RSA_WITH_RC4_128_MD5 - F
|       TLS_RSA_WITH_RC4_128_SHA - F
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Ciphersuite uses MD5 for message integrity
|       Insecure certificate signature: MD5
|_  least strength: F
| ssl-google-cert-catalog: 
|_  No DB entry
| ssl-poodle: 
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs:  CVE:CVE-2014-3566  OSVDB:113251
|           The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and
|           other products, uses nondeterministic CBC padding, which makes it easier
|           for man-in-the-middle attackers to obtain cleartext data via a
|           padding-oracle attack, aka the "POODLE" issue.
|     Disclosure date: 2014-10-14
|     Check results:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|     References:
|       http://osvdb.org/113251
|       https://www.openssl.org/~bodo/ssl-poodle.pdf
|       https://www.imperialviolet.org/2014/10/14/poodle.html
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
1024/tcp open  kdm
MAC Address: 00:0C:29:B0:08:FC (VMware)

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

Note that we were able to run entire sets of scripts by specifying them with a wildcard character (*) rather than by name. So, rather than running each http script by name, we could have specified http-* to run them all at once, as we did with the SMB and SSL scripts. The reason it’s wise to avoid that at times is because sometimes certain scripts require additional information in the form of variables. Sometimes, the scripts just aren’t relevant and you’ll waste time running them. Sometimes, they’ll misbehave or cause the target to misbehave, and by using wildcards, you won’t know which one is to blame.

Now, we can do a bit of remote enumeration with dirb:
root@kali:~# dirb http://192.168.17.129

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Fri Aug  5 13:07:38 2016
URL_BASE: http://192.168.17.129/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://192.168.17.129/ ----
+ http://192.168.17.129/~operator (CODE:403|SIZE:273)                                                                                                  
+ http://192.168.17.129/~root (CODE:403|SIZE:269)                                                                                                      
+ http://192.168.17.129/cgi-bin/ (CODE:403|SIZE:272)                                                                                                   
+ http://192.168.17.129/index.html (CODE:200|SIZE:2890)                                                                                                
==> DIRECTORY: http://192.168.17.129/manual/                                                                                                           
==> DIRECTORY: http://192.168.17.129/mrtg/                                                                                                             
==> DIRECTORY: http://192.168.17.129/usage/                                                                                                            
                                                                                                                                                       
---- Entering directory: http://192.168.17.129/manual/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)
                                                                                                                                                       
---- Entering directory: http://192.168.17.129/mrtg/ ----
+ http://192.168.17.129/mrtg/index.html (CODE:200|SIZE:17318)                                                                                          
                                                                                                                                                       
---- Entering directory: http://192.168.17.129/usage/ ----
+ http://192.168.17.129/usage/index.html (CODE:200|SIZE:3704)                                                                                          
                                                                                                                                                       
-----------------
END_TIME: Fri Aug  5 13:08:06 2016
DOWNLOADED: 13836 - FOUND: 6

If we wanted to, we could even grab screenshots of each page found using cutycapt:

root@kali:~# cutycapt --url=http://192.168.17.129/index.html --out=192.168.17.129-index.html.jpg

…and then use eog at our leisure to view it from the command line:

root@kali:~# eog 192.168.17.129-index.html.jpg 

So, as you can see, we’ve managed to do quite a bit of remote enumeration just using nmap: From locating live targets on the network, to getting detailed information about what ports are open and what’s listening on each port, to enumerating available files and network infrastructure information, and even some vulnerability scanning – all within nmap.

Add in useful tools like dirb and cutycapt, and you have a solid basis for moving forward.

By the way, the scan of this particular host across all 65,535 ports yielded no additional information. But it’s good to do anyway…just don’t sit there waiting for it to finish before doing anything else.

Also, notice that the NSE http scripts turned up different directories than dirb did. That’s because the two serve different purposes, and approach things differently. Don’t just assume that one tool designed to crawl a webserver is as good as another.

A likely next step from here would be to run nikto against the target, to further clarify our remote exploitation possibilities.

root@kali:~# nikto -host 192.168.17.129
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.17.129
+ Target Hostname:    192.168.17.129
+ Target Port:        80
+ Start Time:         2016-08-05 14:29:13 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Wed Sep  5 23:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL.
+ OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html.
+ OSVDB-3268: /manual/: Directory indexing found.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /icons/: Directory indexing found.
+ ERROR: Error limit (20) reached for host, giving up. Last error: error reading HTTP response
+ Scan terminated:  20 error(s) and 19 item(s) reported on remote host
+ End Time:           2016-08-05 14:36:00 (GMT-4) (407 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

As you can see, there are a number of potential remote shells to be had.

To find out the Samba version, we could use smbclient:

 smbclient -L //KIOPTRIX -I 192.168.17.129

WARNING: The "syslog" option is deprecated
Enter root's password: 
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       IPC Service (Samba Server)
	ADMIN$          IPC       IPC Service (Samba Server)

	Server               Comment
	---------            -------
	KIOPTRIX             Samba Server

	Workgroup            Master
	---------            -------
	MYGROUP              KIOPTRIX
	WORKGROUP            GAMINGRIG
Bug BountyOSCP