เว็บโดนแฮก เด้งไปเว็บพนัน Google ขึ้น 'เว็บนี้อาจเป็นอันตราย' — สัญญาณ วิธีกู้ตามลำดับทางการ และทำไมมันกลับมาอีก

"พี่อ๊อด ช่วยด้วย เว็บผมเด้งไปเว็บพนัน..."

"พี่อ๊อด ขอโทษที่ทักดึกนะครับ... เว็บลูกค้าผมพังแล้ว เปิดมาเด้งไปเว็บพนันเลย ลูกค้าเพิ่งโทรมาด่า บอกว่ากดเข้าเว็บร้านตัวเองแล้ว Google ขึ้นแดงทั้งหน้าว่า 'เว็บนี้อาจเป็นอันตราย' ตอนนี้ของขายไม่ได้เลยครับพี่ ผมจะทำยังไงดี"

ผมเชื่อว่าถ้าคุณเป็นคนทำเว็บ คุณเคยเจอ หรือกลัวจะเจอ ข้อความประมาณนี้มาก่อน

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

ผมเขียนโค้ด ทำเว็บมา 20 ปี และทำโฮสติ้งมา 11 ปี ดูแลเว็บลูกค้ารวมกันกว่า 5,000 เว็บ และ VPS อีกราว 600 เครื่อง — เคสเว็บโดนแฮก เด้งเว็บพนัน ฝังสคริปต์ ผมเจอมาเยอะมาก บทความนี้ผมจะเล่าให้ฟังแบบเพื่อนคุยกับเพื่อน ว่า สัญญาณว่าโดนแฮกมีอะไรบ้าง เขาเข้ามาทางไหน กู้กลับมายังไงให้ถูกขั้นตอน (และที่สำคัญ — ลำดับเดียวกับที่เอกสารทางการเขาแนะนำ) ทำไมบางเว็บกู้แล้วโดนซ้ำ และจะปิดประตูยังไงไม่ให้กลับมาอีก

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

ขอเปิดด้วยประโยคที่ผมอยากให้จำไปทั้งบทความเลยครับ:

เว็บโดนแฮกไม่ได้แพ้เพราะ "กู้ไม่เป็น" — ส่วนใหญ่แพ้เพราะ "กู้ผิดลำดับ" คือรีบลบของที่เห็น แต่ลืมปิดประตูหลัง แล้วลืมว่าต้องล้างให้สะอาดก่อนค่อยไปขอ Google ปลดแบน

ส่วนที่ 1 — สัญญาณว่า "เว็บคุณโดนแฮกแล้ว" (เช็กด่วน)

ปัญหาของมัลแวร์สมัยนี้คือมัน "เนียน" — บางทีหน้าเว็บดูปกติเป๊ะตอนคุณเปิดเอง แต่คนอื่นเปิดเจอเว็บพนัน เพราะมันถูกตั้งให้แสดงเฉพาะกับคนที่มาจาก Google หรือเปิดด้วยมือถือ เครื่องคุณที่ล็อกอิน admin อยู่เลยไม่เห็นอะไรผิด นี่แหละที่ทำให้หลายคนรู้ตัวช้า ลองไล่เช็กสัญญาณเหล่านี้:

• เปิดเว็บแล้ว redirect ไปเว็บแปลก — เด้งไปเว็บพนัน เว็บหลอกลวง เว็บขายยา โดยเฉพาะเวลากดมาจากผลค้นหา Google หรือเปิดบนมือถือ บางเคสเด้งเฉพาะตอนเปิดครั้งแรก (ใช้คุกกี้จำว่าเด้งไปแล้ว) ถ้าเปิดเองปกติแต่ลูกค้าเจอ ให้ให้ตรวจเรื่อง conditional redirect / cloaking
• Google ขึ้น "Deceptive site ahead" / "เว็บนี้อาจเป็นอันตราย" หน้าจอแดงทั้งหน้า — แปลว่า Google Safe Browsing ตรวจเจอเนื้อหาอันตรายแล้ว เว็บคุณติด blacklist หน้าแดงและ Search Console ในกรณีนี้เกี่ยวข้องกับ เว็บขึ้นหน้าแดง Deceptive site ahead
• โดนโฮสต์ระงับบัญชี (suspend) เพราะตรวจเจอมัลแวร์ หรือเซิร์ฟเวอร์ส่งสแปมออกจำนวนมาก
• ไฟล์ .php แปลกปลอมโผล่มา ในชื่อมั่วๆ เช่น ไฟล์ตัวอักษรสุ่มยาวๆ หรือไฟล์ที่ชื่อเลียนแบบไฟล์จริง (เช่นมีไฟล์หน้าตาคล้าย core แต่อยู่ผิดที่)
• มี admin user โผล่ขึ้นมาเองใน WordPress ที่คุณไม่ได้สร้าง — สัญญาณชัดว่ามีคนอื่นเข้าถึงระบบได้ และมักเกี่ยวกับ backdoor/admin ปลอม
• Google Search Console เด้งเตือน Security Issues หรือผลค้นหาเว็บคุณมี title/description ภาษาแปลกๆ เรื่องพนัน/ยา (อาการที่เรียกกันว่า Japanese keyword hack หรือ pharma hack)
• traffic / โหลดเซิร์ฟเวอร์พุ่งผิดปกติ ทั้งที่ไม่ได้ทำแคมเปญอะไร — เพราะเว็บถูกใช้เป็นฐานยิงสแปมหรือโจมตีคนอื่น
• หน้าเว็บมีลิงก์แปลกแฝงอยู่ มองด้วยตาไม่เห็น (ซ่อนด้วย CSS) แต่ Google เห็น — ลิงก์พนัน ลิงก์ขายยา
• อีเมลของโดเมนถูกใช้ส่งสแปม จนโดน blacklist อีเมลส่งไม่ออก ลูกค้าไม่ได้รับเมลจากเว็บ

