เว็บโดนแก้หน้าแรกเป็นพื้นดำ ขึ้น 'Hacked by ...' — ตอนนี้ต้องทำอะไรก่อน (กู้ได้ ใจเย็น)

ถ้าเปิดเว็บแล้วหน้าแรกกลายเป็นพื้นดำ มีข้อความ “Hacked by ...” ธง ชื่อกลุ่ม หรือเพลงแปลกๆ ให้ถือว่าเว็บเกิด เหตุการณ์ความปลอดภัย และอาจมีส่วนอื่นถูกแก้ด้วย แม้ตอนนี้จะเห็นความเสียหายแค่หน้าแรกก็ตาม

ข่าวดีคือเว็บส่วนใหญ่กู้กลับมาได้ครับ แต่เป้าหมายแรกไม่ใช่รีบทำให้หน้าตากลับมาสวยเหมือนเดิม เป้าหมายคือหยุดความเสียหาย เก็บหลักฐาน หาขอบเขต และปิดทางเข้าก่อนเปิดเว็บอีกครั้ง

หน้าจอดำคืออาการที่มองเห็น ไม่ใช่ขอบเขตทั้งหมดของการถูกเจาะ

บทความนี้อธิบายเฉพาะการรับมือ กู้คืน และป้องกันเว็บไซต์ของตัวเอง ไม่มีวิธีแก้หน้าเว็บหรือโจมตีระบบของผู้อื่นครับ

ชั่วโมงแรก: หยุดความเสียหายและเก็บหลักฐาน

ช่วงแรกควรทำให้น้อยแต่ถูกลำดับ อย่าลบไฟล์หรือ restore ทับทันทีจนข้อมูลที่ใช้หาต้นเหตุหายไป:

1. บันทึกสิ่งที่พบ — แคปหน้าจอ จด URL เวลาที่พบ ข้อความเตือน และอาการจากผู้ใช้แต่ละคน
2. จำกัดการเข้าถึงเว็บ — ให้ผู้ดูแลเปิด maintenance หรือแยกระบบตามความรุนแรง โดยหลีกเลี่ยงการทำลายไฟล์และ log เดิม
3. ใช้เครื่องที่เชื่อถือได้เปลี่ยน credential — เริ่มจาก hosting/control panel, SSH/SFTP, CMS admin, อีเมลผู้ดูแล และ token หรือ key ที่เกี่ยวข้อง พร้อมยกเลิก session ที่ไม่รู้จัก
4. เก็บสำเนาก่อน cleanup — สำรองไฟล์ ฐานข้อมูล config และ log ชุดปัจจุบันเพื่อใช้ตรวจย้อนหลัง แยกจาก backup ที่จะใช้กู้
5. ตั้งผู้ประสานงานหนึ่งคน — แจ้งเจ้าของเว็บ ทีมพัฒนา และผู้ให้บริการให้รู้ว่าใครตัดสินใจ เพื่อไม่ให้หลายคนแก้ไฟล์พร้อมกัน

อย่า login ผ่านหน้าที่ถูกแก้ อย่าคลิกลิงก์หรือดาวน์โหลดไฟล์จากหน้านั้น และอย่าใช้แค่วันที่แก้ไขไฟล์เป็นหลักฐาน เพราะข้อมูลเวลาอาจถูกเปลี่ยนได้

Website defacement คืออะไร และจอดำบอกอะไรไม่ได้

Website defacement คือการที่บุคคลที่ไม่ได้รับอนุญาตเปลี่ยนเนื้อหา หน้าตา หรือพฤติกรรมของเว็บไซต์ บางเคสแทนหน้าแรกตรงๆ บางเคสเพิ่มหน้าใหม่ ฉีดข้อความ หรือแสดงผลเฉพาะบางอุปกรณ์และบางแหล่งที่มา

สิ่งที่หน้าจอดำยืนยันได้คือ มีใครบางคนหรือบางกระบวนการได้สิทธิ์แก้ระบบ แต่หน้าตาของมันไม่สามารถบอกได้ว่า:

• ผู้โจมตีเข้าถึงแค่ไฟล์หน้าแรก หรือเข้าถึงไฟล์ ฐานข้อมูล และบัญชีผู้ดูแลด้วย
• มี backdoor, web shell, admin แปลก หรืองาน cron ถูกทิ้งไว้หรือไม่
• ข้อมูลลูกค้าถูกเปิดดูหรือส่งออกไปแล้วหรือยัง

