Ivanti Connect Secure ถูกโจมตีจริง 3 ช่องโหว่ต่อกัน CVE-2026-104935

พอดีเห็นประกาศของ Ivanti เมื่อ 13 ต.ค. 2026 ว่า Connect Secure ซึ่งเป็น VPN แบบ SSL ที่หลายองค์กรใช้ให้พนักงานต่อเข้าวงใน มีช่องโหว่ CVE-2026-104935 และถูกโจมตีจริงแล้ว ผมเลยตามอ่านต่อไปจนถึงรอบ 29 กับ 30 ต.ค. ที่มีอีกสองตัวตามมา แล้วรวมเป็นโพสต์เดียว เพราะทั้งสามตัวถูกใช้ต่อกันเป็นสายเดียว (chain) ถ้าอ่านแยกทีละ CVE จะมองไม่เห็นภาพว่าทำไมรอบเดียวไม่พอ

เกิดอะไรขึ้น

ข้อมูลหลักมาจากบล็อกของ Volexity ที่เจอเหตุจริงในช่วงต้นเดือน ต.ค. และเขียนว่าผู้โจมตีเริ่มลงมือกับเครื่องที่ถือว่าแพตช์ครบแล้วในวันที่ 3 ต.ค. สายโจมตีมี 3 ขั้น

1. ข้ามด่านล็อกอิน สคริปต์ welcome.cgi เปิดให้ทุกคนเรียกได้ แต่ถ้าแนบ header ชื่อ X-DSCGI-PATH ระบบจะส่งต่อ request ไปยัง CGI ที่ควรถูกป้องกัน โดยตรวจสิทธิ์จาก URL แต่ปลายทางจริงถูกกำหนดจาก header
2. รันคำสั่ง ตัวรับอัปโหลด wu.cgi เขียนไฟล์ลงดิสก์ก่อนตรวจว่าเป็น ZIP จริงหรือไม่ โดยตั้งชื่อไฟล์จากค่า MD5 ของชื่อไฟล์ที่ผู้ใช้ส่งมา ไฟล์ Perl ที่ปลอมเป็น .zip เลยอยู่บนดิสก์ชั่วครู่ก่อนถูกลบ ผู้โจมตียิง request ขนานกันเพื่อสั่งรันไฟล์นั้นให้ทันช่วงนี้
3. ยกสิทธิ์เป็น root ผ่านบริการ dsinvoked กับ DSCache ซึ่งทำงานด้วยสิทธิ์ root

ลักษณะที่ทำให้ตรวจยากคือ Volexity ไม่พบ web shell หรือ backdoor เลย คำสั่งกับผลลัพธ์วิ่งไปกลับใน HTTPS request ของตัวโจมตีเอง และโค้ดขั้นหลังรันในหน่วยความจำ ที่ทำต่อหลังเข้าได้คือดึงรหัสผ่านที่เก็บบนเครื่อง เช่น บัญชี LDAP ของโดเมน ใช้บัญชีนั้นถามหา LAPS password กับ BitLocker recovery key จาก Active Directory รัน tcpdump ที่เปลี่ยนชื่อเป็น dsstatmond ในโฟลเดอร์ซ่อน .icscap และลบหรือตัดทอน log เพื่อกลบร่องรอย Volexity ประเมินว่าเป็นการเตรียมขยับไปเครื่องอื่นในวง ปฏิบัติการนี้ถูกตรวจพบและสกัดไว้ก่อน เป้าหมายสุดท้ายของผู้โจมตีเลยระบุไม่ได้

ระดับความรุนแรง

CISA ติดสถานะ ransomware ของทั้งสามตัวไว้ที่ "Unknown" ส่วนใน CVE record ของทั้งสามตัว ข้อมูล SSVC ของ CISA บันทึกว่า exploitation เป็น active

ข้อที่ต้องระวังคือตัวเลข CVSS ของ CVE-2026-118527 แค่ 4.3 ระดับกลาง ถ้าคุณจัดลำดับงานจากคะแนนอย่างเดียวจะเลื่อนมันไปท้ายคิว แต่มันอยู่ใน KEV เพราะเป็นส่วนหนึ่งของสายโจมตีจริง คะแนนของแต่ละขั้นเลยประเมินความเสียหายรวมต่ำกว่าที่เกิดขึ้น