ถ้าโดนสักข้อ ให้ถือว่า "น่าจะโดนแล้ว" ไว้ก่อน อย่าเพิ่งคิดว่าเป็นบั๊กธรรมดา

🔎 ไม่ใช่แค่ผมเดาเอง: อาการชุดนี้ — redirect แปลกๆ, Google ขึ้นเตือน, admin user โผล่เอง, ไฟล์แปลกปลอม — คือ "ตัวบ่งชี้ว่าโดนเจาะ" (Indicators of Compromise) ชุดเดียวกับที่เอกสารทางการของ WordPress.org และคู่มือล้างเว็บของผู้เชี่ยวชาญด้านความปลอดภัยเขาไล่เป็นเช็กลิสต์ให้ดูเหมือนกัน เพราะฉะนั้นถ้าคุณเจออาการพวกนี้ มันไม่ใช่ "เรื่องบังเอิญ" — มันคือ pattern ที่วงการเห็นซ้ำๆ จนจดเป็นมาตรฐานไว้แล้ว

ส่วนที่ 2 — เขาเข้ามาทางไหน?

ผมอยากให้คุณเข้าใจตรงนี้ก่อน เพราะถ้าไม่รู้ว่าเขาเข้ามาทางไหน คุณจะกู้ยังไงมันก็กลับมา นี่คือสองมุมที่ทำให้คนทำเว็บโดนซ้ำแล้วซ้ำเล่า:

🔴 (สิ่งที่พลาด) — ความพลาดที่เจอบ่อยสุด

• ไม่อัปเดต WordPress core / ปลั๊กอิน / ธีม — นี่คือช่องทางอันดับหนึ่งจริงๆ ปลั๊กอินเก่าที่มีช่องโหว่ที่ประกาศต่อสาธารณะแล้ว คือป้ายเชิญบอทเข้ามาสแกนทั้งอินเทอร์เน็ต พอเจอเวอร์ชันที่มีช่องโหว่ มันยิงอัตโนมัติ
• รหัสผ่านอ่อน หรือใช้รหัสซ้ำกับที่อื่น — admin / 123456 / ชื่อร้าน ยังมีให้เห็นเยอะ และการใช้รหัสเดียวกับเว็บอื่นที่เคยข้อมูลรั่ว ทำให้โดน credential stuffing (เอารหัสที่รั่วมาลองยิง)
• ไม่เปิด 2FA (ยืนยันตัวตนสองชั้น) — มีแค่รหัสผ่านชั้นเดียว พอรหัสหลุดก็จบ ดูแนวทางเปิดให้ทีมได้ที่ เปิด 2FA ให้ทั้งทีม
• ใช้ nulled plugin / ธีมเถื่อน — ปลั๊กอิน/ธีมพรีเมียมที่โหลดฟรีมาจากเว็บเถื่อน ส่วนใหญ่มักฝัง backdoor มาให้แล้วเรียบร้อยตั้งแต่วันแรก คุณติดตั้งเอง = เปิดประตูให้เขาเอง ผมแยกเรื่องนี้ไว้ที่ ปลั๊กอิน/ธีมเถื่อน
• file permission หลวมเกินไป เช่นตั้งโฟลเดอร์/ไฟล์เป็น 777 (ใครก็เขียนได้) — เปิดทางให้ฝังไฟล์ได้ง่าย อ่านพื้นฐานที่ควรตั้งได้ใน File Permission 644/755 & Ownership
• เครื่อง dev ของคุณเองติดมัลแวร์ ที่ขโมยรหัส FTP/SSH ที่เซฟไว้ใน FileZilla หรือ editor — แฮกเกอร์ไม่ต้องเจาะเว็บเลย แค่ขโมยกุญแจจากเครื่องคุณ เคสนี้โยงกับ มัลแวร์ขโมยรหัสจากเครื่อง dev

🟠 (สิ่งที่ขาด) — สิ่งที่ "ไม่มี" เลยไม่รู้ตัวและกู้ไม่ได้

• ไม่มีระบบเฝ้าระวัง (monitoring) / WAF (Web Application Firewall) — เลยไม่มีใครบอกคุณว่าโดน จนลูกค้าโทรมาด่า ถ้ายังไม่ชัดว่า WAF กันอะไรได้บ้าง ประเด็นนี้เกี่ยวข้องกับ WAF คืออะไร
• ไม่มี backup ที่ใช้กู้ได้จริง — อันนี้เจ็บสุด เพราะต่อให้รู้ว่าโดน แต่ถ้าไม่มีจุดที่สะอาดให้ย้อนกลับไป งานกู้จะกลายเป็นนั่งไล่ลบมัลแวร์ทีละไฟล์เป็นวันๆ และมักไม่หมด ดูภาพรวมที่ ไม่มี Backup = หายนะ

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

ส่วนที่ 3 — ขั้นกู้เว็บโดนแฮก (ลำดับเดียวกับเอกสารทางการ อย่าข้าม)

เวลาแพนิค คนมักทำพลาดข้อเดียวกัน คือ "รีบลบ" — เห็นไฟล์แปลกก็ลบ เห็น user แปลกก็ลบ สุดท้ายลบจนเว็บพังเพิ่ม และลบหลักฐานที่จะบอกว่าเขาเข้ามาทางไหนทิ้งไปด้วย