จึงไม่ควรประเมินความรุนแรงจากความน่ากลัวของหน้าจอ ต้องตรวจสิทธิ์ที่ถูกใช้และขอบเขตที่ได้รับผลกระทบจริง

หาต้นเหตุและขอบเขตที่ถูกแก้

ทางเข้าที่พบบ่อยคือ CMS ปลั๊กอินหรือธีมที่มีช่องโหว่ รหัสผ่านหรือ key รั่ว ฟอร์มอัปโหลดที่ตรวจไฟล์ไม่พอ permission หรือ config ที่กว้างเกินไป และเว็บไซต์อื่นในบัญชีเดียวกันที่ถูกเจาะก่อน

ถ้าระบบรับไฟล์จากผู้ใช้ ให้ตรวจตั้งแต่นามสกุล MIME type เนื้อหาไฟล์ ชื่อที่ใช้จัดเก็บ สิทธิ์ผู้ใช้ ตำแหน่งจัดเก็บ และความสามารถในการรันสคริปต์ ตามแนวทางของ OWASP File Upload Cheat Sheet การบล็อกนามสกุลไม่กี่ชนิดเพียงชั้นเดียวไม่พอ

การตรวจขอบเขตควรครอบคลุมทั้งบัญชี ไม่ใช่เฉพาะ index.php:

• เทียบ core ปลั๊กอินและธีมกับแพ็กเกจ known-good จากแหล่งที่เชื่อถือได้
• ตรวจไฟล์ที่เพิ่มหรือถูกแก้ โค้ดแปลกในไฟล์เดิม ฐานข้อมูล และโฟลเดอร์ uploads/cache/tmp
• ตรวจบัญชี admin, SSH key, API token, cron/scheduled task และการตั้งค่าที่ไม่รู้จัก
• เชื่อม access log, authentication log และเวลาการเปลี่ยนไฟล์เพื่อสร้าง timeline
• ตรวจเว็บไซต์อื่นที่ใช้ user, document root หรือ credential ชุดเดียวกัน

8 ขั้นกู้เว็บให้กลับมาอย่างปลอดภัย

NIST SP 800-61 Rev. 3 วางการตรวจพบ ตอบสนอง และกู้คืนเป็นกระบวนการต่อเนื่อง สำหรับเว็บที่ถูก deface สามารถแปลงเป็นลำดับทำงานได้ดังนี้:

1. ควบคุมเหตุและเก็บหลักฐาน — จำกัดการเข้าถึงและเก็บไฟล์ ฐานข้อมูล config กับ log ก่อนเปลี่ยนแปลง
2. กำหนดขอบเขตและ timeline — หาเวลาเริ่มต้น ทางเข้า ระบบหรือเว็บอื่นที่เกี่ยวข้อง และข้อมูลที่อาจถูกแตะ
3. หมุน credential — เปลี่ยนรหัส key และ token จากเครื่องสะอาด ยกเลิก session และลบบัญชีที่ไม่ได้รับอนุญาต
4. กำจัดสิ่งแปลกปลอม — ลบ backdoor และ persistence พร้อมแทนไฟล์ระบบด้วย known-good ไม่ใช้การเดาจากชื่อไฟล์อย่างเดียว
5. กู้ข้อมูลที่สะอาด — restore ไฟล์และฐานข้อมูลจากจุดก่อนถูกเจาะเมื่อจำเป็น โดยทดสอบใน staging ก่อนถ้าทำได้
6. อุดช่องและ harden — อัปเดตหรือลบส่วนเสริมที่เป็นต้นเหตุ ปรับ permission ป้องกัน uploads และเพิ่มชั้น WAF/monitoring ตามความเหมาะสม
7. ตรวจยืนยันก่อนเปิด — ทดสอบฟังก์ชัน เว็บมือถือ หน้า login แบบฟอร์ม การส่งอีเมล และสแกนทั้งบัญชีอีกครั้ง
8. เฝ้าระวังและบันทึกบทเรียน — ดู log การเปลี่ยนไฟล์ login และ traffic ส่งออก พร้อมจดสิ่งที่แก้เพื่อป้องกันเหตุซ้ำ

