เว็บโดนแฮกเปลี่ยนหน้าแรก (Defacement) ต้องทำอย่างไรทันที

Website Defacement หรืออาการ เว็บโดนแฮกเปลี่ยนหน้า คือการที่ผู้โจมตีเข้าไปแก้ไขเนื้อหาที่แสดงบนเว็บไซต์โดยไม่ได้รับอนุญาต ส่วนใหญ่เป็นการเปลี่ยนหน้าแรกให้เป็นข้อความของผู้โจมตี เช่น “Hacked by …” พร้อมชื่อกลุ่ม ภาพ หรือข้อความทางการเมือง ต่างจากมัลแวร์ประเภทอื่นที่ซ่อนตัว Defacement ถูกออกแบบมาให้ทุกคนเห็น ผู้เข้าชมจึงรู้ทันทีที่เปิดเว็บ

Defacement เป็นหนึ่งในประเภทของ มัลแวร์และการโจมตีเว็บไซต์ ที่เกิดผลเสียต่อความน่าเชื่อถือรวดเร็วที่สุด และหน้าที่ถูกเปลี่ยนเป็นเพียงอาการที่มองเห็น สิ่งที่สำคัญกว่าคือช่องทางที่ผู้โจมตีใช้เข้ามาแก้ไฟล์ หัวข้อด้านล่างเรียงตามลำดับที่ควรทำ ตั้งแต่ชั่วโมงแรกจนถึงการป้องกันระยะยาว

Website Defacement คืออะไร

MITRE ATT&CK ซึ่งเป็นฐานความรู้เทคนิคการโจมตีที่ใช้กันแพร่หลาย จัด Defacement (T1491) ไว้ในกลุ่มเทคนิคด้านผลกระทบ (Impact) และนิยามว่าเป็นการที่ผู้โจมตีแก้ไขเนื้อหาที่มองเห็นได้ ทั้งภายในและภายนอกเครือข่ายขององค์กร ซึ่งกระทบความถูกต้องสมบูรณ์ (integrity) ของเนื้อหาต้นฉบับ เทคนิคนี้แบ่งเป็นสองแบบย่อย คือ Internal Defacement ที่เปลี่ยนเนื้อหาในระบบภายในองค์กร และ External Defacement (T1491.002) ที่เปลี่ยนระบบที่คนภายนอกมองเห็น ซึ่ง MITRE ระบุว่าเว็บไซต์ที่เปิดสู่สาธารณะเป็นเป้าหมายที่พบบ่อย

ตัวอย่างทางประวัติศาสตร์ที่มีการบันทึกไว้คือเวิร์ม Code Red ในปี 2001 ประกาศ CERT Advisory CA-2001-19 ของ CERT/CC ซึ่งออกเมื่อวันที่ 19 กรกฎาคม 2001 ระบุว่าเวิร์มนี้โจมตีเซิร์ฟเวอร์ที่ใช้ IIS 4.0 และ 5.0 และหน้าเว็บบนเครื่องที่ติดเชื้ออาจถูกเปลี่ยนเป็นข้อความ “HELLO! Welcome to http://www.worm.com! Hacked By Chinese!” รูปแบบข้อความ “Hacked by” ลักษณะนี้ยังคงพบในการเปลี่ยนหน้าเว็บจนถึงปัจจุบัน

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

แรงจูงใจของแฮกเกอร์

MITRE อธิบายแรงจูงใจของ Defacement ไว้หลายแบบ ดังนี้

• ส่งสาร ข่มขู่ หรือชี้นำผิด เป้าหมายคือให้ผู้ใช้หมดความเชื่อมั่นในระบบและตั้งคำถามกับความถูกต้องของระบบนั้น
• อ้างผลงาน ผู้โจมตีอาจอ้างความรับผิดชอบต่อการเจาะระบบ ซึ่ง MITRE หมายเหตุว่าการอ้างนั้นอาจเป็นเท็จ
• เผยแพร่ข้อความทางการเมืองหรือโฆษณาชวนเชื่อ MITRE ระบุว่าเว็บไซต์ภายนอกมักตกเป็นเป้าของกลุ่มผู้โจมตีและกลุ่มแฮกทิวิสต์ (hacktivist) เพื่อจุดประสงค์นี้ และ Defacement อาจถูกใช้เป็นตัวจุดชนวนเหตุการณ์ หรือเป็นการตอบโต้การกระทำขององค์กรหรือรัฐบาล
• เตรียมการโจมตีขั้นต่อไป MITRE ระบุว่าการเปลี่ยนหน้าเว็บอาจเป็นขั้นเตรียมการของการโจมตีอื่น เช่น Drive-by Compromise ซึ่งใช้เว็บที่ถูกเจาะแจกจ่ายโค้ดอันตรายให้ผู้เข้าชม (ดู Google เตือนว่าเว็บไซต์นี้อาจเป็นอันตราย และ Drive-by Download)

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