ผมขอบอกตรงนี้ก่อนเลยว่า — 6 สเต็ปที่ผมกำลังจะเล่า ไม่ใช่ลำดับที่ผมคิดขึ้นเอง มันคือลำดับเดียวกับที่เอกสารทางการของ WordPress (หน้า "My site was hacked") และคู่มือล้างเว็บของทีมความปลอดภัยระดับโลกเขาวางไว้เป๊ะ คือ: ตั้งสติ → เก็บหลักฐาน (document) → สแกน → กู้จาก backup สะอาด → หา/ลบ backdoor → reset สิทธิ์เข้าถึงทุกชั้น → อัปเดต → ตรวจจุดที่มักซ่อน ที่ผมย้ำเรื่อง "ลำดับ" เพราะถ้าสลับลำดับ (เช่นไปขอ Google ปลดแบนก่อนล้าง หรือเปลี่ยนรหัสก่อนหา backdoor) มันจะวนกลับมาโดนซ้ำ ทำตามสเต็ปนี้แทน:

สเต็ป 1 — ตั้งสติ และสำรองสภาพปัจจุบันไว้ก่อน (document) อย่าเพิ่งลบอะไรทั้งนั้น ก๊อปไฟล์ทั้งหมด + ฐานข้อมูลในสภาพ "ที่โดนแล้ว" เก็บไว้ชุดหนึ่งก่อน เพราะนี่คือหลักฐานที่จะบอกว่ามัลแวร์อยู่ตรงไหน ไฟล์ไหนถูกแก้ล่าสุด เขาเข้ามาทางไหน ถ้าลบทิ้งหมดคุณจะตามต้นตอไม่เจอ และเสี่ยงโดนซ้ำ — ข้อนี้เอกสารทางการเขาก็ขึ้นเป็นสเต็ปแรกเหมือนกัน ("document everything ก่อนแตะ")

สเต็ป 2 — เอาเว็บเข้าโหมด maintenance / ออฟไลน์ชั่วคราว ปิดเว็บไม่ให้คนนอกเข้าชั่วคราว (maintenance mode หรือจำกัดด้วย IP) เพื่อสองอย่าง: ปกป้องคนเข้าเว็บไม่ให้โดนมัลแวร์ต่อ และหยุดไม่ให้เว็บยิงสแปม/redirect ออกไปจน Google ลงโทษหนักขึ้น

สเต็ป 3 — สแกนหามัลแวร์ / webshell สแกนทั้งไฟล์และฐานข้อมูล หาไฟล์ที่ถูกฝังโค้ดแปลกปลอม ไฟล์ webshell (ไฟล์ที่เปิดให้สั่งงานเซิร์ฟเวอร์จากภายนอก) โค้ดที่ถูกเข้ารหัสซ่อนไว้ และโค้ดแปลกใน wp-config.php, index.php, functions.php ของธีม จุดนี้ถ้ามีทีมเซิร์ฟเวอร์ที่สแกนระดับ server ให้ จะเห็นภาพรวมทั้งบัญชีเร็วกว่าไล่เองทีละไฟล์มาก ถ้าอยากแยกว่าสแกนระดับเซิร์ฟเวอร์ต่างจากปลั๊กอินยังไง ประเด็นนี้เกี่ยวข้องกับ Malware scan ระดับเซิร์ฟเวอร์

สเต็ป 4 — กู้คืนจาก backup ชุดที่สะอาด (ก่อนวันโดนแฮก) นี่คือทางที่เร็วและสะอาดที่สุด — ย้อนเว็บกลับไปจุดที่ยังไม่โดน แทนที่จะนั่งแกะมัลแวร์ทีละจุด (ซึ่งพลาดง่าย) แต่หัวใจคือต้องเลือก backup ชุดที่ "ก่อน" เว็บโดนจริงๆ ไม่งั้นคุณจะกู้เอามัลแวร์กลับมาด้วย เพราะแฮกเกอร์มักฝัง backdoor เงียบๆ ไว้หลายวันก่อนจะลงมือ ถ้าคุณไม่รู้ว่าโดนตั้งแต่เมื่อไหร่ การมี backup ย้อนหลังหลายวัน/หลายเวอร์ชันจะช่วยชีวิตมาก — เรื่อง backup ผมเขียนแยกไว้ละเอียดที่ ไม่มี Backup = หายนะ และเรื่อง "เก็บ backup ที่เดียวกับเว็บทำไมไม่พอ" ที่ Backup ในโฮสต์เดิมก็พอ? อ่านต่อได้

สเต็ป 5 — อัปเดตทุกอย่าง + reset สิทธิ์เข้าถึงทุกชั้น หลังกู้แล้วอย่าเพิ่งวางใจ ทำชุดนี้ให้ครบ (เอกสารทางการเรียกขั้นนี้ว่า "reset access at all levels"):

• อัปเดต WordPress core, ปลั๊กอิน, ธีม ให้เป็นเวอร์ชันล่าสุดทั้งหมด ลบปลั๊กอิน/ธีมที่ไม่ใช้ออก (โดยเฉพาะ nulled ทิ้งให้หมด)
• เปลี่ยนรหัสผ่าน ทุกชั้น: WordPress admin, ฐานข้อมูล (DB), FTP/SFTP, SSH, cPanel/DirectAdmin และถ้ายังใช้ FTP ธรรมดาอยู่ให้ดูเรื่อง เปลี่ยนจาก FTP เป็น SFTP/FTPS
• เปลี่ยน WordPress Secret Keys (salt) ใน wp-config.php — เพื่อเตะทุกคนที่ยังล็อกอินค้างอยู่ออก (รวมถึงแฮกเกอร์ที่ขโมย session ไว้) สร้างชุดใหม่ได้จากเครื่องมือ salt key อย่างเป็นทางการของ WordPress
• ลบ admin user แปลกปลอมที่ไม่ใช่ของคุณออก

