> ## Documentation Index
> Fetch the complete documentation index at: https://hackwithmike.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OSCP Methodology

## Introduction

***

OSCP is an practical hacking exam with a strict 24-hour time constraint. Therefore, time management is the most important aspect of the exam. The ability to identify potentially vulnerable attack vectors within the time constraint is key - you can always research and learn the exploitation process on the fly.

Note that this guide expects you to have basic understanding on hacking and the OSCP exam itself.

To begin with, let's filter out what we **should not spend time on**. Here is what you will likely not expect in the OSCP exam:

* **OSINT** (E.g., Google Dorking & DNS enumeration).
* **Network Poisoning and Spoofing** (LLMNR / NBT-NS Attacks)
* **Client-side Attacks** (E.g., Phishing, XSS, CSRF, etc - highly unlikely)
  * Some practice boxes on PGs and HTBs do simulate client interactions.
  * In the case that this is the intended path, there should also be hints (e.g., "An admin will review your comment")

With these constraints (plus the fact that OSCP is an entry-to-intermediate level certification), we can expect a limited number of possible attack vectors, which can mostly be grouped into the following 3 categories:

<Steps>
  <Step>
    **Vulnerable Versions** & Public Exploits
  </Step>

  <Step>
    Secure Versions but **Misconfigurations**
  </Step>

  <Step>
    Hunting **Sensitive Information**
  </Step>
</Steps>

Noted that the 3 categories can be mixed & matched in a full attack path. For example:

* Vulnerable Apache Web Server *(Vulnerable Version)* -> Path Traversal into reading SSH Private Key *(Misconfiguration & Sensitive Information)*.
* Anonymous SMB Share *(Misconfiguration)* -> Discovered user credentials *(Sensitive Information)*.
* Username used as Password *(Misconfiguration)* -> Run an authenticated RCE exploit *(Vulnerable Version)*.

These three attack vectors apply not only to initial footholds but also to privilege escalation and Active Directory attacks. It is a cyclic process:

<Steps>
  <Step>
    Enumerate the three vectors
  </Step>

  <Step>
    Escalate privileges (Could be lateral / vertical)
  </Step>

  <Step>
    Re-enumerate the three vectors with new privileges.
  </Step>

  <Step>
    Repeat until root / admin
  </Step>
</Steps>

As the old saying goes — OSCP is an **enumeration exam**. If you find yourself crafting complex exploits, or fixing kernel driver dependencies, you are likely 90% on the wrong path. Try to take a step back and redo your enumeration, such as look for another available public exploit, a previous missed open port, some hidden credentials, etc.

## Vulnerable Versions

***

Vulnerable versions of services and applications are usually quick wins when there are **Proof-of-Concepts (PoCs)** and **Public Exploits** available out there.

### Key strategies

<Steps>
  <Step title="Enumerating versions">
    Use automated scanning tools like `nmap`, `netcat`, `wpscan`, etc., to perform banner grabbing or service scanning. Manually walk through each running services and look for service & version information.
  </Step>

  <Step title="Look for public exploits">
    Utilize `searchsploit`, GitHub repos, [Exploit-DB]("https://www.exploit-db.com/"), etc., for existing public exploits.
  </Step>

  <Step title="Fixing and using exploits">
    Make sure the exploit is applicable to the service version. Some exploits have a range of vulnerable versions, and older versions may not be vulnerable. Also some public exploits require fixing and modifying before using.
  </Step>
</Steps>

If you find a vulnerable version with public exploit available, prioritizing trying out all the available exploits online. Don't spending too much time on making your own exploits or bypassing filters. OSCP is all about finding and using the right exploit, with a slight touch on "**fixing the exploit**" (which is usually just changing the target IPs, fixing typos, removing unnecessary spaces, etc.)

<Warning>
  **Beware of Rabbit Holes** \
  \
  It is always possible that the vulnerable versions have already been **patched**, and they are only here as rabbit holes. So if you find the public exploits not working despite all the conditions are met, take a step back and re-enumerate other possible attack paths.
</Warning>

### Enumerating Versions

