เจอไฟล์ .php ชื่อมั่วๆ ในโฟลเดอร์ uploads ที่ไม่ได้สร้างเอง? — web shell ประตูลับที่แฮกเกอร์ทิ้งไว้ (ลบไฟล์เดียวไม่จบ)

ถ้าคุณเปิด File Manager แล้วเจอไฟล์ .php ที่ไม่รู้จักอยู่ในโฟลเดอร์ uploads หรือโฟลเดอร์เก็บรูป ให้ถือว่าเป็น เหตุการณ์ที่ต้องตรวจสอบ จนกว่าจะยืนยันได้ว่าไฟล์นั้นมาจากระบบที่เชื่อถือได้

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

ไฟล์ที่เห็นคือหลักฐาน ไม่ใช่ขอบเขตทั้งหมดของเหตุการณ์

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

เจอ .php ใน uploads ต้องทำอะไรทันที

เป้าหมายช่วงแรกคือหยุดความเสียหายโดยไม่ทำลายเบาะแสที่ใช้หาต้นเหตุ:

1. อย่าเปิดรันไฟล์ — ไม่เรียก URL ของไฟล์และไม่ทดลองทำตามคำสั่งที่อยู่ข้างใน
2. บันทึกข้อมูลที่พบ — จด path ชื่อไฟล์ เวลาที่เห็น ขนาดไฟล์ และเก็บภาพหน้าจอ รวมถึง log ที่เกี่ยวข้องถ้าเข้าถึงได้
3. จำกัดการเข้าถึงเว็บตามความเหมาะสม — หากเว็บกำลังเปลี่ยนหน้า ส่งสแปม หรือสร้างไฟล์ใหม่ ควรเข้า maintenance หรือแยกเว็บออกชั่วคราวโดยผู้ดูแลระบบ
4. เก็บสำเนาก่อน cleanup — สำรองไฟล์ ฐานข้อมูล และ log เพื่อใช้ตรวจย้อนหลัง แยกจาก backup ที่จะใช้กู้ระบบ

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

Web shell คืออะไร และทำไมลบไฟล์เดียวไม่จบ

Web shell คือสคริปต์ฝั่งเซิร์ฟเวอร์ที่ถูกวางหรือแทรกไว้ในเว็บ เพื่อให้ผู้โจมตีกลับมาสั่งงานระบบผ่าน HTTP หรือ HTTPS ได้ มันจึงทำหน้าที่เหมือนประตูลับหลังจากช่องทางแรกถูกเจาะสำเร็จแล้ว

การลบไฟล์ที่เห็นอาจไม่จบด้วยเหตุผลสามข้อ:

• ในบัญชีอาจมี web shell มากกว่าหนึ่งไฟล์ หรือมีโค้ดแปลกแทรกในไฟล์จริง
• บัญชีผู้ดูแล งาน cron key หรือ credential ที่ถูกขโมยอาจยังเปิดทางให้กลับเข้ามา
• ช่องโหว่เดิม เช่นปลั๊กอินเก่า ฟอร์มอัปโหลด หรือสิทธิ์ไฟล์ที่กว้างเกินไปยังไม่ได้แก้

จึงพบรูปแบบ “ลบแล้วกลับมา” ได้บ่อย ไม่ใช่เพราะไฟล์ลบไม่ได้ แต่เพราะต้นเหตุหรือประตูลับอีกบานยังอยู่

แยกไฟล์น่าสงสัยจากไฟล์จริงอย่างไร

สัญญาณที่ควรตรวจต่อ ได้แก่ไฟล์สคริปต์ในโฟลเดอร์ที่ควรมีแต่สื่อ ชื่อสุ่มหรือเลียนแบบไฟล์ระบบ ไฟล์หลักของ CMS ถูกแก้โดยไม่มีการอัปเดต บัญชี admin แปลก งาน scheduled task ที่ไม่รู้จัก หรือไฟล์กลับมาหลังลบ

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

• เทียบกับ known-good — เปรียบเทียบ core ปลั๊กอิน และธีมกับแพ็กเกจต้นฉบับที่เชื่อถือได้
• ตรวจทั้งบัญชี — สแกนไฟล์ที่เพิ่มใหม่ ไฟล์ที่ถูกแก้ และโค้ดที่แทรกในไฟล์เดิม ไม่หยุดที่โฟลเดอร์ที่บังเอิญเจอ
• ดู log ร่วมกัน — เชื่อมเวลาการอัปโหลด การ login การแก้ไฟล์ และ request ผิดปกติเพื่อหาช่องทางเข้ามา
• ตรวจบัญชีและกลไกคงอยู่ — ดูผู้ใช้ admin key งาน cron และการตั้งค่าที่อาจถูกเพิ่มโดยไม่ได้รับอนุญาต

แนวทางร่วมของ NSA และ ASD แนะนำการเทียบระบบจริงกับ known-good และใช้การตรวจหลายชั้นร่วมกัน เพราะ web shell เปลี่ยนชื่อและรูปแบบได้ง่าย การหาเฉพาะ signature หรือเพ่งดูทีละไฟล์จึงพลาดได้

