penetration-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is activated, always start your first response with the 🧢 emoji.

激活本技能后，首次回复请始终以🧢表情开头。

Penetration Testing

渗透测试

A structured framework for conducting authorized security assessments. This skill covers the full pentest lifecycle - from scoping and reconnaissance through exploitation and reporting - with an uncompromising emphasis on authorized testing only. Every technique, tool, and tactic here is applied exclusively within written engagement agreements, sanctioned CTF competitions, or controlled lab environments.

Security testing without explicit written authorization is illegal under the Computer Fraud and Abuse Act (CFAA), the Computer Misuse Act (UK), and equivalent laws in virtually every jurisdiction. There are no exceptions.

这是一个用于开展授权安全评估的结构化框架。本技能覆盖渗透测试全生命周期——从范围界定、信息收集到漏洞利用和报告撰写——且始终强调仅进行授权测试。此处提及的每一项技术、工具和策略，仅适用于已签署项目协议的授权测试、官方认可的CTF竞赛，或受控实验室环境。

在《计算机欺诈与滥用法案》（CFAA）、英国《计算机滥用法案》以及几乎所有司法管辖区的等效法律中，未经明确书面授权的安全测试均属非法行为，无一例外。

When to use this skill

何时使用本技能

Trigger this skill when the user:

Plans or scopes an authorized penetration test engagement
Conducts a web application security assessment following the OWASP Testing Guide
Performs network vulnerability scanning (Nmap, Nessus, OpenVAS)
Tests authentication, session management, or access control weaknesses
Writes a professional pentest report with findings and remediation guidance
Prioritizes vulnerabilities using CVSS scoring or risk-based frameworks
Practices in a CTF competition, HackTheBox, TryHackMe, or personal lab environment

Do NOT trigger this skill for:

Any activity targeting systems the user does not have explicit written authorization to test - this is unauthorized access, not security testing
Attacks on production systems outside a defined and agreed engagement scope, regardless of intent or claimed ownership

当用户有以下需求时，触发本技能：

规划或界定授权渗透测试项目的范围
遵循OWASP测试指南开展Web应用安全评估
执行网络漏洞扫描（使用Nmap、Nessus、OpenVAS）
测试认证、会话管理或访问控制的薄弱点
撰写包含漏洞发现与修复建议的专业渗透测试报告
使用CVSS评分或基于风险的框架对漏洞进行优先级排序
在CTF竞赛、HackTheBox、TryHackMe或个人实验室环境中练习

以下情况请勿触发本技能：

任何针对用户无明确书面授权测试的系统的活动——这属于未授权访问，而非安全测试
在已定义并达成一致的项目范围之外，对生产系统发起攻击，无论意图如何或声称拥有所有权

Key principles

核心原则

Always have written authorization - A signed statement of work, rules of engagement document, or CTF registration is non-negotiable before any testing begins. Verbal permission is legally meaningless. If you do not have written authorization, you do not have authorization.
Follow scope strictly - The engagement scope defines exactly which IP ranges, domains, applications, and test types are in bounds. Scope creep - even "accidental" pivoting to out-of-scope systems - carries legal liability. When in doubt, stop and clarify with the client.
Document everything - Log every command run, every finding discovered, and every timestamp. Detailed records protect the tester legally, enable accurate reporting, and provide the client with a reproducible audit trail.
Responsible disclosure - Critical findings (RCE, credential exposure, data exfiltration paths) must be reported to the client immediately, not at the end of the engagement. Do not hold back critical vulnerabilities to make the final report look more impressive.
Minimize impact - Testing should never cause unnecessary disruption. Avoid destructive exploits, denial-of-service techniques, or mass data extraction unless explicitly authorized. The goal is to demonstrate a vulnerability exists, not to fully exploit it.