<div className="tab-frame">
  <Tabs>
    <Tab title="Web Pages">
      This is the most common attacker vector of outdated version attacks. It could be in the form of an outdated CMS, a web portal for vulnerable systems, a page running on outdated web servers, etc.

      * Wappalzyer Plugin ([Firefox](https://addons.mozilla.org/en-CA/firefox/addon/wappalyzer/), or [Chrome](https://chromewebstore.google.com/detail/wappalyzer-technology-pro/gppongmhjkpfnbhagpmjfkannfbllamg?pli=1) for Burp).

      * Check the HTML source codes.
        * Look for URLs, folder names, developer comments, etc.

      * Check HTTP Response Headers.
        * Look for headers like: `Server`, `X-Powered-By`, etc.

      * For CMS, use WPScan / Droopescan / JoomlaScan / etc.
    </Tab>

    <Tab title="Service on Open Ports">
      As for other running services, we can either detect their versions automatically with existing scanning tools, or interacting with them manually.

      * Service Detection with Nmap. (With the `-sV` flag.)
      * Banner Grabbing with Netcat & Telnet.
      * Interact with the service directly (E.g., SMB, FTP, SSH, etc.)
    </Tab>

    <Tab title="Internal Services (For PrivEsc)">
      If you have **CLI access** to the machine (E.g., Reverse Shell, SSH, etc.):

      * Run the service binary with `--help`, `-h`, `--version`, `-v`, etc.
      * Check if there is a installation file of the service.

      If you have **GUI access** to the machine (E.g., RDP):

      * Open the application and manually look for the version in the About section.
      * Check if there is a installation file of the service.
      * Sometimes the version number is also in the installation path / folder.

      If the service is running on an internally opened port, try to port-forward the service externally for Nmap Scanning.
    </Tab>
  </Tabs>
</div>

### Finding Exploits

<div className="tab-frame">
  <Tabs>
    <Tab title="Exploit Databases">
      Most of the time, you will be able to find the exploit PoC on these databases

      * [Searchsploit](https://www.exploit-db.com/searchsploit) on Kali command line.
      * [Exploit-DB](https://www.exploit-db.com/), [Packet Storm](https://packetstorm.news/),
      * CVE databases (like [MITRE](https://cve.mitre.org/)) are usually not too helpful as they do not directly provide PoCs.
        * Although some may link to the blogs & articles that contain PoCs.
    </Tab>

    <Tab title="GitHub Repos">
      If an exploit has a publicly available exploit, you can most likely find a PoC on GitHub written by some great security researchers. (It could be me or you someday!)

      * Google "*CVE-XXX-XXX GitHub PoC*" or "*\<service name> \<version> exploit*".
      * There are also some famous exploit repos like SecWiki's [Windows Kernel Exploits](https://github.com/SecWiki/windows-kernel-exploits).
      * Always CHECK the codes before running exploits from GitHub - they could be malicious.
    </Tab>

    <Tab title="Metasploit">
      Personally I never find the need to use Metasploit in the exam, since there will always be alternative PoCs available if that particular exploit is the intended path.

      * Regardless, it can sometimes be the easier way to exploit a vulnerability. For example, using Metasploit is probably the easiest way to exploit EternalBlue (apart from AutoBlue)
      * Alternatively, you can always review the [Metasploit module source code](https://github.com/rapid7/metasploit-framework/tree/master/modules) to understand how they exploit a vulnerability and do it manually. This is of course not recommended to be performed during the actual exam.
    </Tab>
  </Tabs>
</div>

### Using Exploits

<div className="tab-frame">
  <Tabs>
    <Tab title="Fixing Exploits">
      While the exploits are publicly available, not all of them are ready-to-use without some **cleaning and fixing**.

      * The most common way of "fixing" an exploit is simply to change the source & target IP addresses, modify the exploit URI paths, provide the correct user credentials, etc.

      * Older Python exploits are written in Python2 and should be run with `python2.7` instead of `python3`.

      * Always remember to with add run permission with `chmod +x <script file>`.

      * Note that many exploits from Exploit-DB are not polished. On the another hand, GitHub usually have better quality PoCs.

        * There can be all sorts of errors, such as incorrect indentations, extra spaces, incorrect spellings, etc. This would require you to have basic knowledge on the programming language to effective debug the exploits.
    </Tab>

    <Tab title="Compiling Exploits">
      Some exploits require **manual compilation** using `gcc`, `mingw`, `make`, etc, but for OSCP level they should be relatively straightforward and shouldn't require a lot of fixing.

      * Look for pre-compiled exploits, and have them saved in your Kali machine for easy reuse.
      * I have a folder containing over 50 precompiled exploits, especially for very commonly used ones such as Potato exploits, EXE reverse shells, PEAS, etc.
      * I also have another folder storing web shell payloads in many different languages, such as php, aspx, Go, Java, WordPress, etc.
    </Tab>

    <Tab title="Matching Versions">
      Make sure the exploit is applicable to the service version. Some exploits have a range of vulnerable versions, and older versions may not be vulnerable.

      * E.g. The famous [Apache Path Traversal Vulnerability](https://www.hackthebox.com/blog/cve-2021-41773-explained) is only vulnerable on Apache 2.4.49 and 2.4.50, but not other versions.
    </Tab>
  </Tabs>
</div>

## Misconfigurations

***

If there are no vulnerable versions, we can then look into **misconfigurations** in different services. The service itself may not be not vulnerable, but it can be set up incorrectly and unsafely.

The definition of misconfiguration here is pretty broad, since it basically covers **anything else that are NOT public exploits** that can be plugged and played. You can expect all the "hacking techniques" being categorized here.

### Key strategies

<Steps>
  <Step title="Enumerate Services">
    Understand what services are running, and their common attack vectors. For example, FTP Server -> Anonymous login? MySQL Service -> UDF code execution? Webpage with File Upload -> Uploading web shell? etc.
  </Step>

  <Step title="Finding Misconfigurations">
    This part requires mostly pattern recognition and experiences gained from grinding boxes and studying existing materials. Not many shortcuts here, but try to look for walkthroughs of boxes with similar services if you are stuck during the exam.
  </Step>

  <Step title="Exploiting Misconfigurations">
    The last step is much easier once you identified the vulnerable service. Some harder boxes may require you to chain multiple misconfigurations and other vulnerabilities, so make sure to take good notes for mapping the final attack path.
  </Step>
</Steps>

### Enumerating Services

<div className="tab-frame">
  <Tabs>
    <Tab title="Web">
      Make sure to thoroughly enumerate the web server. Few points to note here:

      * **Directory Busting:**
        * Hidden admin panels / Sensitive pages.
        * Config files / `.git` Directory.
        * Open directory listing.
      * **Subdomain Enumeration:**
        * Hidden admin panels / Sensitive pages.
        * API Endpoints.
      * **Webpage & Source code Review:**
        * Look for potential usernames / emails / credentials on page contents.
        * Check HTML source codes (Hard-coded credentials / Developer comments / Hidden endpoints, etc.).
        * Understand all functionalities, such as user login, file upload, etc, so that you can focus or skip relevant attack vectors based on the existing functions.
          Remember to perform directory busting on **all the endpoints**, including **different web ports and subdomains**.
        * Always use more than 2 directory busting tools and wordlists to avoid missing important endpoints.
        * Personally I run FeroxBuster with its default wordlist & DirSearch with `directory-list-2.3-small.txt` separately on the same domain.
    </Tab>

    <Tab title="Databases">
      This mostly refers to SQL databases.

      * Identify the SQL server in use - Is it MSSQL? MySQL? SQLite? etc.
      * Check for **anonymous login** & **default / weak credentials**.
        * If that does not work, we will likely get the login credentials from elsewhere, such as web pages, file shares, email servers, etc.
      * For file-based databases like SQLite, the data is stored as a separate .db file, and can be usually be accessed without credentials if you can get your hands on the file.
    </Tab>

    <Tab title="File Shares">
      This includes all the file shares such as FTP, SMB and NFS.

      * Always check for **anonymous login** & **default / weak credentials** first.
        * If that does not work, we will likely get the login credentials from elsewhere, such as web pages, databases, email servers, etc.
    </Tab>

    <Tab title="Remote Access">
      This refers to services like Telnet, SSH, RDP, WinRM, etc.

      * These services are usually not directly exploitable without **correct credentials.**        - Regardless, there could still be some useful information.
        * For example, the Nmap script on SSH (`ssh-hostkey`) tells you what key algorithms are used for authentication (e.g., RSA, ECDSA, etc.)
        * If RSA is in use, perhaps we will be hunting for `id_rsa` private key somewhere. Similarly, the discovered SSH private key may be in `id_ecdsa` format if ECDSA is in use.
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="Mail Services">
      This refers to services such as POP, IMAP and SMTP.

      * Check for **default & weak credentials** like "`admin:admin`".
        * If that does not work, we will likely get the login credentials from elsewhere, such as web pages, file shares, email servers, etc.
      * Even if un-authenticated, try to enumerate usernames from mail services.
      * It is also possible that they are designed for client-side attacks such as sending and received phishing emails.
    </Tab>

    <Tab title="UDP Ports">
      SNMP on UDP port 161 is often missed during port scan.

      * Always remember to run a separate **UDP scan** on Nmap (`sudo nmap -sU`). You can do it with the `-F` flag to only scan for the top 100 common ports if the scan is taking too long.
    </Tab>

    <Tab title="Other External Services">
      This includes all other uncategorized services such as DNS and all other non-common services.

      * DNS is usually not designed to be exploitable especially in simulated boxes. Only try when everything else did not work.
        * There could be scenarios where you can obtain sensitive information from the DNS records, or you may have write access to the DNS records.
      * All other services will require deeper research on what services usually use those ports. If names of the services are identified, try to go through their documentations to understand how to interact with them.
        * Also check if there are any boxes walkthroughs that contain the service / port.
        * Amazing resources from IppSec & 0xdf. You can use keywords of a service to search for walkthroughs:
          * [https://ippsec.rocks/](https://ippsec.rocks/)
          * [https://0xdf.gitlab.io/tags](https://0xdf.gitlab.io/tags)
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="Active Directory">
      For AD environments in OSCP, 90% of the time it is about moving around different services and users by abusing **misconfigured user ACL** or using **discovered credentials**. To do so, we must map out all available services, as well as the relationships between the AD objects.

      * Bloodhound is the go-to tool for identifying misconfigured user & system ACL.
      * Always remember to conduct full port scan on internal targets that are previously unreachable. There can be a MSSQL service running on an uncommon port, and your controlled user may have admin access to the service.
      * Password Reuse is extremely common in Active Directory environments. Always try to spray passwords on different services.
    </Tab>

    <Tab title="Internal Services (For PrivEsc)">
      Enumerate services running internally via different methods such as:

      * Listing internal network connections (`netstat -tunlp` or `ss -tunlp`).
        * Look for open ports that are not exposed externally - maybe there is an MSSQL service running internally only?
        * Identify what processes are running on the open ports.
      * List internal running processes (`ps aux` or `wmic process list brief`).
      * Listing scheduled tasks (`schtasks /query /fo list /v` or `Get-ScheduledTask`).
      * Look for uncommon binaries / applications installed.
    </Tab>
  </Tabs>
</div>

### Finding & Exploiting Misconfigurations

<div className="tab-frame">
  <Tabs>
    <Tab title="Web">
      This refers to all the basic web hacking stuff, with heavy focus on either getting sensitive information (LFI, File Read, etc), or directly getting system access (Web shell, RCE, etc). Here is a list of common attack vectors:

      * **Authentication Attacks**: Default credentials / Anonymous Login / Weak Passwords

      * **Exposed Sensitive Files**: Open Directory Listing / `.git` / Hidden admin panels, etc.

      * **SQL injection**: Authentication Bypass / File Read & Write / RCE

      * **File Upload & Write**: Web shell RCE / Overwrite Login & Config Files / Client side attacks

      * **File Read**: Credential Files / Config Files / Process & Logs for sensitive information

      * **Path Traversal / File Inclusion**: File Read / RCE

      * **Mass Assignment**: Authentication Bypass

      * etc.

      In the rare cases of client side attacks, here are also something you can be looking at:

      * **File Upload**: Malicious Files for Reverse Shell

      * **XSS**: Hijacking Session Token / Extracting Webpage Information

      * **CSRF**: Sending URL for one-click attack

      * etc.
    </Tab>

    <Tab title="Databases">
      This assumes that you have already gained initial access to the database services.

      * Upon successful login, go through all of the non-default tables and databases.

        * Mainly looking for **credentials** (passwords & hashes).

        * It may also be some weird stuff like emails about configurations, etc.

        * List out all users of the database to look for new attack vectors.

      * All SQL injection attacks are naturally applicable once you can make SQL queries in the database.

        * **MSSQL** -> File Read & Write / RCE / NLTM Theft / etc.

        * **MySQL** -> File Read & Write / UDF for RCE / Dumping SQL User Creds / etc.

        Different attacks can be specific to certain database services.
    </Tab>

    <Tab title="File Shares">
      This assumes that you have already gained initial access to the file shares.

      * Upon successful login, go through all directories and files.

        * Mainly looking for **credentials** - It could be in configuration files, PDF files for onboarding employees, email backups, database files (`.db` file), Excel files, ZIP files, etc.

        * Apart from credentials, it can also be **sensitive information** such as hidden endpoints, service versions, etc.

        * Metadata may contain useful information such as usernames. (Check with `exiftool`)

        * Sometimes the files (especially Excel & ZIP files) are **encrypted** and require us to perform brute-force attacks with tools like `zip2john` and `hashcat`.

        * Always check for **Write Access**. It is possible that the file share directory is also hosted in the web server, and we can upload a web shell onto the server.

      File shares are also privilege escalation vectors when there are misconfigurations or we have elevated permissions:

      * For NFS, if `no_root_squash` is set, we can escalate to root by uploading a SUID-bit set shell.

      * For SMB, admin access can lead to command execution with tools like `NetExec` and `Impacket Suite`. Username enumeration is also possible with brute-forcing RID.
    </Tab>

    <Tab title="Remote Access">
      This refers to services like Telnet, SSH, RDP, WinRM, etc.

      * As suggested, these services are usually not designed to be directly exploitable without correct credentials.

      * Regardless, always take notes on the services & their versions to check if there are public exploits.

      * Otherwise, this vector is mostly intended for weak authentication attacks, such as **default / weak credentials**, **password spraying** and **brute-forcing attacks**.
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="Mail Services">
      This refers to services such as POP, IMAP and SMTP.

      * Even if un-authenticated, try to **enumerate usernames** from mail services.

      * Upon successful login, go through all the email records.

        * Mainly looking for **credentials** in emails, such as employee onboarding emails, service reminders, credential updates, etc.

        * If **client-side attacks** are intended, there will be hints in the emails or other places such as the web pages.
    </Tab>

    <Tab title="UDP Ports">
      For SNMP on UDP port 161,  try to run `snmpwalk` with **default community strings** (public, private, manager, etc.)

      * Look for sensitive information such as user emails, passwords, command history, etc.
    </Tab>

    <Tab title="Other External Services">
      This includes all other uncategorized services such as DNS and all other non-common services.

      * As mentioned above, DNS is usually not designed to be exploitable in simulated boxes, and all other services will require deeper research on what services usually use those ports.
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="System Misconfigurations">
      This refers to system-level misconfigurations that are not associated with any particular services.

      * Readable / Writable Sensitive Files.

        * `/etc/passwd`, `/etc/shadow`, Extractable `SAM` & `SYSTEM` hives, SSH key files, Readable root / admin directories, etc.

      * Misconfigured / Elevated Privileges.

        * Anything that can elevate privileges, for example:

          * On Linux: `sudo -l` , Kernel Exploits, Privileged Group Memberships, etc.

          * On Windows, `cmdkey /list` , `whoami /priv`, Kernel Exploits, Registry Exploits, Service Path Misconfigurations, etc.

        * Note that there are numerous priv-esc techniques that cannot be fully listed here.
    </Tab>

    <Tab title="Active Directory">
      While most of the Windows privilege escalation techniques also apply to that when working on an AD environment, there are AD-specific misconfigurations that work on a domain level, for example:

      * **User ACL**: A user is allowed to change the password of another user, adding oneself to another group, etc.

      * **Disabled Kerberos Pre-auth**: Allowing AS-REP roasting attacks to extract password hashes of misconfigured users.

      * **SPN Configured**: Allowing Kerberoasting attacks to extract password hashes of misconfigured users.

      * etc.
    </Tab>

    <Tab title="Internal Services (For PrivEsc)">
      Internal services are usually used to either escalate to a higher privilege, or move laterally to another user that have different sets of privileges.

      * For services running internally, if you have difficult using the services internally, you can always **port-forward** the services to your Kali attacker machine.

        * For example, I often port-forward internally running MSSQL services to my local Kali to use `impacket-mssqlclient` for easier enumeration and exploitation.

        * SSH is mostly used for single port-forwarding, but there are also tools like `plink.exe`, `socat`, `chisel`, `ligolo-ng`, etc.

      * For scheduled tasks, locate the **source binary or script** that is running.

        * [pspy](https://github.com/DominicBreuker/pspy) is the go-to tool to discover scheduled tasks.

        * Scheduled tasks are 99% the intended attack vector in simulated boxes, especially when it is running as root, or another high privilege user.

        * Upon locating the binary or script, try to replace or modify it for reverse shells, spawning root shell, etc. This is usually within a **longer attack chain**, where the scripts themselves are not directly editable, but can be modified by exploit another vulnerability.

      * For uncommon apps & binaries installed:

        * They may either have **publicly available exploits** once you identified the service and version;

        * Alternatively, they may be custom-made services that are intentionally designed to be vulnerable to different attacks, such as command injection, dumping hardcoded credentials with `strings`, etc.

        * They may also be (mis)configured to be able to run with admin privileges.

      * For apps & binaries that can be run with **admin privileges** (e.g., SUID-bit set or `sudo`):

        * For Linux, [GTFOBins](https://gtfobins.github.io/) is the go-to repository to abuse binaries for privilege escalation.

        * For Windows, it is usually less straightforward. Regardless, the end goal is always to escalate your current privileges by actions such as getting admin credentials, spawning reverse shells, creating a new admin user, etc.
    </Tab>
  </Tabs>
</div>

## Sensitive Information

***

If none of the above vulnerabilities can be identified after thorough enumeration, it is likely that the weakness lies not on the services nor misconfigurations, but on **human errors** such as leaked credentials, exposed internal directories, or any type of disclosed **sensitive information**.

This particular attack vector is usually a by-product of enumerating the running services. Sensitive information can be revealed in all sorts of formats, such as error messages when poking around, hidden directories discovered with directory busting, credential files found in file shares, etc. The key here is to always take good notes on all discovery, and to always make sure you have not missed a single detail during enumeration. Remember, enumerate, enumerate, enumerate!

### Key strategies

<Steps>
  <Step title="Gathering Information">
    Collect and record whatever you can during the enumeration process. Pay extra attention to things that related to authentication functions, user credentials (names, emails & passwords), error messages, hidden directories and files, and more.
  </Step>

  <Step title="Using Information">
    With the gathered information, we can now put the pieces together. Do we have credentials that we can brute-force or spray? Do the hidden directories and files contain credentials or configurations? The possibilities are endless and would require case-by-case analysis.
  </Step>
</Steps>

### Gathering Information

<div className="tab-frame">
  <Tabs>
    <Tab title="Web">
      Make sure to thoroughly enumerate the web server. This will look a lot similar to the previous sections:

      * **Directory Busting**:

        * Hidden admin panels / Sensitive pages (e.g., `phpinfo`).

        * Config files (e.g., `.htaccess`) / `.git` Directory.

        * `.git` is a gold mine for information. You can get your hands on the application's source code to identify potential attack vectors (e.g., SQL injections), or there can be hardcoded credentials and session tokens within the source codes.

        * Open directory listing.

      * **Subdomain Enumeration**:

        * Sometimes the good stuffs are hidden behind another Vhost. Always run subdomain enumeration and directory busting on the newly discovered subdomains.

      * **Webpage & Source code Review**:

        * Look for potential usernames / emails / credentials on page contents.

          * The About Us & Contacts sections usually contain emails & domain name information.

          * For blog-like applications, the blog articles often come with author names and comments with commenter names.

          * Some may also put down passwords under the blog posts or comments.

        * Check HTML source codes (Hard-coded credentials / Developer comments / Hidden endpoints, etc.).
    </Tab>

    <Tab title="Databases">
      Upon successful login, go through all of the non-default tables and databases.

      * Mainly looking for **credentials** (password & hashes).

      * Many CMS stores user passwords and hashes under tables such as `users`, `login`, etc.

      * List out all users of the database for new usernames.

      Some SQL services, such as MySQL, also store password hashes of the users. Remember to dump those out for cracking.
    </Tab>

    <Tab title="File Shares">
      Upon successful login, go through all directories and files.

      * Mainly looking for **credentials** - It could be in configuration files, PDF files for onboarding employees, email backups, database files (`.db` file), Excel files, ZIP files, etc.

      * Apart from credentials, it can also be **sensitive information** such as hidden endpoints, service versions, etc.

      * Metadata may contain useful information such as usernames. (Check with `exiftool`)

      * Sometimes the files (especially Excel & ZIP files) are **encrypted** and require us to perform brute-force attacks with tools like `zip2john` and `hashcat`.
    </Tab>

    <Tab title="Remote Access">
      This refers to services like Telnet, SSH, RDP, WinRM, etc.

      * These services are usually not directly exploitable without **correct credentials**.

      * Regardless, there could still be some useful information.

        * For example, the Nmap script on SSH (`ssh-hostkey`) tells you what key algorithms are used for authentication (e.g., RSA, ECDSA, etc.)

        * If RSA is in use, perhaps we will be hunting for `id_rsa` private key somewhere. Similarly, the discovered SSH private key may be in `id_ecdsa` format if ECDSA is in use.
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="Mail Services">
      Emails are often designed to be a realistic scenario of where sensitive information lies:

      * Upon successful login, go through all the emails to check if they have mentioned anything about credentials, development site, configurations, etc.

      * Even if un-authenticated, try to enumerate usernames from mail services such as POP3 and SMTP (See the [example](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-smtp/index.html#username-bruteforce-enumeration) here at HackTricks). The identified usernames can then be passed to other services for brute-forcing / password spraying attacks.
    </Tab>

    <Tab title="UDP Ports">
      For SNMP on UDP port 161,  try to run `snmpwalk` with **default community strings** (`public`, `private`, `manager`, etc.)

      I have seen the following sensitive information exposed in SNMP:

      * Command histories containing passwords

      * User Emails

      * Usernames

      * Processes running

      * etc.
    </Tab>

    <Tab title="Other External Services">
      This includes all other uncategorized services such as DNS and all other non-common services.

      * As mentioned above, there could be scenarios where you can obtain sensitive information from the DNS records, or you may have write access to the DNS records.
    </Tab>
  </Tabs>
</div>

<br />

<div className="tab-frame">
  <Tabs>
    <Tab title="Active Directory">
      For AD environments, we can enumerate sensitive information in many ways, for example:

      * Extract valid usernames via **anonymous LDAP dumping**,  **SMB RID cycling** and running **username brute-forcing** (with [Kerbrute](https://github.com/ropnop/kerbrute)).

      * Go through all the readable file shares and databases.

      * Dump domain-level credentials with local administrator privileges.

        * Once you escalated your privilege on a domain machine as the local administrator, you will mostly discover new credentials of other domain users, either via dumping them with tools like mimikatz & impacket-secretsdump, or finding them in registry, config files, or any other locations that are previously inaccessible.
    </Tab>

    <Tab title="Internal Enumeration (For PrivEsc)">
      In case of hunting for sensitive information internally, here are some general directions you can look into:

      * Go through ALL **configuration files** of the running services. 90% of the time there are hard-coded credentials that can be sprayed again to escalate privileges.

      * Look for SSH key files. They can be in a user's home directory (`.ssh`), or they can be lying on some file share, some notes, etc.

      * Go for **command histories**. They may have records of previous commands that contain user credentials.

      * In a realistic scenario, a user may leave their credentials in a text file lying on the Desktop, or in a note app, in an excel file, etc.

      * System administrators also often store credentials in the **environmental variables** for easier access.

      * Look for Password Manager Database files, e.g., `.kdbx` for KeePass.

      * For Windows, credentials may be stored within **registry** entries, unattended installation files, etc. There may even be system backups of the SAM and SYSTEM hive that allow you to dump all credentials of the Windows machine.
    </Tab>
  </Tabs>
</div>

### Using Information

<div className="tab-frame">
  <Tabs>
    <Tab title="Brute-forcing">
      Suppose you only found potential usernames. We can always run a quick brute-force login attack to check if this is the intended path.

      * Always start out with **default & common credentials**. It also doesn't hurt to try username, service name, or box name as passwords

      * As for the password wordlist, `rockyou.txt` will do the job within 10-20 minutes if brute-forcing is the intended attack path.

      Note that you can also brute-force for usernames if you have a valid password, or if the service itself is vulnerable to username enumeration.

      * For example, some mail services like POP3 and SMTP may be misconfigured to allow username enumeration (See the [example](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-smtp/index.html#username-bruteforce-enumeration) here at HackTricks)

      * Some web applications may also be vulnerable to username enumeration due to improper error messages (e.g., `Username does not exist!`)

      * As mentioned above, we can also brute-force domain usernames from Kerberos running on Port 88 with Kerbrute.

      * I usually use `/usr/share/seclists/Usernames/xato-net-10-million-usernames.txt` from [SecLists](https://github.com/danielmiessler/SecLists).  You can run `sudo apt install seclists` to install SecLists on Kali.
    </Tab>

    <Tab title="Password Spraying">
      Suppose you have a few different potential usernames and passwords, the best approach is to **spray all passwords** to all identified usernames **in all combinations**.

      * For example, if you have found the following user list: `peter`, `john`, `mary`, with the following passwords, `P@ss123!`, `Letme1n#`, then you will have 6 possible combinations in total. However, you should also include **default usernames** such as `administrator` in to the user list, making it 8 possible combinations in total.

      * Just put all the usernames in a `user.txt`, and the passwords in a `pass.txt`, and supply the files as arguments when running tools like `hydra` and `NetExec`.

      * Always remember to spray them on **ALL services**, such as webpages, SQL, SMB, FTP, SSH, and anything with a login function.
    </Tab>

    <Tab title="Other Usages">
      This is a general section on all other information that can be classified as sensitive, but are not credentials, such as hidden directories, config files, etc.

      * Generally, these types of information provide you with hints to continue on the attack path, where you may either discover misconfigurations or version info that can be exploited, or actual credentials hidden in a deeper layer of the attack path.

      * All you have to do is to follow the lead and rerun the enumeration cycle on the three attack vectors, until you discover information that can help escalate your current privileges.
    </Tab>

    <Tab title="Active Directory">
      Here are some specific tips for brute-forcing & password spraying in Active Directory:

      * [NetExec](https://www.netexec.wiki/) has all the functionality you need for spraying passwords on different services.

        * I always run NetExec with the possible credential combinations on ALL available services: `SMB, LDAP, MSSQL, WinRM, WMI, RDP, SSH, FTP`, etc.

        * When the `-d` flag (domain) is not specified, NetExec will by default authenticate the user with the domain provided by the target machine.

        * Remember to add `--local-auth` at the end of the command for a second round of spraying. While the credential pairs may not be valid in the domain, it is always possible that it is a local account (I have success with this in actual engagements).

      * Always check the **password policies** to see if there is account lockout. If that is the case, it means that brute-forcing AD authentication is likely not the intended path.

        * You can do that with `nxc smb <ip> -u <user> -p <pass> --pass-pol`.
    </Tab>
  </Tabs>
</div>

## Conclusion

***

If you read till the end, I sincerely thank you for having the patience to go through my two cents on how to approach the OSCP exam. This is definitely not an exhaustive list, and it may also come across as a bit too exam-oriented. While I understand that real-life hacking involves way more techniques and depths, I truly hope this guide can be a good start to build one's methodology from scratch.

Hopefully what I have learnt along the way had provide some value to your journey, and I am always open to constructive feedbacks for improvements.