Open Source Intelligence (OSINT) is the process of gathering publicly available information about a company or individuals. It includes data such as records of public and private meetings, external dependencies, credentials, and development activity. Sensitive data such as passwords, tokens, or private keys can often be found in public repositories like GitHub or code shared on StackOverflow. Such leaks can allow attackers quick access to internal systems. If critical data is discovered during an assessment, it must be reported immediately as outlined in the Rules of Engagement (RoE).
Infrastructure enumeration involves identifying the client’s internet and intranet-facing assets. This includes servers, domains, and services such as DNS, email, or cloud platforms. The goal is to build a full map of the client’s network, understanding security measures such as web application firewalls, and identifying possible detection points. This process is valuable both externally and internally, helping identify services and systems that may be vulnerable or poorly monitored.
Host enumeration is the analysis of each system in the client’s infrastructure. It includes identifying the OS, running services, versions, and potential misconfigurations. Internally, administrators may assume certain services are 'safe' simply because they are not exposed externally. This often leads to vulnerable services being left unpatched. After exploitation, internal enumeration includes reviewing files, processes, services, and other local elements. This is a core part of post-exploitation and privilege escalation.
Pillaging refers to collecting sensitive data from compromised hosts after successful exploitation. This can include user credentials, internal documents, client lists, and more. It is not a standalone phase but is tightly linked to post-exploitation and privilege escalation. It helps attackers escalate access and move laterally within the network. HTB Academy covers pillaging across several modules such as Active Directory, Linux/Windows Privilege Escalation, and Network Enumeration. The techniques vary depending on OS and context.
During the vulnerability assessment phase, we examine and analyze the information gathered during the information gathering phase. This is an analytical process where findings are interpreted to identify potential weaknesses. There are four common types of analysis used in this stage: Descriptive (what happened), Diagnostic (why it happened), Predictive (what could happen), and Prescriptive (how to respond).
An open port (e.g., TCP 2121) discovered during information gathering might not show detailed results in Nmap. We must form hypotheses and test them using tools like Netcat to verify what service is running. In vulnerability research, we use descriptive and diagnostic techniques to identify components, and search for known vulnerabilities using sources like CVE Details, Exploit DB, Vulners, Packet Storm, or NIST. Once vulnerabilities are found, predictive and prescriptive analysis helps determine impact and testing strategy. This may include replicating the target system locally for safe, controlled testing. If no clear vulnerabilities are found, we return to the information gathering stage. These two stages are often intertwined and iterative, especially in real-world testing scenarios or CTF-style challenges.
During the Exploitation stage, we look for ways to leverage identified vulnerabilities to achieve goals such as gaining a foothold or escalating privileges. This often involves modifying Proof-of-Concept (PoC) exploits to execute code and establish a reverse shell over an encrypted connection. The penetration testing process includes: Pre-Engagement, Information Gathering, Vulnerability Assessment, Exploitation, Post-Exploitation, Lateral Movement, Proof-of-Concept, and Post-Engagement. While these stages are distinct, in practice they often overlap. Understanding which phase we are in helps maintain structure, especially during long and complex assessments.
Once exploitable vulnerabilities are found, we prioritize attacks based on three main factors: Probability of Success, Complexity, and Probability of Damage. Tools like CVSS and the NVD calculator can help estimate these values.
The complexity of an exploit reflects how much effort is needed to use it, depending on our experience and available documentation. We should avoid damage and never run potentially disruptive exploits unless explicitly authorized by the client. A scoring system can help us compare and rank attack paths. For instance, an easy-to-use Remote File Inclusion (RFI) may be preferred over a complex Buffer Overflow with higher risk.
If no reliable PoC is available, we may replicate the target system locally to test or adapt the exploit safely. This involves setting up a virtual machine that mirrors the target’s environment. When in doubt, communicate with the client. If exploitation is too risky, we may mark the vulnerability without exploiting it. The client will always prefer caution and clear communication over system disruption. After successful exploitation and initial access, we document findings thoroughly and proceed to post-exploitation and lateral movement phases.
After successfully exploiting a target, the post-exploitation phase begins. The main goal is to gather sensitive, security-relevant, and business-relevant information from a local perspective. This often requires elevated privileges. Post-exploitation includes components such as: Evasive Testing, Information Gathering, Pillaging, Vulnerability Assessment, Privilege Escalation, Persistence, and Data Exfiltration. If systems are actively monitored, any command or change could trigger alerts. Evasive testing can help identify what defenses detect and block. This benefits the client and helps us refine our stealth techniques.
There are three categories of evasive testing: Evasive, Hybrid-Evasive, and Non-Evasive. These are applied based on the scope, goals, and level of intrusion agreed upon with the client. After gaining local access, we repeat the Information Gathering and Vulnerability Assessment phases, now from an internal perspective. This allows enumeration of local services, users, shares, printers, and more. Pillaging involves extracting system details such as interfaces, routing, DNS, ARP tables, IP subnets, shares, and traffic data. We also look for sensitive files, credentials, or configurations to assess impact and assist in privilege escalation.
Persistence ensures we retain access after disconnection. It is important to establish this early, especially when using unstable exploits. Methods depend on system configuration and should be applied flexibly. We can repeat the Vulnerability Assessment from inside the system, now with deeper access. Our goal is to discover local vulnerabilities or misconfigurations that can aid in privilege escalation. Privilege escalation allows us to gain higher access, such as root or domain admin. This can be done locally or using stolen credentials. Escalating access expands attack capability across the network.
Data exfiltration may be tested with the client’s permission. Simulated (fake) sensitive data can be used to check if defenses like DLP or EDR detect it. This avoids legal risk but still proves the vulnerability. Real data types are governed by regulations like PCI, HIPAA, GLBA, and FISMA. Clients may follow frameworks such as NIST, ISO, CIS Controls, or GDPR. Any successful privilege escalation and exfiltration should be documented clearly. If real personal data is involved, notify the client immediately, and they may choose to pause or adjust the test scope.
After exploitation and post-exploitation, the goal of the Lateral Movement stage is to assess how far an attacker can go inside the network. It tests internal exposure and helps identify paths to sensitive data or full domain compromise. This step simulates real attacker behavior, such as in ransomware scenarios. In this phase, we often repeat prior steps—Information Gathering, Vulnerability Assessment, Exploitation, and Post-Exploitation—on new internal systems. Our aim is to expand access and understand the impact of compromise across the environment.
Pivoting is a key technique where we use the compromised system as a proxy to access non-routable networks. This allows us to scan and interact with internal services as if we were inside the network. Evasive testing may also be applied here, adapting our scans and actions to bypass monitoring tools such as EDR, IDS/IPS, or segmentation defenses. This helps identify detection gaps and weak points. From our internal foothold, we enumerate accessible hosts, services, and shares. Users with specific group memberships (e.g., developers) may have access to sensitive resources that help us expand further.
Privilege exploitation inside the network can include hash reuse (e.g., pass-the-hash), cracking, or credential spraying. Tools like Responder can help capture hashes and move laterally to higher-value targets. Every time we compromise a new host, we repeat post-exploitation activities to extract evidence and business-impacting data. At this point, we are ready to move to the Proof-of-Concept phase to present results to the client.
Proof of Concept (PoC) is a term used in project management to demonstrate the feasibility of an idea or solution. In information security, it means confirming that a vulnerability can be exploited. A PoC helps validate the risk, show the impact, and justify the need for remediation. PoCs can take many forms: simple documentation, detailed attack chains, or working scripts that trigger the vulnerability. A common PoC example is executing calc.exe on Windows to prove code execution. While automated scripts are useful, they can mislead defenders into thinking fixing the script blocks the attack. The vulnerability itself must be mitigated, not just the method. This distinction should be communicated clearly to the client's IT team.
Our report should highlight the full context: the root cause of the issue, the attack path, and how multiple weaknesses may form a chain. Fixing only one part leaves others vulnerable and could allow re-exploitation. For instance, if a Domain Admin uses 'Password123', changing that password solves the symptom—not the cause. The true issue lies in the password policy. Addressing systemic flaws like weak authentication policies is crucial. Overall, PoC serves to illustrate impact and support decisions about mitigation. It is a bridge between discovery and remediation that gives both technical and strategic value to the penetration test.