# Pentest Plan

> วางแผนการทดสอบเจาะระบบแบบได้รับอนุญาต (authorized penetration testing) — กำหนด scope + Rules of Engagement, เลือก methodology (PTES/OWASP WSTG/NIST 800-115), จัดลำดับความรุนแรงด้วย CVSS, รายงานและ retest. Plan an authorized, scoped, legal pen test end-to-end. Trigger เมื่อผู้ใช้พิมพ์ /pentest-plan หรือขอ "pen test / penetration test / ทดสอบเจาะระบบ / rules of engagement / vulnerability assessment / VAPT / pentest report".

- Skill: `ksmaster03/pentest-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ksmaster03/pentest-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ksmaster03/pentest-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ksmaster03 (https://skillmd.com/u/ksmaster03)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/ksmaster03/pentest-plan

---


# /pentest-plan — แผนทดสอบเจาะระบบ (Authorized Penetration Testing)

วางแผนและกำกับการทดสอบเจาะระบบ "แบบมืออาชีพ" ตั้งแต่ขอบเขต (scope) + Rules of Engagement ไปจนถึง methodology, การจัดลำดับความรุนแรง (CVSS), การออกรายงาน finding และการ retest — เน้นกระบวนการ ไม่ใช่การสอนโจมตีจริง

> **กฎเหล็ก (ห้ามข้าม):** ทดสอบเจาะระบบได้ "เฉพาะระบบที่คุณมีสิทธิ์ทดสอบ และได้รับอนุญาตเป็นลายลักษณ์อักษร (written authorization) จากเจ้าของทรัพย์สินที่มีอำนาจลงนาม" เท่านั้น การยิงเป้าหมายที่ไม่ได้รับอนุญาต = ผิดกฎหมาย (เช่น พ.ร.บ. คอมพิวเตอร์ฯ / CFAA) ไม่ว่าจะเจตนาดีแค่ไหน ถ้าไม่มีหนังสืออนุญาต+ขอบเขตชัดเจน **ห้ามเริ่ม** สกิลนี้ช่วย "วางแผน/จัดกระบวนการ/เขียนรายงาน" เท่านั้น ไม่ให้ payload, exploit หรือคำสั่งโจมตีจริง

---

## ใช้ตอนไหน

- ต้องจัด pen test / VAPT ให้ระบบ (web, API, mobile, internal network, cloud) ก่อน go-live หรือเป็นรอบประจำปี/ตามสัญญาลูกค้า
- ลูกค้า/compliance (PCI-DSS, ISO 27001 A.8.29, SOC 2) ขอ "penetration test report" ไม่ใช่แค่ scan
- ต้องร่าง **Rules of Engagement (RoE)** / scope statement / authorization letter ก่อนจ้าง third-party หรือก่อน internal red team ลงมือ
- ได้รายงานจากผู้ทดสอบมาแล้ว ต้องจัดลำดับความรุนแรง (CVSS) + ทำแผน remediation + กำหนด retest
- ต้องตัดสินใจว่าจ้าง third-party หรือใช้ internal team, จะทำ black/grey/white box, internal หรือ external

> **pen test ≠ automated security testing (/security-testing):** `/security-testing` = เครื่องมืออัตโนมัติ (SAST/DAST/SCA/dependency scan) รันใน CI ทุก build, กว้างแต่ตื้น, หา known issue. **Pentest = มนุษย์ผู้เชี่ยวชาญ** จำลองผู้โจมตีจริง, ทำเป็นรอบ (point-in-time), เจาะลึก business logic + chained exploit + privilege escalation ที่เครื่องจับไม่ได้ ทั้งสองอย่างเสริมกัน ไม่แทนกัน — ทำ automated ให้สะอาดก่อน แล้วค่อยจ่ายเงินให้คนเก่งมาหาของที่เครื่องหาไม่เจอ

---

## Input ที่ต้องถามก่อนเริ่ม

1. **Authorization** — มีหนังสืออนุญาตเป็นลายลักษณ์อักษรจากผู้มีอำนาจหรือยัง? ใครเป็นเจ้าของระบบ/ข้อมูล? ระบบโฮสต์บน infra ของใคร (ถ้าเป็น cloud เช่น AWS/Azure/GCP ต้องเช็ค policy ของผู้ให้บริการด้วย)
2. **เป้าหมาย & ขอบเขต** — รายการ targets (domains, IP ranges, URLs, API endpoints, app bundle id): อะไรอยู่ใน scope และที่สำคัญกว่า — **อะไร out of scope** (เด็ดขาด)
3. **ประเภทการทดสอบ** — black / grey / white box? internal (จากในเครือข่าย) หรือ external (จาก internet)? มี credential ให้หรือไม่?
4. **สภาพแวดล้อม** — ทดสอบบน prod, staging หรือ clone? ถ้าจำเป็นต้องทำบน prod มีข้อจำกัดอะไร (ห้ามแตะข้อมูลจริง, ห้ามทำ data-modifying action)?
5. **วัตถุประสงค์ & motivation** — compliance (PCI/ISO/SOC2), ก่อน launch, หลังเปลี่ยนสถาปัตยกรรมใหญ่, หรือ assurance ทั่วไป? มี crown-jewel asset อะไรที่ห่วงเป็นพิเศษ
6. **เวลา & หน้าต่างทดสอบ (time window)** — ช่วงวันที่ทดสอบได้, ช่วงเวลาในวัน (เช่น นอกเวลาทำการเพื่อลดผลกระทบ), deadline ส่งรายงาน
7. **ข้อจำกัด/ข้อห้าม** — ห้าม DoS/DDoS, ห้าม social engineering/phishing (เว้นได้รับอนุญาตชัดเจน), ห้าม exfiltrate ข้อมูลจริง, ห้ามแตะระบบ third-party ที่ฝังในหน้าเดียวกัน
8. **ทีม & ผู้ติดต่อฉุกเฉิน (emergency contact)** — ใครทดสอบ (internal/third-party + ใบรับรอง เช่น OSCP/GPEN/CREST)? ใครเป็น point of contact ฝั่งลูกค้าตลอด 24 ชม. ถ้าเกิดเหตุระบบล่ม
9. **เกณฑ์ความรุนแรง** — ใช้ CVSS v3.1/v4.0 หรือไม่, มี business-context override (เช่น ระบบจ่ายเงิน = ยกระดับ severity) หรือไม่

---

## ขั้นตอน (Playbook)

### เฟส 0 — Pre-engagement / Scoping (สำคัญที่สุด)
1. ยืนยัน **legal authorization** เป็นลายลักษณ์อักษร: ใครลงนามมีอำนาจจริง, ครอบคลุม target ทุกตัวที่จะยิง, ระบุช่วงเวลา ตรวจ ownership ของ IP/domain (ถ้าโฮสต์บน cloud/third-party ต้องมีสิทธิ์หรือแจ้งผู้ให้บริการตาม policy)
2. ร่าง **Rules of Engagement (RoE)** + scope table (เทมเพลตด้านล่าง) ให้ทุกฝ่ายเซ็นรับทราบก่อนลงมือ
3. นิยาม "ความสำเร็จ" + deliverable: รายงานอะไร, รูปแบบไหน, retest รวมในราคาหรือไม่
4. ตั้ง **safe-word / kill switch** และ emergency contact: ถ้าทดสอบทำให้ระบบเริ่มล่ม จะหยุดและแจ้งใครทันที

### เฟส 1 — เลือก Methodology & แนวทาง
เลือกกรอบมาตรฐานให้เข้ากับเป้าหมาย (อ้างอิงเป็นกระบวนการ):
- **PTES** (Penetration Testing Execution Standard) — โครงรวม 7 เฟส ใช้เป็นกระดูกสันหลังของ engagement
- **OWASP WSTG** (Web Security Testing Guide) — checklist ครอบคลุมสำหรับ web app/API
- **OWASP MASTG/MSTG** — สำหรับ mobile app (iOS/Android)
- **NIST SP 800-115** — Technical Guide to Information Security Testing (วิธีการ + การจัดการ)
- (เสริม) **MITRE ATT&CK** — แมป technique ที่จำลอง, **OSSTMM** — งาน network-centric
จับคู่ box type: black box (ไม่มีข้อมูลภายใน, สมจริงสุดแต่ช้า), grey box (มี credential/บางส่วนของสถาปัตยกรรม, คุ้มเวลาสุด), white box (เข้าถึง source/architecture เต็ม, ครอบคลุมสุด)

### เฟส 2 — Execution (ระดับกระบวนการ เท่านั้น)
ตามเฟสมาตรฐาน PTES — ผู้ทดสอบที่ได้รับอนุญาตเป็นผู้ลงมือ สกิลนี้ใช้กำกับ/ตรวจ ไม่ใช่สั่งโจมตี:
1. **Reconnaissance / Information Gathering** — รวบรวมข้อมูลเป้าหมายในขอบเขต (passive/active) ทำ asset & attack-surface inventory
2. **Scanning / Enumeration** — ระบุ service, version, จุดที่น่าสนใจ; แมปเทียบกับ scope (ของนอก scope ห้ามแตะ)
3. **Vulnerability Analysis** — วิเคราะห์ว่าจุดอ่อนใดมีจริง จัดลำดับความเป็นไปได้ในการ exploit (ลด false positive ก่อนรายงาน)
4. **Exploitation** — ผู้ทดสอบยืนยันช่องโหว่ "เท่าที่จำเป็นเพื่อพิสูจน์ impact" ภายใต้ RoE (proof-of-concept ที่ปลอดภัย, ไม่สร้างความเสียหาย/ไม่ดูดข้อมูลจริง) — สกิลนี้ไม่ให้ payload/PoC
5. **Post-Exploitation** — ประเมินผลกระทบจริง: เข้าถึงอะไรได้, ยกระดับสิทธิ์ได้แค่ไหน, pivot ได้หรือไม่ (ทุกอย่างยังอยู่ใน scope + บันทึกหลักฐานให้พอ reproduce); **cleanup** สิ่งที่วางไว้ทุกชิ้น
6. **Reporting** — รวบรวม finding → severity (CVSS) → remediation → executive summary

### เฟส 3 — Reporting & Triage
1. แต่ละ finding ลงเทมเพลต (ด้านล่าง): title, severity, CVSS vector+score, affected asset, impact, evidence summary, remediation, retest status
2. จัด **CVSS** (v3.1/v4.0) + ปรับด้วย business context (asset criticality, exploitability จริง, data sensitivity) → priority สำหรับทีม dev
3. เขียน **executive summary** สำหรับผู้บริหาร (ความเสี่ยงรวม, top risks, สิ่งที่ต้องทำก่อน) + ส่วน technical สำหรับ dev
4. ส่งมอบรายงานผ่านช่องทางปลอดภัย (เข้ารหัส) — รายงาน pen test คือเอกสารลับชั้นสูง

### เฟส 4 — Remediation & Retest
1. ทีม dev แก้ตาม priority; ออก ticket ผูกกับแต่ละ finding
2. **Retest / re-validation**: ผู้ทดสอบกลับมายืนยันว่าแต่ละ finding ถูกปิดจริง (ไม่ใช่ปิดบนกระดาษ) บันทึกลง retest log
3. ออก **retest attestation / clean report** เมื่อ Critical/High ปิดครบ — ใช้ยื่น compliance/ลูกค้า
4. feed บทเรียนกลับเข้า /dev-standards, /threat-model, /security-testing เพื่อกัน regression รอบหน้า

---

## Output / Artifact (เทมเพลตพร้อมใช้)

### 1) Rules of Engagement (RoE) — โครงเอกสาร
```markdown
# Rules of Engagement — <ชื่อโปรเจกต์/ระบบ>
เวอร์ชัน: 1.0 · วันที่: <YYYY-MM-DD> · ระดับชั้นความลับ: CONFIDENTIAL