หากสงสัยว่ามีข้อมูลส่วนบุคคลหรือข้อมูลสำคัญรั่วไหล ต้องประเมินหน้าที่แจ้งผู้เกี่ยวข้องตามนโยบายและกฎหมายที่ใช้กับธุรกิจนั้นเพิ่มเติม ไม่ควรสรุปว่าเป็นเพียงการเปลี่ยนหน้าเว็บ

เลือก backup สะอาดและเคลียร์คำเตือน Google

Backup ช่วยลดเวลาหยุดระบบได้มาก แต่ต้องเป็นชุดที่อยู่ก่อนช่องทางถูกเจาะและกู้ได้ครบจริง ก่อน restore ให้ตอบคำถามเหล่านี้:

1. จุดไหนคือเวลาล่าสุดที่ยืนยันได้ว่าเว็บยังปกติ และหลักฐานที่ใช้ยืนยันคืออะไร?
2. ชุดนั้นมีทั้งไฟล์ ฐานข้อมูล config และ media ที่ต้องใช้หรือไม่?
3. Backup แยกจากบัญชีหรือระบบที่ถูกเจาะ และยังไม่ถูกเขียนทับใช่ไหม?
4. สามารถกู้ทดสอบบน staging แล้วสแกนก่อนนำขึ้นจริงได้หรือไม่?
5. หลัง restore จะนำข้อมูลใหม่กลับมาอย่างไร โดยไม่ดึงไฟล์หรือบัญชีที่เป็นอันตรายกลับมาด้วย?

ถ้า Google หรือ Chrome แสดงคำเตือน ให้ใช้ Security Issues report ใน Google Search Console เป็นจุดตรวจหลัก แก้ปัญหาทุกประเภทและทุกหน้าที่เกี่ยวข้อง ทดสอบให้ครบ แล้วจึงกด Request Review พร้อมอธิบายต้นเหตุ สิ่งที่แก้ และผลตรวจ อย่าส่งซ้ำก่อนผลรอบเดิมออก

ถ้า Search Console ไม่แสดง Security Issue ก็ไม่ต้องสร้างคำขอขึ้นมาเอง แต่ยังควรเฝ้าดูการ index, URL แปลก และผลสแกนหลังเปิดเว็บต่อเนื่อง

เอา index กลับไม่พอ — ผู้ดูแลควรช่วยอะไร

การอัปโหลด index.php หน้าเดิมกลับไปแก้เพียงสิ่งที่ผู้ใช้มองเห็น ไม่ได้ยืนยันว่า backdoor หาย ทางเข้าเดิมถูกปิด หรือข้อมูลส่วนอื่นปลอดภัย ก่อนวางใจผู้ดูแลหรือบริการกู้เว็บ ให้ถามให้ชัดว่า:

1. ช่วยจำกัดเหตุและเก็บหลักฐานก่อน cleanup หรือเริ่มจากลบไฟล์ทันที?
2. ตรวจทั้งบัญชี เว็บไซต์ที่ใช้ user เดียวกัน บัญชี admin key cron และ log หรือไม่?
3. ช่วยเลือกและกู้ backup ที่สะอาดให้ครบทั้งไฟล์กับฐานข้อมูลได้ไหม?
4. หาต้นเหตุ อุดช่อง หมุน credential และ harden หลัง restore ถึงระดับไหน?
5. มีการตรวจซ้ำ เฝ้าระวัง และช่วยดำเนินการกับ Search Console เมื่อมีคำเตือนหรือไม่?

แนวทางของ PhalconHost คือช่วยประเมินเหตุ ตรวจไฟล์ในบัญชี เลือกจุดกู้จาก auto backup เมื่อมีชุดสะอาด และช่วย harden ชั้นเว็บหรือเซิร์ฟเวอร์แบบ best-effort เราเป็นบริการ unmanaged ที่มี Dev ช่วย ไม่ใช่สัญญา managed incident response ที่รับประกันผลทุกกรณี

ถ้าหน้าเว็บคุณกำลังถูกแก้อยู่ ส่งภาพหน้าจอ URL และเวลาที่พบมาทางไลน์ได้ครับ อย่าเพิ่งลบหรือ restore ทับ เดี๋ยวผมช่วยประเมินว่าควรจำกัดระบบตรงไหนและต้องเก็บอะไรต่อก่อนเริ่มกู้ครับ