Reconnaissance - Active Scanning
Guide and examples
Last updated: 10 september 2024
> 1.2.1 Nmap service and version scan
> 1.2.2 Nmap vulnerability scan
> 1.3.1 Gobuster directory bruteforce
> 1.3.2 DirSearch directory bruteforce
> 1.3.3 ffuf subdomain bruteforce
-
Active Scanning
1.1 Scanning IP Blocks
Larger companies like Microsoft or Google may have IP blocks or IP ranges of public IP addresses assigned to them. These IP blocks can be scanned to gather information on the company. Each IP address in the IP block(s) found can be iterated, checked for availability and a reverse IP lookup can be performed to generate a list of (sub)domains related to that company. Every result could be a vector for further information gathering, or compromise of the company. Let's learn how we go about gathering this information.
1.1.1 Finding IP blocks
A useful toolkit in finding company IP blocks is the BGP Toolkit. It allows you to query for information using an ASN number, company name or an IP address. If you haven't got an ASN number yet then the initial goal is to obtain one, which you can then use to display IP block information. You can obtain the ASN number by querying the tooliit with a company name or an IP address. Another tool
In the following example we will query for "Porsche". As you can see the tool returns multiple results, including 7 ASN numbers. Since Porsche's roots are in germany, we're going to pick AS33848.
We get a lot of information about the company once we get a proper ASN number. There are multiple tabs available to us with information, but the most useful one at this point is Prefixes v4. Here we can see multiple IP block ranges which are in use by Porsche. All of those which have at least a matching description can be used to gather more information on Porsche.
1.1.2 Finding (sub)domains
BGP Toolkit
One way to get a list of subdomains is to navigate to an IP block on the BGP Toolkit and select the DNS tab. We will take the first IP block in the list (84.21.32.0/22). Although this method seems to provide outdated information for certain endpoints. A couple of subdomains i've tested were no longer online. A better approach would be to use Nmap.
Nmap
A better way to gather subdomains on IP blocks is to run an Nmap scan. In the code below the -sn option is used to perform a host discovery scan without an additional port scan. This simply sends an ICMP echo request and some other packets to every IP in the IP range to check if they're reachable. If they are, it will also attempt to do a reverse DNS lookup on the IP address to discover a possible domain attached to the IP address. In general this seems to be a superior way to discover active endpoints as this only returns endpoints which are currently online.
┌─[r00t@parrot]─[~]
└──╼ $nmap -sn 84.21.32.0/22
...
Nmap scan report for 84.21.32.194
Host is up (0.097s latency).
Nmap scan report for dns.porsche.de (84.21.32.195)
Host is up (0.099s latency).
Nmap scan report for dns.porsche.ch (84.21.32.196)
Host is up (0.10s latency).
Nmap scan report for 84.21.32.199
Host is up (0.087s latency).
Nmap scan report for preview.porsche.com (84.21.32.200)
Host is up (0.15s latency).
Nmap scan report for mspedit.porsche.com (84.21.32.201)
Host is up (0.20s latency).
Nmap scan report for 84.21.32.202
Host is up (0.17s latency).
Nmap scan report for dealeredit.porsche.com (84.21.32.203)
Host is up (0.093s latency).
Nmap scan report for preview.porscheengineering.com (84.21.32.204)
Host is up (0.095s latency).
Nmap scan report for external.porsche.com (84.21.32.205)
Host is up (0.10s latency).
Nmap scan report for shopprev.porsche.com (84.21.32.206)
Host is up (0.058s latency).
Nmap scan report for geodns.porsche.de (84.21.32.207)
Host is up (0.063s latency).
Nmap scan report for 84.21.32.211
Host is up (0.17s latency).
...
Mitigation
Mitigating information gathering like this is very hard. The only way to really protect yourself against this type of reconnaissance is to minimize the data that's exposed to the internet, and to never expose sensitive data.
1.2 Vulnerability Scanning
With the information we've found so far it's possible to do more in-depth enumeration for each endpoint. With more in-depth scanning it's possible to discover more information such as which hardware and software is running on the endpoints with the corresponding version numbers, which are important to identify possible exploits.
1.2.1 Nmap service and version scan
Aggressive scanning of online endpoints without permission is not ideal, so we're not going to use Porsche for this example. Instead, here is a very good example of how an Nmap service and version scan can discover a critical vulnerability in a Windows 7 system. The following Nmap scan has discovered that our target system is running Windows 7 Service Pack 1, which we did not know prior to the scan.
└──╼ $nmap -sC -sV 192.168.0.44
Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-07 02:34 CET
Nmap scan report for 192.168.0.44
Host is up (0.023s latency).
Not shown: 991 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49156/tcp open msrpc Microsoft Windows RPC
49157/tcp open msrpc Microsoft Windows RPC
Service Info: Host: HARIS-PC; OS: Windows; CPE: cpe:/o:microsoft:windows
1.2.2 Nmap vulnerability scan
Now we could further leverage the power of Nmap and scan for specific vulnerabilities. Since Nmap detected the operating system version on port 445, we will narrow the vulnerability scan down to port 445 to speed up the scan. The -script option can be used to specify that we want to do a vulnerability scan using Nmap.
└──╼ $nmap -script vuln 192.168.0.44 -p 445
Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-07 03:14 CET
Pre-scan script results:
| broadcast-avahi-dos:
| Discovered hosts:
| 224.0.0.251
| After NULL UDP avahi packet DoS (CVE-2011-1002).
|_ Hosts are all up (not vulnerable).
Nmap scan report for 192.168.0.44
Host is up (0.024s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: NT_STATUS_OBJECT_NAME_NOT_FOUND
| smb-vuln-ms17-010:
| VULNERABLE:
| Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
| State: VULNERABLE
| IDs: CVE:CVE-2017-0143
| Risk factor: HIGH
| A critical remote code execution vulnerability exists in Microsoft SMBv1
| servers (ms17-010).
|
| Disclosure date: 2017-03-14
| References:
| https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143
|_ https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/
Nmap done: 1 IP address (1 host up) scanned in 50.24 seconds
As we can see Nmap has discovered a critical RCE vulnerability. If we Google about ms17-010, we quickly find out that this is related to the EternalBlue exploit. This is a simple example of how an endpoint can be scanned to gather information about it and possibly exploit it. In the following example the same scan is executed against a Linux system to enumerate open TCP ports with associated services running on them, with possible version numbers.
Starting Nmap 7.93 ( https://nmap.org ) at 2024-09-07 17:33 CEST
Nmap scan report for 192.168.0.43
Host is up (0.022s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 3539d439404b1f6186dd7c37bb4b989e (ECDSA)
|_ 256 1ae972be8bb105d5effedd80d8efc066 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.18.0 (Ubuntu)
8000/tcp open http SimpleHTTPServer 0.6 (Python 3.10.12)
|_http-server-header: SimpleHTTP/0.6 Python/3.10.12
|_http-title: Directory listing for /
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.04 seconds
With this information it's good practice to search the web for possible exploits for each version of the services we found. While it's not always possible to directly exploit a service, it's great to know which ports are open. We could for example run a number of enumeration tools on port 80 like Nikto or GoBuster to gather more info like subdomains or possible exploits, or perform manual testing to look for vulnerabilities like SSRF or SQL injection etc.
1.3 Wordlist scanning
Scanning the IP blocks of your target is a good way to gather information about them, but there is a way to gather more - possibly hidden - information, and that's by bruteforcing. For example, it's possible to take any wordlist and run it against an endpoint you found to discover hidden subdomains or directories. This way you can uncover hidden administrative portals, sensitive files or even development portals. The tools i usually use for this type of reconnaissance are GoBuster, DirSearch and ffuf. These tools work very well with the default wordlists from DirBuster or with SecLists. In the following example i used GoBuster to bruteforce for directories on a webserver.
1.3.1 Gobuster directory bruteforce
** Beware ** - Bruteforcing is a very noisy thing to do. When running an unthrottled bruteforce attack on anything that's being monitored, the logs of your target will light up like a christmas tree. If stealth needs to be maintained then consider a very patient, or even completely different approach.
root@linux:~# gobuster dir -u http://192.168.0.1 -w /usr/share/dirb/wordlists/common.txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://192.168.0.1
[+] Threads: 10
[+] Wordlist: /usr/share/dirb/wordlists/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2024/09/10 09:33:56 Starting gobuster
===============================================================
/.hta (Status: 403)
/.htaccess (Status: 403)
/.htpasswd (Status: 403)
/css (Status: 301)
/dev (Status: 301)
/fonts (Status: 301)
/images (Status: 301)
/index.html (Status: 200)
/js (Status: 301)
/php (Status: 301)
/server-status (Status: 403)
/uploads (Status: 301)
===============================================================
Gobuster returned some interesting directories like /dev and /uploads. These results were found with a default wordlist from DirBuster called common.txt.
1.3.2 DirSearch directory bruteforce
Although one specific tool can yield great results, it never hurts to run another one for good measure. Sometimes you would be surprised what else comes falling out the tree when you shake it a bit more. The following example shows DirSearch bruteforcing a different webserver. By default DirSearch uses it's own internal worldlist, but it is possible to provide your own.
└──╼ $sudo python3 dirsearch.py -u http://192.168.0.1
_|. _ _ _ _ _ _|_ v0.4.3
(_||| _) (/_(_|| (_| )
Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25 | Wordlist size: 11722
Output: /opt/dirsearch/reports/http_192.168.0.1/_24-04-05_18-02-33.txt
Target: http://192.168.0.1/
[18:02:33] Starting:
[18:04:22] 400 - 795B - /\..\..\..\..\..\..\..\..\..\etc\passwd
[18:04:29] 400 - 795B - /a%5c.aspx
[18:04:39] 302 - 0B - /accounting -> http://192.168.0.1/accounting/
[18:06:44] 302 - 0B - /catalog -> http://192.168.0.1/catalog/
[18:06:54] 302 - 0B - /common -> http://192.168.0.1/common/
[18:06:54] 404 - 762B - /common/
[18:06:54] 404 - 779B - /common/config/db.ini
[18:06:54] 404 - 780B - /common/config/api.ini
[18:06:59] 302 - 0B - /content -> http://192.168.0.1/content/
[18:06:59] 302 - 0B - /content/debug.log -> https://192.168.0.1/content/control/main
[18:06:59] 302 - 0B - /content/ -> http://192.168.0.1/content/control/main
[18:07:01] 200 - 11KB - /control/login
[18:07:03] 200 - 34KB - /control/
[18:07:04] 200 - 34KB - /control
The DirSearch scan resulted in a couple of interesting directories called /control and /control/login which could be investigated further.
1.3.3 ffuf subdomain bruteforce
Another vector for information gathering would be to bruteforce subdomains. This can be done with an interesting web fuzzer called ffuf. It's a little more complex to use, but below is a good example of how to perform a scan.
└──╼ $ffuf -u http://devvortex.htb -H "Host: FUZZ.devvortex.htb" -w /opt/SecLists/Discovery/DNS/subdomains-top1million-20000.txt -mc all -ac
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.0.0
________________________________________________
:: Method : GET
:: URL : http://devvortex.htb
:: Wordlist : FUZZ: /opt/SecLists/Discovery/DNS/subdomains-top1million-20000.txt
:: Header : Host: FUZZ.devvortex.htb
:: Follow redirects : false
:: Calibration : true
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: all
________________________________________________
[Status: 200, Size: 23221, Words: 5081, Lines: 502, Duration: 8556ms]
* FUZZ: dev
:: Progress: [19966/19966] :: Job [1/1] :: 1449 req/sec :: Duration: [0:00:17] :: Errors: 0 ::
This final example shows ffuf supplied with a SecLists subdomains wordlist, a target host from HackTheBox, and the location in the URL where the tool should bruteforce indicated by the word FUZZ. As the result shows, the tool tried 19966 options from the wordlist in 17 seconds and returns one positive result which is dev.devvortex.htb. This certainly is a very interesting subdomain to investigate further.
** For more information, check out the extra links and sources. **