ไคลเอนต์ ScreenConnect ปลอมกระจายห่วงโซ่ VBScript สี่ขั้นไปยังเครื่องที่เชื่อมต่อเข้ามาใหม่ — พฤติกรรมคล้าย worm

สรุปสั้น

นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผยกิจกรรมที่มีพฤติกรรมคล้าย worm ซึ่งอาศัยเครื่องมือเข้าถึงระยะไกล ConnectWise ScreenConnect เป็นตัวกระจายเพย์โหลดที่เขียนด้วย Visual Basic Script ไปยังระบบที่เชื่อมต่อเข้ามาใหม่ บริษัท Huntress ระบุว่าพบสามเหตุการณ์ที่ไม่เกี่ยวข้องกัน ซึ่งใช้ช่องทางเข้าถึงครั้งแรกต่างกันไปทั้งสแกมหลอกว่าเป็นฝ่ายสนับสนุนทางเทคนิคที่หลอกให้เหยื่อเปิด Quick Assist ตัวติดตั้ง MSI ที่น่าจะมาจากฟิชชิง และแบบฟอร์มขอคืนเงินของ Geek Squad ปลอม แต่ทั้งสามกรณีนำไปสู่ห่วงโซ่ VBScript สี่ขั้นและการติดตั้งไคลเอนต์ ScreenConnect ปลอมเหมือนกัน เหตุการณ์ทั้งหมดถูกพบในเดือนสิงหาคม 2569

หลังไคลเอนต์ปลอมถูกติดตั้ง Huntress สังเกตว่ามันเรียก wscript.exe ซ้ำ ๆ เพื่อรันสคริปต์ชื่อ 1.vbs, 2.vbs, 3.vbs และ 4.vbs ต่อกันเป็นทอด โดยสคริปต์ตัวแรกทำหน้าที่สำรวจเครื่อง ตรวจทรัพยากรระบบ ตรวจว่ามี ScreenConnect ติดตั้งอยู่แล้วหรือไม่ และไล่รายชื่อผลิตภัณฑ์ด้านความปลอดภัยที่ทำงานอยู่ แล้วบันทึกผลเป็นค่าสถานะสามบิตลงไฟล์ข้อความ ค่าสถานะนั้นเป็นตัวกำหนดว่าเครื่องจะได้รับเพย์โหลดชุดใด ตั้งแต่แบ็กดอร์ระดับผู้ใช้ ไปจนถึงเครื่องมือยกสิทธิ์ผ่านการข้าม UAC และโปรแกรมขุดคริปโตเคอร์เรนซี

จุดที่ทำให้เรื่องนี้ต่างจากการติดตั้ง RMM ปลอมทั่วไปคือขั้นสุดท้ายเขียนไฟล์สคริปต์ทั้งสี่ตัวกลับลงไปในเครื่อง ทำให้เครื่องที่ถูกเจาะกลายเป็นตัวส่งต่อสคริปต์ให้กับเครื่องที่เชื่อมต่อเข้ามาใหม่ทุกครั้ง เกิดเป็นวงจรแพร่กระจายที่ Huntress อธิบายว่า “การเชื่อมต่อเข้าไปยังไคลเอนต์ ScreenConnect ที่ติดเชื้อ อาจทำให้ระบบฝั่งโฮสต์ได้รับและรันห่วงโซ่ VBScript สี่ขั้นชุดเดียวกัน” ด้าน ConnectWise ได้ออกประกาศแจ้งเตือนแล้วว่าพบปัญหาเกี่ยวกับพฤติกรรมการโอนไฟล์ในเซสชัน ซึ่งกระทบทั้งแบบคลาวด์และแบบติดตั้งเอง

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 7 กันยายน 2569 ว่า บริษัท Huntress ได้เปิดเผยรายละเอียดกิจกรรมที่มีพฤติกรรมคล้าย worm ซึ่งใช้ ConnectWise ScreenConnect กระจายเพย์โหลด VBScript ที่เป็นอันตรายไปยังระบบที่เชื่อมต่อเข้ามาใหม่