สเต็ป 6 — ตรวจจุดที่มัลแวร์ชอบซ่อน ไล่เช็กให้ครบ: .htaccess (มักถูกแก้ให้ redirect หรือบล็อกการเข้าถึง), wp-config.php, โฟลเดอร์ wp-content/uploads (โฟลเดอร์นี้ไม่ควรมีไฟล์ .php รันได้เลย ถ้ามี = น่าสงสัยทันที), งาน cron ที่ตั้งไว้แปลกๆ และเรียงไฟล์ตาม "วันที่แก้ไขล่าสุด" เพื่อดูว่าช่วงเวลาที่โดนนั้นมีไฟล์ไหนถูกแตะบ้าง — เทคนิค "เรียงตามวันที่แก้ล่าสุด" นี่แหละที่คู่มือล้างเว็บมืออาชีพเขาใช้เป็นด่านแรกในการล่าไฟล์ที่ถูกฝัง

ส่วนที่ 4 — ทำไมกู้แล้ว "แฮกกลับมาอีก"? (รู้จักหน้าตาของ backdoor)

นี่คือคำถามที่ผมโดนถามบ่อยที่สุด และเป็นจุดที่คนทำเว็บหลายคนท้อ — "พี่ ผมล้างไปแล้วนะ ทำไมอาทิตย์เดียวมันกลับมาอีก"

คำตอบสั้นๆ คือ: คุณลบของที่อยู่หน้าบ้าน แต่ประตูหลังยังเปิดอยู่

มัลแวร์ที่ฝังเว็บมักไม่ได้มีแค่ตัว redirect หรือสคริปต์พนันที่คุณเห็น แต่มันแอบฝัง backdoor / webshell กระจายไว้หลายจุด — บางทีฝังไว้ในปลั๊กอินที่ดูปกติ ฝังในไฟล์ uploads ฝังเป็นโค้ดสั้นๆ ในธีม หรือซ่อนในฐานข้อมูล backdoor พวกนี้คือ "ประตูหลัง" ที่ให้เขากลับเข้ามาได้ตลอดแม้คุณจะเปลี่ยนรหัสแล้ว

ปัญหาคือ backdoor มันไม่ได้เขียนป้ายว่า "ฉันคือมัลแวร์นะ" — แต่มันมี ลายเซ็นทางโค้ดที่ผู้เชี่ยวชาญใช้ตามรอย ลองรู้จักหน้าตาของมันไว้ จะได้ไม่หลุดตอนไล่ดูเอง:

🔬 ลายเซ็น backdoor ที่เจอบ่อย (รู้ไว้จะตามเจอเร็วขึ้น):

• โค้ดที่ถูก เข้ารหัส/บีบให้อ่านไม่ออก แล้วค่อยถอดตอนรัน — มักเห็นฟังก์ชันอย่าง base64_decode, eval, gzinflate, str_rot13, exec, system, assert ต่อกันยาวๆ เป็นพรืด นี่คือสัญญาณคลาสสิกของ webshell/backdoor ที่คู่มือล้างเว็บมืออาชีพเขายกมาเป็นตัวอย่างแรกๆ
• ไฟล์ .php ที่ไป โผล่ในโฟลเดอร์ที่ไม่ควรมีโค้ดรันได้ โดยเฉพาะ wp-content/uploads (โฟลเดอร์รูป) — ปกติมีแต่ไฟล์รูป/ไฟล์แนบ ไม่ควรมี .php เลย ถ้าเจอ = น่าสงสัยทันที
• โค้ดสั้นๆ แปลกปลอมแทรกหัวไฟล์ index.php / functions.php ของธีม / wp-config.php ที่ดู "ไม่เข้าพวก" กับโค้ดรอบๆ เป้าหมายของ callout นี้คือให้คุณ "จำหน้า" ไว้ตอนไล่ดูเว็บตัวเอง ไม่ใช่สอนเขียนมัน

และมัลแวร์สาย redirect เว็บพนัน/ภาษาแปลกๆ ที่คนทำเว็บไทยเจอบ่อย มันมักมาเป็น "ตระกูล" ที่ซ้ำๆ กัน — เช่นสายที่ชอบฝังตัวกระจายทั้ง core/ธีม/ปลั๊กอินแล้วสร้างไฟล์ใหม่เองเรื่อยๆ (กลุ่มที่คนไทยเรียกกันติดปากว่าสาย wp-vcd และพวก Japanese-keyword/pharma hack) จุดร่วมของมันคือ ฝังหลายจุดเพื่อให้ลบไม่หมด — คุณลบไฟล์หนึ่ง อีกไฟล์ที่ซ่อนอยู่ก็สร้างมันกลับมาใหม่ นี่แหละเหตุผลที่ "ลบทีละไฟล์ตามที่เห็น" มักไม่จบ

เพราะฉะนั้น การกู้ที่ "จบจริง" ต้องทำสองอย่างคู่กันเสมอ:

1. กวาด backdoor ให้หมด — ไม่ใช่แค่ลบหน้าที่เด้งเว็บพนัน แต่ต้องหาประตูหลังทุกบานให้เจอและปิด (ขั้นนี้แหละที่การกู้จาก backup สะอาดช่วยได้มาก เพราะย้อนกลับไปก่อนที่ backdoor จะถูกฝัง)
2. อุดช่องเดิมที่เขาใช้เข้ามา — ถ้าเขาเข้ามาทางปลั๊กอินเวอร์ชันเก่า แล้วคุณกู้เว็บแต่ยังใช้ปลั๊กอินตัวเดิมเวอร์ชันเดิม เขาก็เดินเข้าประตูเดิมได้อีก เรื่องปลั๊กอินเก่า/เลิกพัฒนาประเด็นนี้เกี่ยวข้องกับ ปลั๊กอิน/ธีมที่เลิกพัฒนาแล้ว

ลบหน้าบ้านอย่างเดียว = เดี๋ยวกลับมา ปิดประตูหลัง + อุดช่องที่เขาเข้า = ถึงจะจบ

ส่วนที่ 5 — ปลด Google "เว็บนี้อาจเป็นอันตราย" ต้องล้างให้สะอาด "ก่อน" ค่อยขอ review

