Scope based recon

ManieshNeupane
Sep 4, 2021
4 min read

Updated: Sep 19, 2021

Reconnaissance (aka Recon) is an essential process in pentesting, especially Black Box Pentesting, where you don't have specifics about your target. Before starting to hit your target, it is important to gather as much information as possible about your target to specify your Attack Surface area. An "Attack Surface" is a fancy term used to define the "Viable Attack Points" for your target.

Recon comes in hand when gathering information about your target. Some people may consider recon as something to automate and find vulnerabilities. However, from my experience, recon is more about crafting a better Attack Surface that will allow you to have more Attack Vectors giving you a fair opportunity to uncover potential Security Vulnerabilities. Automation is an aspect of the recon, but the manual analysis also plays a crucial role.

In this article, I will talk about Scope Based Recon Methodology. Looking at how to perform recon and examine what methods are best to use based on your scope. Usually, it is not a good idea to apply the same type of recon to every scope; instead, it's good to select a toolkit based on your scope and customize your recon. I'll also discuss a few interesting tools that I use and some helpful life hacks for recon.

Let's dig into it!

The below image outlines a detailed mindmap for Scope Based Recon Methodology (which will be the base of this article).

What is Scope Based Recon Methodology?

Scope Based Recon Methodology divides the recon process based on scope. Sometimes you will get a wide scope target and sometimes just a single application to work on. In such scenarios, performing the same amount of recon is less fruitful and time-consuming. This methodology talks about what recon methods can be used for a single application vs. wildcard scope vs. wide scope like (*test.com). Simply put, Scope Based Recon is a methodology to decide How to Perform Recon when a specific scope is provided.

Why Scope Based Recon Methodology is useful ?

1:)

Saves lots of time ,

2:)

You know what exactly to look for,

3:)

You can easily automate your recon workflow,

4:)

Less of a chance to submit Out-of-Scope Issues,

5:)

Just like other security methodologies, it enables you to perform better recon,

Ok, now let's break down recon methodology by scope:

What to Look for small based recon ?

Directory Enumeration:

Performing a recursive directory enumeration both with and without session is useful. Always use a good wordlist to maximum results and you will often get some good hits.

Tools & Wordlists:

1:)

Dirsearch tool ,

https://github.com/maurosoria/dirsearch

2:)

FFUF tool ,

https://github.com/ffuf/ffuf

3:)

Wordlists ,

https://wordlists.assetnote.io/

Note: There are many more tools & wordlist that you can use;however, these are my preferences.

Technology Fingerprinting:

Check for the services running on the application. Often the servers, libraries and third-party components used might be outdated and vulnerable to known security issues.

Tools:

Wappalyzer Plugin
Whatweb

CVEs: Check for the CVEs and known vulnerabilities of old/outdated software and libraries used in the application.

Port Scanning:

Performing port scanning is always useful as you can get some interesting ports exposed running some services that may be using default credentials, misconfigured, or are known vulnerable.

Tools for the port scan;

Nmap:

https://nmap.org/

Nabbu:

https://github.com/projectdiscovery/naabu

Broken Link Hijacking:

If the application has some social media profiles, a third party linked website, or reference to any expired domain– try to perform a takeover. Tools:

Broken Link Hijacking Burp Plugin:

https://github.com/arbazkiraak/BurpBLH

JS Files for Hardcoded APIs & Secrets:

JavaScript files often contain interesting information. Digging into each and every JavaScript file you can get a bunch of useful information from Hardcoded APIs, Secrets (such as AWS Credentials), Information about S3 Buckets, More Subdomains, PII Information, Endpoints, Interesting Parameters, Logics to Bypass certain restrictions like for XSS and Open Redirection, you can do a lot. Now there are tons of ways to deal with JavaScript files, like:

* Use Automated tools for findings hardcoded information,

* Use Automated tools for finding interesting parameters, keywords, endpoints, and other pieces of information,

* Download all JavaScript files recursively and use GF patterns/Custom Regex to look for interesting information,

*Differentiate JavaScript files (Previous vs. Current) over a period of time to see if something interesting came up,

Tools:

SecretFinder: https://github.com/m4ll0k/SecretFinder ,
JFScan: https://github.com/KathanP19/JSFScan.sh ,
LinkFinder: https://github.com/GerbenJavado/LinkFinder
DetectDynamicJS: https://github.com/PortSwigger/detect-dynamic-js (Burp Plugin)
Retire.js: https://github.com/retirejs/retire.js/ (Burp Plugin/Browser Extension/Standalone)
JS Link Finder: https://github.com/PortSwigger/js-link-finder (Burp Plugin)

Parameter Discovery:

Often you will be able to discover parameters that might not be directly visible through the application navigation but are still processed on the server-side. These parameters are often vulnerable to attacks such as SSRF, Open Redirection, XSS, SQLi, IDORs, etc.

Tools:

Arjun: https://github.com/s0md3v/Arjun
ParamSpider: https://github.com/devanshbatham/ParamSpider
Param Miner: https://github.com/PortSwigger/param-miner

Wayback History: Checking for Wayback History is always a great idea. You can often find URLs that may no longer be available through application workflow but are still accessible. Sometimes, sensitive pages are cached revealing interesting information and you can also get a bunch of endpoints to test for various different vulnerabilities.

Tools & Websites

Wayback Machine: https://archive.org/web/
waybackurls: https://github.com/tomnomnom/waybackurls
gau: https://github.com/lc/gau.

Domain-Specific GitHub & Google Dorking:

Google Dorking methods are always useful specifically to increase the attack surface by finding more and more endpoints, exposed services, etc. However, in the case of small scope recon, you can check for authentication tokens, UUIDs, User/Asset Identifier, Backup Files, Sensitive Cached information using Google Dorks & GitHub Dorking.

Tools & Websites

GHDB: https://www.exploit-db.com/google-hacking-database
Interesting GitHub Dorks List: https://gist.githubusercontent.com/EdOverflow/8bd2faad513626c413b8fc6e9d955669/raw/06a0ef0fd83920d513c65767aae258ecf8382bdf/gistfile1.txt
GitDorker: https://github.com/obheda12/GitDorker/tree/master/Dorks
GitRob: https://github.com/michenriksen/gitrob
GitHound: https://github.com/tillson/git-hound