始终获取书面授权——在开始任何测试前，签署的工作说明书、项目规则文档或CTF注册证明是必不可少的。口头许可在法律上无效。若无书面授权，则视为无授权。
严格遵循范围——项目范围明确定义了允许测试的IP范围、域名、应用程序和测试类型。范围蔓延——即使是“意外”转向超出范围的系统——也会带来法律责任。如有疑问，请立即停止并与客户确认。
记录所有操作——记录每一条执行的命令、每一个发现的漏洞以及每一个时间戳。详细记录可为测试者提供法律保护，确保报告准确，并为客户提供可复现的审计轨迹。
负责任地披露漏洞——关键发现（远程代码执行RCE、凭证泄露、数据泄露路径）必须立即报告给客户，而非等到项目结束。切勿隐瞒关键漏洞，以免让最终报告看起来更“出彩”。
最小化影响——测试不应造成不必要的中断。除非获得明确授权，否则避免使用破坏性漏洞利用、拒绝服务技术或大规模数据提取。测试的目标是证明漏洞存在，而非完全利用漏洞。

Core concepts

核心概念

Pentest phases

渗透测试阶段

The Penetration Testing Execution Standard (PTES) defines five phases that form a repeatable methodology for every engagement:

Phase	Goal	Key activities
Reconnaissance	Understand the target's attack surface	Passive OSINT (WHOIS, Shodan, Google dorks), active scanning, subdomain enumeration
Scanning & Enumeration	Map live hosts, open ports, services, and versions	Nmap, Nessus, Nikto, banner grabbing, service fingerprinting
Exploitation	Demonstrate that a vulnerability can be leveraged	Metasploit, manual exploit development, web app attacks (SQLi, XSS, SSRF)
Post-Exploitation	Assess impact depth after initial compromise	Privilege escalation, lateral movement, credential harvesting, persistence (within scope)
Reporting	Communicate risk to the client in actionable terms	Executive summary, technical findings, CVSS scores, remediation steps

渗透测试执行标准（PTES）定义了五个阶段，构成了每个项目可重复的方法论：

阶段	目标	关键活动
信息收集	了解目标的攻击面	被动开源情报收集（WHOIS、Shodan、Google dorks）、主动扫描、子域名枚举
扫描与枚举	映射存活主机、开放端口、服务及其版本	Nmap、Nessus、Nikto、Banner抓取、服务指纹识别
漏洞利用	证明漏洞可被利用	Metasploit、手动漏洞利用开发、Web应用攻击（SQL注入、XSS、SSRF）
后渗透测试	评估初始攻陷后的影响深度	权限提升、横向移动、凭证收集、持久化（在范围内进行）
报告撰写	以可执行的方式向客户传达风险	执行摘要、技术发现、CVSS评分、修复步骤

Vulnerability severity - CVSS

漏洞严重性——CVSS

The Common Vulnerability Scoring System (CVSS v3.1) provides a standardized numerical score (0.0-10.0) used to communicate severity:

Score	Severity	Typical examples
9.0-10.0	Critical	Unauthenticated RCE, pre-auth SQL injection with DBA access
7.0-8.9	High	Authenticated RCE, significant privilege escalation, SSRF to metadata
4.0-6.9	Medium	Stored XSS, IDOR exposing other users' data, weak TLS config
0.1-3.9	Low	Informational disclosure, missing security headers, verbose errors
0.0	Informational	Best-practice gaps with no direct exploitability

CVSS scores are a communication tool, not the final word on business risk. A medium-severity finding in a payment card system may carry higher business risk than a high-severity finding on a low-value internal tool. Always contextualize scores for the client.

通用漏洞评分系统（CVSS v3.1）提供了标准化的数值评分（0.0-10.0），用于传达漏洞严重性：

评分	严重性	典型示例
9.0-10.0	关键	未认证RCE、预认证SQL注入且获取DBA权限
7.0-8.9	高	已认证RCE、显著权限提升、可访问元数据的SSRF
4.0-6.9	中	存储型XSS、IDOR泄露其他用户数据、弱TLS配置
0.1-3.9	低	信息泄露、缺失安全头、详细错误信息暴露
0.0	信息性	无直接可利用性的最佳实践缺口