มีสเต็ปนึงที่คนแพนิคแล้วชอบทำสลับ จนเรื่องบานปลาย คือเรื่อง การขอให้ Google ปลดป้ายแดง "เว็บนี้อาจเป็นอันตราย" ผมขอแยกออกมาเป็นหัวข้อเลย เพราะพลาดตรงนี้แล้วเจ็บซ้ำสอง

ลำดับที่ถูก ตามที่ Google เขาบอกไว้ในเอกสารเรื่องเว็บโดนแฮก/deceptive site คือแบบนี้ (ผมขยายแยกไว้ที่ เว็บขึ้นหน้าแดง Deceptive site ahead):

1. ล้างเว็บให้สะอาดจริงก่อน — กวาดมัลแวร์ + ปิด backdoor + อุดช่องให้ครบตามสเต็ปข้างบน
2. แล้วค่อยเข้าไป "ขอรีวิวความปลอดภัย" (request a security review) ใน Google Search Console ตรงรายงาน Security Issues
3. รอ — การรีวิวใช้เวลา (มักหลายวัน) Google ต้องกลับมาสแกนเว็บคุณซ้ำเพื่อยืนยันว่าสะอาดจริงถึงจะปลดป้ายแดง/ปลด blacklist ให้

จุดที่คนพลาดคือ รีบกดขอ review ทั้งที่ยังล้างไม่สะอาด — พอ Google กลับมาสแกนแล้วยังเจอมัลแวร์/redirect อยู่ คำขอจะถูกตีกลับ และการส่งซ้ำๆ ทั้งที่ยังไม่สะอาดจะทำให้รอบรีวิวรอบถัดไป "ช้าลง" ไม่ใช่เร็วขึ้น เท่ากับเว็บคุณติดป้ายแดงนานขึ้นไปอีก ระหว่างนั้นของก็ขายไม่ได้ ลูกค้าก็เห็นหน้าแดงทุกคนที่กดเข้ามา

💡 พูดง่ายๆ: อย่าใช้ปุ่มขอ review เป็น "ปุ่มลองดู" ขอเมื่อมั่นใจว่าล้างจริงเท่านั้น เพราะแต่ละครั้งที่โดนตีกลับ คุณเสียทั้งเวลาและเครดิตกับ Google · นี่คือเหตุผลที่ "ลำดับ" สำคัญกว่า "ความเร็ว" — ล้างให้จบก่อน ค่อยไปเคาะประตู Google

ส่วนเรื่องระงับบัญชี (suspend) จากฝั่งโฮสต์ก็หลักการเดียวกัน — อย่าเพิ่งรีบขอเปิดเว็บกลับมาเฉยๆ ทั้งที่ยังไม่ล้าง เพราะพอมัลแวร์ยังอยู่ ระบบสแกนของโฮสต์ก็จะ suspend ซ้ำอีกรอบ วนไม่จบ

ส่วนที่ 6 — ป้องกันระยะยาว (Hardening)

กู้เสร็จแล้วอย่าหยุดแค่นั้น มาทำให้เว็บแข็งขึ้นกัน หลักการคือ "ลดประตูให้เหลือน้อยที่สุด และเฝ้าทุกบานที่เหลือ" — และอีกหลายข้อข้างล่างนี้คือสิ่งที่เอกสาร Hardening WordPress อย่างเป็นทางการเขาแนะนำตรงกัน ถ้าต้องการเช็กลิสต์ฝั่งป้องกันเต็มๆ อ่าน ป้องกันเว็บก่อนโดนแฮก

• อัปเดตสม่ำเสมอ — core / ปลั๊กอิน / ธีม ตั้งรอบเช็กเป็นกิจวัตร นี่คือเกราะชั้นที่ได้ผลที่สุดและเสียแรงน้อยที่สุด
• รหัสแข็ง + เปิด 2FA ทุกบัญชี admin และใช้ password manager เลิกใช้รหัสซ้ำ
• ตั้ง file permission ให้ถูก — โดยทั่วไปไฟล์ 644, โฟลเดอร์ 755, wp-config.php เข้มกว่านั้นได้ (เช่น 640) อย่าใช้ 777 เด็ดขาด (ค่า 644/755 นี้คือค่าที่เอกสารทางการระบุไว้ตรงๆ)
• Firewall ระดับเซิร์ฟเวอร์ (เช่น CSF) + fail2ban — บล็อก IP ที่พยายามเดารหัสซ้ำๆ อัตโนมัติ
• WAF (Web Application Firewall) — ดักรูปแบบการโจมตีที่รู้จักก่อนถึงตัวเว็บ
• จำกัดจำนวนครั้งล็อกอินที่ผิด (limit login attempts) — กัน brute force
• ปิดสิ่งที่ไม่ได้ใช้ — ปิด XML-RPC ถ้าไม่จำเป็น (เป็นช่องยอดฮิตของ brute force), ปิดการแก้ไฟล์ธีม/ปลั๊กอินผ่านหน้า WordPress (DISALLOW_FILE_EDIT) เพื่อไม่ให้ใครฝังโค้ดผ่านหน้าแอดมินได้ (ข้อนี้เอกสาร Hardening แนะนำชัด)
• สแกนมัลแวร์เป็นรอบ — ตั้งให้สแกนอัตโนมัติ ไม่ใช่รอจนลูกค้าโทรมาด่า
• หลักการ least privilege — ให้สิทธิ์เท่าที่จำเป็น user ไหนไม่ต้องเป็น admin ก็อย่าให้ แม้แต่สิทธิ์ของ DB user ก็จำกัดได้ ยิ่งมี admin น้อย ยิ่งมีประตูน้อย

