Overview

Pre-Engagement

  • Multiple documents should be reviewed during the pre-engagement period:
    • Non-Disclosure Agreement (NDAs)
      • NDAs can come in different types: unilateral, bilateral, multilateral. Each of these will protect only one party, both parties, or multiple parties from disclosing information discovered. Multilateral NDAs could be used for cooperative or hybrid networks that may affect more than one party.
    • Scoping Questionnaire
      • Such tests could include: internal pentest, external pentest, internal vuln assessment, external vuln assessment, wireless assessment, physical security assessment, application security assessment, social engineering assessment, web app assessment
        • External pentest is the full picture; Similar to how an attacker would get in, it starts with the attacker on the outside of the environment, probing publicly available infrastructure to attempt to gain a foothold
        • Internal pentest can start after successful exploitation during the external pentest, or can start as part of an "assumed-breach" scenario to test what would happen if the external defenses were breached.
      • Each test should have further questions. Example: for social engineering, should this be restricted to just email phishing? Or are phone calls (vishing), text messages (smishing) or in person attacks acceptable?
    • Pentesting Proposal (Contract / Scope of Work)
      • A signed scope of work (SOW) or contract is crucial for setting the guardrails of what can be tested. This should be in writing and signed by a authorized signatory for the target. Validation of the signatory to confirm they are eligible to commence a penetration test is crucial to ensuring the pentester is protected during or after the test.
      • Information about the scope such as # of live hosts, IPs/CIDR ranges, domains, wireless SSIDs, web/mobile apps, targeted users, physical locations, targeting of AD, bypassing of controls (NAC, firewall, AV).etc
      • Define critical infrastructure that is out of scope
    • Rules of Engagement (RoE)
      • see below for some of the sections that could be included
    • Contractors Agreement
      • required for physical tests if a pentester is caught and police are called
    • After-Assessment Reports
      • All the notes from the assessment should be revised and aggregated into a final report

These sections can be a part of multiple of the above documents, particuarly the RoE * Goals * Milestones that must be achieved during the engagement * Pentest Type * Scoping should be exhaustive to determine what type of test is being requested. This can be done with a questionnaire * Methodologies * OWASP, OSSTMM.etc * Pentesting Locations * Internal, or remote.etc * Time Estimation * At least start and end dates for the full engagement * Determining time windows for each phase and if testing should occur during work hours or after * Third Parties * Cloud Providers, ISPs, hosting providers may need to be looped into the agreement depending on the targeted infrastructure * Evasiveness * The stealthiness of the test should also be considered. Should it be evasive and attempt to be undetected the entire time? Should it be a hybrid and start stealthy but can ramp up to determine when the controls are able to detect the activity? Or is stealth not required and tooling can be loud and hammer away, barring denial-of-service or being destructive. * Risks * Risks and consequences should be outlined. While the intent is not to cause a system outage, it is possible that the exploitation of a vulnerability could inadvertently take a system down. * Brute-forcing can cause user accounts to lock-out * Information Handling * Laws and regulations can differ depending on the target's industry and location. All laws need to be researched beforehand to ensure compliance during testing * GDPR is a data privacy regulation that impacts personal data and information disclosure for European entities. The US does not have a national data regulation, but some states such as California have their own version that needs to be considered, if applicable. * Target's industry can impact data disclosure as well. Healthcare organizations in the US have to respect HIPAA. School districts in the US need to be mindful of COPPA. Financial institutions also have other regulations such as SOX or GLBA. * Contact Information * Name, job title, email, phone number and escalation priority order during the engagement * Lines of Communication * What channels should be used during the engagement? Email, phone, in-person meetings.etc

This phase should always boil down to these main points: * Written consent from the owner or authorized agent of the network is required before testing begins, including a range of IPs / domains that are in-scope for testing * The scope can not be breached without additional written and signed addendums to the contract * Exploits should not damage the systems or network being tested * Access to discovered personal or company-confidential data should not be accessed without written consent. This is paramount to complying with the multitude of data disclosure regulations globally. * Intercepting communications (emails, phone calls) needs consent of one of the parties to prevent breach of wire-tapping or monitoring laws * Certain regulatory systems, such as systems under HIPAA, require additional authorization before testing can occur to prevent data disclosure, or downtime of critical infrastructure. For each pentest engagement, a new VM should be stood up. This prevents any traces of data from the last engagement and ensures we are starting with a clean slate. * Kali Linux or ParrotOS come with a breadth of tools to get off the ground running quickly.