รายงานระบุว่าสามเหตุการณ์ที่ตรวจพบไม่มีความเกี่ยวข้องกัน และใช้วิธีเข้าถึงครั้งแรกที่หลากหลาย แต่ทั้งหมดจบลงที่การเปิดใช้ห่วงโซ่ VBScript สี่ขั้นซึ่งนำไปสู่การติดตั้ง ScreenConnect ปลอม โดยเหตุการณ์แรกเป็นการโจมตีด้วยวิศวกรรมสังคมที่โน้มน้าวให้ผู้ใช้เปิด Quick Assist ในบริบทของสแกมฝ่ายสนับสนุนทางเทคนิค จากนั้นจึงติดตั้งไคลเอนต์ ScreenConnect ปลอมที่ติดต่อเซิร์ฟเวอร์สั่งการที่ 45.13.237[.]190 (tele-sync.opik[.]net) ซึ่งเป็นที่เก็บไฟล์ RAR บรรจุสคริปต์ VBS ทั้งสี่ไฟล์

เหตุการณ์ที่สองเป็นตัวติดตั้ง MSI ชื่อ ScreenConnect.ClientSetup.msi ที่น่าจะถูกส่งมาทางฟิชชิง โดยติดตั้งไคลเอนต์ที่ถูกตั้งค่าให้สื่อสารกับ 131.123.40[.]98 บนพอร์ต 8041 และไคลเอนต์ปลอมนั้นเรียกสคริปต์ VBScript ทั้งสี่ไฟล์จากไดเรกทอรีชั่วคราวของ ScreenConnect แทบจะทันที

เหตุการณ์ที่สามเริ่มจากการค้นหาแบบฟอร์มขอคืนเงินของ Geek Squad ซึ่งนำไปสู่การติดตั้งไคลเอนต์ปลอมชื่อ ScreenConnect.Client.exe ที่เชื่อมต่อไปยัง borertors92.anondns[.]net จากนั้นเซสชันจึงใช้ wscript.exe รันสคริปต์ VBS ทั้งสี่ไฟล์จากโฟลเดอร์ Temp

Huntress ระบุว่าอย่างน้อยมีเพย์โหลดสามชุดที่แตกต่างกันถูกส่งลงเครื่องตามค่าสถานะที่สคริปต์ตัวแรกกำหนดไว้ โดยค่า 000 และ 001 นำไปสู่แบ็กดอร์ ScreenConnect ระดับผู้ใช้ ค่า 010 นำไปสู่เครื่องมือยกระดับสิทธิ์ผ่านการข้าม User Account Control พร้อมกลไกฝังตัว และค่า 011 นำไปสู่เครื่องมือทำอุโมงค์และโปรแกรมขุดคริปโตเคอร์เรนซี

นอกจากนี้ Huntress ยังพบตัวบ่งชี้ร่วมกันเพิ่มเติม ได้แก่ คีย์ Run ของผู้ใช้ชื่อ WindowsServiceHost ที่ชี้ไปยังไฟล์ WindowsServiceHost.vbs ในไดเรกทอรี AppData ของผู้ใช้ และพบเครื่องมือ RMM ตัวอื่นอย่าง UltraViewer บนเครื่องที่ได้รับผลกระทบบางเครื่องด้วย

ด้วยความซับซ้อนและขอบเขตของห่วงโซ่การโจมตีเหล่านี้ ทีม SOC ของ Huntress จึงแนะนำอย่างหนักแน่นว่าเครื่องที่ได้รับผลกระทบควรถูกติดตั้งระบบใหม่จากสื่อที่เชื่อถือได้ หรือติดตั้งระบบปฏิบัติการใหม่ทั้งหมด ขณะที่ ConnectWise ตอบสนองต่อผลการตรวจสอบนี้ด้วยการออกประกาศแจ้งเตือนว่าพบปัญหาที่กระทบพฤติกรรมการโอนไฟล์ในเซสชัน Remote Access Support และ Access ของ ScreenConnect ซึ่งกระทบทั้งการติดตั้งแบบคลาวด์และแบบติดตั้งเอง และแนะนำให้ลดความเสี่ยงด้วยการปิดสิทธิ์การโอนไฟล์ของช่างเทคนิคไว้ก่อนจนกว่าจะมีตัวแก้