CVSS评分是一种沟通工具，而非业务风险的最终结论。支付卡系统中的中危漏洞可能比低价值内部工具中的高危漏洞具有更高的业务风险。始终要为客户提供评分的上下文说明。

Rules of engagement

项目规则（ROE）

Rules of engagement (ROE) define the guardrails for a test. A well-formed ROE document covers:

Scope: IP ranges, domains, applications in-scope and out-of-scope
Test types: Allowed techniques (e.g., is social engineering in scope? DoS testing?)
Time windows: Permitted testing hours (avoid peak business hours for network tests)
Emergency contacts: Who to call if testing causes unintended disruption
Data handling: How captured credentials and PII must be stored and destroyed
Exclusions: Specific systems, third-party services, or shared infrastructure that must not be touched

项目规则（ROE）定义了测试的约束条件。一份完善的ROE文档应涵盖：

范围：允许和禁止测试的IP范围、域名、应用程序
测试类型：允许使用的技术（例如，社会工程是否在范围内？拒绝服务测试是否允许？）
时间窗口：允许测试的时间段（网络测试应避开业务高峰时段）
紧急联系人：若测试造成意外中断，应联系的人员
数据处理：捕获的凭证和个人身份信息（PII）的存储和销毁方式
排除项：不得触碰的特定系统、第三方服务或共享基础设施

Common tasks

常见任务

Plan a pentest engagement

规划渗透测试项目

Before any technical work begins, define:

Scope document - list every IP range, CIDR block, domain, and application explicitly authorized for testing. Write a separate exclusion list.
Rules of engagement - cover testing windows, allowed techniques, emergency contacts, and data handling requirements (see ROE section above).
Timeline - reconnaissance phase, active testing phase, reporting phase, and remediation validation window.
Test type - black-box (no prior knowledge), grey-box (limited knowledge like a standard user account), or white-box (full source code and architecture access).

Always get ROE signed before the first Nmap packet leaves your machine.

在开展任何技术工作之前，需明确：

范围文档——列出所有明确授权测试的IP范围、CIDR块、域名和应用程序。单独编写排除列表。
项目规则——涵盖测试窗口、允许的技术、紧急联系人和数据处理要求（见上述ROE部分）。
时间线——信息收集阶段、主动测试阶段、报告阶段和修复验证窗口。
测试类型——黑盒测试（无先验知识）、灰盒测试（有限知识，如标准用户账户）或白盒测试（完全访问源代码和架构）。

在发送第一个Nmap数据包之前，务必让ROE签署完毕。

Conduct a web application assessment

开展Web应用评估

Follow the OWASP Testing Guide (OTG) v4 methodology:

1. Information Gathering
   - OTG-INFO-001: Fingerprint web server and technology stack
   - OTG-INFO-003: Review webserver metafiles (robots.txt, sitemap.xml)
   - OTG-INFO-007: Map application entry points

2. Authentication Testing
   - OTG-AUTHN-001: Test credentials over encrypted transport
   - OTG-AUTHN-003: Test account lockout and brute-force protections
   - OTG-AUTHN-006: Test for default credentials

3. Authorization Testing
   - OTG-AUTHZ-001: Directory traversal / file inclusion
   - OTG-AUTHZ-002: Bypass authorization schema (IDOR, privilege escalation)

4. Session Management Testing
   - OTG-SESS-001: Test cookie attributes (Secure, HttpOnly, SameSite)
   - OTG-SESS-005: Test for CSRF

5. Input Validation Testing
   - OTG-INPVAL-001: Reflected/stored/DOM XSS
   - OTG-INPVAL-005: SQL injection
   - OTG-INPVAL-017: SSRF

6. Business Logic Testing
   - OTG-BUSLOGIC-004: Test for process timing attacks
   - OTG-BUSLOGIC-009: Test for upload of malicious files

