เว็บ PHP อาจโดน PHP2Shell เจาะแล้ว — ชั่วโมงแรกและวันถัดไปต้องทำอะไร
สงสัยว่าเว็บ PHP โดน PHP2Shell เจาะ? ลำดับงานชั่วโมงแรก: แยกเครื่องแต่ไม่ปิด เก็บหลักฐาน หา webshell หมุน secret สร้างเครื่องใหม่ แจ้ง สคส. ใน 72 ชม. ตาม PDPA
เว็บ PHP อาจโดน PHP2Shell เจาะแล้ว — ชั่วโมงแรกและวันถัดไปต้องทำอะไร
อัปเดต PHP เสร็จแล้ว แต่คำถามที่ยังค้างอยู่คือ ก่อนอัปเดต มีใครเข้ามาแล้วหรือยัง
ถ้ายังตอบไม่ได้ ให้ทำตามลำดับนี้ จำกัดการเชื่อมต่อแต่ไม่ปิดเครื่อง เก็บหลักฐานก่อนลบหรือ reimage เทียบไฟล์กับ baseline ที่ตรวจแล้ว ยกเลิก secret ทุกตัวที่แอปอ่านได้ แล้วสร้างเครื่องใหม่บน PHP ที่แก้แล้ว ส่วนนาฬิกา 72 ชั่วโมงของ PDPA เริ่มเมื่อรู้หรือมีเหตุอันควรเชื่อว่าข้อมูลส่วนบุคคลถูกละเมิด ไม่ใช่ตอนเจอ PHP ที่มีช่องโหว่หรือแค่สงสัยว่ามีคนบุกรุก
ทำไมต้องคิดเผื่อว่าโดนแล้ว Amazon เห็นความพยายามโจมตีครั้งแรกตั้งแต่ 17 ตุลาคม 2026 สี่วันก่อนแพตช์ออก และบอกว่ายังไม่ชัดว่าครั้งไหนสำเร็จ ถ้าสำเร็จ ผู้โจมตีจะรันโค้ดด้วยสิทธิ์ของ PHP worker โดยไม่ต้องล็อกอิน รายละเอียดช่องโหว่และเวอร์ชันที่แก้แล้วอยู่ในบทความหลักของชุดนี้
ปิดเว็บเลย หรือแค่แยกออกจากเครือข่าย?
คู่มือของ CISA ให้ชั่งผลต่อบริการ เวลาและคนที่ต้องใช้ และผลต่อหลักฐาน หนึ่งในทางเลือกคือตัดระบบที่เปิดสู่สาธารณะออกจากอินเทอร์เน็ตชั่วคราว NCSC ของอังกฤษก็ให้พิจารณาเอาระบบออฟไลน์ถ้าแพตช์และมาตรการชั่วคราวทำไม่ทัน
แต่ "แยก" ไม่ได้แปลว่า "ปิดเครื่อง" AA20-245A ของ CISA เตือนว่ารีบเกินไป memory ก็หายตาม และการถอดออกจาก load balancer แค่หยุดทราฟฟิกของแอป ไม่ได้กักตัวเครื่อง ให้จำกัดขาเข้า ขาออก และการเชื่อมต่อไปเครื่องอื่น แล้วทดสอบว่าใช้ได้จริง โดยเหลือช่องทางที่ควบคุมไว้สำหรับเก็บหลักฐาน บน AWS การแก้ security group ไม่ตัด connection ที่ถูก track อยู่ทันที ถ้าต้องตัดทันทีให้ใช้ network ACL
อย่ารีบบล็อก IP แล้วคิดว่าจบ บล็อกโดยไม่รู้ว่าเข้ามาทางไหน ผู้โจมตีก็ยังเข้าได้ และ Amazon บอกว่า IP ที่เผยแพร่เป็นเครือข่ายนิรนามที่ใช้ร่วมกัน ให้เอาไปสืบ ไม่ใช่บล็อกทิ้ง
ก่อนลบอะไร เก็บหลักฐานไว้ก่อน
การ restore backup ทับเครื่องเดิมอาจเขียนทับหลักฐานบนเครื่องนั้น CISA ให้เก็บ log หลายชั้น ถ้าต้องวิเคราะห์เชิง forensic ให้เก็บ memory และ disk image และจดทุกชิ้นว่าเก็บด้วยวิธีไหน เมื่อไหร่ ใครเก็บ สำหรับเว็บ PHP เราแนะนำเพิ่มว่าให้เก็บ log ของเว็บเซิร์ฟเวอร์ PHP-FPM และแอป, snapshot หรือ export container, hash ของไฟล์ใน web root และรายการ process กับ connection Amazon แนะนำให้ย้อนดูถึง 17 ตุลาคม จึงควรเช็คว่า log ช่วงนั้นยังเหลือไหม
log บนเครื่องที่โดนเจาะ คนที่คุมเครื่องได้ก็แก้ได้ log ที่ส่งออกนอกเครื่องไว้ก่อนเกิดเหตุจึงมีค่ากว่า ซึ่งเป็นงานของ zcrLog ที่เก็บ log ได้ 90 วันถึง 2 ปี ตรวจความถูกต้องด้วย MD5, SHA-1, SHA-256 และเข้ารหัส AES-128 แต่บทความนี้ไม่ได้อ้างว่า zcrLog อ่าน log ของ Apache หรือ PHP-FPM ได้ ที่ย้อนดูได้คือ log จากแหล่งที่ส่งเข้าไปจริง เช่น ไฟร์วอลล์
หา webshell ต้องเทียบกับอะไร
MITRE ATT&CK อธิบายว่า webshell คือประตูหลังที่ฝังในเว็บเซิร์ฟเวอร์เพื่อกลับเข้ามาได้เรื่อยๆ NSA แนะนำให้เทียบเว็บที่รันจริงกับ "known-good" คือแอปเดียวกันที่ติดตั้งใหม่พร้อมอัปเดต แล้วดูว่าไฟล์ไหนเพิ่มหรือถูกแก้ release ที่ deploy ไว้ใช้เป็น known-good ได้ก็ต่อเมื่อดึงจากนอกเครื่องที่สงสัย ตรวจสอบแยกต่างหาก และเช็คแล้วว่า repository กับ build pipeline ไม่ถูกแตะ ทุกจุดที่ต่างต้องตรวจทีละรายการ แล้วไล่ดูต่อ
- โฟลเดอร์ที่ PHP เขียนได้ เช่น upload, tmp และ cache (ข้อนี้เราเพิ่มเอง)
- crontab ของบัญชีเว็บ MITRE ระบุว่า cron เป็นช่องทางรันโค้ดซ้ำ
- บัญชีใหม่ ทั้งในระบบปฏิบัติการและแอดมินในฐานข้อมูลของแอป
- process ที่เว็บเซิร์ฟเวอร์เรียกขึ้นมา NSA ชี้ว่าเว็บเซิร์ฟเวอร์ปกติแทบไม่เรียก ipconfig
- การเชื่อมต่อขาออกจาก PHP หรือเว็บเซิร์ฟเวอร์ ตามที่หน่วยงานไซเบอร์ของแคนาดาแนะนำให้สืบ
แหล่งที่เราอ่านไม่ได้เผยแพร่ชื่อไฟล์หรือ hash ของ webshell ที่ผูกกับ PHP2Shell การเทียบกับ baseline จึงสำคัญกว่าการค้นชื่อไฟล์ วิธีไล่ log อยู่ในบทความล่าร่องรอยใน log
secret ตัวไหนต้องเปลี่ยน
ทุกตัวที่แอปอ่านได้ ทั้งรหัสผ่านฐานข้อมูล API key ใน .env คีย์ cloud หรือคีย์ payment gateway เพราะโค้ดที่รันด้วยสิทธิ์เดียวกับแอปก็อ่านได้ ประกาศคำแนะนำด้านความปลอดภัยของ CVE-2026-109619 ยังระบุเรื่องข้อมูลใน memory รั่ว และ CISA ให้หมุน secret ที่สงสัยว่าหลุด
เราแนะนำให้ยกเลิกของเก่าที่ต้นทางทันที แล้วใส่ค่าใหม่บนเครื่องที่สร้างใหม่เท่านั้น และเตะ session ทั้งหมด Sansec รายงานว่า cookie PHPSESSID อาจพาข้อมูลจาก memory ออกไป ถ้าคีย์ cloud หลุด ให้ดู audit log ย้อนถึง 17 ตุลาคม ใครส่ง AWS CloudTrail หรือ Google Cloud audit log เข้า zcrLog ไว้ก็ค้นจากตรงนั้นได้
ทำไมต้องสร้างใหม่ ไม่ "ล้าง" เครื่องเดิม
ลบ webshell ได้หนึ่งไฟล์ ไม่ได้แปลว่าไม่มีไฟล์ที่สอง CISA เขียนว่าผู้โจมตีมักฝังทางเข้าไว้หลายทาง จึงให้ reimage จาก image ที่รู้ว่าสะอาด หรือสร้างใหม่ทั้งหมด
สร้างเครื่องใหม่บน PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ขึ้นไป หรือแพ็กเกจ distro ที่ backport แล้ว (8.1 ลงไปต้องใช้ backport จาก vendor หรืออัปเกรด) รีสตาร์ท worker ทุกตัว ดึงโค้ดจากแหล่งที่ตรวจแล้ว เช็คว่าไฟล์ upload ที่ย้ายกลับไม่มี .php ปน (ข้อนี้เราแนะนำเอง) และทดสอบให้ครบก่อนต่อกลับ production ตามที่ CISA แนะนำ
หลังต่อกลับเข้าระบบ CISA ให้เฝ้าดูสัญญาณการกลับเข้ามาอีกระยะ AWS แนะนำให้เปิด error log ของ PHP ให้ครบ แต่ไม่มี error ก็ไม่ได้พิสูจน์ว่าปลอดภัย
ใครต้องแจ้ง: สคส., ThaiCERT และตำรวจ
PDPA มาตรา 37 (4) ให้แจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุละเมิดเท่าที่ทำได้ เว้นแต่ไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล ถ้าเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาด้วย DPO จึงต้องประเมินไปพร้อมกับการสืบ
ประกาศเรื่องการแจ้งเหตุ พ.ศ. 2565 ให้ระบุลักษณะการละเมิด ช่องทางติดต่อ DPO ผลกระทบ และมาตรการที่ใช้ ถ้ามีเหตุจำเป็นจนแจ้งช้ากว่า 72 ชั่วโมง ต้องแจ้งโดยเร็วและไม่เกิน 15 วันนับแต่ทราบเหตุพร้อมชี้แจงเหตุผล แล้ว สคส. จึงพิจารณาว่าจะยกเว้นความผิดหรือไม่ ไม่ใช่การขยายเวลาตามปกติ ข้อ 8 ให้สัญญากำหนดว่าผู้ประมวลผล เช่น โฮสต์หรือ agency ต้องแจ้งผู้ควบคุมข้อมูลโดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ตนทราบเหตุเท่าที่ทำได้ ส่วนหน้าที่แจ้ง สคส. ยังเป็นของผู้ควบคุมข้อมูล การแจ้งใช้แบบ ตข. 001 ส่งที่ saraban@pdpc.or.th และแบบฟอร์มเตือนให้แจ้งความถ้าพบการกระทำผิดทางอาญา ทั้งหมดนี้คือสิ่งที่ตัวบทเขียน ไม่ใช่คำปรึกษากฎหมาย
ThaiCERT ภายใต้ สกมช. ทำหน้าที่เฝ้าระวัง วิเคราะห์ แจ้งเตือน และประสานการรับมือภัยไซเบอร์ แจ้งเหตุได้ที่ thaicert@ncsa.or.th หรือโทร 02 114 3531 (24 ชั่วโมง) และ ThaiCERT ได้ออกประกาศแจ้งเตือนเรื่อง PHP2Shell เป็นภาษาไทยเมื่อ 22 ตุลาคม 2026 ซึ่งแนะนำว่าหากพบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาต ให้แยกระบบ เก็บรักษา log และหลักฐาน และเริ่มกระบวนการตอบสนองเหตุทันที
สรุปลำดับงานช่วงแรก
| ช่วง | งาน | ต้องได้อะไรก่อนไปต่อ |
|---|
| ทันทีที่สงสัย | จำกัดการเชื่อมต่อ ไม่ปิดเครื่อง แจ้ง DPO | เวลาที่ตรวจพบเหตุ (ยังไม่ใช่จุดเริ่มนับ 72 ชม.) |
| ก่อนลบหรือ reimage | เก็บ log, memory, snapshot, hash | บันทึกว่าใครเก็บอะไร เมื่อไหร่ |
| วันแรก | เทียบ baseline ไล่ cron บัญชี process ย้อนถึง 17 ต.ค. | สิ่งที่พบ หรือ "ไม่พบ" พร้อมข้อจำกัด |
| วันแรก | ยกเลิก secret ที่ต้นทาง เตะ session | รายการ secret ที่ยกเลิกแล้ว |
| เมื่อมีเหตุอันควรเชื่อว่าข้อมูลส่วนบุคคลถูกละเมิด | DPO ประเมินความเสี่ยง | เวลาที่ทราบเหตุ (เริ่มนับ 72 ชม.) |
| ก่อนเปิดเว็บ | สร้างเครื่องใหม่บน PHP ที่แก้แล้ว ใส่ secret ใหม่ | ผ่านการทดสอบ |
| ภายใน 72 ชม. นับแต่ทราบเหตุละเมิด | ส่งแบบ ตข. 001 ถ้าเข้าเงื่อนไข | สำเนาที่ส่ง |
| หลังต่อกลับเข้าระบบ | เฝ้าดู error log ไฟล์ใหม่ การเชื่อมต่อขาออก | การเฝ้าดูที่มีเจ้าของ ขอบเขต รอบทบทวน และเกณฑ์ยกระดับ |
ถ้างานนี้ต้องมีหลายคนรับช่วงกันและต้องเก็บบันทึกว่าใครอนุมัติขั้นไหน ลองเทียบแพ็กเกจได้ที่หน้าราคา
ลำดับในตารางข้างบนเป็นลำดับที่เราแนะนำเอง และเหตุครั้งหน้าก็ต้องใช้อีก ถ้าต้องมาไล่จากความจำตอนกำลังวุ่น ขั้นตอนก็มักตกหล่น zcrSOAR เก็บลำดับนี้ไว้ในคลัง playbook ได้ พร้อมเวอร์ชัน ขั้นอนุมัติ และ dry-run และตั้งแต่ละขั้นเป็น Autonomous, Approval หรือ Blocked ได้ เช่น รวบรวมข้อมูลให้วิ่งเอง ส่วนตัดเครื่องให้รอคนอนุมัติในคิวเดียว ทุกครั้งที่รันจะบันทึกเวลา ผู้ใช้ action และผลลัพธ์ไว้ ตัวนี้ขายแยกจาก zcrSIEM และไม่ได้ตรวจจับ PHP2Shell ทางแก้ยังเป็นการแพตช์ PHP เหมือนเดิม
อยากเห็นหน้าจอจริงก่อน ลองเดโม ได้
เครื่องมือฟรีก็ทำได้ดี และขอบเขตของบทความนี้
งานเทียบ baseline ใช้ของฟรีได้ เช่น sha256sum เทียบกับ release ที่ตรวจแล้ว git --no-optional-locks status --ignored --untracked-files=all ที่รันบนสำเนาที่เก็บไว้ (ไม่ใช่บนเครื่องจริง) และสคริปต์ฟรีของ NSA บน GitHub แต่ไม่มีคำสั่งไหนคำสั่งเดียวพิสูจน์ได้ว่าเครื่องสะอาด จะใช้ checklist หรือ SOAR ให้ดูที่ความซับซ้อนของเหตุ ความสามารถของทีม การประสานหลายฝ่าย และหน้าที่ต้องเก็บหลักฐาน
นี่ไม่ใช่คู่มือ forensic การเก็บ memory ให้ใช้เป็นหลักฐานได้ต้องมีคนที่ทำเป็น ถ้าไม่มี CISA และ NCSC แนะนำให้ใช้ผู้ให้บริการตอบสนองเหตุภายนอก และ "ไม่พบ" ไม่เท่ากับ "ไม่ได้โดน"
อ่านต่อ
เช็คเวอร์ชัน PHP ทุกเครื่อง · กักกัน Ransomware แบบมีคนอนุมัติ · หลัง Incident จบ ต้องรายงานอะไร · PDPA คืออะไร
ติดต่อทีมงาน
อยากคุยว่า playbook ตอบสนองเหตุของทีมคุณควรมีขั้นไหนบ้าง และขั้นไหนควรรอคนอนุมัติ คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย zcr ให้ซอฟต์แวร์ ส่วนงานสืบสวน เก็บหลักฐาน กักกัน และกู้คืนระบบแบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
แหล่งข้อมูลอ้างอิง
- Amazon Threat Intelligence — PHP2Shell exploitation prior to public disclosure — ความพยายามโจมตีแรก 17 ต.ค. 2026, ยังไม่ชัดว่าสำเร็จหรือไม่, ให้เริ่มสืบจาก 17 ต.ค., IP เป็นเครือข่ายนิรนามที่ใช้ร่วมกัน
- PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) และ GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — รันโค้ดด้วยสิทธิ์ของ web worker โดยไม่ต้องยืนยันตัวตน, memory disclosure
- PHP.net — 2026 news archive — เวอร์ชันที่แก้แล้ว, PHP 8.1 ลงไป, การรีสตาร์ท worker
- CISA — Cybersecurity Incident & Vulnerability Response Playbooks — การเก็บหลักฐาน, ทางเลือกในการกักกัน, การหมุน secret, reimage จาก gold source, การทดสอบและเฝ้าดู
- CISA AA20-245A — Technical Approaches to Uncovering and Remediating Malicious Activity — เก็บหลักฐานก่อนจัดการ, ความเสี่ยงที่ memory หาย, การบล็อก IP, ผู้ให้บริการ IR ภายนอก
- UK NCSC — Critical security issue affecting PHP — พิจารณาเอาระบบออฟไลน์, ผู้ให้บริการ IR
- Canadian Centre for Cyber Security AL26-026 — สิ่งผิดปกติที่ต้องสืบ
- AWS — Using AWS WAF to apply mitigations for PHP2Shell — การเปิด error log และ "ไม่มี error ไม่ได้พิสูจน์ว่าปลอดภัย"
- Sansec — PHP2Shell — cookie
PHPSESSID ที่อาจพาข้อมูลจาก memory ออกไป
- NSA Cybersecurity — Mitigating Web Shells — การเทียบกับ known-good, process แปลกที่เว็บเซิร์ฟเวอร์เรียกขึ้นมา
- MITRE ATT&CK T1505.003 Web Shell และ T1053.003 Cron
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — มาตรา 37 (4)
- ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 — ข้อ 5, 6, 7, 8
- สคส. — แบบฟอร์มการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล (ตข. 001) — อีเมลสำหรับส่ง และหมายเหตุเรื่องแจ้งความ
- ThaiCERT และ เกี่ยวกับ ThaiCERT — บทบาทและช่องทางแจ้งเหตุ
- AWS — Amazon EC2 security group connection tracking — การแก้ security group ไม่ตัด connection ที่ถูก track ทันที, ใช้ network ACL เพื่อตัดทันที
- ThaiCERT — แจ้งเตือน พบช่องโหว่ PHP2Shell (22 ต.ค. 2026) — ข้อ 3.10 แนวทางเมื่อพบการเข้าถึงโดยไม่ได้รับอนุญาต