ป้องกัน uploads ไม่ให้กลายเป็นจุดรันโค้ด

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

• อนุญาตเฉพาะชนิดไฟล์ที่ธุรกิจจำเป็นต้องใช้ และตรวจทั้งนามสกุล MIME type และเนื้อหาไฟล์
• เปลี่ยนชื่อไฟล์เป็นชื่อที่ระบบสร้างเอง ไม่ใช้ชื่อหรือ path ที่ผู้ใช้อัปโหลดส่งมาโดยตรง
• เก็บไฟล์นอก webroot หรือคนละระบบเมื่อทำได้ หากต้องอยู่ใน webroot ให้ปิดความสามารถในการรันสคริปต์
• ใช้สิทธิ์แบบ least privilege ให้บัญชีเว็บเขียนได้เฉพาะตำแหน่งที่จำเป็น
• จำกัดขนาดไฟล์ ตรวจสิทธิ์ผู้ใช้ ป้องกัน CSRF และสแกนไฟล์ก่อนนำไปประมวลผลเมื่อระบบรองรับ
• อัปเดต CMS ปลั๊กอิน ธีม และไลบรารีที่เกี่ยวกับการอัปโหลดอย่างต่อเนื่อง

วิธีปิดการรัน PHP แตกต่างกันระหว่าง Apache, Nginx, LiteSpeed และโครงสร้างโฮสติ้ง จึงควรให้ผู้ดูแลตรวจ config ก่อนแก้เพื่อไม่ให้เว็บหรือไฟล์ดาวน์โหลดใช้งานผิดปกติ

6 ขั้นรับมือให้จบทั้งไฟล์และต้นเหตุ

1. ควบคุมเหตุและเก็บหลักฐาน — จำกัดการเข้าถึงตามความรุนแรง เก็บไฟล์ ฐานข้อมูล และ log ก่อนเปลี่ยนแปลง
2. หาขอบเขตทั้งหมด — ตรวจทั้งบัญชี เว็บไซต์อื่นที่ใช้ user เดียวกัน ไฟล์ที่ถูกแก้ บัญชี admin key และงาน cron
3. กำจัดด้วยแหล่งที่เชื่อถือได้ — แทน core ปลั๊กอิน และธีมจากต้นฉบับสะอาด หรือ restore จาก backup ก่อนวันถูกเจาะ
4. อุดช่องทางเข้ามา — อัปเดตหรือลบส่วนเสริมที่มีปัญหา แก้ฟอร์มอัปโหลด ปรับสิทธิ์ และหมุนรหัสผ่าน token กับ key ที่เกี่ยวข้อง
5. ป้องกันการกลับมา — ปิดการรันสคริปต์ในพื้นที่ uploads ใช้ allowlist และเปิดชั้นป้องกันอย่าง WAF หรือ file integrity monitoring ตามความเหมาะสม
6. ตรวจยืนยันและเฝ้าระวัง — ทดสอบเว็บ ตรวจ log การเปลี่ยนไฟล์ บัญชี และพฤติกรรมส่งออกต่อเนื่อง พร้อมยืนยันว่า backup ชุดใหม่สะอาดและกู้ได้

การ restore โดยไม่อุดช่องเดิมมีโอกาสโดนซ้ำ ส่วนการลบไฟล์โดยไม่ตรวจขอบเขตก็มีโอกาสเหลือ backdoor ทั้งสองอย่างจึงต้องทำเป็นกระบวนการเดียวกัน

ลบไฟล์เดียวไม่พอ — ผู้ดูแลควรช่วยอะไร

ถ้าผู้ให้บริการบอกว่า “มี malware scan” ให้ถามต่อว่าระบบและทีมช่วยได้ถึงระดับไหน:

1. สแกนเฉพาะไฟล์ที่แจ้ง หรือไล่ทั้งบัญชีรวมไฟล์ที่ถูกแทรกโค้ด?
2. เทียบไฟล์ระบบกับ known-good และตรวจ log เพื่อหาต้นเหตุหรือไม่?
3. ช่วยเลือก backup ที่สะอาดและ restore ให้ครบทั้งไฟล์กับฐานข้อมูลได้ไหม?
4. ช่วยปิดการรันสคริปต์ใน uploads อุดช่องโหว่ และหมุน credential ที่เกี่ยวข้องหรือไม่?
5. หลัง cleanup มีการตรวจซ้ำหรือเฝ้าระวังการกลับมาหรือเปล่า?

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

ถ้าคุณเจอไฟล์ .php แปลกในเว็บ ส่งชื่อไฟล์ path และเวลาที่พบมาทางไลน์ได้ครับ อย่าเปิดรันไฟล์นั้น เดี๋ยวผมช่วยประเมินว่าควรจำกัดระบบตรงไหนและต้องตรวจอะไรต่อ โดยไม่หยุดแค่การลบไฟล์เดียวครับ