𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁

คุณรันการสแกนมัลแวร์ คุณเปลี่ยนไฟล์หลัก (core files) คุณอัปเดตปลั๊กอินและเปลี่ยนรหัสผ่าน เว็บไซต์ดูเหมือนจะสะอาดแล้ว

สองวันต่อมา ลูกค้าโทรมา บัญชีผู้ดูแลระบบ (admin) ใหม่กลับมาอีกครั้ง ผู้เข้าชมเว็บไซต์ถูกเปลี่ยนเส้นทางไปยังเว็บไซต์ที่เป็นอันตราย

นี่คือฝันร้ายของ "Persistence" (การฝังตัวเพื่อคงอยู่)

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

เมื่อเร็วๆ นี้ ผมได้จัดการกับเคสที่ความพยายามในการล้างมัลแวร์ล้มเหลวถึงสามครั้ง อาการที่พบนั้นเฉพาะเจาะจงมาก:

• Ghost Admins: บัญชีใหม่ที่มีชื่อสุ่มปรากฏขึ้นทุกๆ 48 ชั่วโมง • Conditional Redirects: เฉพาะผู้เข้าชมใหม่ที่มาจาก Search Engine เท่านั้นที่เห็นเว็บไซต์อันตราย ส่วนนักพัฒนาไม่เห็นอะไรเลย

ทีมงานได้เขียนทับ WordPress core และอัปเดตปลั๊กอินไปแล้ว เครื่องสแกนไม่พบอะไรเลย แต่มัลแวร์กลับฟื้นคืนชีพขึ้นมาใหม่เหมือนไฮดรา (Hydra)

ผู้โจมตีมีกลไกการคงอยู่ (persistence mechanism) ในฐานข้อมูลหรือใน cron job เครื่องสแกนอัตโนมัติตรวจไม่พบเพราะโค้ดนั้นถูกเขียนขึ้นมาแบบเฉพาะเจาะจง (custom code)

ผมใช้ Command Line เพื่อค้นหาความจริง

ขั้นแรก ผมตรวจสอบไฟล์หลักโดยใช้ checksum: wp core verify-checksums

ไฟล์หลักสะอาดดี Backdoor ซ่อนอยู่ใน wp-content หรือในฐานข้อมูล

ผมค้นหาไฟล์ที่มีการแก้ไขในช่วง 7 วันที่ผ่านมา: find . -type f -mtime -7 -name "*.php"

จากนั้น ผมค้นหาฟังก์ชันที่น่าสงสัย เช่น eval() หรือ base64_decode(): grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('

ผมพบไฟล์ที่ถูกฝังไว้ในปลั๊กอินพรีเมียมที่ล้าสมัย แต่การลบปลั๊กอินออกก็ยังไม่สามารถหยุดการติดเชื้อได้

ผู้โจมตีทิ้งตัวกระตุ้น (trigger) ไว้ในตาราง wp_options ภายใต้ตัวเลือก cron ทุกครั้งที่ WordPress cron ทำงาน มันจะไปดึง payload ใหม่มา ทำให้ไฟล์หลักถูกติดเชื้อซ้ำอีกครั้งเพียงไม่กี่นาทีหลังจากที่เพิ่งล้างไป

ในการแก้ไขเรื่องนี้ คุณต้องปฏิบัติตามลำดับขั้นตอนอย่างเคร่งครัด:

  1. การล้างฐานข้อมูล (Database Scrubbing)
  1. การล้างระบบไฟล์ (File System Purge)
  1. การเปลี่ยนข้อมูลประจำตัว (Credential Rotation)

นอกจากนี้ ผมยังได้ติดตั้งมาตรการป้องกัน (guardrails) สามอย่างเพื่อไม่ให้เกิดเหตุการณ์ซ้ำรอย:

• การป้องกันที่ Edge: ฉันใช้ Cloudflare WAF เพื่อบล็อกคำขอ POST ที่น่าสงสัยไปยังไดเรกทอรีที่สำคัญ • การกำหนดสิทธิ์ไฟล์: ฉันล็อกโครงสร้างไดเรกทอรี โดยกำหนดให้ไดเรกทอรีเป็น 755 และไฟล์เป็น 644 และตั้งค่า wp-config.php ให้เป็นแบบ read-only • การปิดการแก้ไข: ฉันเพิ่ม DISALLOW_FILE_EDIT และ DISALLOW_FILE_MODS ลงใน wp-config.php เพื่อป้องกันไม่ให้ใครก็ตามสามารถแก้ไขโค้ดผ่านแดชบอร์ดได้

อย่าเชื่อเครื่องหมายถูกสีเขียวจากปลั๊กอิน ให้สันนิษฐานไว้ก่อนว่าการเจาะระบบได้เกิดขึ้นแล้ว จงปกป้องเว็บไซต์ของคุณจากภายในสู่ภายนอก

ที่มา: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm