1. Plan
A sound plan for your Penetration Test will help to keep you focused throughout the process.
Understand the client's scope
Understand why your client wants a Penetration test. Primarily, answer the popular 5 Ws and H (Who, What, Why, Where, When, and How). Understanding their motivation and requirements will help you identify the appropriate strategy, set realistic timelines, outline limitations, identify additionally needed information, and ultimately meet expectations.
Choose a strategy
Once you understand your client's requirements, you can choose an appropriate strategy. Typically, there are three (3 strategies :
White Box - The client shares a fair amount of private information to help you identify and understand your targets and the infrastructure. (e.g. version information, types of firewalls, IDS, IPS, client's IPs, client's domains, minimal infrastructure details, allow-list for Pentester IPs)
Grey Box - The client shares very limited private information about their network and systems (e.g. IPs, domains, minimal infrastructure details, allow-list for Pentester IPs).
Black Box - The client does not share any identifying details about their network and systems because they want you to simulate a real-world stranger attacking the network (e.g. client would confirm targets after your passive reconnaissance but no IDS/IPS exceptions for the IPs you'll be testing from).
Prepare your proposal
Your proposal should essentially outline what you will test and how you test it, in principle. Below are areas to consider when preparing a proposal for your client.
It's normal that only after your proposal is accepted, and a signed NDA is in place will your client share the specific IPs/domains to be targeted.
Outline your methodology
This is the high-level process you will take from start to finish. Providing your methodology shows that you have a structured process for the engagement from the perspectice of project management and professional knowledge about Penetration Testing. Below is an ordered summary of the Penetration Testing process you will commonly see online if you research.
| Phase | Description |
|---|---|
| 1. Footprinting (Passive and Active gathering) | Identifying active targets by discovering open and active services |
| 2. Enumeration (Active gathering) | Extracting information from to identify attack vectors. |
| 3. Vulnerability scanning | Broad automated and manual scans that will check for vulnerabilities across all open ports. |
| 4. Exploitation | At this phase, you will take advantage of previously confirmed weaknesses in your targets to gain access to sensitive data/areas. |
| 5. Post-exploitation | Using the access obtained to gain greater access and control over your target(s). |
| 6. Report | Communicating the findings of security weaknesses and issues discovered throughout the engagement |
Define a reporting format
Describe how you will report your findings. Choose a format valuable to your client based on their feedback. Some clients have specific reporting requirements based on their internal reporting tools and structure.
Examples of sections to include: Executive and Technical.
Examples of output formats: MS WORD, PDF, Excel (tabular).
State disclaimers and restrictions
First, assess the laws and regulations applicable to both you and your client to ensure your testing doesn't trigger an offence.
Secondly, find out from your client if there are any limitations that will be imposed during testing and give some examples, such as: requiring testing only during certain hours, exlucing certain types of exploitation.
It's important to get these details clear from the porposal stage because if limitations are only provided after your porposal then they can negatively affect your planned budget, resources, timelines and staff availability.
Note
Limitations on testing must also be outlined in the Rules of Engagement document which usually has more granular details about limitations such as the contact person's information for emergencies (you wouldn't receive this when preparing a proposal). You can populate the RoE based on your client's feedback, or they may already have one prepared.
Some very mature clients will require this to be a signed document from them after your proposal is accepted, while others may send an email outlining when testing is allowed and test case to exclude.
State prices
Calculate your costs from start to finish, add your markup and charge your service price. Cost is your own time and resources. The service price is what your client will pay you.
Signed NDA (Non-Disclosure Agreement)
Include a reference to any previously signed NDA or attach the signed NDA in the Appendices section of the report.
Note
It's normal that only after a client accepts your proposal, and a signed NDA is in place will you receive the specific IPs/domains to be targeted.
Define the Rules of Engagement (RoE)
Mutually document the boundaries of testing which the client requires, using an RoE document.
The Rules of Engagement document is important because your proposal highlights more of what will be done, but clients often have specific requirements limitations and requirements such as: the time of day for testing, limitations on a specific IP/domain because of its sensitivity, who should be contacted in emergencies, how often they want to be updated, how data should be handled, etc.
Identify testing periods
Document the client's acceptable times of day for testing. Some clients may not want testing to occur doing normal or peak business hours.
Get the specific targets
List the specific IPs and domains to be tested.
List escalation contacts
Get mobile contact details of people who must be contacted in emergencies and for critical findings.
Get client's authorisation
Get formal approval from authorised officials (usually Senior Management). Approval is commonly a signature on a physical or digital document.
Verify Third-Party authorisation
In some cases, a target may be hosted by a Third-Party such as a Cloud Service Provider (CSP). Sometimes Cloud Service Customers (CSCs) would be required by the CSP to get authorisation before launching any Penetration Tests because the CSP's cloud environment is shared with multiple other customers (CSCs).
Note
Ask for a copy of the authorisation before you start testing. In some cases the CSP may send a normal email message giving authorisation to your client ( the CSC) and not a formal document.
Test Environment
Prepare your systems for testing.
Virtual Machines, OS, and tools
Consider using VMs (Virtual Machines) for your testing machines because it makes it easier to deploy a new and clean system for each engagement.
Also, consider the impact of any licensing restrictions for commercial tools you use as you delete and spin up new VMs which had licensed tools installed.
2. Gather Information
Passive Gathering
Indirectly gather information on your target company.
Identify Artefacts
Use Search Engines to discover indexed content.
Below are sample items you should interrogate.
| Files | Paths | Other |
|---|---|---|
| Pages | Directories | Misconfigurations |
| Images | Login portals | Email address |
| Audio/ Video | Error pages | Sensitive Disclosures |
Identify Metadata
Analyse user-generated files (especially documents) for metadata. Metadata means data about data.
Below are sample resources you can use.
| Tools | Platforms | Used for |
|---|---|---|
| Metagoofil | Linux | Documents |
| exiftool | Linux | Images |
| Clean Docs (Commercial) | Windows | Documents |
| Metashield Analyzer (Commerical) | Browser-based | Documents and Images |
Below are examples of meta-data on documents.
| Data type | Data type | Data type |
|---|---|---|
| Creator/ Username | Description | Version |
| Date Created | Tags | Operating System |
| Program Generator | Comments | Date Last Modified |
Identify People
People refer to employees and related third parties. These sample areas can help in profiling human users and deduct or solicit sensitive information.
| Social Media | Interests | Search Engines |
|---|---|---|
| Likes | Articles | |
| Affiliations | Blog Posts | |
| Idols | Forums | |
| Relatives | News |
Note
Business Social Media such as LinkedIn can help to deduct internal network infrastructure because people often state the kind of technologies they use in their current role. Knowing someone's full name can help in guessing username formats for brute-force attacks and email address formats (if no emails are found). People's interests can help in guessing their passwords by profiling them. e.g. A major Barcelona football fan. Social engineering attacks can be tailored to someone's publicised lifestyle, friends, affiliations, likes and dislikes
Identify Infrastructure and Technologies
Internet Scanners
Internet scanners provide useful reports on both IPs and domains infrastructure without you interacting with the target.
Below are sample resources you can use.
| Resources/ Tools | Platforms | Vendor |
|---|---|---|
| Site Report | Browser-based | Netcraft |
| Built With | Windows | Built With |
Identify domain owners
You can use WHOIS Lookups to help identify domain owners. Don’t be surprised if their identity information is masked. That means you don't see domain owners name, address nor phone number. This is often because they paid for a specific privacy service called Domain Privacy or is automatically given privacy under GDPR.
whois
whois example.com
# whois | calls the whois program
# example.com | the domain for which you want to retrieve the registration record
Analyse DNS - Forward and Reverse DNS Lookups
Start to map domains to IPs and IPs to domains through DNS. Forward DNS Lookup provides you with a domain to IP mapping while a Reverse DNS Lookup provides IP to domain mapping.
Below are sample Linux commands for some DNS analysis tools. This assumes you're using an OS with the tools below already installed. E.g. Kali Linux.
dnsenum
dnsenum example.com
# dnsenum | calls the program
# example.com | is the domain you are selecting to scan
# The above query does not try to brute-force sub-domains. It will only run basic queries against the domain's nameservers.
dnsenum -f file.txt example.com
# -f or --file | is the command that tells dnsenum that you want to use a wordlist.
# file.txt | is the file containing the list of words you want to use when brute-forcing sub-domains.
dnsrecon
dnsrecon -d example.com
# dnsenum - calls the program
# example.com- is the domain you are setting to scan
# The above query does not try to brute-force sub-domains. It will only run basic queries against the domain's nameservers.
dnsenum -D file.txt example.com
# -D or --dictionary | is the command that tells dnsrecon that you want to use a wordlist.
# file.txt | is the file containing the list of words you want to use when brute-forcing sub-domains.
fierce
fierce -dns example.com
# -dns | is the command to set the domain you would like to scan
# By default, fierce uses it's own built-in wordlist to brute-force sub-domains
fierce -dns example.com -wordlist file.txt
# -wordlist | allows you to specify your own wordlist to use when brute-forcing sub-domains.
Identify Routes to Targets
Identify the route your connection takes to reach your target(s). Additional IPs and domains may be revealed.
Below are sample Linux commands for some DNS analysis tools.
traceroute (Linux)
traceroute 192.168.10.1
# traceroute | calls the program
# example.com | IP address for which you want to check the route (number of hops)
tracert (Windows)
tracert 192.168.10.1
# tracert | calls the program
# example.com | IP address for which you want to check the route (number of hops)
nmap
nmap --script=http-traceroute 192.168.10.1
# dnsenum - calls the program
# --script=http-traceroute |
# 192.168.10.1 | is the IP you are targeting you are setting to scan
nmap --script=http-traceroute -iL filename.txt
# -iL | Input from list of hosts/networks
# filename.txt | is the location to the file containing the target hosts.
# nmap does a traceroute for all targets when you use the -A option
Automated Footprinting
Automate some of the process to identify and correlate targets.
Below are sample tools you can use.
| Tool | Platform | License |
|---|---|---|
| Maltego | Linux and Windows | Free and Commercial |
| Recon-ng | Linux | Open-source |
Active Gathering
Connect to the target host and begin to explore each active service.
Scan Ports
By now, you've identified and confirmed a list of target IP addresses, domains and gathered public information about your client. Now, let's identify live hosts, their open ports and active services.
The primary aim is to extract enough useful data from each active service to identify potential angles of attack (Attack Vectors).
Ping Scan
Run a ping scan to identify live hosts quickly.
Port Scan
Scan for open ports without sending pings to identify which services are running. Some IT admins disable response to pings. Remember, because a port is open, doesn't mean that it's running the default service associated with that port. E.g. port 443 (default service: HTTPS) can be configured to provide SSH (default port: 22).
SYN Scan - The TCP handshake is stopped at SYN/ACK. No ACK is sent to the target.
Connect Scans - The full TCP handshake is completed.
Sample NMap commands
Below are some basic commands you can run if you're using nmap to do port scans.
A single IP
nmap -A -Pn -p 0-65535 192.168.10.1
# nmap | calls the program
# -A | Enable OS detection, version detection, script scanning, and traceroute
# -Pn | Do not ping the host before scanning
# -p 0-65535 | specifies the port range you want to scan
# 192.168.10.1 | is just a random IP address for demonstration purposes
Subnet of IPs
nmap -A -Pn -p 0-65535 192.168.10.1/24
# nmap | calls the program
# -A | Enable OS detection, version detection, script scanning, and traceroute
# -Pn | Do not ping the host before scanning
# -p 0-65535 | specifies the port range you want to scan
# 192.168.10.1 | target IP address
# /24 | tells nmap to scan a subnet of the first 3 octets. ie. 192.168.10.1- 192.168.10.254
# You may use /8 and /16 in after your target IP address according to your requirements
A list of IPs
nmap -A -Pn -p 0-65535 -iL filename.txt
# nmap | calls the program
# -A | Enable OS detection, version detection, script scanning, and traceroute
# -Pn | Do not ping the host before scanning
# -p 0-65535 | specifies the port range you want to scan
# -iL | Input from list of hosts/networks
# filename.txt | is the location to the file containing the target hosts.
Below are sample tools you can use.
| Tool | Platform | License |
|---|---|---|
| Maltego | Linux and Windows | Free and Commercial |
| Recon-ng | Linux | Open-source |
Below are samples of popular services you may see from a port scan, their associated service and summary.
| Port # | Default Service | Suggestion |
|---|---|---|
| 21 | FTP | A file transfer service is running. |
| 22 | SSH | A remote administration service is running |
| 80 | HTTP | An unencrypted protocol transmitting web traffic |
| 443 | HTTPS | An encrypted protocol transmitting web traffic |
| 8080 | HTTP | A web proxy service is running |
| 3389 | RDP | A Windows remote desktop service is running |
Note
In a Black Box strategy, enumerating all ports at once increases the risk of triggering security sensors. In a White Box strategy, your IP address is likely to be white-listed by your client to prevent blocking.
Enumeration
Attack Vectors
Based on the nature of the service running on each port, use appropriate methods to connect and extract and analyse relevant data.
Extracting and analysing will help narrow-down feasible entry points.
Below are samples of information you're targeting.
| Info | Use |
|---|---|
| Find software versions | Linux |
| Identify the Operating System | Linux |
| Bruteforce Files and Directories | Linux and Windows |
| Find valid user IDs | Linux |
| Bruteforce access credentials | Linux |
| Find sensitive disclosures | Linux |
| Find login areas | Linux |
Sample of website root directory
- Expand all
- Collapse all
- index - Homepage of web application - loads by default when the domain is visited
- robots.txt - A text file intended to be publicly accessible for directing Search Engine Spiders. This file often discloses sensitive directories administrators do NOT want to be indexed (A poor approach).
- admin -
In most cases, this directory is for administrative purposes and is often NOT linked on the front-end for regular users or shown only in the source code of a page. This is where directory brute-forcing is useful and inspecting front-end source code.
- login - This is often the path to an administrative login page and also may not be linked in front-end html code which is not visible in User Interface (UI). This is why crawling and recursive directory brute-forcing is important.
- register - This is often a registration for new users and depending on the purpose of the web application it may or may not be linked on the front-end. This may be a BIG security issue as you may be able to create unauthorised users and log into the application.
- temp -
This may be a directory that is not linked on the front end but contains server-side files which are exposed (publicly accessible) or have directory listing enabled
- backup.txt - May not be linked on the front-end but can be recursively brute-forced. It may disclose details of database backups events, table names, errors, admin users, etc.
- password.txt This may not be linked on the front end but can be recursively brute-forced. It may contain passwords or other private details because an admin believed it's "hidden" since it's not linked on the front-end.
- default.txt - May be some default file which may have been overlooked when implementing the web application. It may contain sensitive details but may not be linked on the front-end but easily guessable. Additionally, emphasising the importance of enumeration.
- js -
This directory often contains front-end JavaScripts which sometimes discloses backend functionality. In many situations server-side validation is not being done. This directory and files are usually publicly linked in response pages.
- form-validation.js - May give insight into what kind of input is being validated client-side. This may help with crafting malicious inputs such as SQL injections.
- login.js - May give insight into how log in works client-side and deduce server-side actions.
- css -
This directory and files are usually publicly linked in response pages and set the display styles of pages.
- bootstrap.css
- style.css
- style.min.css
- img -
This directory often contains images of the web application but sometimes accepts POST and PUT requests. This directory and files are usually publicly linked in response pages and often time have directory indexing allowed.
- image1.jpg - A publicly linked image file but may contain useful meta-data.
- image2.png - An UNLINKED linked image file but may contain useful meta-data.
Research and Analysis
You've gathered some valuable information, now do some research (online especially) to start narrowing your strategy of attack.
Next, you should run broad automated vulnerability scans to help discover vulnerabilities and confirm some of the information/weaknesses you may already know.
3. Scan for Vulnerabilities
Run broad automated scans that will check for thousands of vulnerabilities across all open ports.
Note
In a Black Box approach, it's wise to only run vulnerability scans on known open ports to minimise security alerts. In a White Box approach, it's wise to run vulnerability scans on all ports to increase the chances of identifying additional data missed in previous checks.
Scan for network-level vulnerabilities
Identify weaknesses in services which don't run in a browser. Additionally, you're aiming to find weaknesses such as missing security patches, misconfiguration, End of Life software, information disclosures, potential SQL injection, and Improper Error Handling.
Common network vulnerabilities
Below are samples of vulnerabilities commonly discovered from a web vulnerability scan.
| High Impact | Medium Impact | Low Impact |
|---|---|---|
| End of Life OS/unsupported Software | Information Disclosure | Disclosed Login Pages |
| Buffer Overflow | Weak Cryptography | Expired Certificate |
| Default Credentials | Weak Password Policy | Default Community Strings |
| Missing Security Patches | Misconfigurations | Broken File Permissions |
| Privilege Escalation | Arbitrary File Access | Improper Error Handling |
| Unauthenticated Access | Remote File Inclusion | Malware Common Ports Active |
| OS command Injection | User Enumeration | Insecure Temporary File |
Below are examples of vulnerability scanners.
| Tool | Platform | License |
|---|---|---|
| Nessus | Linux and Windows | Commercial |
| Nexpose | Linux and Windows | Commercial |
| Core Impact | Windows | Commercial |
| OpenVas | Linux | Open Source |
Note
Many vulnerabilities are often attached to the specific version of software running. So identifying version numbers is critical.
Scan for web level vulnerabilities
Find vulnerabilities in hosts accessible through a web browser.
Common web vulnerabilities
Below are samples of vulnerabilities commonly discovered from a web vulnerability scan.
| High Impact | Medium Impact | Low Impact |
|---|---|---|
| SQL Injection | Debugging Enabled | Source code disclosure |
| File Path Traversal | Cross-site request forgery | Unencrypted communications |
| Code Injection | Header injection | Strict transport security not enforced |
| Cross-site Scripting | SQL statement in request parameter | Client-side HTTP parameter pollution |
| Local File Path Manipulation | Database connection string disclosed | Link manipulation (stored DOM-based) |
| Clear text submission of passwords | Open redirection (stored) | Cookie manipulation (DOM-based) |
| HTTP PUT Method enabled | SSL cookie without secure flag set | Password field with autocomplete enabled |
Manual scanning
Manually probe for vulnerabilities based on your target's active services.
Analyse exposed source code.
Fuzz software for sensitive disclosures and abnormal responses
4. Exploit & Post-Exploit
At this phase, you will take advantage of previously confirmed weaknesses in your targets.
Exploit
There are two (2) basic options at this point: create an exploit or source an exploit.
Craft your exploit using a suitable approach. Some exploits are more successful when done manually while others are better when automated.
Note
Remember to the inspect any exploit code you find online to ensure it's legitimate and safe.
Post-Exploit
You've executed a successful exploit and gained access to private sensitive areas or sensitive data on your target. Now it's time to see how much further across the network you can go based on the compromised host.
Pull sensitive data
Pull data from your currently compromised host and use it to improve your network map and develop further targeted attacks.
Use existing access rights (Horizontal movement)
Use your current level of access to find and attack other internal systems, especially those not reachable from the internet.
Increase access rights (vertical movement)
Use trusted exploits and methods to increase what you can access. Increasing your access will help you to get a stronger hold on the network where you can compromise more hosts.
Be careful; some exploits may cause a Denial of Service.
Compromise other systems
Use your initial compromise to reach and compromise other in-scope systems.
Maintain Access
Keep your access alive through other means in case your initial exploit is detected and blocked. Maintaining access can usually be done through means such as creating fake user accounts for public hosts, installing keyloggers, and installing remote shells.
5. Report & Clean-Up
Communicate the findings of security weaknesses and issues discovered throughout the engagement.
Get to the point with your findings and rank each by how badly it impacts your client's business (e.g. Critical, High, Medium, Low, Informational). Concisely express each issue (Finding), why it's bad (Impact), targets affected (IPs/domains, URLs), and how each finding could be minimised or fixed (Remediation/Recommendation).
Below is a sample layout you could use for a report.
Reporting layout
Cover page - State the report's title, your client's name and date, at a minimum.
Table of Contents - A list of headings throughout the document.
Scope - What was agreed to be tested.
Approach - How testing was done.
Executive Findings - A summary of weaknesses discovered, targeted to decision-makers, like senior management.
Technical Findings - Details of weaknesses discovered, formatted for technical staff, like network administrators.
Appendices - Additional supportive information, such as screenshots, tables, charts, references and extracts of related documents.
Note
The primary objective is to ensure your client understands the findings from your Penetration Test. A single format may not suit all of your clients, so be open to tweaking your reporting layout to suit your clients' needs.
Clean-up
After your testing or any critical compromises, you should provide your client with a reasonably detailed list of changes you've made to their systems.
This list will help your client to decide which systems need to be cleaned and the extent of cleaning required such as whether files need to be deleted, settings need to be rolled back or an entire OS(Operating System) system needs to be restored from a trusted backup.
Even if you don't think a system change was major, it's still important to share it.
6. Close Engagement
Client satisfaction
Get feedback from your client about their experience working with you to execute a Penetration Test from start to end and how you could improve.
Payment
Collect any outstanding monies owed to you. If you're an internal staff like a Red Team member, then this may not be applicable to you because you won't be billing your own company.
Document lessons learnt
Make notes of what went well and what did not, so you can continuously improve future Penetration Tests.
References:
- Nmap Cheat Sheet | HighOn.Coffee
- Issue Definitions | Burp Suite - Portswigger.
- Mastering Kali Linux for Advanced Penetration Testing - Second Edition: Secure your network with Kali Linux - the ultimate white hat hackers' toolkit
- The Hacker Playbook 3: Practical Guide To Penetration Testing Paperback – by Peter Kim
- PTEST Standard