## 1. Authorization
- เจ้าของระบบ/ผู้มีอำนาจอนุมัติ: <ชื่อ-ตำแหน่ง> ลงนาม: __________ วันที่: ______
- ผู้ทดสอบ (บริษัท/ทีม + ใบรับรอง): <...>
- หนังสืออนุญาตอ้างอิง: <เลขที่/ลิงก์>  | ยืนยันว่าเป้าหมายทั้งหมดเป็นทรัพย์สินของผู้อนุมัติ: [ ] ใช่

## 2. Scope (ดูตารางข้อ 6)
## 3. ประเภทการทดสอบ: [ ] Black [ ] Grey [ ] White  |  [ ] Internal [ ] External
## 4. หน้าต่างเวลา (Time Window)
- วันที่ทดสอบ: <เริ่ม> ถึง <สิ้นสุด>  | ช่วงเวลาที่อนุญาต: <เช่น 22:00–05:00 ICT>
- สภาพแวดล้อม: [ ] Production [ ] Staging [ ] Clone

## 5. ข้อห้าม (Prohibited / Out of bounds)
- [x] ห้าม DoS / DDoS / volumetric / resource exhaustion
- [x] ห้ามแก้ไข/ลบ/ดูด (exfiltrate) ข้อมูลจริงของลูกค้า — ใช้ข้อมูลทดสอบเท่านั้น
- [x] ห้าม social engineering / phishing (เว้นระบุอนุญาตชัดในข้อ 7)
- [x] ห้ามแตะ asset/บริการ third-party ที่ไม่อยู่ในกรรมสิทธิ์ผู้อนุมัติ
- [x] ห้ามทิ้ง backdoor/implant; ต้อง cleanup ทุกอย่างหลังเสร็จ

