FortiBleed: ไม่ใช่ช่องโหว่ใหม่ แต่เป็นบทเรียนเรื่อง Credential ที่องค์กรต้องรับมือทันที
- Marketing Online
- 4 วันที่ผ่านมา
- ยาว 4 นาที
FortiBleed คือแคมเปญขโมยและรวบรวมรหัสผ่าน (credential) ของอุปกรณ์ Fortinet ขนาดใหญ่ที่ถูกเปิดเผยกลางเดือนมิถุนายน 2026 ไม่ใช่ช่องโหว่ (CVE) ตัวใหม่ และไม่ใช่ zero-day Fortinet ยืนยันเองว่าเกิดจากการนำรหัสผ่านที่รั่วจากเหตุการณ์เก่ามาใช้ซ้ำ ร่วมกับการ brute-force อุปกรณ์ที่ตั้งรหัสผ่านอ่อนและไม่มี MFA สิ่งที่ต้องทำทันทีคือ รีเซ็ตรหัสผ่าน admin/VPN ทั้งหมด เปิด MFA และปิดการเข้าถึงหน้า management จากอินเทอร์เน็ต
1. FortiBleed คืออะไร (และไม่ใช่อะไร)
ในช่วงกลางเดือนมิถุนายน 2026 วงการความมั่นคงปลอดภัยไซเบอร์ตื่นตัวกับเหตุการณ์ที่ถูกตั้งชื่อว่า "FortiBleed" ซึ่งเป็นการเปิดเผยฐานข้อมูลรหัสผ่านของอุปกรณ์ Fortinet จำนวนมหาศาลที่ถูกขโมยและรวบรวมไว้โดยกลุ่มผู้โจมตี
สิ่งแรกที่ต้องทำความเข้าใจให้ตรงกัน และเป็นจุดที่หลายคนเข้าใจผิด คือ FortiBleed ไม่ใช่ช่องโหว่ (vulnerability) และไม่มีรหัส CVE เป็นของตัวเอง ชื่อ "FortiBleed" ถูกตั้งเลียนแบบ "Heartbleed" ซึ่งเป็นช่องโหว่ชื่อดังในอดีต ทำให้หลายคนเข้าใจไปว่ามันคือบั๊กตัวใหม่ที่รอ patch มาแก้ แต่ความจริงไม่ใช่เช่นนั้น
Fortinet ออกแถลงการณ์ทางการผ่านทีม PSIRT เมื่อวันที่ 19 มิถุนายน 2026 โดยระบุชัดเจนว่านี่ไม่ใช่ช่องโหว่ใหม่ของ Fortinet และไม่เกี่ยวข้องกับเหตุการณ์หรือ advisory ล่าสุดใด ๆ Fortinet เชื่อว่ากิจกรรมนี้เกิดจากการที่ผู้โจมตีนำ credential จากเหตุการณ์ก่อนหน้า (อ้างอิง advisory FG-IR-26-060 และ FG-IR-25-647) มาใช้ซ้ำ ร่วมกับเทคนิค brute-force โจมตีอุปกรณ์ที่มีการตั้งรหัสผ่านอ่อนแอและไม่ได้เปิดใช้ MFA
พูดให้เข้าใจง่าย: FortiBleed ไม่ใช่ "ประตูบ้านมีรูรั่ว" แต่เป็น "กุญแจบ้านของคุณหลุดไปอยู่ในมือคนร้ายแล้ว" ซึ่งเป็นปัญหาที่อันตรายในรูปแบบที่ต่างออกไป และวิธีรับมือก็ต่างกันด้วย
2. ลำดับเหตุการณ์ (Timeline)
วันที่ (ปี 2026) | เหตุการณ์ |
13 มิ.ย. | นักวิจัยด้านความปลอดภัย Volodymyr "Bob" Diachenko ค้นพบเซิร์ฟเวอร์ของผู้โจมตีที่เปิดเผยสู่อินเทอร์เน็ต บรรจุฐานข้อมูลรหัสผ่าน admin และ VPN ของ FortiGate |
16–19 มิ.ย. | ทีมวิจัยจาก SOCRadar, Hudson Rock และนักวิจัย Kevin Beaumont เข้าวิเคราะห์และยืนยันว่ารหัสผ่านบางส่วนใช้งานได้จริง |
18 มิ.ย. | CISA (หน่วยงานความมั่นคงไซเบอร์สหรัฐฯ) ออก Alert เตือนให้ทำ hardening อุปกรณ์ Fortinet |
19 มิ.ย. | Fortinet PSIRT ออกแถลงการณ์ทางการ ยืนยันว่าไม่ใช่ช่องโหว่ใหม่ |
22 มิ.ย. | CISA อัปเดต Alert เพิ่มลิงก์ไปยังคำแนะนำของ Fortinet |
3. ขนาดและขอบเขตของผลกระทบ
FortiBleed ถือเป็นหนึ่งในการเปิดเผยรหัสผ่าน FortiGate ครั้งใหญ่ที่สุดเท่าที่เคยมีการยืนยัน ตัวเลขจากแหล่งต่าง ๆ มีดังนี้:
- ~74,000 อุปกรณ์ ที่ได้รับผลกระทบ ทั้ง firewall และ VPN gateway (ตัวเลขจาก CISA)
- 73,932 firewall URL ที่ไม่ซ้ำกัน ครอบคลุม 194 ประเทศ และกว่า 21,600 domain
- คิดเป็นสัดส่วนประมาณ ครึ่งหนึ่ง ของอุปกรณ์ Fortinet ที่เปิดสู่อินเทอร์เน็ตทั้งหมด
องค์กรที่ได้รับผลกระทบครอบคลุมหลายภาคส่วน ทั้งหน่วยงานรัฐ โทรคมนาคม การเงิน สาธารณสุข การผลิต และโครงสร้างพื้นฐานสำคัญ (critical infrastructure) รวมถึงบริษัทข้ามชาติขนาดใหญ่
เรื่องการระบุตัวผู้โจมตี (Attribution): นักวิจัยประเมินว่าน่าจะเป็นกลุ่มที่พูดภาษารัสเซีย โดยพิจารณาจากเครื่องมือ โครงสร้างพื้นฐาน และรูปแบบการเลือกเป้าหมาย อย่างไรก็ตาม นี่เป็นเพียงการ "ประเมิน" (assessment) ไม่ใช่ข้อสรุปที่ยืนยันแน่นอน
> หมายเหตุสำคัญ: SOCRadar ระบุว่าไม่พบหลักฐานว่ากิจกรรมนี้มาจาก zero-day หรือการเจาะตัวผลิตภัณฑ์ Fortinet โดยตรง แต่เกิดจาก brute-force และ credential stuffing ต่อบริการ Fortinet ที่เปิดสู่อินเทอร์เน็ต ซึ่งสอดคล้องกับจุดยืนของ Fortinet เอง
4. กลไกทางเทคนิค — FortiBleed ทำงานอย่างไร
ส่วนนี้เป็นหัวใจทางเทคนิคที่ทีม engineer ควรเข้าใจ เพราะมันอธิบายว่าทำไมการ "แค่ patch" ถึงไม่เพียงพอ
4.1 จุดเริ่มต้น: การดึง configuration file
อุปกรณ์ FortiGate เก็บข้อมูลการตั้งค่าทั้งหมดไว้ใน configuration file ซึ่ง รวมถึง hash ของรหัสผ่าน admin ด้วย เมื่อผู้โจมตีสามารถเข้าถึงและดึง config file ออกมาได้ (ไม่ว่าจะผ่านช่องโหว่เก่า การเปิด management interface สู่อินเทอร์เน็ต หรือ credential ที่ได้มาก่อนหน้า) พวกเขาก็จะได้ทั้งข้อมูล network topology และวัตถุดิบสำหรับถอดรหัสผ่านไปพร้อมกัน
4.2 จุดอ่อนเชิงโครงสร้าง: SHA-256 vs PBKDF2
นี่คือหัวใจของเรื่อง Fortinet เคยเก็บ hash รหัสผ่านของ admin ด้วยอัลกอริทึม SHA-256 (with salt) ซึ่งถอดรหัสแบบ offline ได้ค่อนข้างเร็วด้วยเครื่องมือสมัยใหม่
ต่อมา Fortinet เปลี่ยนมาใช้ PBKDF2 ซึ่งทนทานต่อการ brute-force มากกว่ามาก โดยเริ่มรองรับตั้งแต่ FortiOS เวอร์ชัน 7.2.11, 7.4.8 และ 7.6.1 เป็นต้นไป
หมายเหตุเรื่องเวอร์ชัน: เลขข้างต้น (7.2.11/7.4.8/7.6.1) คือเวอร์ชัน แรกที่เริ่มรองรับ PBKDF2 ส่วนคำแนะนำในหัวข้อ 7 ที่ให้อัปเกรดไปสาย 7.4, 7.6 หรือ 8.0 หมายถึงสายเวอร์ชันที่ Fortinet แนะนำให้อัปเกรดไป (เวอร์ชันล่าสุดในแต่ละสายย่อมรองรับ PBKDF2 อยู่แล้ว) ตัวเลขทั้งสองชุดจึงไม่ได้ขัดแย้งกัน
แต่ปัญหาอยู่ที่ขั้นตอนการ migration: เมื่ออัปเกรดจากเวอร์ชันเก่า รหัสผ่าน admin เดิม จะยังคงถูกเก็บเป็น SHA-256 hash อยู่ จนกว่า admin คนนั้นจะ login เข้าระบบสำเร็จหลังอัปเกรด ระบบจึงจะแปลง hash เป็น PBKDF2 ให้
ผลที่ตามมาคือ องค์กรจำนวนมากที่ "อัปเกรดเฟิร์มแวร์แล้ว" แต่ admin ยังไม่ได้ login ใหม่ ก็ยังคงเก็บรหัสผ่านด้วย SHA-256 ที่อ่อนแอ — และตกเป็นเป้าได้ทันทีหาก config file หลุดออกไป
4.3 ประเด็นที่ engineer สาย hardening ต้องรู้: setting `old-password` ที่ซ่อนอยู่
มีรายละเอียดสำคัญที่หลายคนมองข้าม: แม้รหัสผ่านจะถูกอัปเกรดเป็น PBKDF2 แล้ว SHA-256 hash เดิมก็ยังถูกเก็บไว้ใน setting ที่ซ่อนชื่อ `old-password` เพื่อรองรับ backward compatibility
- setting `old-password` นี้ มองไม่เห็นจากหน้า admin ปกติ แต่จะปรากฏใน config backup ที่ super_admin ดึงออกมา
- บน FortiOS v7.2.x และ v7.4.x หากต้องการลบ SHA-256 hash เดิมออกให้หมดจริง ๆ ต้องเปิดใช้ setting `login-lockout-upon-weaker-encryption` ใน `system password-policy`
นี่หมายความว่า แม้คุณคิดว่าระบบใช้ PBKDF2 แล้ว config backup ก็อาจยังมี hash แบบเก่าซ่อนอยู่ และหากไฟล์นั้นหลุด ผู้โจมตีก็ยังถอดรหัสได้อยู่ดี
4.4 Offline cracking — ทำไม patch อย่างเดียวไม่พอ
เมื่อได้ hash มาแล้ว ผู้โจมตีนำไปถอดรหัส (crack) แบบ offline บนเครื่องของตัวเอง ซึ่งหลบเลี่ยงกลไกป้องกัน เช่น rate-limiting หรือ account lockout ที่ทำงานเฉพาะตอน login จริงได้ทั้งหมด เมื่อถอดรหัสสำเร็จก็จะได้รหัสผ่านที่ใช้ login เข้าอุปกรณ์ได้จริง
5. ทำไม FortiBleed ถึงรับมือยากกว่าช่องโหว่ CVE ทั่วไป
นี่คือประเด็นเชิงแนวคิดที่สำคัญที่สุดของทั้งเหตุการณ์
ช่องโหว่ CVE ทั่วไปจะให้ขอบเขตที่ชัดเจนแก่ผู้ป้องกัน: รู้ว่าเวอร์ชันไหนเสี่ยง (unpatched versions) และมีเส้นตายชัดเจน (วันที่ patch ออก) เมื่อ patch แล้วก็จบ
แต่ FortiBleed ต่างออกไปโดยสิ้นเชิง เพราะมันเป็นปัญหาเรื่อง credential ไม่ใช่ software — สามารถสรุปความแตกต่างได้ดังนี้:
- Patch window มีขอบเขต แต่ Credential window ไม่มีขอบเขต — รหัสผ่านที่ถูกขโมยไปจะยังใช้ login ได้เรื่อย ๆ แม้คุณจะอัปเดต software ครบทุก CVE แล้ว จนกว่าจะ rotate (เปลี่ยน) รหัสผ่านทุกตัวด้วยตัวเอง
- ตรวจจับยาก — การที่ผู้โจมตี login ด้วยรหัสผ่านที่ถูกต้องนั้น "ดูเหมือนกิจกรรม admin ปกติ" ทุกประการ ไม่มี exploit code ให้ดักที่ perimeter และไม่มี malware signature ให้จับ การตรวจจับต้องอาศัยการวิเคราะห์พฤติกรรม (behavioral analysis) ของรูปแบบการ authenticate และการเปลี่ยนแปลง config
- เสี่ยงต่อ lateral movement — เมื่อได้สิทธิ์ admin บน firewall แล้ว ผู้โจมตีมักไม่หยุดแค่นั้น แต่จะใช้เป็นหัวสะพานเจาะเข้า Active Directory และเครือข่ายภายในต่อไป
สรุปสั้น ๆ: องค์กรที่ patch ครบทุก CVE สัปดาห์นี้ แต่ไม่ได้ rotate รหัสผ่านและไม่เปิด MFA ก็ยังคงมีความเสี่ยงอยู่
6. องค์กรของคุณได้รับผลกระทบหรือไม่ — วิธีตรวจสอบ
เงื่อนไขที่ทำให้เข้าข่ายเสี่ยง
องค์กรของคุณอยู่ในกลุ่มเสี่ยงหาก:
- มี FortiGate ที่เปิดหน้า management interface (web console, SSH) หรือ SSL VPN endpoint ให้เข้าถึงได้โดยตรงจากอินเทอร์เน็ต
- เคยอัปเกรด FortiOS จากเวอร์ชันเก่า แต่ admin บางบัญชียังไม่ได้ login ใหม่หลังอัปเกรด (รหัสผ่านยังเป็น SHA-256)
- ไม่ได้เปิดใช้ MFA บนบัญชี admin และ VPN
- เคยถูกโจมตีหรือมีช่องโหว่ในอดีต แต่ตอนนั้น "patch แล้วแต่ไม่ได้เปลี่ยนรหัสผ่าน"
### สิ่งที่ต้องตรวจสอบในระบบ
1. ตรวจ config หา user หรือการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต โดยเปรียบเทียบกับ config สำรองที่รู้ว่าสะอาด (known good configuration)
2. ระวังบัญชีแปลกปลอม ที่อาจถูกสร้างขึ้น โดยเฉพาะชื่อที่พยายามปลอมเป็นบัญชีระบบ เช่น `forticloud`, `fortiuser`, `fortinet-support`, `fortinet-tech-support`
3. ตรวจ log หาการเข้าถึงระดับ admin จาก IP ที่ไม่รู้จัก
4. ตรวจ domain controller log หาร่องรอย lateral movement การเข้าถึงที่ผิดปกติ บัญชีน่าสงสัย หรือการแก้ไข config ที่ไม่ได้รับอนุญาต
5. หากมีการเชื่อม AD/LDAP integration ให้ถือว่าบัญชีนั้นอาจถูก compromise และเฝ้าระวังการนำไป authenticate ที่อื่นหรือการสร้างบัญชีเพิ่ม
7. แนวทางแก้ไข — Action Plan ตามคำแนะนำทางการ
ต่อไปนี้คือ 6 ขั้นตอนเร่งด่วนตามคำแนะนำทางการจาก Fortinet PSIRT จัดเรียงตามลำดับความสำคัญ:
### ทำทันที (Critical)
1. ยุติ session และรีเซ็ตรหัสผ่านทั้งหมด
ยุติ session ของ admin ที่ active อยู่ทั้งหมด แล้วรีเซ็ตรหัสผ่าน VPN และ admin ทุกตัว โดยเฉพาะระบบที่เปิดสู่อินเทอร์เน็ต พร้อมบังคับใช้นโยบายรหัสผ่านที่แข็งแรง
2. เปิดใช้ MFA
เปิด Multi-Factor Authentication บนบัญชี administrator และ VPN user ทุกบัญชี — ขั้นตอนนี้ช่วยลดประสิทธิภาพของรหัสผ่านที่ถูกขโมยไปได้อย่างมาก แม้ผู้โจมตีจะมีรหัสผ่านที่ถูกต้องก็ตาม
3. ปิด/จำกัดการเข้าถึงหน้า management
ลด attack surface โดยจำกัดการจัดการอุปกรณ์ ตามลำดับความปลอดภัย:
- ดี: จำกัดผ่าน trusted host
- ดีกว่า: ใช้ local-in policy
- ดีที่สุด: ยกเลิกการจัดการผ่านอินเทอร์เน็ตทั้งหมด
### ทำตามมา (สำคัญ)
4. อัปเกรดและล้าง hash เก่า
อัปเกรดเป็นเวอร์ชันล่าสุดของ 7.4, 7.6 หรือ 8.0 ซึ่งรองรับ PBKDF2 hashing จากนั้นทำตามคำแนะนำเพื่อลบ legacy password setting เดิมผ่าน `set login-lockout-upon-weaker-encryption`
> สำคัญ: หลังอัปเกรด ต้องให้ admin ทุกคน login อย่างน้อยหนึ่งครั้ง เพื่อให้ระบบแปลง hash เป็น PBKDF2 หากทำไม่ได้ ให้ super_admin แก้รหัสผ่านของ admin ที่เหลือด้วยตนเอง
5. ตรวจสอบ configuration
ทบทวน firewall user, VPN user และ config อื่น ๆ หาการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต (ดูรายละเอียดในหัวข้อ 6)
6. ตรวจสอบ log
มองหาการเข้าถึงระดับ admin จาก IP/domain ที่ไม่คาดคิด และตรวจ domain controller log หา lateral movement
หากพบหลักฐานการถูกโจมตี (IoC)
หากพบการแก้ไข config ที่ไม่ได้รับอนุญาตหรือ IoC อื่น ๆ ให้ ถือว่าอุปกรณ์ถูก compromise และดำเนินการตามขั้นตอนการกู้คืนของ Fortinet ตรวจหาการสร้าง VPN user, การรีเซ็ตรหัสผ่านที่ไม่คาดคิด หรือการ login VPN จากตำแหน่งที่ผิดปกติ ซึ่งอาจบ่งชี้ว่าผู้โจมตีพยายามเคลื่อนเข้าสู่เครือข่ายภายในแล้ว
8. สรุป — Key Takeaways
- FortiBleed ไม่ใช่ช่องโหว่ใหม่ และไม่มี patch มาปิดมันได้ — มันคือปัญหาเรื่อง credential ที่รั่วและถูกนำมาใช้ซ้ำ
- patch อย่างเดียวไม่พอ — ต้อง rotate รหัสผ่านทุกตัว เพราะรหัสที่หลุดไปจะใช้ได้เรื่อย ๆ จนกว่าจะเปลี่ยน
- MFA คือเกราะที่สำคัญที่สุด — ช่วยป้องกันแม้ในกรณีที่รหัสผ่านหลุดไปแล้ว
- ลด attack surface — อย่าเปิดหน้า management หรือ SSL VPN สู่อินเทอร์เน็ตโดยไม่จำเป็น
- อย่าลืม hash ที่ซ่อนอยู่ — หลังอัปเกรดต้องให้ admin login ใหม่ทุกคน และพิจารณาเปิด `login-lockout-upon-weaker-encryption` เพื่อล้าง SHA-256 hash เดิม
เหตุการณ์นี้เป็นเครื่องเตือนใจว่า ความปลอดภัยของอุปกรณ์ perimeter ไม่ได้จบที่การ "อัปเดตเวอร์ชัน" แต่ต้องครอบคลุมถึง credential hygiene, MFA และการลดพื้นผิวการโจมตีไปพร้อมกัน
9. แหล่งอ้างอิง
แหล่งทางการ (Primary)
- Fortinet PSIRT — "Analysis of Reported Credential Compromise of FortiGate Devices" (19 มิ.ย. 2026)
- CISA Alert — "CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure" (18 มิ.ย. 2026)
แหล่งวิเคราะห์ทางเทคนิค (Secondary)
- Arctic Wolf — Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries
- Recorded Future (Insikt Group) — FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems
- Bitdefender — Technical Advisory: FortiBleed Credential Exposure Campaign
- Censys — June 19 Advisory: Fortinet Credential Exposure Campaign
- SOCRadar Threat Research Unit (STRU)
- Hudson Rock
เอกสารนี้รวบรวมข้อมูลจากแหล่งสาธารณะที่น่าเชื่อถือ ณ เดือนมิถุนายน 2026 สถานการณ์อาจมีการอัปเดตเพิ่มเติม โปรดตรวจสอบ advisory ล่าสุดจาก Fortinet PSIRT และ CISA ก่อนดำเนินการ
ความคิดเห็น