penetration testing execution standard
0x01 High Level Organization of the Standard
The penetration testing execution standard consists of seven (7) main sections. These cover everything related to a penetration test.
from the initial communication and reasoning behind a pentest,
through the intelligence gathering and threat modeling phases where testers are working behind the scenes in order to get a better understanding of the tested organization,
through vulnerability research, exploitation and post exploitation, where the technical security expertise of the testers come to play and combine with the business understanding of the engagement,
and finally to the reporting, which captures the entire process, in a manner that makes sense to the customer and provides the most value to it.
0x02 Pre-engagement Interactions
Remember, a penetration test should not be confrontational. It should not be an activity to see if the tester can “hack” you. It should be about identifying the business risk associated with and attack.
2.2 Introduction to Scope
Neglecting to properly complete pre-engagement activities has the potential to open the penetration tester (or his firm) to a number of headaches including scope creep, unsatisfied customers, and even legal troubles.
The scope of a project specifically defines what is to be tested. How each aspect of the test will be conducted will be covered in the Rules of Engagement section.
One key component of scoping an engagement is outlining how the testers should spend their time.
It is important in the Pre-Engagement phase that the tester is able to serve as a guide through what may be uncharted territory for a customer.
The tester must understand the difference between a test which focuses on a single application with severe intensity and a test where the client provides a wide range of IP addresses to test and the goal is to simply find a way in.
2.3 Metrics for Time Estimation
Once the time to test is determined, it is a prudent practice to add 20% to the time.
Another component of the metrics of time and testing is that every project needs to have a definitive drop dead date.
All good projects have a well-defined beginning and end.
2.4 Scoping Meeting
The goal of the scoping meeting is to discuss what will be tested. Rules of engagement and costs will not be covered in this meeting.
First, it needs to be established explicitly what IP ranges are in scope for the engagement. It is not uncommon for a client to be resistant and assume that it is the prerogative of the tester to identify their network and attack it, to make the test as realistic as possible. This would indeed be an ideal circumstance, however, possible legal ramifications must be considered above all else.
2.5 Additional Support Based on Hourly Rate
Any requests outside of the original scope should be documented in the form of a statement of work that clearly identifies the work to be done. We also recommend that it be clearly stated in the contract that additional work will be done for a flat fee per hour and explicitly state that additional work can not be completed until a signed and counter-signed SOW is in place.
2.7 General Questions
2.7.1 Network Penetration Test 2.7.2 Web Application Penetration Test 2.7.3 Wireless Network Penetration Test 2.7.4 Physical Penetration Test 2.7.5 Social Engineering 2.7.6 Questions for Business Unit Managers 2.7.7 Questions for Systems Administrators
2.8 Scope Creep
do not hesitate to ask for additional funding to compensate for the extra time spent. If a customer refuses to pay for the extra work, it is almost never worth staying on to do that work.
The second point is even more critical. When dealing with existing customers, take care to keep the prices lower. Taking advantage of a good situation by price gouging is a sure way to drive away repeat business.
2.9 Specify Start and End Dates
To mitigate this risk, add a simple statement to the contract which mentions that all retesting must be done within a certain timeframe after the final report delivery.
2.10 Specify IP Ranges and Domains
Before starting a penetration test, all targets must be identified. These targets should be obtained from the customer during the initial questionnaire phase. Targets can be given in the form of specific IP addresses, network ranges, or domain names by the customer.
2.11 Dealing with Third Parties
The most important thing to remember is that while permission may have been granted by the client, they do not speak for their third party providers. Thus, permission must be obtained from them as well in order to test the hosted systems. Failing to obtain the proper permissions brings with it, as always, the possibility of violating the law, which can cause endless headaches.
2.11.1 Cloud Services 2.11.2 ISP 2.11.3 MSSPs Managed Security Service Providers also may need to be notified of testing. 2.11.4 Countries Where Servers are Hosted
2.12 Define Acceptable Social Engineering Pretexts
Be sure that any pretexts chosen for the test are approved in writing before testing is to begin.
2.13 DoS Testing
Stress testing or Denial of Service testing should be discussed before the engagement begins.
if the organization is also worried about the availability of their services, then the stress testing should be conducted in a non-production environment which is identical to the production environment.
2.14 Payment Terms
2.14.1 Net 30 The total amount is due within 30 days of the delivery of the final report. This is usually associated with a per month percentage penalty for non-payment. This can be any number of days you wish to grant your customers (i.e. 45, or 60).
2.14.2 Half Upfront It is not uncommon to require half of the total bill upfront before testing begins. This is very common for longer-term engagements.
2.14.3 Recurring A recurring payment schedule is more commonly used for long-term engagements. For example, some engagements may span as far as a year or two. It is not at all uncommon to have the customer pay in regular installments throughout the year.
Every penetration test should be goal-oriented. This is to say that the purpose of the test is to identify specific vulnerabilities that lead to a compromise of the business or mission objectives of the customer. It is not about finding un-patched systems. It is about identifying risk that will adversely impact the organization.
2.15.1 Primary The primary goal of a test should not be driven by compliance.
2.15.2 Secondary The secondary goals are directly related to compliance.
2.15.3 Business Analysis Before performing a penetration test it is beneficial to determine the maturity level of the client’s security posture For customers with a very immature security program, it is often a good idea to perform a vulnerability analysis first.
Some testers believe there is a stigma surrounding Vulnerability Analysis (VA) work. Those testers have forgotten that the goal is to identify risks in the target organization, not about pursuing the so-called “rockstar” lifestyle. If a company is not ready for a full penetration test, they will get far more value out of a good VA than a penetration test.
Establish with the customer in advance what information about the systems they will be providing. It may also be helpful to ask for information about vulnerabilities which are already documented. This will save the testers time and save the client money by not overlapping testing discoveries with known issues. Likewise, a full or partial white-box test may bring the customer more value than a black-box test, if it isn’t absolutely required by compliance.
2.16 Establish Lines of Communication
One of the most important aspects of any penetration test is communication with the customer. How often you interact with the customer, and the manner in which you approach them, can make a huge difference in their feeling of satisfaction.
2.17 Emergency Contact Information
Obviously, being able to get in touch with the customer or target organization in an emergency is vital. Emergencies may arise, and a point of contact must have been established in order to handle them.
2.17.1 Incident Reporting Process 2.17.2 Incident Definition 2.17.3 Status Report Frequency 2.17.4 PGP and Other Alternatives
2.18 Rules of Engagement
2.18.1 Timeline A clear timeline should be established for the engagement. While scope defines the start and the end of an engagement, the rules of engagement define everything in between.
GANTT Charts and Work Breakdown Structures are often used to define the work and the amount of time that each specific piece of the work will take. Seeing the schedule broken down in this manner aids those involved in identifying where resources need to be applied and it helps the customer identify possible roadblocks which many be encountered during testing
2.18.2 Locations Another parameter of any given engagement which is important to establish with the customer ahead of time is any destinations to which the testers will need to travel during the test. This could be as simple as identifying local hotels, or complex as identifying the applicable laws of a specific target country.
However, if the data cannot be physically or virtually obtained, how can it be proved that the testers indeed obtained access to the information? This problem has been solved in a number of ways. There are ways to prove that the vault door was opened without taking any of the money. For instance, a screenshot of database schema and file permissions can be taken, or the files themselves can be displayed without opening them to displaying the content, as long as no PII is visible in the filenames themselves.
2.18.3 Evidence Handling When handling evidence of a test and the differing stages of the report it is incredibly important to take extreme care with the data. Always use encryption and sanitize your test machine between tests. Never hand out USB sticks with test reports out at security conferences. And whatever you do, don’t re-use a report from another customer engagement as a template! It’s very unprofessional to leave references to another organization in your document.
2.18.4 Regular Status Meetings Throughout the testing process it is critical to have regular meetings with the customer informing them of the overall progress of the test. These meetings should be held daily and should be as short as possible. Meetings should be kept to three concepts: plans, progress and problems. Plans are generally discussed so that testing is not conducted during a major unscheduled change or an outage. Progress is simply an update to the customer on what has been completed so far. Problems should also be discussed in this meeting, but in the interest of brevity, conversations concerning solutions should almost always be taken offline
2.18.5 Time of the Day to Test Certain customers require all testing to be done outside of business hours. This can mean late nights for most testers. The time of day requirements should be well established with the customer before testing begins.
2.18.6 Dealing with Shunning
2.18.7 Permission to Test One of the most important documents which need to be obtained for a penetration test is the Permission to Test document. This document states the scope and contains a signature which acknowledges awareness of the activities of the testers.
2.18.8 Legal Considerations Some activities common in penetration tests may violate local laws. For this reason, it is advised to check the legality of common pentest tasks in the location where the work is to be performed. For example,any VOIP calls captured in the course of the penetration test may be considered wiretapping in some areas.
2.19 Capabilities and Technology in Place
Good penetration tests do not simply check for un-patched systems. They also test the capabilities of the target organization. To that end, below is a list of things that you can benchmark while testing.
- Ability to detect and respond to information gathering
- Ability to detect and respond to foot printing
- Ability to detect and respond to scanning and vuln analysis
- Ability to detect and respond to infiltration (attacks)
- Ability to detect and respond to data aggregation
Ability to detect and respond to data ex-filtration
When tracking this information be sure to collect time information. For example, if a scan is detected you should be notified and note what level of scan you were preforming at the time.
0x03 Intelligence Gathering
Levels are an important concept for this document and for PTES as a whole. It’s a maturity model of sorts for pentesting. Defining levels allows us to clarify the expected output and activities within certain real-world constraints such as time, effort, access to information, etc.
Level 1 Information Gathering (think: Compliance Driven) Mainly a click-button information gathering process. This level of information can be obtained almost entirely by automated tools. Bare minimum to say you did IG for a PT.
Level 2 Information Gathering (think: Best Practice) This level can be created using automated tools from level 1 and some manual analysis. A good understanding of the business, including information such as physical location, business relationships, org chart, etc.
Level 3 Information Gathering (think: State Sponsored) More advanced pentest, Redteam, full-scope. All the info from level 1 and level 2 along with a lot of manual analysis. An Army Red Team is tasked to analyze and attack a segment of the Army’s network in a foreign country to find weaknesses that could be exploited by a foreign national. A level 3 information gathering effort would be appropriate in this case.
3.2 Intelligence Gathering
3.2.1 What it is Intelligence Gathering is performing reconnaissance against a target to gather as much information as possible to be utilized when penetrating the target during the vulnerability assessment and exploitation phases. The more information you are able to gather during this phase, the more vectors of attack you may be able to use in the future. Open source intelligence (OSINT) is a form of intelligence collection management that involves finding, selecting, and acquiring information from publicly available sources and analyzing it to produce actionable intelligence. 1 3.2.2 Why do it We perform Open Source Intelligence gathering to determine various entry points into an organization. These entry points can be physical, electronic, and/or human. Many companies fail to take into account what information about themselves they place in public and how this information can be used by a determined attacker. On top of that many employees fail to take into account what information they place about themselves in public and how that information can be used to to attack them or their employer. 3.2.3 What is it not OSINT may not be accurate or timely. The information sources may be deliberately/accidentally manipulated to reflect erroneous data, information may become obsolete as time passes, or simply be incomplete. It does not encompass dumpster-diving or any methods of retrieving company information off of physical items found on-premises.
3.3 Target Selection
3.3.1 Identification and Naming of Target It is also not all that uncommon for a company to have a number of sub-companies underneath them. For example General Electric and Proctor and Gamble own a great deal of smaller companies.
3.3.2 Consider any Rules of Engagement limitations 3.3.3 Consider time length for test 3.3.4 Consider end goal of the test Every test has an end goal in mind - a particular asset or process that the organization considers critical. Having the end result in mind, the intelligence gathering phase should make sure to include all secondary and tertiary elements surrounding the end goal. Be it supporting technologies, 3rd parties, relevant personnel, etc… Making sure the focus is kept on the critical assets assures that lesser relevant intelligence elements are de-prioritized and categorized as such in order to not intervene with the analysis process.
Open Source Intelligence (OSINT) takes three forms; Passive, Semi-passive, and Active.
3.5 Covert Gathering
3.7 Identify Protection Mechanisms
0x04 Threat Modeling
The standard focuses on two key elements of traditional threat modeling - assets and attacker (threat community/agent). Each one is respectively broken down into business assets and business processes and the threat communities and their capabilities.
As a minimum, all four elements should be clearly identified and documented in every penetration test.
The model should be clearly documented, and be delivered as part of the final report as the findings in the report will reference the threat model in order to create a more accurate relevance and risk score that is specific to the organization (rather than a generic technical one).
4.1.1 High level threat modeling process 1. Gather relevant documentation 2. Identify and categorize primary and secondary assets 3. Identify and categorize threats and threat communities 4. Map threat communities against primary and secondary assets
There are a variety of tools available to identify targets and map attack vectors. These normally focus on the business assets (what systems to target) and business processes (how to attack them.)
4.2 Business Asset Analysis
4.2.1 Organizational Data Policies, Plans, and Procedures Product Information (e.g. trade secrets, R&D data) Marketing Information (plans, roadmaps, etc.) Financial Information (e.g. bank, credit, equity accounts) Technical Information • Infrastructure Design Information • System Configuration Information • User Account Credentials • Privileged User Account Credentials
Employee Data Customer Data
4.2.2 Human Assets • Executive Management • Executive Assistants • Middle Management • Administrative Assistants • Technical/Team Leads • Engineers • Technicians • Human Resources
4.3 Business Process Analysis
By mapping these processes, identifying the critical vs. non-critical processes and eventually finding flaws in them we are able to understand how the business works, what makes them money and eventually how specific threat communities can make them lose money.
4.3.1 Technical infrastructure supporting process As business processes are usually supported by IT infrastructure (such as computer networks, processing power, PCs for entering information and managing the business process, etc…), all those elements must be identified and mapped. Such mapping should be clear enough to be used later on in the process when translating the threat model to the vulnerability mapping and exploitation.
4.3.2 Information assets supporting process 4.3.3 Human assets supporting process 4.3.4 3rd party integration and/or usage of/by process
4.4 Threat Agents/Community Analysis
4.5 Threat Capability Analysis
4.6 Motivation Modeling
0x05 Vulnerability Analysis
Vulnerability testing is the process of discovering flaws in systems and applications which can be leveraged by an attacker. These flaws can range anywhere from host and service misconfiguration, or insecure application design.Although the process used to look for flaws varies and is highly dependent on the particular component being tested, some key principals apply to the process.
When conducting vulnerability analysis of any type the tester should properly scope the testing for applicable depth and breadth to meet the goals and/or requirements of the desired outcome. Depth values can include such things as the location of an assessment tool, authentication requirements, etc. For example; in some cases it maybe the goal of the test to validate mitigation is in place and working and the vulnerability is not accessible; while in other instances the goal maybe to test every applicable variable with authenticated access in an effort to discover all applicable vulnerabilities. Whatever your scope, the testing should be tailored to meet the depth requirements to reach your goals. Depth of testing should always be validated to ensure the results of the assessment meet the expectation (i.e. did all the machines authenticate, etc.). In addition to depth, breadth must also be taken into consideration when conducting vulnerability testing. Breadth values can include things such as target networks, segments, hosts, application, inventories, etc. At its simplest element, your testing may be to find all the vulnerabilities on a host system; while in other instances you may need to find all the vulnerabilities on hosts with in a given inventory or boundary. Additionally breadth of testing should always be validated to ensure you have met your testing scope (i.e. was every machine in the inventory alive at the time of scanning? If not, why).
There are two distinct ways to interact with the target component: automated, and manual.
Automated Automated testing utilizes software to interact with a target, examine responses, and determine whether a vulnerability exists based on those responses.
Network/General Vulnerability Scanners Port Based When the scanner determines that a port is open, a presumption is made by the scanner as to whether a vulnerability is present or not. For example, if a port based scanner connects to TCP port 23, and that port is listening, the scanner is likely to report that the telnet service is available on the remote host, and flag it as having a clear text authentication protocol enabled.
Web Application Scanners General application flaw scanners Most web application scans start with the address of a website, web application, or web service. The scanner then crawls the site by following links and directory structures. After compiling a list of webpages, resources, services and/or other media offered, the scanner will perform tests, or audits against the results of the crawl. For example, if a webpage discovered in the crawl has form fields, the scanner might attempt SQL injection or cross-site scripting. If the crawled page contained errors, the scanner might look for sensitive information displayed in the error detail, and so on.
Directory Listing/Brute Forcing
Web Server Version/Vulnerability Identification Methods OPTIONS PUT/DELETE TRACE/TRACK
Network Vulnerability Scanners/Specific Protocols VPN Voice Network Scanners War Dialing VoIP
Manual Direct Connections As with any automated process or technology, the margin for error always exists. Instabilities in systems, network devices and network connectivity may introduce inaccurate results during testing. It is always recommended to execute manual direct connections to each protocol or service available on a target system to validate the results of automated testing as well as identifying all potential attack vectors and previously unidentified weaknesses.
Obfuscated Multiple Exit Nodes Security monitoring and defense systems operate under the pretense of identifying malicious activity from a specific IP address. In situations where Intrusion Detection systems are deployed and monitoring activity, sourcing assessment and attack activities from multiple IP addresses provide more accurate results and lessen the opportunity for a monitoring device on a target network to identify and respond.
IDS Evasion When conducting assessment activities against a target environment where IDS technologies are deployed, it may be necessary to perform evasion. Using methods such as string manipulation, polymorphism, session splicing, and fragmentation can provide more accurate results while bypassing signature matching patterns implemented in IDS devices.
Metadata Analysis Though metadata is quite common on documents located on a company’s internal network, companies should take care to purge metadata before making documents available to the public, or on the public Internet. For this reason, any metadata an attacker could gain access to passively (without directly attacking the target) should be considered a security issue.
Correlation between Tools When working with multiple tools the need for correlation of findings can become complicated. Correlation can be broken down into two distinct styles, specific and categorical correlation of items, both are useful based on the type of information, metrics and statistics you are trying to gather on a given target.
Manual Testing/Protocol Specific
Attack Avenues Creation of attack trees During a security assessment, it is crucial to the accuracy of the final report to develop an attack tree as testing progresses throughout the engagement. As new systems, services and potential vulnerabilities are identified; an attack tree should be developed and regularly updated. This is especially important during the exploitation phases of the engagement as one point of entry that materializes could be repeated across other vectors mapped out during the development of the attack tree.
Isolated Lab Testing The accuracy of vulnerability analysis and exploitation is substantially greater when replicated environments are setup in an isolated lab. Often times, systems may be hardened with specific control sets or additional protection mechanisms. By designing a lab that mimics that of the target organization, the consultant can ensure that the vulnerabilities identified and exploits attempted against the desired targets are reliable and lessen the opportunity for inaccurate results or system inoperability.
Visual Confirmation Manual Connection with Review
Public Research Vulnerability Databases Vendor Advisories
Exploit Databases and Framework Modules Common/default Passwords Hardening Guides/Common Misconfigurations
Private Research Setting up a replica environment Testing Configurations
Fuzzing Fuzzing, or fault injection, is a brute-force technique for finding application flaws by programmatically submitting valid, random or unexpected input to the application. The basic process involves attaching a debugger to the target application, and then running the fuzzing routine against specific areas of input and then analyzing the program state following any crashes. Many fuzzing applications are available, although some testers write their own fuzzers for specific targets.
Identifying potential avenues/vectors Log in or connect to a target network application to identify commands and other areas of input. If the target is a desktop application that reads files and/or web pages, analyze the accepted file formats for avenues of data input. Some simple tests involve submitting invalid characters, or very long strings of characters to cause a crash. Attach a debugger to analyze the program state in the event of a successful crash.
Disassembly and code analysis Some programming languages allow for decompilation, and some specific applications are compiled with symbols for debugging. A tester can take advantage of these features to analyze program flow and identify potential vulnerabilities. Source code for open source applications should be analyzed for flaws. Web applications written in PHP share many of the same vulnerabilities, and their source code should be examined as part of any test.
The exploitation phase of a penetration test focuses solely on establishing access to a system or resource by bypassing security restrictions. If the prior phase, vulnerability analysis was performed properly, this phase should be well planned and a precision strike.. The main focus is to identify the main entry point into the organization and to identify high value target assets. If the vulnerability analysis phase was properly completed, a high value target list should have been complied. Ultimately the attack vector should take into consideration the success probability and highest impact on the organization.
Countermeasures are defined as preventative technology or controls that hinder the ability to successfully complete an exploit avenue. This technology could be a Host Based Intrusion Prevention System, Security Guard, Web Application Firewall, or other preventative methods. When performing an exploit, several factors should be taken into consideration.
6.2.1 Anti-Virus Encoding / Packing / Encrypting / Whitelist Bypass / Process Injection / Purely Memory Resident
6.2.2 Human 6.2.3 Data Execution Prevention (DEP) 6.2.4 Address Space Layout Randomization 6.2.5 Web Application Firewall (WAF)
Evasion is the technique used in order to escape detection during a penetration test. This could be circumventing a camera system as to not be seen by a guard, obfuscating your payloads to evade Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) or encoding requests/responses to circumvent web application firewalls. Overall, the need to identify a low risk scenario for evading a technology or person should be formulated prior to the exploit.
6.4 Precision Strike
The main focus of a penetration test is to simulate an attacker in order to represent a simulated attack against the organization. The value brought through a penetration test is generally not through smash and grab techniques where the attacks are noisy in nature and in an attempt to try every exploit. This approach may be particularly useful at the end of a penetration test to gauge the level of incident response from the organization, but in most cases the exploitation phase is a accumulation of specific research on the target.
6.5 Customized Exploitation Avenue
Every attack will typically not be the same in how the exploitation avenue occurs. In order to be successful in this phase, the attack should be tailored and customized based on the scenario. For example, if a wireless penetration test is occurred, and a specific technology is in use, these need to be identified and attacked based on what technologies are in place. Having a clear understanding of each scenario and the applicability of an exploit is one of the most important aspects of this phase of the penetration test.
6.6 Tailored Exploits
The penetration tester should have the knowledge in place to be able to customize an exploit and the ability to change on the fly in order to successfully complete the attack.
6.6.1 Exploit Customization A common theme for exploits is to target specific versions of operating systems or applications.
6.7 Zero-Day Angle
This type of attack often represents a highly advanced organization that can handle a focused attack against the organization through normal attack methods. In certain scenarios research may be conducted in order to reverse engineer, fuzz, or perform advanced discovery of vulnerabilities that have not been discovered.
6.7.1 Fuzzing 6.7.2 Source Code Analysis 6.7.3 Types of Exploits Buffer Overflows / SEH Overwrites (structured exception handler ) / Return Oriented Programming 6.7.4 Traffic Analysis 6.7.5 Physical Access Human Angle / PC Access 6.7.6 Proximity Access (WiFi) WiFi Attacks / Attacking the User There are several common techniques in use of this, but most commonly the attacker would setup a wireless access point with the same name or an enticing name in order for the victim to connect.
6.8 Example Avenues of Attack
Web Application Attacks Social-Engineering Physical Attack Avenues Memory Based Exploits (i.e. buffer/heap overflows, memory corruptions, use-after-free). Man in the Middle VLAN Hopping USB/Flash Drive deployment Reverse Engineering Zero-Day Angle Attacking the user Encryption Cracking Graphics Processing Unit (GPU) Cracking Traffic Analysis Firewire Routing protocols Phishing with Pretexting Employee Impersonation
6.9 Overall Objective
In the pre-engagement interaction phase with the customer, a clear definition of the overall objectives of the penetration test should have been communicated. In the case of the exploitation phase, the biggest challenge is identifying the least path of resistance into the organization without detection and having the most impact on the organizations ability to generate revenue. By performing the prior phases properly, a clear understanding of how the organization functions and makes money should be relatively understood. From the exploitation phase and into the post-exploitation phase, the attack vectors should rely solely on the mission of circumventing security controls in order to represent how the organization can suffer substantial losses through a targeted attack against the organization.
0x07 Post Exploitation
The purpose of the Post-Exploitation phase is to determine the value of the machine compromised and to maintain control of the machine for later use. The value of the machine is determined by the sensitivity of the data stored on it and the machines usefulness in further compromising the network. The methods described in this phase are meant to help the tester identify and document sensitive data, identify configuration settings, communication channels, and relationships with other network devices that can be used to gain further access to the network, and setup one or more methods of accessing the machine at a later time. In cases where these methods differ from the agreed upon Rules of Engagement, the Rules of Engagement must be followed.
7.2 Rules of Engagement
7.2.1 Protect the Client Unless previously agreed upon, there will be no modification of services which the client deems “critical” to their infrastructure. All modifications, including configuration changes, executed against a system must be documented. 。。。
7.2.2 Protecting Yourself Ensure that the contract and/or statement of work signed by both the client and provider that the actions taken on the systems being tested are on behalf and in representation of the client. 。。。
7.3 Infrastructure Analysis
7.3.1 Network Configuration 7.3.2 Network Services
Pillaging refers to obtaining information (i.e. files containing personal information, credit card information, passwords, etc.) from targeted hosts relevant to the goals defined in the pre-assessment phase. This information could be obtained for the purpose of satisfying goals or as part of the pivoting process to gain further access to the network. The location of this data will vary depending on the type of data, role of the host and other circumstances. Knowledge and basic familiarity with commonly used applications, server software and middleware is very important, as most applications store their data in many different formats and locations. Special tools may be necessary to obtain, extract or read the targeted data from some systems.
7.4.1 Installed Programs • List of the applications and their associated versions installed on the system. • List of operating system updates applied to the system.
7.4.2 Installed Services Services on a particular host may serve the host itself, or other hosts in the target network. It is necessary to create a profile of each targeted host, noting the configuration of these services, their purpose, and how they may potentially be used to achieve assessment goals or further penetrate the network.
（Security Services；File/Printer Shares ；Database Servers ；Directory Servers ；Name Servers ；Deployment Services ；Certificate Authority ；Source Code Management Server ；Dynamic Host Configuration Server ；Dynamic Host Configuration Server （DHCP）；Virtualization ；Messaging ；Monitoring and Management ；Backup Systems ；Networking Services (RADIUS,TACACS..etc) ）
7.4.3 Sensitive Data （Key-logging ；Screen capture ；Network traffic capture ；Previous Audit reports ）
7.4.4 User Information In this section the main focus is on the information present on the target system related to user accounts either present on the system or that have connected remotely and have left some trace that the personnel performing the assessment can gather and analyze for further penetration or provide the desired goal of the assessment.
On System General information that can be gather on a compromised system are: • History files ； • Encryption Keys (SSH, PGP/GPG) ； • Interesting Documents (.doc/x, .xls/x , password.*) ； • User specific application configuration parameters • Individual Application History (MRU Windows only, history files..etc) • Enumerate removable media • Enumerate network shares / domain permission (gpresult)
IM Clients • Enumerate Account Configuration (User, Password, Server, Proxy) • Chat Logs
7.4.5 System Configuration Password Policy Security Policies Configured Wireless Networks and Keys
7.5 High Value/Profile Targets
7.6 Data Exfiltration
7.6.1 Mapping of all possible exfiltration paths 7.6.2 Testing exfiltration paths 7.6.3 Measuring control strengths
• Installation of backdoor that requires authentication. • Installation and/or modification of services to connect back to system. User and complex password should be used as a minimum; use of certificates or cryptographic keys is preferred where possible. (SSH, ncat, RDP). Reverse connections limited to a single IP may be used. • Creation of alternate accounts with complex passwords. • When possible backdoor must survive reboots.
7.8 Further Penetration Into Infrastructure
7.8.1 From Compromised System Actions that can be taken from a compromised system: • Upload tools • Use local system tools • ARP Scan • Ping Sweep • DNS Enumeration of internal network • Directory Services Enumeration • Brute force attacks • Enumeration and Management thru Management Protocols and compromised credentials (WinRM, WMI, SMB, SNMP..etc) • Abuse of compromised credentials and keys (Webpages, Databases..etc) • Execute Remote Exploits
7.8.2 Thru Compromised System Actions that can be taken thru a compromised system: • Port Forwarding • Proxy to internal network (SSH) • VPN to internal network • Execute Remote Exploit • Abuse of compromised credentials and keys (Webpages, Databases..etc)
The cleanup process covers the requirements for cleaning up systems once the penetration test has been completed. This will include all user accounts and binaries used during the test. • Remove all executable, scripts and temporary file from a compromised system. If possible use secure delete method for removing the files and folders. • Return to original values system settings and application configuration parameters if they where modified during the assessment. • Remove all backdoors and/or rootkits installed. • Remove any user accounts created for connecting back to compromise systems.
8.2 Report Structure
The report is broken down into two (2) major sections in order to communicate the objectives, methods, and results of the testing conducted to various audiences.
8.3 The Executive Summary
Background: Overall Posture: Risk Ranking/Profile: General Findings: Recommendation Summary: Strategic Roadmap:
8.4 Technical Report
Introduction: The introduction section of the technical report is intended to be an initial inventory of: • Personnel involved in the testing from both the Client and Penetration Testing Team • Contact information • Assets involved in testing • Objectives of Test • Scope of Test • Strength of Test • Approach • Threat/Grading Structure
Exploitation/ Vulnerability Confirmation:
Post Exploitation: • Privilege Escalation path – Technique used • Acquisition of Critical Information Defined by client • Value of information • Access to core business systems • Access to compliance protected data sets • Additional Information/Systems Accessed • Ability of persistence • Ability for exfiltration • Countermeasure Effectiveness