## 6. การจัดการเหตุฉุกเฉิน (Emergency Handling)
- Emergency contact (24/7): <ชื่อ / เบอร์ / ช่องทาง>
- เงื่อนไขหยุดทันที (kill switch): ระบบ degrade/down, แตะข้อมูลจริงโดยไม่ตั้งใจ, พบ breach ของผู้อื่น
- ช่องทางรายงานสด: <Slack/Line/โทร>

## 7. ข้อยกเว้นที่อนุญาตเป็นพิเศษ: <ระบุ หรือ "ไม่มี">
## 8. การส่งมอบ: รูปแบบรายงาน <...> · ส่งผ่านช่องทางเข้ารหัส <...> · retest รวม: [ ] ใช่ [ ] ไม่
```

### 2) Scope Table
| # | Target (asset) | ประเภท | In/Out | Environment | หมายเหตุ/ข้อจำกัด |
|---|----------------|--------|--------|-------------|------------------|
| 1 | app.example.com | Web/API | In | Staging | full UI + REST |
| 2 | 203.0.113.0/24 | Network | In | Prod | external only, no DoS |
| 3 | payments.* | Service | **Out** | — | third-party PSP, ห้ามแตะ |
| 4 | iOS bundle com.example.app | Mobile | In | Staging build | MASTG |

### 3) Finding Report (ต่อ 1 ช่องโหว่)
```markdown
### [F-001] <ชื่อ finding สั้น ชัด>
- **Severity:** Critical / High / Medium / Low / Info
- **CVSS:** 8.8 — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`  (ระบุ vector เสมอ)
- **Affected asset:** <URL/endpoint/host/parameter/component + version>
- **Category:** <เช่น OWASP WSTG / CWE-id>
- **Impact (ผลกระทบเชิงธุรกิจ):** <ผู้โจมตีที่ได้รับอนุญาตจำลองทำอะไรได้ → กระทบข้อมูล/เงิน/ชื่อเสียงอย่างไร>
- **Evidence summary:** <สรุปหลักฐานแบบ reproduce ได้ — request/response, screenshot, log ref; ไม่ลงรายละเอียด payload ในรายงานสาธารณะ>
- **Likelihood / Exploitability:** <ง่าย/ยาก, ต้องมี precondition อะไร>
- **Remediation (คำแนะนำแก้):** <แนวทางแก้ที่ชัด + reference เช่น secure coding guideline>
- **References:** <CWE / OWASP / vendor advisory>
- **Status:** Open / Fixed / Risk-Accepted  |  **Retest:** Not yet / Pass / Fail
- **Owner / Ticket:** <ผู้รับผิดชอบ / JIRA-xxx>
```