และเหนือสิ่งอื่นใด — backup คือเส้นชีวิตของการกู้ ต่อให้ป้องกันดีแค่ไหน วันที่พลาดจริงสิ่งที่ทำให้คุณนอนหลับคือการรู้ว่า "เดี๋ยวก็กู้กลับได้" รายละเอียดเรื่อง backup ที่กู้ได้จริง ผมเขียนไว้ที่ ไม่มี Backup = หายนะ

สรุปเป็นตาราง: เจออาการนี้ → ทำอะไรก่อน

หลายคนอ่านมาถึงตรงนี้แล้วยังงงว่า "แล้วของผมอยู่ขั้นไหน ต้องเริ่มตรงไหน" ผมสรุปเป็นตารางให้เซฟไว้ใช้ตอนแพนิคได้เลย:

อาการที่เจอ	สิ่งที่ควรทำก่อนเป็นอันดับแรก	สิ่งที่ "ห้าม" ทำ
เว็บเด้งไปเว็บพนัน/หลอกลวง	สำรองสภาพปัจจุบัน → ปิดเว็บ maintenance → เช็ก .htaccess กับ index.php	อย่ารีบลบไฟล์มั่วจนเสียหลักฐาน
Google ขึ้น "เว็บนี้อาจเป็นอันตราย"	กู้เว็บให้สะอาดก่อน แล้วค่อยขอ security review ใน Google Search Console	อย่าส่งขอรีวิวทั้งที่ยังไม่ล้างจริง (โดนตีกลับ + รอบถัดไปยิ่งช้า)
มี admin user แปลกโผล่มา	เปลี่ยนรหัสทุกชั้น + เปลี่ยน salt keys (เตะทุก session ออก) แล้วลบ user แปลก	อย่าลบ user อย่างเดียวแล้วคิดว่าจบ — เขายังมี backdoor อยู่
โดนโฮสต์ suspend / ส่งสแปม	ติดต่อโฮสต์ขอรายละเอียดว่าตรวจเจออะไร/ไฟล์ไหน แล้วกู้จาก backup สะอาด	อย่าเปิดเว็บกลับมาเฉยๆ โดยยังไม่ล้าง (โดน suspend ซ้ำ)
เจอไฟล์ .php ใน uploads / โค้ด base64+eval แปลกๆ	ถือว่าเจอ backdoor — เก็บหลักฐาน แล้วกู้จาก backup ก่อนวันโดน + ไล่ไฟล์ที่แก้ล่าสุด	อย่าลบทีละไฟล์ตามที่เห็นแล้วคิดว่าหมด (มันสร้างกลับ)
กู้ไปแล้วแต่กลับมาอีกในไม่กี่วัน	ถือว่ายังมี backdoor — ต้องกวาดให้หมด + อุดช่องเดิม (ปลั๊กอิน/ธีมที่เป็นต้นเหตุ)	อย่ากู้ทับด้วย backup ชุดเดิมที่ติดมัลแวร์ซ้ำๆ

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

3M ของเรื่อง "เว็บโดนแฮก" (เอาไปเช็กเว็บตัวเองได้เลย)

ผมขอรวบ 3M ให้เห็นเป็นภาพเดียว เพราะมันคือชุดความคิดที่ทำให้คนเจ็บซ้ำ:

🔴 (สิ่งที่พลาด) (ความพลาดที่ทำเอง)

• ไม่อัปเดต core/ปลั๊กอิน/ธีม
• ใช้รหัสอ่อนหรือรหัสซ้ำ และไม่เปิด 2FA
• ลง nulled plugin/ธีมเถื่อน หรือตั้ง permission เป็น 777
• เซฟรหัส FTP/SSH ไว้ในเครื่อง dev ที่ติดมัลแวร์
• รีบลบไฟล์/ลบ user ตอนแพนิคจนเสียหลักฐาน
• รีบกดขอ Google review ทั้งที่ยังล้างไม่สะอาด

🟠 (สิ่งที่ขาด) (สิ่งที่ "ไม่มี" เลยรับมือไม่ได้)

• ไม่มี monitoring/WAF เลยไม่รู้ว่าโดน
• ไม่มี backup สะอาดหลายเวอร์ชันให้ย้อน
• ไม่มีคนที่ "อ่าน backdoor เป็น" คอยช่วยไล่ตอนวิกฤต
• ไม่มี hardening พื้นฐาน เช่น firewall, limit login และการปิด XML-RPC ที่ไม่จำเป็น

🔵 (ความเข้าใจผิด) (ความเข้าใจผิด)

• "ลบหน้าที่เด้งเว็บพนันออกก็จบแล้ว" — ไม่จบ ถ้า backdoor ยังอยู่ มันสร้างกลับได้
• "เครื่องผมเปิดเว็บดูปกติ แสดงว่าไม่โดน" — บางเคสเด้งเฉพาะคนมาจาก Google หรือมือถือ
• "กู้เว็บแล้วรีบกด Google ปลดแบนเลย" — ต้องล้างสะอาดก่อน ไม่งั้นโดนตีกลับและรอนานขึ้น
• "เว็บมี custom code ต้องจ้างบริการล้างที่การันตี 100% เท่านั้น" — เดี๋ยวผมเล่าในส่วนถัดไปว่าทำไมมันไม่ใช่คำตอบเดียว

ส่วนที่ 7 — "แล้วผมควรกู้เองตามคู่มือ หรือจ้างบริการล้างมัลแวร์ดี?" (และคนที่มี custom code อยู่ตรงไหน)

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

