> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-17/enumeration/hidden-directory/trick-0014.md).

# Hidden Directory via Network Analysis

***

Monitor HTTP traffic using browser developer tools (Network tab) while browsing the application. Look for dynamically loaded resources, redirects (3xx status codes), or embedded links within responses that point to paths not immediately obvious from the page source or static analysis.

When examining redirects and URL parameters, be particularly vigilant for parameters that appear to dictate navigation paths or resource locations. If you can’t find any obvious parameters in URLs that seem to control redirection or path loading, you might want to try finding hidden ones by fuzzing the parameters with a tool like `ffuf`. Sometimes dangerous parameters and endpoints are left exposed either accidentally or because the developers forget to remove them from the production environment. As a parameter fuzz wordlist, `burp-parameter-names.txt` (which can be found in Seclists, for example, under `/usr/share/seclists/Discovery/Web-Content` on systems where it's installed via `apt install seclists`) can be useful.

Once relevant parameters are identified (either visible or fuzzed), look for those that look like a path or a URL. Here are some examples of the types of parameters that could lead to discovery:

```
https://site.com/login?ReturnURL=https%3A%2F%2Fsite.com%2Fmy-account
https://site.com/form-complete?return=%2Fcompleted
https://site.com/api/v2/redirect?url=https%3A%2F%2Fsite.com%2F404
```

If a parameter includes a full URL (e.g., `ReturnURL=https%3A%2F%2Fsite.com%2Fmy-account`), try changing the path component of that URL to other suspected internal paths. If the parameter looks like a relative path (e.g., `return=%2Fcompleted`), attempt to substitute other potential path names. The server might handle such parameters by concatenating the provided path to its own domain. For instance, a server-side implementation could be:

```javascript
app.get('/form-complete', (req, res) => {
  var redirectPath = req.query.return; // e.g., /completed
  res.redirect('https://site.com'+redirectPath); // Results in https://site.com/completed
});
```

By manipulating the `redirectPath` value in the request (e.g., to `/admin_console` or `/debug_page.php`), one might be able to access unlinked sections or functionalities within the application. Careful observation of how the application constructs these redirect URLs is key, as slight variations or improper input sanitization can lead to vulnerabilities. For example, if the application attempts to filter or validate these paths, common bypass techniques like URL encoding (single or double), path traversal sequences (`../`), or case variations might be effective depending on the backend processing.

Hidden directories might also be referenced in client-side JavaScript. Modern web applications are heavily built on JavaScript, and many critical functionalities, including API calls and business logics, are built on client-side nowadays. Understanding the client-side logic can lead to the discovery of unique vulnerabilities, including unlinked paths.\
To begin, one might use a tool like `hakrawler` to crawl and extract all possible links and JavaScript files under a given path. After extracting the domain value from the given URL, the value can be passed to `hakrawler` to crawl and extract all possible links and JavaScript files under the given path. The results can be refined to contain only domain-related values.\
Once JavaScript files are identified, they can be analyzed. Content discovery is one of the most important tasks as it might disclose some sensitive information, installation files, back up files and so on. JavaScript files reside in the target will immensely help us a lot identify directory paths. Because, those path will be used regularly and the paths will be unique as per the target as well. A tool like `jsa.py` can be employed to extract the relative and absolute paths from JavaScript files.\
Furthermore, tools like `gf` with specific patterns can be used to identify sensitive information in the JavaScript files. As part of this process, you might utilize patterns such as:

1. `awskeys` - check for aws keys in JavaScript files
2. `firebase` - check for firebase URLs in JavaScript files
3. `json_file` - check for Json file in JavaScript files
4. `s3-buckets` - check for aws s3 buckets in JavaScript files
5. `sec` - check for secrets in JavaScript files
6. `ip` - check for ip addresses in JavaScript files
7. `upload-fields` - check for file upload fields in JavaScript files\
   These patterns can help find hidden information inside JavaScript files, some of which (like JSON file references or specific API endpoints buried in secrets) might reveal further hidden directories or paths.

These discovered paths, whether from JavaScript analysis or parameter manipulation, might be fetched dynamically. For instance, visiting a path like `/sup3r_s3cr3t_fl4g.php` could trigger a request to `intermediary.php?hidden_directory=/WExYY2Cv-qU`, revealing `/WExYY2Cv-qU` as the actual hidden path. This illustrates how a parameter can directly contain the name of a hidden resource.