### 4) Retest Log
| Finding | Severity | First found | Remediation อ้างอิง | Retest date | ผลลัพธ์ | ผู้ retest |
|---------|----------|-------------|---------------------|-------------|---------|-----------|
| F-001 | Critical | 2026-06-10 | PR #482 | 2026-06-18 | Pass (ปิดแล้ว) | <name> |
| F-007 | High | 2026-06-11 | config change | 2026-06-18 | **Fail** (ยัง bypass ได้) | <name> |

### 5) Severity Rollup (executive)
| Severity | จำนวน | ปิดแล้ว | คงค้าง |
|----------|-------|--------|--------|
| Critical | 1 | 1 | 0 |
| High | 3 | 2 | 1 |
| Medium | 5 | 1 | 4 |

---

## Checklist / Definition of Done

- [ ] มี **written authorization** จากผู้มีอำนาจ + ยืนยัน ownership ของทุก target (รวม cloud provider policy ถ้าเกี่ยวข้อง)
- [ ] RoE เซ็นครบทุกฝ่าย: scope, time window, ข้อห้าม (DoS/prod data), emergency contact ชัดเจน
- [ ] ระบุ box type + internal/external + environment (prod/staging/clone) แล้ว
- [ ] เลือก methodology (PTES + WSTG/MASTG/NIST 800-115) ตรงกับเป้าหมาย
- [ ] ทุก finding มี CVSS vector+score, impact เชิงธุรกิจ, remediation, evidence ที่ reproduce ได้
- [ ] รายงานแยก executive summary + technical detail; ส่งผ่านช่องทางเข้ารหัส
- [ ] Critical/High มี owner + ticket + วันที่แก้
- [ ] **Retest** ทำจริงและบันทึกใน retest log; ออก attestation เมื่อปิด Critical/High ครบ
- [ ] ยืนยัน cleanup: ไม่มี implant/test data/บัญชีค้างในระบบ
- [ ] บทเรียนป้อนกลับ /threat-model + /dev-standards + /security-testing

