เว็บ WordPress โดนแฮก: ขั้นตอนตรวจสอบและกู้คืน

อาการของเว็บ WordPress ที่ถูกแฮกมีหลายแบบ เช่น หน้าเว็บถูกเปลี่ยนเป็นข้อความแปลกๆ ผู้เข้าชมจากมือถือถูกพาไปเว็บพนันหรือเว็บหลอกลวง Google แสดงคำเตือน "เว็บไซต์นี้อาจถูกแฮก" มีบัญชีผู้ดูแลที่ไม่รู้จักโผล่ขึ้นมา หรือโฮสต์ส่งอีเมล Spam ออกไปเป็นจำนวนมาก

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

สิ่งที่ต้องเตรียม

• สิทธิ์เข้าแผงควบคุมโฮสติ้ง (Plesk หรือ DirectAdmin) หรือสิทธิ์ SSH ที่ใช้ sudo ได้ สำหรับ Cloud Server
• WP-CLI (แนะนำอย่างยิ่ง ดู จัดการ WordPress ด้วย WP-CLI)
• ไฟล์สำรองที่แน่ใจว่าสร้างก่อนถูกแฮก ถ้ามี
• รายชื่อปลั๊กอินและธีมที่ใช้งานจริง พร้อมแหล่งดาวน์โหลดที่ถูกต้อง
• เครื่องคอมพิวเตอร์ที่สะอาดและสแกนไวรัสแล้ว สำหรับใช้เปลี่ยนรหัสผ่าน

ขั้นตอนที่ 1: ควบคุมความเสียหายก่อน

เป้าหมายคือหยุดไม่ให้ผู้เข้าชมได้รับอันตรายเพิ่ม และไม่ให้ผู้บุกรุกทำอะไรต่อ

1. ถ้าเว็บกำลังพาผู้ใช้ไปเว็บอันตราย ให้ปิดเว็บชั่วคราวด้วยหน้า Maintenance แบบไฟล์ HTML ธรรมดา หรือจำกัดการเข้าถึงเฉพาะ IP ของคุณ
2. ตรวจว่ามีโปรเซสแปลกๆ ทำงานอยู่หรือไม่ (สำหรับ Cloud Server) ด้วย ps aux --sort=-%cpu | head โปรเซสที่รันจาก /tmp หรือชื่อสุ่มควรตรวจสอบเป็นพิเศษ
3. ถ้าเครื่องส่งอีเมล Spam ออกไป ให้หยุดคิวอีเมลและตรวจว่า IP ติด Blacklist หรือไม่ ดู ตรวจสอบและขอถอด IP ออกจาก Blacklist อีเมล

ขั้นตอนที่ 2: สำรองสภาพปัจจุบันไว้เป็นหลักฐาน

ก่อนลบหรือแก้อะไร ให้สำรองทั้งไฟล์และฐานข้อมูลในสภาพที่ถูกแฮกแยกไว้ ใช้สำหรับตรวจย้อนหลังว่าเข้ามาทางไหน และกู้ข้อมูลที่อาจลบผิด

cd /var/www/example.com
wp db export /root/hacked-db-$(date +%F).sql
tar czf /root/hacked-files-$(date +%F).tar.gz .

เก็บไฟล์เหล่านี้ไว้นอกโฟลเดอร์เว็บ (อย่าวางไว้ใน public_html เพราะจะดาวน์โหลดได้จากภายนอก) บน Plesk และ DirectAdmin ใช้ระบบสำรองของแผงควบคุมได้ ดู สำรองและกู้คืนเว็บไซต์ด้วย Backup Manager บน Plesk หรือ สำรองและกู้คืนข้อมูลบน DirectAdmin

ขั้นตอนที่ 3: ตัดสินใจว่าจะกู้จากไฟล์สำรองหรือทำความสะอาด

แม้จะกู้จากไฟล์สำรอง ก็ยังต้องทำขั้นตอนที่ 7 และ 8 เพราะช่องโหว่เดิมยังอยู่

ขั้นตอนที่ 4: ตรวจไฟล์ Core, ปลั๊กอิน และธีม

