FortiBleed 2.0 พบข้อมูลรั่วเพิ่มเติม องค์กรที่ใช้ FortiGate ควรตรวจสอบอะไรอีกครั้ง

องค์กรที่ตรวจสอบ FortiBleed ไปแล้วเมื่อเดือนมิถุนายน อาจต้องกลับมาตรวจสอบอีกครั้ง หลังมีการเผยแพร่ผลวิเคราะห์ FortiBleed 2.0 ซึ่งพบข้อมูลบัญชีและ Configuration ของ FortiGate เพิ่มเติม รวมถึงข้อมูลที่ไม่ปรากฏในชุดแรก

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

FortiBleed คืออะไร

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

Fortinet ระบุในการประเมินเบื้องต้นว่า ผู้โจมตีมีการนำข้อมูลเข้าสู่ระบบจากเหตุการณ์ก่อนหน้ากลับมาใช้ และใช้วิธี Brute Force กับอุปกรณ์ที่มีรหัสผ่านอ่อนแอและไม่ได้เปิด MFA โดยยืนยันว่า FortiBleed ไม่ใช่ชื่อช่องโหว่ใหม่ของ Fortinet

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

FortiBleed 2.0 พบอะไรเพิ่มเติม

รายงานของ Hudson Rock วิเคราะห์ไฟล์รายงาน Configuration จำนวน 1,703 ไฟล์ พบข้อมูลบัญชีและข้อมูลรับรองการเข้าสู่ระบบรวม 101,419 รายการ ในจำนวนนี้มี 40,573 รายการที่มีข้อมูลลับในรูปแบบข้อความที่อ่านได้ เช่น รหัสผ่าน

ข้อมูลที่พบครอบคลุมหลายประเภท ได้แก่

• บัญชี Local User และข้อมูลที่เกี่ยวข้องกับการใช้งาน VPN
• บัญชีผู้ดูแลระบบ
• บัญชี LDAP Bind ที่อุปกรณ์ใช้เชื่อมต่อ Active Directory
• ข้อมูลลับสำหรับ High Availability หรือ HA
• ข้อมูลเข้าสู่ระบบ SMTP

นอกจากนี้ ยังพบชื่อโดเมน 975 รายการที่ไม่ปรากฏในชุดข้อมูลเปรียบเทียบของ FortiBleed ครั้งแรก ตัวเลขนี้ไม่ได้หมายถึงองค์กรที่เพิ่งถูกโจมตีใหม่ 975 แห่ง เพราะหนึ่งองค์กรอาจเกี่ยวข้องกับหลายโดเมน และข้อมูลบางส่วนอาจเชื่อมโยงกับผู้ให้บริการที่ดูแลอุปกรณ์แทนลูกค้า

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

ทำไม Configuration ที่รั่วไหลจึงกระทบมากกว่าตัว Firewall

Configuration ของ Firewall อาจมีทั้งรายละเอียดเครือข่ายและข้อมูลที่อุปกรณ์ใช้ยืนยันตัวตนกับบริการอื่น เมื่อข้อมูลเหล่านี้รั่วไหล ผู้โจมตีจึงอาจรู้มากกว่าที่อยู่หน้า Login เช่น ตำแหน่งของ Directory Server และบัญชีที่ใช้เชื่อมต่อระบบภายใน

ตัวอย่างที่ควรตรวจสอบเป็นพิเศษคือ LDAP Bind Account หากรหัสผ่านของบัญชีนี้รั่วไหล ต้องประเมินว่าบัญชีมีสิทธิ์อะไรและถูกนำไปใช้ที่ใดบ้าง การพบรหัสผ่าน LDAP ไม่ได้แปลว่าผู้โจมตีจะได้สิทธิ์ Domain Admin โดยอัตโนมัติ แต่หากบัญชีได้รับสิทธิ์เกินความจำเป็น ผลกระทบก็อาจขยายออกไปได้มากขึ้น

ด้วยเหตุนี้ การตรวจสอบจึงควรครอบคลุมระบบที่เชื่อมต่อกับ FortiGate ด้วย โดยเฉพาะเมื่อพบหลักฐานว่ามีบุคคลภายนอกเข้าถึงอุปกรณ์หรือแก้ไขการตั้งค่าไปแล้ว