วิธีการโจมตี

ห่วงโซ่ทำงานเป็นสี่ขั้นโดยแต่ละขั้นรอไฟล์ที่ขั้นก่อนหน้าสร้างไว้ ขั้นแรกคือ 1.vbs ทำหน้าที่สำรวจเครื่อง ตรวจทรัพยากรระบบ เช่น หน่วยความจำเกิน 5 GB หรือไม่ ตรวจว่ามี ScreenConnect ติดตั้งอยู่แล้วหรือไม่ และไล่รายชื่อผลิตภัณฑ์ด้านความปลอดภัยที่ทำงานอยู่ ซึ่งครอบคลุม Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos และ Symantec Endpoint Protection แล้วเขียนผลลัพธ์ลง %TEMP%\value.txt ในรูปตัวแปรสถานะสามบิต ตัวอย่างเช่นค่า 000 หมายถึงไม่มี ScreenConnect ติดตั้งอยู่เดิม มีโปรเซสของผลิตภัณฑ์ความปลอดภัยจากผู้ผลิตรายอื่นทำงานอยู่ และไม่มีไคลเอนต์ ScreenConnect ในโฟลเดอร์ Program Files

ขั้นที่สองคือ 2.vbs ซึ่งรอไฟล์ %TEMP%\value.txt แล้วตรวจว่ามีคำว่า abort อยู่หรือไม่ ถ้าไม่มีก็จะดาวน์โหลดไฟล์จาก Dropbox ถอดรหัสเนื้อหาแล้วเขียนลง %TEMP%\map.txt โดยเนื้อหาไฟล์ข้อความนี้ไม่ถูกนำไปรัน และลักษณะที่แท้จริงของเพย์โหลดที่ดึงมายังไม่ชัดเจน เนื่องจากลิงก์ Dropbox นั้นไม่ออนไลน์แล้วตั้งแต่วันที่ 2 กันยายน 2569

ขั้นที่สามคือ 3.vbs ทำงานคล้ายกัน คือรอไฟล์ %TEMP%\map.txt แล้วดาวน์โหลดไฟล์จากลิงก์ Dropbox ที่ระบุไว้ในไฟล์นั้น โดยเลือกตามค่าสถานะที่ 1.vbs กำหนดไว้ใน %TEMP%\value.txt แล้วเขียนผลลัพธ์ลง %TEMP%\out.enc

ขั้นที่สี่คือ 4.vbs ซึ่งรอไฟล์ %TEMP%\out.enc แล้วเรียกสคริปต์ PowerShell ชื่อ %TEMP%\runner.ps1 เพื่อถอดรหัสเนื้อหาของ out.enc เขียนลง %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip แล้วรันสคริปต์ PowerShell ขั้นที่สองชื่อ PyTorchFix.ps1 นอกจากนี้ runner.ps1 ยังปิดโปรเซส wscript.exe และ cscript.exe ทุกตัว และลบไดเรกทอรีที่ใช้เตรียมการทิ้งหลังขั้นสุดท้ายทำงานเสร็จ

กลไกที่ทำให้เกิดการแพร่กระจายอยู่ที่ 4.vbs เช่นกัน เพราะหากค่าใน %TEMP%\value.txt เป็น 010 หรือ 011 สคริปต์จะเขียนไฟล์ VBScript ทั้งสี่ตัวลงที่ C:\Users\Public\Libraries\Default\Lib\Lib1 ซึ่งเปลี่ยนเครื่องที่ถูกเจาะให้กลายเป็นกลไกส่งมอบเนื้อหาให้กับทุกการเชื่อมต่อใหม่ที่ไคลเอนต์แบ็กดอร์มองเห็น Huntress อธิบายเพิ่มว่า “ต่อมาไคลเอนต์จะบันทึก ConnectionID ของแต่ละการเชื่อมต่อไว้เพื่อเลี่ยงการเล่นงานเซสชันเดิมซ้ำ แต่จะลบตัวระบุนั้นทิ้งเมื่อเซสชันหลุด ทำให้การเชื่อมต่อกลับเข้ามาใหม่ในภายหลังกระตุ้นการติดเชื้อได้อีกครั้ง”