It's important to state that during all phases of the process, detailed notes, including any screenshots, logs, commands, files created/removed, policies changed, hosts compromised, accounts compromised.etc, are being taken. Not only to aid during cleanup, but to make the final report easier to assemble.

Information Gathering

  • Different test types can differ in how much information we start with
    • Blackbox is the minimal information provided to start such as external IP ranges and domains. Nothing more.
    • Greybox provides an additional layer of information, maybe specific IPs, URLs, hostnames or subnets to focus on
    • Whitebox provides a full disclosure. Could be full network topology diagrams, detailed configurations, admin credentials, source code
  • Different environments can also vary how information is gathered
    • Some environments, like IoT or SCADA environments, are more fragile and cannot have automated tooling scanning or it could DoS the entire network.
    • Cloud environments mean the cloud provider also may need notified or have additional rules for engagement.
    • Mobile devices could be corporate-owned or BYOD, which could be out of scope.
  • During recon, it is important not to jump ahead at the first potential vulnerability discovered, but ensure as much information is gathered up front. This can help prevent a loss of time if the exploitation of the first vuln fails and won't require falling back into more recon.
    • Pentests differ from CTFs in that a pentest is meant to be exhaustive. This stage should be much more meticulous and require more patience to ensure as much information is gathered up front before the exploitation phase starts. CTFs tend to immediately jump into the first vuln/exploit as time is of the essence.
  • Multiple ways to gather this information including:
    • OSINT - reviewing publicly available data with methodologies such as Google Dorking. Does not require polling the target directly.
    • Enumeration - utilizing tooling directly on the authorized network ranges to attempt to discover services, hosts and other information.
      • See [[Footprinting]] for more info on methodology

Vulnerability Assessment

  • Divided into two areas, one is scanning for known vulns using automated tools. The other is analyzing the results to determine a path forward
  • Analysis can be broken down further into
    • Descriptive - describes data set based on characteristics
    • Diagnostic - ex. reviewing data to determine root cause of vulnerability
    • Predictive - evaluating historical and current data to determine future probabilities or detect trends
    • Prescriptive - narrow down what actions to take to eliminate a problem or trigger a certain action

Exploitation

  • One fork after the assessment stage, requires utilizing the information from the two prior steps to prepare targeted attacks against the found endpoint.
  • Attacks can be prioritized with the probability of success, complexity and probability of damage. CVSS scoring and NVD calculator can aid in determining the success rate.
  • Also broken into two main areas: actual exploitation of potential vulnerabilities, and remotely exposed services that could be misconfigured or vulnerable for access
  • Web exploitation tends to be its own special focus due to the diversity of web frameworks, hosting options, dependencies
  • There may not be a readily available PoC for a specific vulnerability. This requires setting up a local test VM as close as possible to the target environment. Then, we can attempt to reconstruct the exploit for use in the live test against our target, taking into consideration the easiness and destructiveness of the exploit.

Post-Exploitation

  • Once exploitation succeeds, access tends to be granted as least-privilege (ie, a locked-down service account specifically used for running the web app).
  • This stage essentially starts a new chapter for information gathering, as new recon is required to determine the best path forward into privilege escalation and/or lateral movement.
    • At the post-exploitation stage, pillaging is a new element for info gathering. This helps understand the role of the system and how it communicates with other systems that could be used for lateral movement or stealing credentials to re-use.
  • This stage can be the most critical for evasive testing. As simple commands like net user or whoami from a strange account or IP can trigger alerts and cause our comprised user account or host to become quarantined.
  • Data exfiltration can be an additional step during post-exploitation. This needs to be already stated in the scope, as the type of data could be under other regulations (HIPAA, PCI, GLBA.etc)
    • Dummy data could be created to test exfiltration and see if DLP, EDR or firewall systems detect this

Lateral Movement

  • Succeeds exploitation and part of post-exploitation. One of the available paths forward in further compromising the environment.

Proof-Of-Concept

  • A detailed writeup on how a vulnerability was exploited, that can be reproduced to confirm the vulnerability exists

Post-Engagement

  • Clean-up of all exploitation commands
  • Polishing of notes into a summary report that is detailed and consumable by both executive and technical teams
  • The role of a pentester is to remain impartial and provide remediation recommendations for all discovered activity. It is not on the pentester to perform any remediation or provide detailed remediation advice. (ie. "sanitize user input" for code vulnerable to SQL injection instead of rewriting and providing a copy of better code)
  • Regulations may require the evidence from the test be retained for a period of time. Encrypting these results and destroying the VM that was used during the test are critical for maintaining confidentiality.