ใครโดนบ้าง และรุ่นที่แก้

ผมเจอข้อมูลรุ่นไม่ตรงกันระหว่างแหล่ง เลยแยกให้ดู

สรุปที่ใช้งานได้คือ ให้ขึ้นให้ถึง 25.1.1.3, 25.1.3.1 หรือ 22.8R2.6 ขึ้นไป ตามสายที่ใช้อยู่ ซึ่งตรงกับประกาศของ Canadian Cyber Centre และครอบคลุม CVE record ของสาย 22.8 เนื่องจาก 22.8R2.5 แก้เฉพาะตัวแรก มีจุดหนึ่งที่สองแหล่งไม่ตรงกันจริง CVE record ของ CVE-2026-104935 เขียนว่ากระทบ "ก่อน 25.1.3.0" และไม่ได้ลง 25.1.1.x เป็นรุ่นที่แก้ ขณะที่ Canadian Cyber Centre ใช้เกณฑ์ 25.1.1.3 สำหรับสายนั้น ใครอยู่บน 25.1.1.x ผมแนะนำให้ขยับไป 25.1.3.1 ที่ชัดเจนกว่า แล้วเช็กกับหน้า advisory ของ Ivanti อีกรอบ Volexity ยืนยันว่าเจอการโจมตีบนเครื่องรุ่น 22.8R2.4 ที่ถือว่าแพตช์ครบ ณ วันนั้น หน้า advisory ต้นฉบับของ Ivanti เป็นหน้าที่ต้อง render ด้วยเบราว์เซอร์ ผมเปิดอ่านเนื้อหาจริงไม่ได้ ตัวเลขรุ่นด้านบนเลยมาจาก CVE record กับหน่วยงานรัฐที่อ้าง advisory ตรวจรุ่นกับหน้า Ivanti อีกรอบก่อนลงจริง

วิธีแก้

1. เช็กรุ่น ดูเวอร์ชันและ build จากหน้า admin ของ appliance แล้วเทียบกับตารางข้างบน
2. ลง build ใหม่ ให้ถึงรุ่นที่แก้ทั้งสามตัว แม้เคยแพตช์รอบ 13 ต.ค. มาแล้วก็ต้องลงอีกรอบ
3. เก็บหลักฐานก่อนรีบูต ถ้ามีเหตุสงสัย เพราะร่องรอยบางส่วนอยู่ในหน่วยความจำ
4. ค้น log เครือข่ายย้อนหลัง หา request ที่เข้าข่ายตามหัวข้อถัดไป
5. เปลี่ยนรหัสผ่านที่เครื่องเก็บไว้ โดยเฉพาะบัญชีที่ VPN ใช้ bind กับ LDAP/AD

ถ้ามีหลายเครื่อง จดเลขรุ่นที่อ่านได้ไว้ในสเปรดชีตแล้วเทียบกับรุ่นเป้าหมายของสายเดียวกันด้วย sort -V จะไม่พลาดเพราะอ่านเลขเอง (ตัวอย่างสาย 25.1.x เท่านั้น สาย 22.8R2.x มีตัวอักษรปน ให้เทียบเลขท้ายด้วยตา)

cur=25.1.1.2; min=25.1.1.3
if [ "$(printf '%s\n' "$min" "$cur" | sort -V | head -n1)" = "$min" ]; then
  echo "OK $cur"
else
  echo "ต้องอัปเดต $cur ต่ำกว่า $min"
fi

ข้อ 5 ในรายการเป็นความเห็นผมเอง ไม่ใช่คำแนะนำที่ Volexity เขียนไว้ตรงๆ แต่ในเมื่อผู้โจมตีดึงรหัสผ่านที่เก็บบนเครื่องไปจริง การเปลี่ยนรหัสผ่านเหล่านั้นเป็นเรื่องที่ควรทำ ลองดูก่อนว่าบัญชี service ที่ VPN ใช้ bind มีสิทธิ์อ่านอะไรใน AD บ้าง

# ต้องมีโมดูล ActiveDirectory (RSAT) บนเครื่องที่รัน
# บัญชีสมมติชื่อ svc-vpn-ldap ดูว่าอยู่กลุ่มอะไร ควรมีสิทธิ์อ่านเท่าที่จำเป็นเท่านั้น
Get-ADPrincipalGroupMembership -Identity svc-vpn-ldap | Select-Object Name