ทางที่ 1 — กู้เองตามคู่มือ (DIY) ในเน็ตมีคู่มือดีๆ เยอะ ทั้งของฝรั่งและของไทย ส่วนใหญ่สอนแนวเดียวกัน คือลบไฟล์เก่าทิ้ง ลง WordPress core ใหม่จาก wordpress.org เปลี่ยน salt ปิด file edit เก็บไว้แต่ wp-config กับ uploads — ซึ่ง ถูกหลักนะครับ ผมเห็นด้วยกับลำดับพวกนั้น แต่ปัญหาคือ คู่มือมันคือ "แผนที่" ไม่ใช่ "คนเดินไปกับคุณ" วันที่คุณแพนิคตอนตี 3 มือสั่น ลูกค้าโทรมาด่า คุณต้องมานั่งแกะ backdoor ที่ซ่อนเป็นโค้ด base64 ในไฟล์ธีมเอง ต้องตัดสินใจเองว่า backup เวอร์ชันไหนสะอาด ต้องเดาเองว่าอุดช่องไหน — คู่มือไม่ได้ยกหูมาช่วยคุณคิดตอนนั้น

ทางที่ 2 — จ้างบริการล้างมัลแวร์ครั้งเดียว (ที่มักมาพร้อมคำว่า "การันตี") อีกทางคือจ้างบริการล้างเป็นครั้งๆ ซึ่งก็มีข้อดีของมัน แต่ผมอยากให้คุณสังเกตเงื่อนไขตัวเล็กๆ ที่บริการแนวนี้มักมี — หลายเจ้า "กันงานที่มี custom code ออก" คือถ้าเว็บคุณแก้โค้ดธีม/ปลั๊กอินเอง หรือมีระบบที่เขียนเพิ่มเอง เขาจะไม่รับประกัน หรือไม่รับเคสนั้นเลย เพราะมันยุ่งยากเกินสคริปต์ล้างมาตรฐานของเขา · และคำว่า "การันตี 100% ไม่โดนซ้ำ" เนี่ย ผมพูดตรงๆ ในฐานะคนทำมา 20 ปีว่า ความปลอดภัยมันไม่มีใครการันตี 100% ได้จริง — ใครพูดคำนี้เต็มปาก ผมว่าน่ากังวลกว่าน่าวางใจ

แล้วคนทำเว็บที่มี custom code อยู่ตรงไหน? นี่แหละจุดที่ผมเห็นช่องว่างมาตลอด — เพราะ คนทำเว็บ/agency เกือบทุกคน "มี custom code" ไม่มากก็น้อย ธีมที่แก้เอง ปลั๊กอินที่เขียนเพิ่ม ระบบ booking/ตะกร้าที่ทำเอง พอเป็นแบบนี้ บริการล้างสำเร็จรูปที่ตัดเคส custom code ทิ้ง มันก็ไม่ตอบโจทย์คุณ ส่วนคู่มือ DIY ก็ทิ้งให้คุณงมเองตอนตี 3 — สองทางเลือกหลักของตลาด เลยมีรอยโหว่ตรงกลางพอดี สำหรับคนที่ "เขียนโค้ดเองเป็น แต่อยากมีคนที่เข้าใจโค้ดช่วยดูตอนวิกฤต"

ตรงรอยโหว่นี้แหละครับ คือที่ที่ผมตั้งใจให้ PhalconHost ยืนอยู่ — เดี๋ยวเล่าต่อในส่วนถัดไป

เล่าให้ฟังหนึ่งเคส (เพื่อให้เห็นภาพ)

ผมขอเล่าแบบรวมๆ จากหลายเคสที่เจอ ไม่เจาะจงลูกค้ารายไหน เพื่อให้คุณเห็นว่าทำไม "ลำดับ" ถึงสำคัญ

คนทำเว็บคนหนึ่งทักมาว่าเว็บลูกค้าเด้งเว็บพนัน เขารีบมากเลยลงมือเองก่อน — เห็นไฟล์ .php แปลกๆ ก็ไล่ลบ เห็น user แปลกก็ลบ เปลี่ยนรหัส WordPress แล้วรีบเข้าไปกดขอ Google ปลดแบนทันที เว็บดูปกติ เขาดีใจมาก

ผ่านไปสามวัน เว็บเด้งเว็บพนันอีก คราวนี้หนักกว่าเดิม แถม Google ก็ยังไม่ปลดป้ายแดงให้ เพราะตอนที่เขากดขอ review เว็บยังไม่สะอาดจริง คำขอเลยโดนตีกลับ

พอมานั่งไล่ดูด้วยกัน เราถึงเจอว่า ตอนแรกเขาลบเฉพาะไฟล์ที่ "เห็นชัด" แต่ยังมี backdoor อีกตัวซ่อนเป็นโค้ด base64 สั้นๆ อยู่ในไฟล์ของธีม และมีอีกตัวฝังในโฟลเดอร์ uploads ที่ปกติไม่ควรมีไฟล์รันได้เลย — สองตัวนั้นคือประตูหลังที่ทำให้เขากลับเข้ามาฝัง redirect ใหม่ได้ทันทีหลังเปลี่ยนรหัส และต้นเหตุจริงๆ คือปลั๊กอินตัวหนึ่งที่ค้างเวอร์ชันเก่าที่มีช่องโหว่ — เขาลบ redirect แต่ไม่เคยอุดประตูบานนั้น และเว็บนี้ก็เป็นเว็บที่มี custom code (ธีมแก้เอง) ซึ่งถ้าไปจ้างบริการล้างสำเร็จรูปบางเจ้า ก็อาจโดนปฏิเสธเคสตั้งแต่แรก

สิ่งที่ทำให้เคสนี้จบในที่สุดคือ การย้อนกลับไปหา backup ชุดที่ "ก่อน" วันที่ backdoor ถูกฝัง (ไม่ใช่แค่ก่อนเว็บเด้ง เพราะ backdoor ถูกฝังเงียบๆ มาก่อนหลายวัน) แล้วอัปเดต+ลบปลั๊กอินต้นเหตุ + ทำ hardening ให้ครบ + ล้างให้สะอาดจริงก่อน ค่อยกดขอ Google review รอบใหม่ ซึ่งคราวนี้ผ่าน หลังจากนั้นเว็บก็ไม่กลับมาอีก

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

แล้ว PhalconHost ช่วยเรื่องนี้ยังไง?

ผมเปิด PhalconHost เพราะตอนเป็นคนทำเว็บ ผมเจ็บกับการที่เว็บมีปัญหาตอนดึกแล้วโทรหาโฮสต์ ได้แต่บอทกับฝ่ายขายที่ไม่เข้าใจว่าโค้ดเราทำงานยังไง ไม่มีใครช่วยไล่ปัญหาจริงๆ ผมเลยตั้งใจทำในสิ่งที่ผมเองอยากได้ตอนนั้น:

• Auto backup ฟรีให้ลูกค้าทุกคน เก็บแยก ไม่คิดเพิ่ม — เพราะวันที่เว็บโดนแฮกจริง สิ่งที่ทำให้กู้ได้เร็วและสะอาดคือ backup ย้อนหลังที่ "ก่อนโดน" หลายเวอร์ชัน (จุดสะอาดให้ย้อนตอนเพิ่งรู้ว่า backdoor ฝังมานาน) ผมไม่เชื่อในการขาย backup แยกแล้วเวลามีปัญหาค่อยมาบอกลูกค้าว่า "คุณไม่ได้ซื้อ backup ไว้" — เพราะตอนข้อมูลหายจริง ไม่มีลูกค้าคนไหนยอมรับคำนั้น มันคือ ความรับผิดชอบพื้นฐานของคนที่ดูแลข้อมูลคนอื่น ไม่ใช่ของแถม
• firewall และมาตรการความปลอดภัยระดับเซิร์ฟเวอร์ — ดักและบล็อกตั้งแต่ชั้นเครื่อง ไม่ใช่ปล่อยให้ทุกอย่างไปตกที่ปลั๊กอินตัวเดียวในเว็บคุณ อ่านภาพรวมฝั่งป้องกันได้ที่ ป้องกันเว็บก่อนโดนแฮก
• Dev ตัวจริงช่วยดู — และเข้าใจ custom code เพราะเราก็เป็น dev — นี่คือจุดที่ผมอยากเน้น จากส่วนที่ 7 ที่เล่าไป: ตลาดมีแค่ "คู่มือ DIY ให้ไปงมเอง" กับ "บริการล้างสำเร็จรูปที่มักตัดเคส custom code ทิ้ง" — เราอยู่ตรงกลางที่ขาดไป เวลาเว็บคุณมีปัญหา คุณแจ้งมา เราจัดให้ คือคุยกับคนที่เขียนโค้ดมา 20 ปี ที่อ่าน backdoor เป็น ช่วยไล่ดูว่าเขาเข้ามาทางไหน ช่วยดู hardening ให้ — แบบ best-effort ตามแต่ละเคส ไม่ใช่ตอบสั้นๆ ว่า "ไปจ้างคนมาแก้เองนะครับ" และไม่ใช่ปฏิเสธเพราะเว็บคุณมีโค้ดที่แก้เอง

ผมขอพูดให้ชัดเพื่อความซื่อสัตย์: เราเป็น โฮสติ้งที่มี Dev ช่วยดูเกินหน้าที่แบบ best-effort "แจ้งมา เราจัดให้" — ไม่ใช่บริษัทรับ manage เว็บให้ทั้งหมดแบบดูแลทุกบรรทัดโค้ดให้คุณ และผมไม่เคลมว่า "การันตีเว็บไม่โดนแฮก" หรือ "การันตี uptime ไม่ล่ม" เพราะความปลอดภัยไม่มีใครการันตีแบบนั้นได้จริง · ถ้าคุณอยากได้คนที่เข้ามาดูแลจัดการเว็บให้ทุกอย่างแบบเต็มรูปแบบ (managed เต็มตัว) ผมบอกตรงๆ ว่าเราไม่ได้ทำถึงขั้นนั้น — แต่ถ้าคุณเป็นคนทำเว็บที่ "ทำเองเป็น แต่อยากมี Dev ที่เข้าใจโค้ดอยู่ข้างๆ ตอนวิกฤต" นั่นแหละคือสิ่งที่เราเป็น

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

สุดท้ายนี้

เว็บโดนแฮกไม่ใช่จุดจบ และไม่ใช่เรื่องน่าอายของคนทำเว็บ — มันเกิดขึ้นได้กับทุกคน สิ่งที่ทำให้ต่างคือคุณ อ่านสัญญาณเป็น กู้ถูกลำดับ (ตามที่เอกสารทางการเขาวางไว้) ปิดประตูหลังให้หมด ล้างสะอาดก่อนค่อยขอ Google ปลดแบน และมี backup ที่กู้ได้จริง เป็นเส้นชีวิต ไว้เสมอ

ขอแค่จำหลักง่ายๆ ไว้: อย่าลบมั่วตอนแพนิค (เก็บหลักฐานก่อน) · backdoor มันฝังหลายจุดและมีลายเซ็นแบบ base64/eval ให้ตามรอย · กู้จากจุดสะอาดดีกว่าไล่แกะทีละไฟล์ · และล้างให้จบก่อนค่อยไปเคาะประตู Google

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

ถ้าตอนนี้เว็บคุณกำลังมีอาการที่ผมเล่ามา หรือคุณแค่อยากให้มีคนช่วยตรวจว่าเว็บแข็งพอยัง — ทักไลน์มาเล่าให้ผมฟังได้เลยครับ เล่าอาการมาคร่าวๆ เดี๋ยวผมช่วยดูให้ว่าควรเริ่มตรงไหน แม้คำตอบจะเป็น "ของคุณยังไม่ถึงขั้นต้องย้ายมาก็ได้" ผมก็จะบอกตามนั้น คุยกับ Dev ตัวจริง ไม่ใช่บอท — ถ้าไม่เหมาะผมบอกตรง 🙂