สิ่งที่ต้องทำใน 1 ชั่วโมงแรก

ปฏิกิริยาแรกของเจ้าของเว็บส่วนใหญ่คือรีบลบหน้าที่ถูกเปลี่ยนหรือกู้ Backup ทับทันที ซึ่งทำให้หลักฐานที่ใช้หาช่องทางเจาะหายไป เอกสาร FAQ My site was hacked ของ WordPress.org แนะนำให้เริ่มจากการบันทึกสิ่งที่เกิดขึ้น และให้ทำสำเนาสภาพแวดล้อมอีกชุดก่อนเริ่มทำความสะอาด แม้สำเนานั้นจะติดเชื้ออยู่ก็ตาม ส่วน NIST SP 800-61 Rev. 3 (เมษายน 2025) แนะนำให้เก็บข้อมูลของเหตุการณ์โดยรักษาความถูกต้องและที่มาของข้อมูลไว้ และระบุว่าการควบคุมความเสียหาย (containment) คือการป้องกันไม่ให้เหตุการณ์ขยายวง

ลำดับต่อไปนี้รวมสองแนวทางนั้นเข้าด้วยกัน

1. บันทึกสิ่งที่เห็น (5 นาทีแรก) จับภาพหน้าจอหน้าที่ถูกเปลี่ยนพร้อม URL จดเวลาที่พบพร้อมเขตเวลา และจดว่าก่อนหน้านี้มีการติดตั้งหรือแก้ไขอะไรในเว็บบ้าง ตามที่เอกสารของ WordPress.org ระบุ ข้อมูลนี้คือฐานของรายงานเหตุการณ์
2. ทำสำเนาเว็บและบันทึกการเข้าถึงก่อนแก้ไขอะไร สำรองไฟล์ทั้งหมด ฐานข้อมูล และ access log กับ error log ของเว็บเก็บแยกไว้ (ดูคำสั่งในหัวข้อตัวอย่างด้านล่าง) โฮสต์หลายรายเก็บบันทึกไว้เพียงระยะสั้น ถ้าไม่สำรองไว้ตอนนี้ อาจหายไปก่อนจะได้ตรวจ
3. ปิดเว็บชั่วคราว แทนที่หน้าเว็บด้วยหน้าแจ้งปิดปรับปรุงที่ตอบกลับด้วยรหัส HTTP 503 คำแนะนำของ Google Search Central ระบุว่าถ้าจำเป็นต้องปิดเว็บด่วน 1–2 วัน ให้แสดงหน้าข้อมูลพร้อมรหัส 503 และเตือนว่าควรใช้วิธีนี้ในระยะสั้นมาก (ไม่เกินสองสามวัน) มิฉะนั้นจะกระทบการแสดงผลใน Search อย่างมีนัยสำคัญ
4. เปลี่ยนรหัสผ่านทุกช่องทางจากเครื่องที่สะอาด ได้แก่ ผู้ดูแล WordPress ทุกบัญชี แผงควบคุมโฮสต์ FTP/SFTP และฐานข้อมูล และสร้างคีย์ลับ (salts) ใน wp-config.php ใหม่เพื่อบังคับให้ทุกเซสชันที่ล็อกอินอยู่หลุดออก เอกสารของ WordPress.org แนะนำทั้งสองขั้นนี้ และแนะนำให้สแกนคอมพิวเตอร์ของตนเองด้วย เพราะในหลายกรณีรหัสผ่านถูกขโมยจากเครื่องของเจ้าของเว็บ
5. ตรวจบัญชีผู้ใช้ ดูว่ามีบัญชีผู้ดูแลระบบที่ไม่รู้จักหรือไม่ ถ้ามี ให้บันทึกชื่อบัญชีและวันที่สร้างไว้ก่อนลบ เพราะวันที่สร้างช่วยระบุช่วงเวลาที่ถูกเจาะ
6. แจ้งโฮสต์ เอกสารของ WordPress.org ระบุว่าการเจาะอาจกระทบมากกว่าเว็บเดียว โดยเฉพาะบนโฮสติ้งแบบแชร์ โฮสต์ยังช่วยยืนยันได้ว่าเป็นการเจาะจริงหรือเป็นปัญหาของบริการ
7. รายงานหน่วยงานถ้าจำเป็น ThaiCERT ซึ่งดำเนินงานโดยสำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (สกมช.) รับแจ้งเหตุภัยคุกคามทางไซเบอร์ทางอีเมล thaicert@ncsa.or.th และโทรศัพท์ 02 114 3531 ตามที่ระบุใน หน้าติดต่อของ ThaiCERT และ หน้ากิจกรรมประสานความช่วยเหลือ แนะนำให้เตรียมรายละเอียดเหตุการณ์ วันเวลา ช่องทางที่พบ และหลักฐานประกอบ เช่น ภาพหน้าจอ

