2019 June 21 PageView:

PTES -读书笔记

PTES (penetration testing execution standard) 读书笔记

0x01 High Level Organization of the Standard

The penetration testing execution standard consists of seven (7) main sections.

0x02 Pre-engagement Interactions

2.1 Overview

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.

2.15 Goals

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.

  1. Ability to detect and respond to information gathering
  2. Ability to detect and respond to foot printing
  3. Ability to detect and respond to scanning and vuln analysis
  4. Ability to detect and respond to infiltration (attacks)
  5. Ability to detect and respond to data aggregation
  6. 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

3.1 General

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.

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.

3.4 OSINT

Open Source Intelligence (OSINT) takes three forms; Passive, Semi-passive, and Active.

3.5 Covert Gathering

3.6 Footprinting

3.7 Identify Protection Mechanisms

0x04 Threat Modeling

4.1 General

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

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

5.1 Testing

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).

5.2 Active

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.

Service Based

Banner Grabbing

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.

5.3 Passive

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.

Traffic Monitoring

5.4 Validation

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

5.5 Research

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.

0x06 Exploitation

6.1 Purpose

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.

6.2 Countermeasures

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)

6.3 Evasion

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

7.1 Purpose

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

7.4 Pillaging

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

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:

Web Browsers

IM Clients

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

7.7 Persistence

7.8 Further Penetration Into Infrastructure

7.8.1 From Compromised System
Actions that can be taken from a compromised system:

7.8.2 Thru Compromised System
Actions that can be taken thru a compromised system:

7.9 Cleanup

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.

0x08 Reporting

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:

Information Gathering:

Vulnerability Assessment:

Exploitation/ Vulnerability Confirmation:

Post Exploitation:

Post Exploitation:

Risk/Exposure:

Conclusion:

参考文献

[1] The penetration testing execution standard

All content is licensed under CC BY-NC-SA

Built with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents