สรุปคำตอบ
เว็บโดนแฮกคือเหตุที่ผู้ไม่ได้รับอนุญาตเข้าถึงหรือแก้ไขเว็บไซต์ วิธีรับมือคือบันทึกอาการและเวลา นำเว็บออฟไลน์ด้วยหน้า 503 จากนอกเซิร์ฟเวอร์ แจ้งโฮสติ้ง สำรองเว็บสภาพปัจจุบัน แล้วเปลี่ยนรหัสผ่านทุกจุดและตัด session จากนั้นติดตั้งไฟล์ใหม่จากแหล่งทางการ ลบ Backdoor ตรวจผู้ใช้และฐานข้อมูล อัปเดตและปิดช่องโหว่ เปลี่ยนรหัสผ่านซ้ำ แล้วจึงขอ Review จาก Google
เว็บโดนแฮก หมายถึงเหตุการณ์ที่ผู้ไม่ได้รับอนุญาตเข้าถึงหรือแก้ไขเว็บไซต์ เช่น ฝังโค้ดอันตราย สร้างหน้าสแปม เพิ่มบัญชีผู้ดูแล หรือใช้เซิร์ฟเวอร์ส่งอีเมลสแปม ในทางความมั่นคงปลอดภัยไซเบอร์ เหตุแบบนี้เรียกว่า cybersecurity incident และการรับมืออย่างเป็นระบบเรียกว่า incident response คำถามว่า “เว็บโดนแฮก ทำอย่างไร” จึงมีคำตอบเป็นลำดับขั้นที่ชัดเจน ได้แก่ ควบคุมความเสียหาย ตัดการเข้าถึง ล้างสิ่งแปลกปลอม ปิดช่องโหว่ แล้วจึงขอให้ Google ตรวจสอบใหม่
ถ้าเว็บที่ถูกแฮกเป็นร้านค้าออนไลน์ที่รับบัตรเครดิต ให้อ่านเรื่องหน้าที่แจ้งเหตุภายใน 72 ชั่วโมงและการตรวจหน้า Checkout ใน Magecart คืออะไร
ขั้นตอนในบทความนี้เรียบเรียงจาก 3 แหล่งหลัก คือเอกสาร NIST SP 800-61 Rev. 3 เอกสาร FAQ My site was hacked ของ WordPress.org และชุดบทความ Help, I think I’ve been hacked ของ Google ปรับให้เข้ากับกรณีเว็บ WordPress โดนแฮกซึ่งพบบ่อยในไทย ถ้ายังไม่แน่ใจว่าเว็บติดมัลแวร์ประเภทใด อ่านภาพรวมก่อนที่ มัลแวร์เว็บไซต์คืออะไร มีกี่แบบ
กรอบคิด: กู้เว็บตามหลัก Incident Response
NIST SP 800-61 Revision 3 ชื่อ Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile เผยแพร่ฉบับสมบูรณ์ (final) เมื่อเมษายน 2025 และใช้แทน Revision 2 ฉบับเดือนสิงหาคม 2012 (NIST CSRC) ฉบับใหม่เลิกใช้วงจร 4 ระยะแบบเดิมเป็นแกนหลัก แล้วจัดกิจกรรมตาม 6 ฟังก์ชันของ NIST Cybersecurity Framework 2.0 คือ Govern, Identify, Protect, Detect, Respond และ Recover โดยให้เหตุผลว่าปัจจุบันเหตุเกิดบ่อยขึ้น สร้างความเสียหายมากขึ้น และการกู้คืนอาจใช้เวลาเป็นสัปดาห์หรือเป็นเดือน (NIST SP 800-61r3)
ตารางด้านล่างเทียบระยะเดิมกับฟังก์ชันใหม่ตาม Table 1 ของเอกสาร และขั้นตอนที่ตรงกันในบทความนี้
| ระยะในฉบับเดิม (Rev. 2) | ฟังก์ชัน CSF 2.0 (Rev. 3) | ขั้นตอนในบทความนี้ |
|---|---|---|
| Preparation | Govern, Identify, Protect | Backup, 2FA, การอัปเดต (ทำก่อนเกิดเหตุ) |
| Detection & Analysis | Detect, Identify (Improvement) | ตั้งสติ บันทึกเหตุการณ์ สแกนยืนยัน |
| Containment, Eradication & Recovery | Respond, Recover | ขั้นที่ 1–6 |
| Post-Incident Activity | Identify (Improvement) | บันทึกบทเรียนหลังกู้เสร็จ |
ข้อสังเกตสำคัญจาก NIST คือบทเรียนควรนำไปใช้ทันทีที่พบ ไม่ต้องรอให้การกู้คืนจบก่อน สำหรับเว็บขนาดเล็ก หลักนี้แปลว่า ถ้าระหว่างกู้พบว่าช่องโหว่มาจากปลั๊กอินตัวใด ให้จัดการกับปลั๊กอินนั้นในเว็บอื่นที่คุณดูแลด้วยเลย
อย่าตกใจ ทำสิ่งนี้ก่อน
WordPress.org เริ่มคำแนะนำด้วย Stay calm และขั้นที่ลงมือทำได้ทันทีขั้นแรกคือ Document หรือการบันทึก (WordPress.org) ให้จดสิ่งต่อไปนี้ก่อนแก้ไขอะไร
- อาการที่ทำให้เชื่อว่าเว็บโดนแฮก เช่น เด้งไปเว็บพนัน หน้าแรกถูกเปลี่ยน หรือ Google ขึ้นคำเตือน
- วันเวลาที่พบ และเขตเวลา
- การเปลี่ยนแปลงล่าสุด เช่น ติดตั้งปลั๊กอินใหม่ แก้ธีม หรือแก้ widget
- ข้อมูลสภาพแวดล้อมของโฮสต์ เช่น ผู้ให้บริการ เวอร์ชัน PHP และเวอร์ชัน WordPress
WordPress.org อธิบายว่าบันทึกนี้คือฐานของรายงานเหตุการณ์ (incident report) ไม่ว่าจะกู้เองหรือจ้างผู้เชี่ยวชาญ ด้าน NIST ระบุว่าแม้เหตุมัลแวร์ส่วนใหญ่จะไม่นำไปสู่การดำเนินคดี ข้อมูลที่เก็บระหว่างรับมือเหตุก็ยังถือเป็นหลักฐาน และควรเก็บรักษาตามนโยบายขององค์กร (NIST SP 800-61r3)
อีกข้อที่มักถูกมองข้ามคือเครื่องคอมพิวเตอร์ของผู้ดูแลเว็บ WordPress.org แนะนำให้สแกนแอนติไวรัสแบบเต็มบนเครื่องของคุณด้วย เพราะในหลายกรณีการโจมตีเริ่มจากโทรจันบนเครื่องผู้ดูแลที่ดักรหัสผ่าน FTP และ wp-admin ถ้ายังไม่แน่ใจว่าเว็บโดนแฮกจริง ให้ยืนยันก่อนด้วย วิธีเช็คว่าเว็บไซต์ติดไวรัสหรือไม่ ด้วยเครื่องมือฟรี และดูอาการเบื้องต้นได้ที่ WordPress ติดไวรัส อาการและวิธีตรวจสอบเบื้องต้น
ขั้นที่ 1 ปิดเว็บชั่วคราวและสำรองข้อมูลสภาพปัจจุบัน
NIST นิยาม containment ว่าเป็นการป้องกันไม่ให้เหตุขยายวง สำหรับเว็บไซต์ การควบคุมขั้นแรกคือหยุดไม่ให้เว็บส่งเนื้อหาอันตรายถึงผู้เข้าชม Google แนะนำให้นำเว็บออฟไลน์โดยหยุดเว็บเซิร์ฟเวอร์ หรือชี้ DNS ไปที่หน้าคงที่บนเซิร์ฟเวอร์อื่นที่ตอบ HTTP 503 และเตือนว่าการให้เว็บที่ถูกเจาะตอบรหัส 4xx หรือ 5xx เองยังไม่พอ เพราะเนื้อหาอันตรายยังส่งไปพร้อมรหัสเหล่านี้ได้ ส่วนการใช้ robots.txt บล็อกก็ไม่ช่วย เพราะกันได้เฉพาะ crawler ของเครื่องมือค้นหา (web.dev: Quarantine your site)
ในทางปฏิบัติ ถ้าใช้ Cloudflare หรือ DNS ที่ตั้งกฎได้ ให้ส่งผู้เข้าชมไปหน้าแจ้งปิดปรับปรุงที่อยู่นอกเซิร์ฟเวอร์เดิม ถ้าทำไม่ได้ ให้ขอให้โฮสติ้งระงับเว็บชั่วคราว Google ระบุด้วยว่าการปิดเว็บชั่วคราวระหว่างกู้มีผลต่ออันดับในอนาคตเพียงเล็กน้อย
ต่อมาให้แจ้งโฮสติ้ง ทั้ง Google และ WordPress.org แนะนำขั้นนี้ เพราะเหตุอาจกระทบมากกว่าเว็บของคุณ โดยเฉพาะบน shared hosting และโฮสติ้งอาจช่วยยืนยันได้ว่าเป็นการโดนแฮกจริงหรือเป็นปัญหาบริการ (WordPress.org)
จากนั้นสำรองเว็บในสภาพที่ติดมัลแวร์อยู่ ทั้งไฟล์และฐานข้อมูล WordPress.org แนะนำให้ถ่าย snapshot อีกครั้งก่อนเริ่มล้าง แม้จะติดมัลแวร์ เพื่อให้มีสำเนาอ้างอิงถ้าเกิดความเสียหายร้ายแรงระหว่างแก้ ส่วน Google แนะนำในกรณีที่ไม่มี backup ที่สะอาดว่าให้ทำสำเนาเว็บที่ติดเชื้อไว้ 2 ชุด แล้วล้างบนสำเนา ไม่ใช่บนเซิร์ฟเวอร์จริง (web.dev: Clean and maintain your site) เก็บสำเนานี้แยกจาก backup เก่าที่สะอาด และอย่าเขียนทับกัน วิธีสำรองที่ถูกต้องอ่านได้ที่ ควรทำ Backup WordPress อย่างไรให้ปลอดภัย
ขั้นที่ 2 เปลี่ยนรหัสผ่านทุกจุด (โฮสต์, FTP, ฐานข้อมูล, แอดมิน)
WordPress.org ระบุว่าต้องเปลี่ยนทุก access point ได้แก่ FTP/SFTP, wp-admin, cPanel หรือแผงควบคุมโฮสต์อื่น และ MySQL โดยครอบคลุมผู้ใช้ทุกคนที่เข้าถึงระบบได้ ไม่ใช่เฉพาะตัวคุณ และควรใช้รหัสผ่านที่ซับซ้อน ยาว และไม่ซ้ำกัน Google ให้รายการเดียวกัน คือ FTP, การเข้าถึงฐานข้อมูล, ผู้ดูแลระบบ และบัญชีของ CMS (web.dev) ควรเพิ่มรหัสผ่านอีเมลที่ใช้กู้คืนบัญชีเหล่านี้ด้วย เพราะถ้าอีเมลถูกยึด ผู้โจมตีจะรีเซ็ตรหัสใหม่ได้เสมอ
การเปลี่ยนรหัสผ่านไม่ได้ทำให้คนที่ล็อกอินค้างอยู่หลุดออก WordPress.org จึงแนะนำให้สร้าง secret keys ชุดใหม่จาก WordPress key generator แล้วเขียนทับค่าเดิมใน wp-config.php ซึ่งจะบังคับให้ทุกคนที่ยังล็อกอินอยู่ออกจากระบบ ถ้าเข้า SSH ได้ ใช้ WP-CLI ทำได้ดังนี้
ตัด session ที่ล็อกอินค้างอยู่ทั้งหมด
# สร้าง salt keys ชุดใหม่ใน wp-config.php (ทุกคนจะถูกล็อกเอาต์)
wp config shuffle-salts
# ลบ session ของผู้ใช้ทุกคน
wp user list --field=ID | xargs -n 1 wp user session destroy --allทั้งสองคำสั่งมาจากเอกสาร WP-CLI (config shuffle-salts และ user session destroy) สำรอง wp-config.php ก่อนรันเสมอ
ถ้าเปลี่ยนรหัสผ่านฐานข้อมูล ต้องแก้ค่า DB_PASSWORD ใน wp-config.php ให้ตรงกันด้วย และหากผู้โจมตียึดบัญชีแอดมินจนล็อกอินไม่ได้ WordPress.org แนะนำให้เข้าฐานข้อมูลผ่าน phpMyAdmin หรือ Adminer แล้วแก้อีเมลของผู้ใช้ในตาราง wp_users จากนั้นกดลืมรหัสผ่านที่หน้าล็อกอิน
สำคัญ: ทั้ง Google และ WordPress.org ให้เปลี่ยนรหัสผ่านซ้ำอีกครั้งหลังล้างเว็บเสร็จ เพราะถ้ายังมี Backdoor หรือโทรจันบนเครื่องผู้ดูแล รหัสที่เปลี่ยนในขั้นนี้อาจรั่วอีก หลังกู้เสร็จควรเปิด 2FA ให้บัญชีผู้ดูแลทุกคน ซึ่ง WordPress.org แนะนำให้พิจารณาใช้ อ่านเพิ่ม: 2FA คืออะไร
ขั้นที่ 3 สแกนและลบไฟล์แปลกปลอม
ขั้นนี้คือ eradication ในภาษาของ incident response WordPress.org เรียกว่าเป็นส่วนที่ยากที่สุดของกระบวนการ และแนะนำแนวทางดังนี้ (WordPress.org)
- สแกนทั้งสองแบบ ใช้ทั้งเครื่องมือภายนอก เช่น VirusTotal และ Sucuri SiteCheck และปลั๊กอินในเว็บ เช่น Wordfence เพราะแต่ละแบบตรวจคนละส่วน รายละเอียดอยู่ใน บทความเครื่องมือเช็คเว็บติดไวรัส
- ติดตั้งไฟล์ core ใหม่ด้วยเวอร์ชันเดียวกับที่ใช้อยู่ ผ่าน FTP/SFTP ไม่ใช่ปุ่มติดตั้งใหม่ใน wp-admin เพราะตัวติดตั้งมักเขียนทับเฉพาะไฟล์ที่มีอยู่ ขณะที่การแฮกมักเพิ่มไฟล์ใหม่เข้ามา โฟลเดอร์
/wp-adminและ/wp-includesแทนที่ได้ทั้งโฟลเดอร์อย่างปลอดภัย - ตรวจ
wp-contentอย่างละเอียด เพราะมีไฟล์ theme และ plugin ทยอยแทนที่ด้วยไฟล์จากแหล่งทางการทีละตัว - ตรวจไฟล์ที่ถูกแก้บ่อย คือ
.htaccess(ซึ่งอาจมีหลายไฟล์ในหลายโฟลเดอร์),index.php,header.php,footer.phpและfunctions.phpเพราะไฟล์เหล่านี้มีผลกับทุกหน้า
Google ระบุให้ติดตั้งแบบสะอาด (clean installation) ไม่ใช่แค่อัปเกรด เพื่อไม่ให้ไฟล์ที่ติดเชื้อหลงเหลือ และให้ลบซอฟต์แวร์หรือปลั๊กอินที่ไม่ได้ใช้ออก (web.dev) ห้ามติดตั้ง theme หรือ plugin เถื่อน (nulled) แทนของเดิม เพราะเป็นช่องทางติดมัลแวร์ที่เราพบบ่อยในเคสที่แก้
จุดที่ทำให้เว็บกลับมาติดซ้ำมากที่สุดคือ Backdoor หรือ Web Shell ที่ซ่อนไว้ เช่น ไฟล์ PHP ในโฟลเดอร์ uploads หรือไฟล์ที่ตั้งชื่อเลียนแบบไฟล์ core วิธีหาและลักษณะที่พบบ่อยอธิบายไว้ใน Backdoor ใน WordPress คืออะไร ทำไมล้างไวรัสแล้วกลับมาติดซ้ำ และ Web Shell คืออะไร
กู้จาก Backup หรือล้างไฟล์เอง
Google แบ่งเป็น 3 กรณี (web.dev)
| สถานการณ์ | แนวทางตามคำแนะนำของ Google |
|---|---|
| มี backup ที่สะอาดและเป็นปัจจุบัน | กู้จาก backup ติดตั้งอัปเดตทั้งหมด แก้ช่องโหว่ และเปลี่ยนรหัสผ่าน |
| มี backup ที่สะอาดแต่เก่า | สำรองเว็บที่ติดเชื้อไว้ก่อน กู้ backup เก่า อัปเกรดซอฟต์แวร์ทั้งหมดก่อนเปิดเว็บ แล้วเทียบหาเนื้อหาใหม่ที่สะอาดมาใส่คืน |
| ไม่มี backup | ทำสำเนาเว็บที่ติดเชื้อ 2 ชุด ล้างบนสำเนา แล้วจึงนำขึ้นใช้งาน |
NIST เพิ่มเงื่อนไขว่าให้ตรวจ backup หรือทรัพย์สินที่จะใช้กู้คืนว่ามี indicators of compromise ไฟล์เสียหาย หรือปัญหาด้านความถูกต้องหรือไม่ก่อนนำมาใช้ (NIST SP 800-61r3) ข้อนี้สำคัญเพราะ backup ที่คิดว่าสะอาดอาจถูกฝัง Backdoor ไว้ก่อนที่อาการจะปรากฏ Google แนะนำให้ใช้ log ของเซิร์ฟเวอร์หาวันที่ถูกเจาะ เพื่อรู้ว่า backup ชุดใดยังสะอาด (web.dev: Identify the vulnerability)
ขั้นที่ 4 ตรวจผู้ใช้และฐานข้อมูล
Google แนะนำให้ตรวจบัญชีผู้ใช้ทั้งหมด หาบัญชีที่ผู้โจมตีสร้างขึ้น และจดชื่อบัญชีที่น่าสงสัยไว้ก่อนลบ (web.dev) ชื่อและวันที่สร้างบัญชีช่วยให้ไล่ log ได้ว่าผู้โจมตีเข้ามาเมื่อไร
สำหรับ WordPress ให้ดูทั้งบัญชี Administrator ที่ไม่รู้จัก และบัญชีบทบาทอื่นที่เพิ่งสร้าง ส่วนฐานข้อมูลให้ตรวจค่า siteurl และ home ในตาราง wp_options และเนื้อหาในตาราง wp_posts ที่มีสคริปต์หรือลิงก์แปลกปลอม
หาผู้ดูแลที่ไม่รู้จักและเนื้อหาที่ถูกฝังในฐานข้อมูล
# รายชื่อผู้ดูแลระบบพร้อมวันที่สร้างบัญชี (WP-CLI)
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
-- ค่า URL ของเว็บ (ต้องเป็นโดเมนของคุณเท่านั้น) ใช้ใน phpMyAdmin
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');
-- บทความและหน้าที่มี script ฝังอยู่
SELECT ID, post_title, post_modified FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%';ถ้าตารางใช้ prefix อื่นที่ไม่ใช่ wp_ ให้เปลี่ยนตามค่าใน wp-config.php ผลที่พบอาจเป็นของปกติ เช่น โค้ดฝังวิดีโอที่คุณใส่เอง ให้ตรวจทีละรายการก่อนลบ
ถ้าพบหน้าหรือลิงก์พนันจำนวนมาก อ่านวิธีจัดการแบบเจาะจงได้ที่ เว็บโดนฝังลิงก์พนัน สล็อต บาคาร่า ถ้าหน้าแรกถูกเปลี่ยนเป็นข้อความของผู้โจมตี ดู เว็บโดนแฮกเปลี่ยนหน้าแรก (Defacement) และถ้าเว็บเด้งไปเว็บอื่น ดู เว็บเด้งไปเว็บอื่น เกิดจากอะไร ความเสี่ยงของการมีผู้ดูแลหลายคนอธิบายไว้ใน User Admin หลายคนใน WordPress เสี่ยงอย่างไร
ขั้นที่ 5 อัปเดตทุกอย่างและปิดช่องโหว่
ถ้าล้างแล้วไม่ได้ปิดทางที่ผู้โจมตีใช้เข้ามา เว็บจะถูกเจาะซ้ำ Google ชี้ว่าเว็บอาจถูกเจาะหลายครั้งแยกจากกัน การพบช่องโหว่หนึ่งจุดจึงไม่ได้แปลว่าพบครบ และยกช่องโหว่ที่พบบ่อยไว้ 4 กลุ่ม คือ เครื่องของผู้ดูแลติดสปายแวร์, รหัสผ่านอ่อนหรือใช้ซ้ำ, ซอฟต์แวร์ล้าสมัย และการเขียนโค้ดที่ไม่ปลอดภัย เช่น open redirect และ SQL injection (web.dev)
WordPress.org เรียกขั้นการหาว่าผู้โจมตีเข้ามาทางไหนว่า forensics และยอมรับว่าเจ้าของเว็บจำนวนมากทำได้ยากเพราะขาดความรู้หรือขาดข้อมูล แหล่งข้อมูลหลักคือ log ของเซิร์ฟเวอร์ เอกสาร Hardening WordPress ระบุว่า log คือสิ่งที่ช่วยมากที่สุดในการทำความเข้าใจว่าเกิดอะไรขึ้นกับเว็บ โดยเฉพาะเมื่อทำ forensics ให้ขอ access log และ error log ย้อนหลังจากโฮสติ้งโดยเร็ว เพราะ log มักถูกเก็บไว้ในช่วงเวลาจำกัด
เมื่อเว็บสะอาดแล้ว ให้อัปเดต WordPress เป็นเวอร์ชันล่าสุด ซึ่ง WordPress.org ระบุว่าเวอร์ชันเก่ามีโอกาสถูกแฮกมากกว่า และอัปเดต theme กับ plugin ทุกตัว ช่องโหว่ที่พบบ่อยในปีนี้สรุปไว้ใน ช่องโหว่ WordPress ที่พบบ่อยที่สุด 2026 และเหตุผลของการอัปเดตอยู่ใน ทำไมต้องอัปเดต Plugin และ Theme มาตรการป้องกันระยะยาวอยู่ใน วิธีป้องกันเว็บ WordPress โดนแฮก
ขั้นที่ 6 แจ้ง Google ให้ตรวจสอบใหม่
ถ้า Google ขึ้นคำเตือนหรือ Search Console แจ้ง Security Issues คำเตือนจะไม่หายเองทันทีหลังล้างเสร็จ Google กำหนดให้ทำ 4 อย่างก่อนขอตรวจสอบใหม่ คือ ยืนยันความเป็นเจ้าของเว็บใน Search Console, ล้างสิ่งที่ผู้โจมตีทำไว้, แก้ช่องโหว่ และนำเว็บที่สะอาดกลับมาออนไลน์ (web.dev: Request a review) เอกสาร Search Console ระบุเพิ่มว่าให้กด Request Review เมื่อแก้ปัญหาทุกข้อในรายงานครบในทุกหน้าแล้ว (Google Search Console Help)
ในคำขอให้อธิบายสั้นๆ ว่าล้างอะไรและแก้ช่องโหว่อย่างไร ระยะเวลาตรวจตามที่ Google ระบุมีดังนี้
| ประเภทปัญหา | ระยะเวลาตรวจโดยประมาณ |
|---|---|
| Hacked with spam | อาจนานถึงหลายสัปดาห์ |
| Malware | ไม่กี่วัน |
| Phishing | ประมาณ 1 วัน |
เมื่อ Google ยืนยันว่าเว็บสะอาด คำเตือนในเบราว์เซอร์และผลค้นหาจะถูกนำออกภายใน 72 ชั่วโมง (web.dev) ขั้นตอนใน Search Console แบบละเอียดอยู่ที่ Search Console แจ้ง Security Issues ต้องทำอย่างไร และกรณีคำเตือนสีแดงในเบราว์เซอร์อยู่ที่ Google เตือน เว็บไซต์นี้อาจเป็นอันตราย ทำอย่างไรดี
นอกจาก Google ยังมีบัญชีดำอื่น WordPress.org แนะนำให้ลงทะเบียนเว็บกับ Bing Webmaster และบริการอื่นด้วย และเตือนว่าผลกระทบที่พบมากขึ้นคือ IP ของเซิร์ฟเวอร์ถูกขึ้นบัญชีดำอีเมล เมื่อเว็บถูกใช้ส่งสแปม ถ้าอีเมลของโดเมนส่งไม่ออกหลังเหตุ อ่าน อีเมลส่งไม่ออก อาจเพราะเว็บโดนฝัง Spam Mailer
หลังกู้เสร็จ: บันทึกบทเรียนและข้อมูลส่วนบุคคล
NIST แนะนำให้จัดทำ after-action report ที่บันทึกตัวเหตุการณ์ การรับมือ การกู้คืน และบทเรียนที่ได้ (NIST SP 800-61r3) สำหรับเว็บธุรกิจขนาดเล็ก รายงานนี้อาจยาวเพียงหน้าเดียว แต่ควรตอบให้ได้ว่า ผู้โจมตีเข้ามาทางไหน ข้อมูลอะไรถูกเข้าถึง และเปลี่ยนอะไรไปแล้วเพื่อไม่ให้เกิดซ้ำ งานที่ต้องทำต่อหลังล้างเว็บสรุปไว้ใน หลังล้างไวรัส WordPress ต้องทำอะไรต่อ
ถ้าเว็บเก็บข้อมูลส่วนบุคคล เช่น ข้อมูลสมาชิกหรือคำสั่งซื้อ และมีโอกาสที่ข้อมูลรั่วไหล สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ระบุว่ากฎหมายกำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลมีหน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลให้ สคส. ทราบภายใน 72 ชั่วโมง ตามประกาศคณะกรรมการฯ เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ซึ่งมีผลใช้บังคับตั้งแต่ 15 ธันวาคม 2565 (สคส.) รายละเอียดของหลักเกณฑ์และข้อยกเว้นควรอ่านจากประกาศฉบับเต็มหรือปรึกษาผู้เชี่ยวชาญด้านกฎหมาย นอกจากนี้ ThaiCERT ภายใต้ สกมช. เปิดช่องทางแจ้งเหตุภัยคุกคามไซเบอร์ไว้บน เว็บไซต์ ThaiCERT
เมื่อไหร่ควรจ้างผู้เชี่ยวชาญ
WordPress.org ยอมรับว่าการหาต้นเหตุเป็นเรื่องยากสำหรับเจ้าของเว็บที่ขาดความรู้ทางเทคนิคหรือข้อมูล log และชุดบทความของ Google ก็เริ่มต้นด้วยขั้นตอนการสร้างทีมสนับสนุน (web.dev: Help, I think I’ve been hacked) จากเคสที่เราแก้ สถานการณ์ที่ควรให้ผู้เชี่ยวชาญดูแลมีดังนี้
- ล้างเองแล้วเว็บกลับมาติดซ้ำ ซึ่งมักแปลว่ายังมี Backdoor หรือยังไม่ได้ปิดช่องโหว่
- หาไม่ได้ว่าผู้โจมตีเข้ามาทางไหน
- โฮสติ้งระงับบัญชี หรือมีหลายเว็บในบัญชีเดียวกันติดพร้อมกัน (อ่าน Hosting แจ้งพบ Malware ต้องทำอย่างไร)
- เว็บรับชำระเงินหรือเก็บข้อมูลลูกค้า ซึ่งต้องประเมินว่าข้อมูลรั่วหรือไม่
- ไม่มี backup ที่สะอาด และไม่มีสิทธิ์เข้า SSH หรือฐานข้อมูล
ถ้าต้องการเปรียบเทียบก่อนตัดสินใจ อ่าน ล้างไวรัส WordPress เอง vs จ้างผู้เชี่ยวชาญ และสิ่งที่ควรเตรียมก่อนจ้างอยู่ใน ก่อนจ้างคนแก้เว็บ WordPress ต้องเตรียมอะไรบ้าง หากต้องการให้ทีมของเรากู้เว็บให้ ดูรายละเอียดได้ที่บริการ ล้างไวรัส WordPress
คำถามที่พบบ่อย
เว็บโดนแฮก ทำอย่างไรเป็นอย่างแรก?
บันทึกอาการและเวลาที่พบ แล้วหยุดไม่ให้เว็บส่งเนื้อหาอันตรายถึงผู้เข้าชม Google แนะนำให้นำเว็บออฟไลน์โดยให้หน้า 503 ตอบจากนอกเซิร์ฟเวอร์ที่ถูกเจาะ จากนั้นแจ้งโฮสติ้งและสำรองเว็บในสภาพปัจจุบันก่อนแก้ไข
ปิดเว็บระหว่างกู้ จะเสียอันดับใน Google ไหม?
Google ระบุว่าการปิดเว็บชั่วคราวหรือเป็นช่วงๆ ระหว่างกู้มีผลต่ออันดับในอนาคตเพียงเล็กน้อย ความเสียหายจากการปล่อยให้ผู้เข้าชมได้รับมัลแวร์หรือถูกขึ้นคำเตือนมักมากกว่า
เปลี่ยนรหัสผ่านแล้ว ทำไมยังโดนแฮกซ้ำ?
ผู้โจมตีอาจฝัง Backdoor ที่เข้าเว็บได้โดยไม่ต้องใช้รหัสผ่าน หรือยังมีโทรจันบนเครื่องผู้ดูแลที่ดักรหัสใหม่ได้ ต้องลบ Backdoor ปิดช่องโหว่ สแกนเครื่องผู้ดูแล แล้วเปลี่ยนรหัสผ่านซ้ำหลังล้างเสร็จ ตามคำแนะนำของ WordPress.org
กู้จาก Backup อย่างเดียวพอไหม?
ไม่พอ Google ให้อัปเดตซอฟต์แวร์ แก้ช่องโหว่ และเปลี่ยนรหัสผ่านหลังกู้ด้วย และ NIST แนะนำให้ตรวจ backup ว่าไม่มีร่องรอยการเจาะก่อนใช้ เพราะ backup อาจถูกฝัง Backdoor ไว้ก่อนอาการปรากฏ
ขอ Review จาก Google แล้วต้องรอนานแค่ไหน?
Google ระบุว่ากรณีสแปมอาจใช้เวลาหลายสัปดาห์ มัลแวร์ไม่กี่วัน และ phishing ประมาณ 1 วัน เมื่อผ่านแล้วคำเตือนจะถูกนำออกภายใน 72 ชั่วโมง
เว็บโดนแฮก ต้องแจ้งหน่วยงานรัฐไหม?
ถ้ามีการละเมิดข้อมูลส่วนบุคคล สคส. ระบุว่าผู้ควบคุมข้อมูลมีหน้าที่แจ้งเหตุต่อ สคส. ภายใน 72 ชั่วโมง ตามประกาศปี 2565 ซึ่งมีข้อยกเว้นตามหลักเกณฑ์ ควรอ่านประกาศฉบับเต็มหรือปรึกษาผู้เชี่ยวชาญด้านกฎหมาย ส่วนการแจ้งเหตุภัยคุกคามไซเบอร์ทำได้ผ่าน ThaiCERT
แหล่งอ้างอิง
- Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (NIST SP 800-61r3). National Institute of Standards and Technology. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://csrc.nist.gov/pubs/sp/800/61/r3/final
- Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). NIST SP 800-61r3 (PDF). National Institute of Standards and Technology. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
- WordPress.org. (2026). FAQ My site was hacked. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/faq-my-site-was-hacked/
- WordPress.org. (ม.ป.ป.). Hardening WordPress. Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/hardening/
- WordPress.org. (ม.ป.ป.). WordPress.org secret-key service. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://api.wordpress.org/secret-key/1.1/salt/
- Google. (ม.ป.ป.). Help, I think I’ve been hacked. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/hacked
- Google. (ม.ป.ป.). Quarantine your site. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/quarantine-your-site
- Google. (ม.ป.ป.). Identify the vulnerability. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/identify-the-vulnerability
- Google. (ม.ป.ป.). Clean and maintain your site. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/clean-and-maintain-your-site
- Google. (ม.ป.ป.). Request a review. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/request-a-review
- Google. (ม.ป.ป.). Security Issues report. Search Console Help. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://support.google.com/webmasters/answer/9044101?hl=en
- สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล. (2024). กฎหมายลำดับรอง PDPA ประกาศ กคส. เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.pdpc.or.th/3662/
- WP-CLI. (ม.ป.ป.). wp config shuffle-salts. Developer.WordPress.org. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/config/shuffle-salts/
- WP-CLI. (ม.ป.ป.). wp user session destroy. Developer.WordPress.org. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/user/session/destroy/
- ThaiCERT. (ม.ป.ป.). Thailand Computer Emergency Response Team (ThaiCERT). สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.thaicert.or.th/