กู้เว็บจาก Backup

NIST SP 800-61 Rev. 3 ระบุว่าการกู้คืน (recovery) รวมถึงการกู้ระบบจาก Backup ที่สะอาด การสร้างระบบใหม่ และการแทนที่ไฟล์ที่ถูกเจาะ คำสำคัญคือ “สะอาด” Backup ที่ใช้ต้องสร้างก่อนที่ผู้โจมตีจะเข้ามาครั้งแรก ซึ่งอาจเกิดก่อนวันที่หน้าเว็บถูกเปลี่ยนหลายวันหรือหลายสัปดาห์ ถ้ากู้จาก Backup ที่มี Backdoor อยู่แล้ว ก็เท่ากับกู้ช่องทางของผู้โจมตีกลับมาด้วย

แนวทางเลือก Backup มีดังนี้

• ใช้ข้อมูลจาก access log และวันที่สร้างบัญชีแปลกปลอม (ถ้ามี) ประมาณวันที่ถูกเจาะครั้งแรก แล้วเลือก Backup ที่เก่ากว่าวันนั้น
• ถ้าไม่แน่ใจ ให้กู้ไฟล์ WordPress หลักใหม่จากแหล่งทางการแทนการกู้ทั้งชุด เอกสารของ WordPress.org ระบุว่าโฟลเดอร์ /wp-admin และ /wp-includes แทนที่ได้อย่างปลอดภัย และควรใช้เวอร์ชันเดียวกับที่เว็บใช้อยู่
• ข้อมูลที่เปลี่ยนหลังวันที่ Backup เช่น คำสั่งซื้อหรือบทความใหม่ ต้องนำกลับมาจากสำเนาที่ทำไว้ในชั่วโมงแรกอย่างระมัดระวัง โดยตรวจว่าไม่มีโค้ดแปลกปลอมติดมา
• หลังกู้แล้ว ให้อัปเดต WordPress, Plugin และ Theme ทันทีก่อนเปิดเว็บ เพราะ Backup ที่กู้มายังมีช่องโหว่เดิมอยู่

วิธีเก็บ Backup ให้ใช้กู้ได้จริงในสถานการณ์นี้ อธิบายไว้ใน ควรทำ Backup WordPress อย่างไรให้ปลอดภัย

ทำไมต้องหาจุดที่โดนเจาะด้วย ไม่ใช่แค่กู้หน้าเว็บ

การเปลี่ยนหน้าเว็บบอกเพียงว่าผู้โจมตีมีสิทธิ์เขียนไฟล์หรือแก้ฐานข้อมูลของเว็บได้ แต่ไม่ได้บอกว่าผู้โจมตีทำอะไรอีกบ้าง NIST SP 800-61 Rev. 3 อธิบายขั้นการกำจัด (eradication) ว่ามีเป้าหมายเพื่อกำจัดกลไกการคงอยู่ (persistence) และช่องทางเข้า เช่น ลบมัลแวร์ ปิดบัญชีที่ถูกเจาะ และระบุและแก้ไขช่องโหว่ทั้งหมดที่ถูกใช้ และแนะนำให้มองหาสัญญาณการคงอยู่ทั้งในระบบที่รู้ว่าถูกโจมตีและระบบอื่นที่อาจเป็นเป้าหมาย การประเมินอย่างผิวเผินอาจทำให้ประเมินขนาดของเหตุการณ์ต่ำเกินจริง

ในเว็บ WordPress สิ่งที่มักพบร่วมกับการเปลี่ยนหน้าเว็บ ได้แก่

• Web Shell และ Backdoor ไฟล์ที่ให้ผู้โจมตีกลับเข้ามาได้แม้เปลี่ยนรหัสผ่านแล้ว อ่านรายละเอียดได้ที่ Web Shell คืออะไร และ Backdoor ใน WordPress ทำไมล้างไวรัสแล้วกลับมาติดซ้ำ
• บัญชีผู้ดูแลระบบที่ถูกสร้างเพิ่ม ซึ่งเอกสารของ WordPress.org จัดเป็นสัญญาณบ่งชี้การถูกเจาะ (Indicator of Compromise)
• โค้ดที่ถูกฝังในไฟล์ที่ทุกหน้าโหลด เอกสารของ WordPress.org ระบุไฟล์ที่ควรตรวจคือ index.php, header.php, footer.php, functions.php และ .htaccess
• มัลแวร์ที่ซ่อนตัว เช่น สคริปต์ส่งอีเมลสแปม (ดู อีเมลส่งไม่ออก อาจเพราะเว็บโดนฝัง Spam Mailer) หรือ JavaScript ที่พาผู้เข้าชมไปเว็บอื่น