# เปลี่ยนรหัสผ่านบัญชี service (จะถามรหัสใหม่ตอนรัน) แล้วอย่าลืมแก้ค่าบนตัว VPN ให้ตรงกัน
Set-ADAccountPassword -Identity svc-vpn-ldap -Reset -NewPassword (Read-Host -AsSecureString 'new password')

เช็กว่าโดนหรือยัง

Volexity ให้แนวทางค้นไว้ 3 อย่าง และมีรายการ IOC ใน GitHub ของเขา

• request จำนวนมากไปที่ /dana-na/auth/url_default/welcome.cgi ที่มี header X-DSCGI-PATH ชี้ไปยัง wu.cgi หรือพาธใต้ /home/runtime/tmp/ ถ้ามีเครื่องมือที่เทียบ URL กับค่า header ได้ ให้แจ้งเตือนเมื่อสองค่านี้ไม่ตรงกัน
• ไฟล์แปลกใน /tmp/ เช่น สคริปต์ LDAP/Kerberos, ผลลัพธ์ JSON และไฟล์ packet capture
• process หรือไฟล์ชื่อ dsstatmond และโฟลเดอร์ซ่อน .icscap

# log ที่ export จาก WAF / reverse proxy / SIEM (ต้องเป็น log ที่บันทึก request header ไว้)
zgrep -i 'x-dscgi-path' /srv/logs/edge/*.log* | grep -i 'welcome.cgi' | head -n 50

# snapshot หรือ diagnostic bundle ที่แตกไว้ในเครื่องวิเคราะห์ (ไม่ใช่บน appliance)
grep -rIl -e 'dsstatmond' -e '.icscap' /srv/forensics/ics-snapshot/ 2>/dev/null
find /srv/forensics/ics-snapshot \( -name '.icscap' -o -name 'dsstatmond' \) -print

ถ้าไม่มี log ที่เก็บ header ไว้เลย ก็ไม่ได้แปลว่าปลอดภัย แปลว่าไม่มีหลักฐานให้ดู Volexity ระบุให้ใช้ memory และ network forensics กับเครื่องที่สงสัย และถือว่ามีการบุกแล้วถ้าพบว่าการเคลื่อนไหวในวงในเริ่มจากตัว VPN สำหรับเครื่องเซิร์ฟเวอร์ที่อยู่หลัง VPN ค่อยไล่ตรวจต่อตามแนว ตรวจความปลอดภัยเซิร์ฟเวอร์ Debian ได้

ส่วน factory reset ผมหาคำแนะนำของ Ivanti ที่เปิดอ่านได้ไม่เจอ เลยไม่ขอเขียนว่าต้องทำหรือไม่ต้องทำ ให้ตรวจที่หน้า advisory ของ Ivanti เอง

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

ปล. ในไฟล์ KEV ของ CISA ช่อง forensic triage เป็น Yes ของ CVE-2026-104935 และ CVE-2026-111357 แต่เป็น No ของ CVE-2026-118527 ส่วนข้อกำหนด BOD 26-04 อยู่ในทั้งสามรายการ ใครไม่ได้อยู่ในหน่วยงานรัฐสหรัฐฯ ก็ใช้เป็นแนวทางดูได้

ที่มา: CVE record ของ CVE-2026-104935 (https://www.cve.org/CVERecord?id=CVE-2026-104935), CVE-2026-111357 (https://www.cve.org/CVERecord?id=CVE-2026-111357), CVE-2026-118527 (https://www.cve.org/CVERecord?id=CVE-2026-118527), CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), Volexity "A Series of Unauthenticated Events" (https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/), Canadian Centre for Cyber Security AV26-1035 (https://cyber.gc.ca/en/alerts-advisories/ivanti-security-advisory-av26-1035), Cyber Security Agency of Singapore AL-2026-147 (https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-147/) หน้า advisory ของ Ivanti ที่ CVE record อ้างถึง (https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-CVE-2026-104935) ผมเปิดอ่านเนื้อหาไม่ได้ ข้อมูลถึง 5 พ.ย. 2026 ถ้ามีรายละเอียดเพิ่มหรือ Ivanti แก้ข้อมูลรุ่น เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