ส่วนสาขาค่าสถานะ 011 ซึ่งหมายถึงไม่มี ScreenConnect ติดตั้งอยู่เดิม มีเพียง Microsoft Defender เป็นโปรแกรมป้องกันเครื่องปลายทางตัวเดียวบนเครื่อง และไม่มีไคลเอนต์ ScreenConnect อยู่ จะได้รับเพย์โหลดที่ปิดการรายงานผลของ Microsoft Defender ปิด Windows memory integrity และรันโปรแกรมขุดเหรียญ XMRig

ผลกระทบ

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

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

ในแง่การกำจัด คำแนะนำของ Huntress ที่ให้ล้างเครื่องแล้วติดตั้งใหม่ไม่ใช่คำแนะนำที่เกินเลย เพราะสาขาที่ยกสิทธิ์ผ่านการข้าม UAC มีการฝังตัวและมีการแก้ค่าการป้องกันของระบบ ทั้งการปิดการรายงานผลของ Defender และการปิด memory integrity ซึ่งเป็นการเปลี่ยนแปลงที่ยังค้างอยู่แม้จะลบตัวมัลแวร์ออกไปแล้ว

ข้อจำกัดของหลักฐานที่ควรระบุคือ เนื้อหาที่ 2.vbs ดึงมาจาก Dropbox ยังไม่มีใครระบุได้ว่าคืออะไร เพราะลิงก์ถูกปิดไปตั้งแต่วันที่ 2 กันยายน 2569 และรายงานไม่ได้ระบุจำนวนเหยื่อ ขอบเขตทางภูมิศาสตร์ หรือตัวตนของผู้อยู่เบื้องหลัง ทั้งสามเหตุการณ์เป็นเหตุการณ์ที่ไม่เกี่ยวข้องกันตามที่ Huntress ระบุ จึงยังสรุปไม่ได้ว่าเป็นกลุ่มเดียวกันหรือเป็นชุดเครื่องมือที่ถูกแบ่งปันกันใช้

คำแนะนำ

ปิดสิทธิ์การโอนไฟล์ของช่างเทคนิคใน ScreenConnect ตามคำแนะนำของ ConnectWise จนกว่าจะมีตัวแก้ โดยเข้าหน้า Administration แล้วไปที่ Security > Roles แก้ไขบทบาทที่ผูกกับผู้ใช้ และในหน้าต่าง Scoped Permissions ของแต่ละกลุ่มเซสชัน ให้ยกเลิกสิทธิ์ TransferFiles หรือ TransferFilesInSession สำหรับเวอร์ชันเก่า แล้วบันทึกค่า ทำซ้ำกับทุกบทบาทที่มีอยู่

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

ตั้งการแจ้งเตือนเมื่อพบ wscript.exe หรือ cscript.exe ถูกเรียกจากไดเรกทอรีชั่วคราวหรือจากไดเรกทอรีของ ScreenConnect รวมถึงการสร้างไฟล์ในเส้นทาง C:\Users\Public\Libraries\Default\Lib\Lib1 และคีย์ Run ชื่อ WindowsServiceHost ที่ชี้ไปยัง WindowsServiceHost.vbs ใน AppData

เฝ้าระวังการเปลี่ยนแปลงค่าความปลอดภัยของระบบ โดยเฉพาะการปิดการรายงานผลของ Microsoft Defender และการปิด memory integrity ซึ่งเป็นร่องรอยของสาขาที่ติดตั้งโปรแกรมขุดเหรียญ และเป็นค่าที่ต้องตรวจคืนแม้จะกำจัดมัลแวร์ไปแล้ว

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

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

Indicators of Compromise (IoCs)

หมายเหตุ: ไอพีและโดเมนข้างต้นถูก defang แล้วเพื่อป้องกันการคลิกโดยไม่ตั้งใจ

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

• Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts — The Hacker News
• Rogue ScreenConnect Installations — Huntress
• ConnectWise Trust Center — Advisories