เคยตรวจสอบแล้ว หรือสแกน VA ผ่าน ยังต้องทำอะไรอีก

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

ส่วนผลการสแกน Vulnerability Assessment หรือ VA ควรใช้ประกอบกับการตรวจสอบด้านอื่น การสแกนช่องโหว่ทั่วไปไม่ได้ยืนยันว่ารหัสผ่านขององค์กรไม่เคยรั่วไหล และไม่ได้ทดแทนการตรวจสอบประวัติการเข้าสู่ระบบหรือการเปลี่ยนแปลง Configuration

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

องค์กรควรเริ่มรับมืออย่างไร

1. ทบทวนอุปกรณ์และช่องทางเข้าถึง

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

2. เปลี่ยนข้อมูลเข้าสู่ระบบที่อาจรั่วไหลและยุติ Session เดิม

สำหรับอุปกรณ์ที่ได้รับผลกระทบ Fortinet แนะนำให้ยุติ Session ของผู้ดูแลระบบและ VPN พร้อมเปลี่ยนรหัสผ่านที่เกี่ยวข้อง เปิด MFA และตรวจสอบบัญชีที่ไม่รู้จัก การเปลี่ยนรหัสผ่านควรครอบคลุมบัญชีที่นำรหัสผ่านเดียวกันไปใช้กับระบบอื่นด้วย

3. ตรวจสอบบัญชีที่เชื่อมต่อกับบริการอื่น

ทบทวนบัญชี LDAP และข้อมูลลับของบริการที่เกี่ยวข้อง เช่น HA, RADIUS และ SMTP ว่าจำเป็นต้องเปลี่ยนหรือไม่ พร้อมประสานเจ้าของระบบก่อนดำเนินการ เพื่อให้บริการที่ใช้งานข้อมูลเหล่านี้ยังทำงานได้ตามปกติ

4. ตรวจสอบ Configuration และ Logs

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

5. อัปเดตระบบและประเมินความจำเป็นในการทำ Incident Response

ติดตั้งอัปเดตตามคำแนะนำของ Fortinet หากพบการแก้ไข Configuration ที่ไม่ได้รับอนุญาตหรือหลักฐานการบุกรุก ควรเข้าสู่กระบวนการ Incident Response เพื่อประเมินขอบเขตและกู้คืนระบบอย่างเหมาะสม การอัปเดตซอฟต์แวร์เพียงอย่างเดียวไม่ทำให้ข้อมูลที่หลุดออกไปแล้วหมดความเสี่ยง

ตรวจสอบข้อมูลรั่วไหลร่วมกับ Incognito Lab

FortiBleed 2.0 เป็นเหตุผลให้องค์กรกลับมาทบทวนว่าข้อมูลเข้าสู่ระบบที่เคยใช้ยังมีผลต่อความปลอดภัยในปัจจุบันหรือไม่ โดยเฉพาะบัญชีที่เชื่อมโยงหลายระบบและอาจตกหล่นจากการเปลี่ยนรหัสผ่านครั้งก่อน

Incognito Lab ให้บริการ RedAlert สำหรับเฝ้าระวังข้อมูลเข้าสู่ระบบที่รั่วไหลจาก Infostealer Logs และแหล่งข้อมูลที่เกี่ยวข้อง ช่วยให้องค์กรมีข้อมูลเพิ่มเติมสำหรับตรวจสอบความเสี่ยงจากบัญชีของพนักงานและบุคคลภายนอกที่เกี่ยวข้องกับระบบขององค์กร

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

ดูรายละเอียดบริการ RedAlert ของ Incognito Lab

และสามารถใช้เครื่องมือ RedAlert จากทาง Incognito Lab ในการตรวจสอบว่า domain ของคุณได้รับผลกระทบอย่างไรจากเหตุการณ์ FortiBleed 2.0 ได้ที่ https://fortibleed.redalertlab.com/

แหล่งอ้างอิง

• Hudson Rock: FortiBleed 2.0 — 975 New Domains & 40,573 Exposed Secrets
• HKCERT: FortiBleed 2.0 Reveals Additional FortiGate Configuration and Credential Exposure
• Fortinet: Analysis of Reported Credential Compromise of FortiGate Devices