Tools: Burp Suite (proxy and scanner), OWASP ZAP, SQLMap (authorized use only), ffuf (directory brute-forcing), Nikto (initial reconnaissance).

遵循OWASP测试指南（OTG）v4方法论：

1. 信息收集
   - OTG-INFO-001：识别Web服务器和技术栈指纹
   - OTG-INFO-003：审查Web服务器元文件（robots.txt、sitemap.xml）
   - OTG-INFO-007：映射应用程序入口点

2. 认证测试
   - OTG-AUTHN-001：测试加密传输下的凭证
   - OTG-AUTHN-003：测试账户锁定和暴力破解防护
   - OTG-AUTHN-006：测试默认凭证

3. 授权测试
   - OTG-AUTHZ-001：目录遍历/文件包含
   - OTG-AUTHZ-002：绕过授权机制（IDOR、权限提升）

4. 会话管理测试
   - OTG-SESS-001：测试Cookie属性（Secure、HttpOnly、SameSite）
   - OTG-SESS-005：测试CSRF

5. 输入验证测试
   - OTG-INPVAL-001：反射型/存储型/DOM型XSS
   - OTG-INPVAL-005：SQL注入
   - OTG-INPVAL-017：SSRF

6. 业务逻辑测试
   - OTG-BUSLOGIC-004：测试流程时序攻击
   - OTG-BUSLOGIC-009：测试恶意文件上传

工具：Burp Suite（代理和扫描器）、OWASP ZAP、SQLMap（仅授权使用）、ffuf（目录暴力破解）、Nikto（初始信息收集）。

Perform a network vulnerability scan

执行网络漏洞扫描

A repeatable Nmap scanning workflow for authorized network assessments:

bash

undefined

用于授权网络评估的可重复Nmap扫描工作流：

bash

undefined

Phase 1: Host discovery (fast, low noise)

阶段1：主机发现（快速、低噪音）

nmap -sn 10.0.0.0/24 -oG hosts-up.txt

Phase 2: Service version scan on live hosts

阶段2：对存活主机进行服务版本扫描

nmap -sV -sC -p- --open -iL hosts-up.txt -oA nmap-full

Phase 3: Targeted UDP scan for key services

阶段3：针对关键服务的定向UDP扫描

nmap -sU -p 53,67,161,500 -iL hosts-up.txt -oA nmap-udp

Phase 4: Vulnerability scripts (NSE) - authorized only

阶段4：漏洞脚本（NSE）——仅授权使用

nmap --script vuln -iL hosts-up.txt -oA nmap-vuln


Follow up with Nessus or OpenVAS for CVE-matched vulnerability detection. Always
save raw scan output - it is evidence in the report.

> Set scan rate limits (`--max-rate`) to avoid triggering IDS alerts or causing
> unintended service disruption on fragile systems.

nmap --script vuln -iL hosts-up.txt -oA nmap-vuln


后续使用Nessus或OpenVAS进行匹配CVE的漏洞检测。始终保存原始扫描输出——这是报告中的证据。

> 设置扫描速率限制（`--max-rate`），避免触发IDS警报或对脆弱系统造成意外服务中断。

Test authentication and session management

测试认证和会话管理

Authentication testing checklist:

Credentials transmitted over TLS only (no HTTP fallback)
Account lockout triggers after N failed attempts (test: 10-20 rapid attempts)
Password reset tokens are single-use, expire quickly, and are not guessable
Session tokens have sufficient entropy (min 128 bits)
Session cookies set with
```
Secure
```
,
```
HttpOnly
```
, and
```
SameSite=Strict
```
Session invalidated on logout (server-side, not just client-side cookie deletion)
No session fixation (new token issued after successful login)
MFA bypass paths tested (fallback flows, recovery codes, API endpoint parity)

认证测试清单：