---

## เคล็ดลับ & ข้อควรระวัง

- **authorization ก่อนเสมอ ไม่มีข้อยกเว้น** — ถ้าผู้ใช้ขอให้ทดสอบ/หาช่องโหว่ระบบที่ไม่ได้เป็นเจ้าของหรือไม่มีหนังสืออนุญาต ให้ปฏิเสธและอธิบายเรื่องความถูกกฎหมาย สกิลนี้ทำงานบนสมมุติฐานว่า "ได้รับอนุญาตและมีขอบเขตแล้วเท่านั้น"
- **อยู่ในระดับวางแผน/กระบวนการ/รายงาน** — ไม่ให้ exploit code, payload, หรือคำสั่งโจมตีที่ใช้ยิงจริง สิ่งที่ส่งมอบคือเอกสาร + การจัดลำดับ + คำแนะนำแก้ไข
- **ทดสอบบน prod = ความเสี่ยงสูง** — ถ้าเลี่ยงได้ใช้ staging/clone; ถ้าจำเป็นบน prod ต้องมี kill switch, นอกเวลาพีค, ห้ามแตะข้อมูลจริง และมีคนฝั่งลูกค้าเฝ้าตลอด
- **scope creep คือกับดัก** — เจอช่องน่าสนใจที่อยู่นอก scope ต้องหยุดและขออนุญาตเพิ่มเป็นลายลักษณ์อักษรก่อน ห้ามลุยเอง
- **รายงานคือสินค้าจริง ไม่ใช่ตัว exploit** — มูลค่าอยู่ที่ finding ที่ชัด, CVSS ที่ถูกต้อง, remediation ที่ทำตามได้ และ retest ที่พิสูจน์ว่าปิดจริง
- **CVSS อย่างเดียวไม่พอ** — ปรับด้วย business context: SQLi บนหน้า marketing กับบนระบบจ่ายเงิน คะแนนดิบอาจเท่ากันแต่ priority ต่างกันมาก
- **third-party vs internal:** third-party ให้มุมมองอิสระ + ใบรับรอง (OSCP/CREST/GPEN) เหมาะกับ compliance/ก่อน launch ใหญ่; internal team เร็ว+รู้ระบบลึก เหมาะกับรอบถี่ — แต่ระวัง conflict of interest, ควรสลับ third-party เป็นระยะ
- **เก็บความลับ** — รายงานระบุช่องโหว่ที่ยังไม่แก้ = เอกสารอันตราย เข้ารหัส, จำกัดผู้เข้าถึง, มี retention policy
- **point-in-time** — pen test ยืนยันสถานะ ณ วันที่ทดสอบเท่านั้น โค้ด/infra เปลี่ยน = ต้องทดสอบใหม่; ใช้ /security-testing ใน CI อุดช่องระหว่างรอบ

---

## เชื่อมกับเฟสอื่น

- **ก่อนหน้า:** `/security-testing` — รัน automated SAST/DAST/SCA ให้สะอาดก่อน แล้วค่อยให้ pen test หาของที่เครื่องหาไม่เจอ
- **ถัดไป:** `/release-deploy` — ปิด Critical/High + retest pass ก่อน go-live; finding ที่ risk-accepted ต้องมีผู้อนุมัติ
- **ภาพรวมทั้งวงจร:** `/sdlc-agile`
- **ป้อนกลับ:** `/threat-model` (อัปเดต attack surface จาก finding จริง), `/authn-authz-design` + `/sod-matrix` (ช่องโหว่ด้านสิทธิ์), `/dev-standards` (secure coding gap ที่พบซ้ำ), `/business-logic-spec` (ช่องโหว่เชิง logic)