WP-CLI เทียบไฟล์ของ WordPress กับค่า Checksum ทางการได้

wp core verify-checksums
wp plugin verify-checksums --all

ถ้าผลแสดง File doesn't verify against checksum หรือ File should not exist คือไฟล์ถูกแก้หรือถูกเพิ่มเข้ามา ส่วนปลั๊กอินที่ไม่ได้มาจาก WordPress.org (ปลั๊กอินเสียเงิน) จะตรวจด้วยคำสั่งนี้ไม่ได้ ต้องดาวน์โหลดชุดใหม่จากผู้พัฒนาโดยตรง

วิธีที่ปลอดภัยที่สุดคือแทนที่ไฟล์ Core ทั้งหมดด้วยชุดใหม่ในเวอร์ชันเดิม โดยไม่แตะโฟลเดอร์ wp-content

wp core download --version=$(wp core version) --force --skip-content

คำสั่งนี้ไม่ลบไฟล์แปลกปลอมที่ถูกเพิ่มเข้ามาใน wp-admin หรือ wp-includes ให้ลบไฟล์ที่ verify-checksums รายงานว่า should not exist ด้วยตนเอง

สำหรับปลั๊กอินจาก WordPress.org ติดตั้งทับด้วยชุดใหม่ได้ทีละตัว

wp plugin install contact-form-7 --force

ลบปลั๊กอินและธีมที่ไม่ได้ใช้ทิ้งทั้งหมด รวมถึงธีมหรือปลั๊กอินเถื่อน (Nulled) ซึ่งเป็นทางเข้าที่พบบ่อยมาก

ขั้นตอนที่ 5: ค้นหาไฟล์ PHP ที่น่าสงสัย

โฟลเดอร์ uploads ไม่ควรมีไฟล์ PHP เลย

find wp-content/uploads -type f -name '*.php'

หาไฟล์ PHP ที่ถูกแก้ภายใน 7 วันที่ผ่านมา (ปรับตัวเลขตามช่วงที่สงสัย)

find . -type f -name '*.php' -mtime -7 -ls

ค้นรูปแบบโค้ดที่มักใช้ซ่อน Backdoor

grep -rlE 'eval\(base64_decode|eval\(gzinflate|str_rot13\(|assert\(\$_(POST|GET|REQUEST)' --include='*.php' .

ผลที่ได้ต้องใช้วิจารณญาณ ปลั๊กอินที่ถูกต้องบางตัวก็ใช้ base64_decode ตามปกติ ให้เปิดดูไฟล์ก่อนลบ และตรวจไฟล์ต่อไปนี้ด้วยตาเสมอ

• wp-config.php มีโค้ดแทรกด้านบนหรือล่างสุดหรือไม่
• .htaccess มีกฎ Redirect ไปโดเมนแปลกๆ โดยเฉพาะเงื่อนไขตาม HTTP_USER_AGENT หรือ HTTP_REFERER
• wp-content/mu-plugins/ ซึ่งทำงานอัตโนมัติและไม่แสดงในหน้าปลั๊กอินปกติ
• index.php ของธีมและ functions.php

ขั้นตอนที่ 6: ตรวจฐานข้อมูลและบัญชีผู้ใช้

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

ลบบัญชีผู้ดูแลที่ไม่รู้จัก โดยโอนเนื้อหาให้บัญชีที่ถูกต้อง

wp user delete 17 --reassign=1

ตรวจค่า URL ของเว็บว่าไม่ถูกเปลี่ยนไปโดเมนอื่น และค้นสคริปต์ที่ถูกฝังในเนื้อหา

wp option get siteurl
wp option get home
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 50;"

ถ้าตาราง wp_ ใช้ Prefix อื่น ให้เปลี่ยนตามค่า $table_prefix ใน wp-config.php

ขั้นตอนที่ 7: เปลี่ยนรหัสผ่านและกุญแจทั้งหมด

ทำจากเครื่องที่สะอาด เปลี่ยนทุกรายการต่อไปนี้ ไม่ใช่แค่รหัสผ่าน WordPress