凭证仅通过TLS传输（无HTTP回退）
连续N次失败尝试后触发账户锁定（测试：10-20次快速尝试）
密码重置令牌为一次性使用、快速过期且不可猜测
会话令牌具有足够的熵（最小128位）
会话Cookie设置了
```
Secure
```
、
```
HttpOnly
```
和
```
SameSite=Strict
```
属性
注销时会话失效（服务器端，而非仅客户端删除Cookie）
无会话固定漏洞（成功登录后颁发新令牌）
测试MFA绕过路径（回退流程、恢复代码、API端点一致性）

Write a pentest report

撰写渗透测试报告

A professional report structure:

1. Executive Summary (1-2 pages, non-technical audience)

Engagement scope and objectives
Overall risk rating with one-sentence rationale
Top 3 most critical findings in plain language
Recommended prioritization order for remediation

2. Technical Findings (one page per finding minimum)

Each finding must include:

Field	Content
Title	Short, descriptive vulnerability name
Severity	CVSS v3.1 score + vector string
Affected component	URL, IP, service, and version
Description	What the vulnerability is and why it exists
Evidence	Screenshots, request/response pairs, tool output
Impact	What an attacker can achieve if exploited
Remediation	Specific, actionable fix with code examples where applicable
References	CVE, CWE, OWASP reference

3. Remediation Summary - table of all findings sorted by severity with estimated remediation effort.

4. Appendices - raw tool output, full scope definition, methodology reference.

专业报告结构：

1. 执行摘要（1-2页，面向非技术受众）

项目范围和目标
总体风险评级及一句话理由
用通俗易懂的语言列出前3个最关键的发现
建议的修复优先级顺序

2. 技术发现（每个发现至少一页）

每个发现必须包含：

字段	内容
标题	简短、描述性的漏洞名称
严重性	CVSS v3.1评分 + 向量字符串
受影响组件	URL、IP、服务及其版本
描述	漏洞是什么以及为何存在
证据	截图、请求/响应对、工具输出
影响	攻击者利用该漏洞可实现的目标
修复建议	具体、可执行的修复方案，适用时提供代码示例
参考	CVE、CWE、OWASP参考链接

3. 修复摘要——按严重性排序的所有发现表格，包含估计修复工作量。

4. 附录——原始工具输出、完整范围定义、方法论参考。

Prioritize vulnerabilities by risk

按风险对漏洞进行优先级排序

CVSS score alone is not sufficient for prioritization. Apply this framework:

Risk = Severity x Exploitability x Business Impact

For each finding, score 1-5:
  Severity:           CVSS base score (normalize: Critical=5, High=4, Med=3, Low=1)
  Exploitability:     1=requires physical access, 3=authenticated remote, 5=unauthenticated remote
  Business Impact:    1=no sensitive data/system, 5=production PII or financial system

Priority 1 (fix in 24-48h): Risk score 60+
Priority 2 (fix in 1-2 weeks): Risk score 30-59
Priority 3 (fix in next sprint): Risk score 10-29
Priority 4 (fix when convenient): Risk score <10

Always review with the client - they know which systems are business-critical.

仅靠CVSS评分不足以进行优先级排序。应用以下框架：

风险 = 严重性 × 可利用性 × 业务影响

对每个发现，按1-5分评分：
  严重性：           CVSS基础评分（归一化：关键=5，高=4，中=3，低=1）
  可利用性：     1=需要物理访问，3=已认证远程访问，5=未认证远程访问
  业务影响：    1=无敏感数据/系统，5=生产环境PII或金融系统

优先级1（24-48小时内修复）：风险评分≥60
优先级2（1-2周内修复）：风险评分30-59
优先级3（下一个迭代周期修复）：风险评分10-29
优先级4（方便时修复）：风险评分<10

始终与客户一起审核——他们了解哪些系统是业务关键系统。

Set up a testing lab for practice

搭建测试实验室用于练习

Build a safe, isolated practice environment:

Virtualization: VirtualBox or VMware Workstation, host-only or NAT networking
Vulnerable targets: DVWA, Metasploitable 2/3, VulnHub VMs, HackTheBox machines, TryHackMe rooms
Attacker OS: Kali Linux or Parrot OS (come pre-loaded with pentest tooling)
Network isolation: Never bridge your lab network to a production or corporate network
Snapshots: Snapshot VM state before each exploitation attempt for easy revert

Practice only on systems you own or platforms that grant explicit authorization (HTB, THM, VulnHub). Setting up a lab is the correct path when you want to develop skills without an engagement in hand.

构建一个安全、隔离的练习环境：

虚拟化：VirtualBox或VMware Workstation，使用仅主机或NAT网络
脆弱目标：DVWA、Metasploitable 2/3、VulnHub虚拟机、HackTheBox机器、TryHackMe房间
攻击者操作系统：Kali Linux或Parrot OS（预装渗透测试工具）
网络隔离：切勿将实验室网络桥接到生产或企业网络
快照：在每次漏洞利用尝试前拍摄VM快照，以便轻松恢复

仅在你拥有的系统或明确授权的平台（HTB、THM、VulnHub）上练习。当你手头没有项目时，搭建实验室是提升技能的正确途径。

Anti-patterns

反模式

Anti-pattern	Why it's wrong	What to do instead
Testing without written authorization	Illegal under CFAA and equivalent laws worldwide, regardless of intent or claimed ownership	Obtain signed statement of work and ROE before any testing begins
Scope creep during exploitation	Pivoting to out-of-scope systems creates legal exposure even if discovered accidentally	Stop immediately, document the out-of-scope system found, notify the client, get written scope extension if needed
Running destructive exploits without explicit authorization	Can cause data loss, service outages, or permanent system damage	Demonstrate exploitability with a PoC that proves the vulnerability without causing harm (e.g., `id` vs full shell)
Saving client credentials or PII beyond the engagement	Creates data liability and breaches engagement agreement	Destroy captured credentials per the data-handling terms in the ROE; never store them after the engagement closes
Reporting only exploited vulnerabilities	Misses the full attack surface - un-exploited vulnerabilities still carry risk	Report all findings including those that could not be exploited in the test window, with CVSS-based risk scores
Vague remediation advice ("fix the SQL injection")	Developers cannot act on generic advice	Provide specific remediation - parameterized query example, library recommendation, configuration change - for every finding

反模式	错误原因	正确做法
无书面授权开展测试	违反CFAA及全球等效法律，无论意图或声称的所有权如何	在开始任何测试前，获取签署的工作说明书和ROE
漏洞利用过程中范围蔓延	转向超出范围的系统会带来法律风险，即使是意外发现	立即停止，记录发现的超出范围系统，通知客户，如需扩展范围需获取书面授权
未经明确授权使用破坏性漏洞利用	可能导致数据丢失、服务中断或系统永久损坏	使用不造成损害的PoC证明漏洞存在（例如，执行 `id` 而非获取完整shell）
项目结束后保留客户凭证或PII	造成数据风险并违反项目协议	根据ROE中的数据处理条款销毁捕获的凭证；项目结束后绝不存储
仅报告已利用的漏洞	遗漏了完整的攻击面——未被利用的漏洞仍存在风险	报告所有发现，包括测试窗口内未被利用的漏洞，并附上基于CVSS的风险评分
模糊的修复建议（如“修复SQL注入”）	开发人员无法根据通用建议采取行动	为每个发现提供具体的修复方案——参数化查询示例、库推荐、配置变更

References

参考资料

For detailed methodology and patterns, load the relevant references file:

```
references/methodology.md
```
- PTES and OWASP Testing Guide methodology, phase-by-phase breakdown, tool reference, and reporting templates

Only load references files when the current task requires them - they are long and will consume context.

如需详细方法论和模式，请加载相关参考文件：

```
references/methodology.md
```
——PTES和OWASP测试指南方法论、分阶段分解、工具参考和报告模板

仅当当前任务需要时才加载参考文件——这些文件篇幅较长，会占用上下文资源。