ตัวอย่างหน้าที่ถูกเปลี่ยนและคำสั่งตรวจสอบ

ตัวอย่างในหัวข้อนี้ตัดส่วนที่ทำงานได้ออกแล้ว และเปลี่ยนโดเมนเป็นโดเมนสมมติ .example ใช้เพื่อให้จำหน้าตาได้เวลาเจอในเว็บของคุณเท่านั้น

<?php /* ไฟล์ index.php เดิมของ WordPress ถูกแทนที่ทั้งไฟล์ */ ?>
<html><head><title>Hacked by …</title></head>
<body style="background:#000;color:#0f0;text-align:center">
  <h1>HACKED BY …</h1>
  <p>Your security is … </p>
  <audio autoplay src="https://cdn.bad-site.example/…"></audio>
  <script src="https://cdn.bad-site.example/…"></script>
</body></html>
<?php
if (isset($_GET['up'])) { /* … ฟอร์มอัปโหลดไฟล์ถูกตัดออก … */ }
?>

# สำรองไฟล์เว็บและ log ทั้งหมด (เปลี่ยน public_html และพาธ log ตามโฮสต์ของคุณ)
tar -czf ~/evidence-$(date +%F-%H%M).tar.gz public_html logs

# สำรองฐานข้อมูล (ต้องติดตั้ง WP-CLI)
wp db export ~/evidence-db-$(date +%F-%H%M).sql

# บันทึกค่า hash เพื่อยืนยันภายหลังว่าไฟล์หลักฐานไม่ถูกแก้
sha256sum ~/evidence-* > ~/evidence.sha256

# ตรวจไฟล์หลักของ WordPress เทียบกับ checksum ทางการ
wp core verify-checksums

# ตรวจไฟล์ของ Plugin ที่มาจากคลังของ WordPress.org
wp plugin verify-checksums --all

# ไฟล์ที่ถูกแก้ภายใน 7 วันที่ผ่านมา
find . -type f \( -name "*.php" -o -name "*.html" -o -name ".htaccess" \) -mtime -7

# ไฟล์ที่มีข้อความ hacked by
grep -rli "hacked by" --include="*.php" --include="*.html" --include="*.js" .

# บัญชีผู้ใช้ที่สร้างล่าสุด
wp user list --fields=ID,user_login,roles,user_registered --orderby=user_registered --order=DESC

วิธีป้องกัน

การป้องกัน Defacement ใช้หลักเดียวกับการป้องกันการเจาะเว็บโดยทั่วไป แต่มีบางมาตรการที่ตรงกับปัญหานี้โดยเฉพาะ

รายการมาตรการทั้งหมดแบบทำตามได้ทีละข้ออยู่ใน วิธีป้องกัน WordPress โดนแฮก และขั้นตอนกู้เว็บที่ถูกแฮกแบบเต็มอยู่ใน เว็บ WordPress โดนแฮก ต้องทำอะไรก่อน ถ้าต้องการให้ผู้เชี่ยวชาญช่วยกู้หน้าเว็บ หาช่องทางที่ถูกเจาะ และวางระบบป้องกัน WP Doctor Thailand มีบริการ ล้างไวรัสและมัลแวร์ WordPress และ Security Hardening

คำถามที่พบบ่อย

แหล่งอ้างอิง

1. MITRE. (ม.ป.ป.). Defacement, Technique T1491 – Enterprise. MITRE ATT&CK. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://attack.mitre.org/techniques/T1491/
2. MITRE. (2025). Defacement: External Defacement, Sub-technique T1491.002 – Enterprise. MITRE ATT&CK. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://attack.mitre.org/techniques/T1491/002/
3. CERT Coordination Center. (2001). CERT Advisory CA-2001-19 “Code Red” Worm Exploiting Buffer Overflow In IIS Indexing Service DLL. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://seclists.org/cert/2001/13
4. National Institute of Standards and Technology. (2025). SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://csrc.nist.gov/pubs/sp/800/61/r3/final
5. WordPress.org. (2018, ปรับปรุง 2026). FAQ My site was hacked. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/faq-my-site-was-hacked/
6. WordPress.org. (ม.ป.ป.). Hardening WordPress. WordPress Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/hardening/
7. WordPress.org. (ม.ป.ป.). wp core verify-checksums – WP-CLI Command. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/core/verify-checksums/
8. Google Search Central. (ม.ป.ป.). Temporarily pause or disable a website. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developers.google.com/search/docs/crawling-indexing/pause-online-business
9. ThaiCERT, สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ. (ม.ป.ป.). ติดต่อสำนักงาน. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.thaicert.or.th/contactus/
10. ThaiCERT, สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ. (ม.ป.ป.). กิจกรรมประสานความช่วยเหลือ. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.thaicert.or.th/support-coordination/