1. รหัสผ่านผู้ใช้ WordPress ทุกคนที่มีสิทธิ์ Editor ขึ้นไป
2. รหัสผ่านแผงควบคุม, FTP/SFTP และ SSH
3. รหัสผ่านผู้ใช้ฐานข้อมูล แล้วแก้ค่า DB_PASSWORD ใน wp-config.php ให้ตรง
4. สร้าง Salt และ Key ใหม่ ซึ่งจะบังคับให้ทุกคนที่ล็อกอินค้างอยู่หลุดออก

wp config shuffle-salts

ตรวจ Cronjob ด้วย เพราะผู้บุกรุกมักตั้งให้ดาวน์โหลดโค้ดกลับมาใหม่ บน Cloud Server ใช้ crontab -l ของผู้ใช้เว็บ และดูใน /etc/cron.d/ ส่วนงาน Cron ภายใน WordPress ดูได้ด้วย wp cron event list

ขั้นตอนที่ 8: อัปเดตและปิดช่องโหว่

wp core update
wp plugin update --all
wp theme update --all

จากนั้นทำตาม เช็กลิสต์ความปลอดภัยเว็บไซต์ WordPress และเปิด Two-Factor Authentication สำหรับหน้า Login WordPress ถ้าเป็น Cloud Server ที่ดูแลเอง ให้ทบทวน เช็กลิสต์ความปลอดภัยหลังเปิด Linux Server ใหม่ ด้วย

ตรวจสอบผลลัพธ์

• รัน wp core verify-checksums อีกครั้ง ต้องได้ Success: WordPress installation verifies against checksums.
• เปิดเว็บจากมือถือด้วยเครือข่ายมือถือ และลองเข้าผ่านผลค้นหา Google เพราะมัลแวร์บางตัว Redirect เฉพาะผู้ที่มาจาก Search Engine
• ถ้า Google ติดคำเตือน ให้เข้า Google Search Console ที่รายงาน Security & Manual Actions > Security issues ตรวจรายการ แล้วกด Request Review พร้อมอธิบายสิ่งที่แก้ไข ถ้ายังไม่ได้ยืนยันเว็บ ดู ยืนยันความเป็นเจ้าของเว็บไซต์บน Google Search Console
• เฝ้าดู Access Log ต่ออีกหลายวัน โดยเฉพาะคำขอ POST ไปยังไฟล์ที่ไม่ควรมีคนเรียก

ปัญหาที่พบบ่อย

ลบไฟล์แล้ว ไม่กี่ชั่วโมงไฟล์กลับมาอีก

แปลว่ายังมี Backdoor หรือ Cronjob เหลืออยู่ ตรวจ mu-plugins, Cronjob ของระบบ และเว็บอื่นในบัญชีโฮสติ้งเดียวกัน เว็บที่อยู่ใต้ผู้ใช้เดียวกันเขียนไฟล์ของกันและกันได้ ต้องทำความสะอาดทุกเว็บพร้อมกัน

เว็บพังหลังติดตั้ง Core ใหม่

มักเป็นเพราะธีมหรือปลั๊กอินเก่าเกินไป ใช้ WP_DEBUG หาสาเหตุ ดู แก้ปัญหา "There has been a critical error" ใน WordPress ด้วย WP_DEBUG ถ้าเข้าหลังบ้านไม่ได้ ดู ปิดปลั๊กอิน WordPress เมื่อเข้าหลังบ้านไม่ได้

Redirect แปลกๆ เกิดเฉพาะบางคน

โค้ดอันตรายบางแบบทำงานเฉพาะผู้ที่ยังไม่ล็อกอิน หรือเฉพาะ User Agent ของมือถือ ผู้ดูแลที่ล็อกอินอยู่จะไม่เห็นอาการ ให้ทดสอบด้วยหน้าต่างไม่ระบุตัวตน และตรวจด้วย curl -sI -A "Mozilla/5.0 (iPhone)" https://example.com/ ว่ามี Location: ไปที่อื่นหรือไม่

ถ้าไม่แน่ใจว่าทำความสะอาดครบหรือยัง หรือต้องการความช่วยเหลือในการตรวจสอบ ติดต่อทีมงาน THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/