ปฏิบัติการ Dragon Weave: เปิดโปงปฏิบัติการที่เชื่อมโยงกับจีนซึ่งมุ่งเป้าไปที่สาธารณรัฐเช็กและไต้หวัน โดยใช้ระบบควบคุมและสั่งการบนคลาวด์ Azure

เนื้อหา

• บทนำ
• เป้าหมายสำคัญ
  • อุตสาหกรรมที่ได้รับผลกระทบ
  • การมุ่งเน้นทางภูมิศาสตร์
• ห่วงโซ่การติดเชื้อ
• การค้นพบเบื้องต้น
  • ตรวจสอบเอกสารล่อลวง
• การวิเคราะห์ทางเทคนิค
  • ขั้นตอนที่ 1 – การส่งมอบครั้งแรก
    • เส้นทาง A: การประมวลผลแบบ LNK
    • เส้นทาง B: การส่งมอบโดยใช้ไฟล์ปฏิบัติการ
  • ขั้นตอนที่ 2 – ห่วงโซ่ดรอปเปอร์แบบใช้สคริปต์
  • ขั้นตอนที่ 3 – RUSTCLOAK (Rust Loader)
  • ขั้นตอนที่ 4 – AZUREVEIL (เอเจนต์ Adaptix C2)
• โครงสร้างพื้นฐานและการระบุแหล่งที่มา
• สรุป
• SEQRITE การป้องกัน
• ตัวบ่งชี้การประนีประนอม (IOCs)
• การแมป MITRE ATT&CK
• Authors

บทนำ

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

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

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

นอกจากนี้ เรายังวิเคราะห์การเข้ารหัสหลายชั้นที่ใช้ในการปกป้องเพย์โหลดและวิธีการที่ช่วยให้ผู้โจมตีหลบเลี่ยงการตรวจจับ บล็อกนี้ยังนำเสนอตัวบ่งชี้สำคัญของการถูกบุกรุก (IOCs) เน้นย้ำข้อค้นพบที่สำคัญจากการวิเคราะห์ของเรา และเชื่อมโยงพฤติกรรมที่สังเกตได้กับเทคนิค MITRE ATT&CK เพื่อสนับสนุนการระบุตัวตนของแคมเปญนี้ว่าเป็นผู้ก่อภัยคุกคามที่เชื่อมโยงกับประเทศจีน

เป้าหมายสำคัญ

อุตสาหกรรมที่ได้รับผลกระทบ

• ภาครัฐและภาครัฐ
• งานวิจัยและวิชาการ
• เทคโนโลยีและซอฟต์แวร์
• บริการทางการเงิน

การมุ่งเน้นทางภูมิศาสตร์

• สาธารณรัฐเช็ก
• ไต้หวัน

ห่วงโซ่การติดเชื้อ

การค้นพบเบื้องต้น

ในฐานะส่วนหนึ่งของความพยายามในการติดตามภัยคุกคามอย่างต่อเนื่องของเรา SEQRITE ทีมแล็บตรวจพบไฟล์ ZIP ที่น่าสงสัยบนเครื่อง threat intelแพลตฟอร์มไลเจนซ์ VirusTotal.

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

หลังจากวิเคราะห์เนื้อหาของไฟล์ ZIP ที่แตกออกมาแล้ว เราพบไฟล์ที่น่าสงสัยหลายไฟล์ รวมถึงโฟลเดอร์ชื่อdataไฟล์ทางลัด 計畫申請審查結果通知單.pdf.lnk ที่ปลอมตัวเป็นเอกสาร PDF และไฟล์ปฏิบัติการ _計畫申請審查結果通知單.exe ที่ปลอมตัวเป็นไฟล์ปกติ ชื่อไฟล์แปลว่า“แจ้งผลการพิจารณาใบสมัครโครงการ”ซึ่งบ่งชี้ว่ามีความพยายามที่จะปลอมตัวเป็นเอกสารทางการ ชื่อไฟล์เขียนด้วยภาษาจีนตัวเต็ม ซึ่งเป็นภาษาที่ใช้กันทั่วไปในไต้หวัน ซึ่งยิ่งบ่งชี้ว่าแคมเปญนี้มุ่งเป้าไปที่ผู้ใช้ในภูมิภาคดังกล่าว

หลังจากวิเคราะห์เนื้อหาในโฟลเดอร์ข้อมูลแล้ว เราพบไฟล์หลายไฟล์ที่เกี่ยวข้องกับขั้นตอนต่างๆ ของห่วงโซ่การติดเชื้อ รวมถึงคอนเทนเนอร์เพย์โหลดที่เข้ารหัส (1.dat และ Com.dat) ไฟล์สคริปต์ (Profile.ps1 และ empty.vbs) ไฟล์ DLL ที่เป็นอันตรายซึ่งใช้สำหรับการติดตั้งแบบ sideloading (UnityPlayer.dll) และไฟล์ PDF ล่อลวงที่ใช้เพื่อเบี่ยงเบนความสนใจของเหยื่อ

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

ตรวจสอบเอกสารล่อลวง

หลังจากตรวจสอบเนื้อหาของไฟล์ ZIP แล้ว เราพบเอกสารล่อลวงอยู่ในโฟลเดอร์ data/ ชื่อ 000b67d70f3876965bb09fd37164b7.pdf นอกจากนี้ เมื่อวิเคราะห์ไฟล์ปฏิบัติการหลัก _計畫申請審查結果通知單.exe เรายังพบเอกสารล่อลวงอีกฉบับฝังอยู่ภายในไฟล์ไบนารีนั้นเอง เมื่อมองแวบแรก เอกสารทั้งสองดูคล้ายกันเนื่องจากชื่อ แต่เนื้อหาแตกต่างกัน

เอกสารที่ 1: เหยื่อล่อที่พบในโฟลเดอร์ data/

พบไฟล์ 000b67d70f3876965bb09fd37164b7.pdf ภายในโฟลเดอร์ data/ และไฟล์นี้ถูกเข้ารหัสโดยใช้การดำเนินการ XOR แบบไบต์เดียวด้วยคีย์ 0xBE เมื่อถอดรหัสแล้ว พบว่าเอกสารดังกล่าวเขียนด้วยภาษาจีนและมีเนื้อหาที่เกี่ยวข้องกับโฆษณาซอฟต์แวร์ WPS ในรูปแบบ PDF แม้ว่าจะมีรูปแบบการตั้งชื่อคล้ายกับเอกสารล่อลวงที่ฝังอยู่ในไฟล์ปฏิบัติการ แต่ไฟล์นี้ไม่ได้ถูกอ้างอิงหรือใช้งานในขั้นตอนใด ๆ ของห่วงโซ่การติดเชื้อเลย

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

เอกสาร 2: Embedded Decoy Inside _計畫申請審查結果通知單.exe.exe

ไฟล์ล่อลวงถูกฝังอยู่ภายในไฟล์ปฏิบัติการ _計畫申請審查結果通知單.exe และเป็นเอกสารที่แสดงให้เหยื่อเห็นระหว่างการทำงาน เอกสารมีชื่อว่า 000b67d70f3876965bb09fd37164b7ccrezervaci.pdf ซึ่งเป็นการรวมสตริงคล้ายแฮชเข้ากับคำภาษาเช็ก (“rezervaci”) เอกสารเขียนด้วยภาษาเช็กและดูเหมือนจะเป็นหนังสือแจ้งนัดหมายจากสำนักงานประกันสังคมแห่งสาธารณรัฐเช็ก (ČSSZ) ซึ่งน่าจะคัดลอกมาจากเว็บไซต์ทางการ cssz.cz เอกสารประกอบด้วยรายละเอียดต่างๆ เช่น การนัดหมายสำหรับบุคคลชื่อZuzana Koškováในวันที่ 16 มีนาคม 2026 ทำให้ดูเหมือนเป็นเอกสารที่ออกโดยรัฐบาลจริง

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

เอกสารนี้ยังรวมถึงลิงก์ไปยังเว็บไซต์อย่างเป็นทางการของสำนักงานประกันสังคมแห่งสาธารณรัฐเช็ก (ČSSZ) สำหรับการจัดการหรือยกเลิกการนัดหมาย ดูเหมือนว่าเอกสารนี้จะถูกสร้างขึ้นโดยการบันทึกหรือพิมพ์เว็บไซต์ต้นฉบับเป็นไฟล์ PDF

ในส่วนถัดไป เราจะพิจารณาถึงแง่มุมทางเทคนิคของแคมเปญนี้

การวิเคราะห์ทางเทคนิค

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

ในเส้นทาง Aการติดเชื้อจะเริ่มต้นเมื่อเหยื่อคลิกไฟล์ LNK ที่เป็นอันตราย 計畫申請審查結果通知單.pdf.lnk การกระทำนี้จะเรียกใช้สคริปต์ VBScript (empty.vbs) โดยไม่แจ้งให้ทราบล่วงหน้า จากนั้นสคริปต์ VBScript จะเรียกใช้สคริปต์ PowerShell (Profile.ps1) สคริปต์ PowerShell นี้มีหน้าที่ถอดรหัสไฟล์1.datเขียนเนื้อหาที่ถอดรหัสแล้วลงในไฟล์ RuntimeBroker_update.exe และเรียกใช้ไฟล์นั้น

ในเส้นทาง Bเหยื่อจะเรียกใช้ไฟล์ _計畫申請審查結果通知單.exe โดยตรง ไฟล์ปฏิบัติการนี้ทำหน้าที่เป็นตัวติดตั้งแบบครบวงในตัวที่ใช้ภาษา Rust ซึ่งจะแยกส่วนประกอบที่จำเป็นทั้งหมดออกมาเอง จากนั้นจึงเรียกใช้ไฟล์ RuntimeBroker_update.exe ตัวเดียวกัน

แม้ว่าขั้นตอนเริ่มต้นจะแตกต่างกัน แต่ทั้งสองเส้นทางก็จบลงที่ขั้นตอนเดียวกัน RuntimeBroker_update.exe โหลดไฟล์ UnityPlayer.dll ที่เป็นอันตรายโดยใช้การโหลด DLL จากด้านข้าง ซึ่งนำไปสู่การเรียกใช้ตัวโหลดที่ใช้ Rust ที่เราเรียกว่าRUSTCLOAKตัวโหลดนี้จะถอดรหัสและเรียกใช้เพย์โหลดสุดท้ายAZUREVEILซึ่งเป็นเอเจนต์ C2 ของ Adaptix

ขั้นตอนที่ 1 – การส่งมอบครั้งแรก

เส้นทาง A: การประมวลผลแบบ LNK

วิธีการส่งมัลแวร์วิธีแรกเริ่มต้นด้วยไฟล์ทางลัดของ Windows ที่เป็นอันตรายชื่อ 計畫申請審查結果通知單.pdf.lnk ซึ่งแปลว่า “ประกาศผลการพิจารณาใบสมัครโครงการ.pdf” การใช้ส่วนขยายสองชั้น ( .pdf.lnk ) เป็นไปโดยเจตนา เพื่อให้ไฟล์ดูเหมือนเอกสาร PDF ทั่วไป

ไฟล์ LNK นี้ถูกตั้งค่าให้เรียกใช้ wscript.exe จากไดเร็กทอรีระบบของ Windows โดยส่ง .\data\empty.vbs เป็นอาร์กิวเมนต์ แทนที่จะเปิดไฟล์ PDF ทางลัดนี้จะเรียกใช้ไฟล์ VBScript นี้ในพื้นหลังโดยไม่แสดงข้อความใดๆ ในขณะเดียวกันก็ใช้ไอคอน Microsoft Edge เพื่อให้ดูเหมือนเอกสารปกติ

เส้นทาง B: การส่งมอบโดยใช้ไฟล์ปฏิบัติการ

วิธีการส่งมอบแบบที่สองใช้ไฟล์ปฏิบัติการที่คอมไพล์ด้วย Rust ชื่อ _計畫申請審查結果通知單.exe ไฟล์นี้ทำหน้าที่เป็นตัวติดตั้งแบบสมบูรณ์ โดยมีส่วนประกอบที่จำเป็นทั้งหมดฝังอยู่ภายใน จึงไม่จำเป็นต้องพึ่งพาไฟล์ภายนอกใดๆ จากไฟล์ ZIP

ระหว่างการวิเคราะห์แบบไดนามิก เราพบว่าไฟล์ไบนารีนี้ดำเนินการหลายอย่างด้วยตัวเอง ขั้นแรก มันจะสร้างไดเร็กทอรีที่ %LOCALAPPDATA%\WebViewFixUtility เพื่อจัดเก็บไฟล์ของมัน จากนั้นมันจะปล่อยส่วนประกอบหลายอย่าง รวมถึง BrowserViewUtility.exe (ไฟล์ปฏิบัติการที่ถูกต้องซึ่งใช้สำหรับการติดตั้งแบบ sideloading), UnityPlayer.dll ที่เป็นอันตราย (RUSTCLOAK), ไฟล์การกำหนดค่าที่เข้ารหัส, เอกสารล่อ (000b67d70f3876965bb09fd37164b7ccrezervaci.pdf) และ RuntimeBroker_update.exe

ขั้นตอนที่ 2 – ห่วงโซ่ดรอปเปอร์แบบใช้สคริปต์

เส้นทาง Bจัดการทุกอย่างภายใน ดังนั้นจากตรงนี้เราจะมุ่งเน้นเฉพาะเส้นทาง Aซึ่งเป็นกระบวนการแบบสคริปต์ที่เคลื่อนผ่านส่วนประกอบเพิ่มเติมอีกสามส่วน ได้แก่ empty.vbs, Profile.ps1 และ 1.dat แต่ละส่วนมีบทบาทในการเตรียมและเรียกใช้ไฟล์ไบนารีสุดท้าย RuntimeBroker_update.exe ซึ่งจะถูกนำไปใช้สำหรับการโหลด DLL ในภายหลัง

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

หลังจากวิเคราะห์สคริปต์ VB แล้ว เราพบว่ามันเป็นสคริปต์ VB ขนาดเล็กมากที่มีจุดประสงค์เดียวคือการเรียกใช้ไฟล์ Profile.ps1 โดยใช้ PowerShell มันเรียกใช้ PowerShell โดยเปิดใช้งานการข้ามการตรวจสอบนโยบายการเรียกใช้ และทำงานในหน้าต่างที่ซ่อนอยู่ ดังนั้นผู้ใช้จึงมองไม่เห็นอะไรเลย สคริปต์เองไม่มีตรรกะที่แท้จริงใดๆ และทำหน้าที่เป็นเพียงสะพานเชื่อมไปยังขั้นตอนต่อไปเท่านั้น

ตรรกะหลักของกระบวนการแพร่เชื้อถูกจัดการโดย Profile.ps1 สคริปต์นี้อ่านไฟล์ 1.datจาก โฟลเดอร์ data/และถอดรหัสโดยใช้การดำเนินการ XOR อย่างง่ายกับคีย์ที่กำหนดไว้ล่วงหน้า P@ssw0rd_am_2026 หลังจากถอดรหัสแล้ว ไฟล์จะกลายเป็นRuntimeBroker_update.exeซึ่งจะถูกเขียนลงดิสก์

สคริปต์นี้ยังย้ายไฟล์ UnityPlayer.dll และ Com.dat ไปยังไดเร็กทอรี %TEMP% เพื่อให้ส่วนประกอบที่จำเป็นทั้งหมดอยู่รวมกัน เมื่อทุกอย่างพร้อมแล้ว สคริปต์จะเรียกใช้ RuntimeBroker_update.exe ในพื้นหลังและเปิดเอกสารล่อเพื่อเบี่ยงเบนความสนใจของผู้ใช้

ไฟล์ 1.dat ไม่ใช่ไฟล์ปฏิบัติการทั่วไป มันเป็นคอนเทนเนอร์ที่เข้ารหัสแบบ XOR ซึ่งบรรจุไฟล์ RuntimeBroker_update.exe การเข้ารหัสทำได้ง่ายและใช้คีย์สั้นๆ น่าจะเป็นเพื่อหลีกเลี่ยงการตรวจจับขั้นพื้นฐาน เมื่อถอดรหัสโดย Profile.ps1 แล้ว ไฟล์ปฏิบัติการจริง RuntimeBroker_update.exe จะถูกสร้างและเรียกใช้งาน

ดังที่ได้อธิบายไว้ก่อนหน้านี้ แคมเปญนี้ใช้จุดเริ่มต้นสองจุดที่แตกต่างกัน ขึ้นอยู่กับว่าเหยื่อมีปฏิสัมพันธ์กับไฟล์เก็บถาวรอย่างไร ทั้งสองเส้นทางจะส่งเพย์โหลดเดียวกันคือ RuntimeBroker_update.exe ในท้ายที่สุด แต่มีวิธีการที่แตกต่างกัน เส้นทาง A ใช้สคริปต์แบบหลายขั้นตอนซึ่งเริ่มต้นเมื่อเหยื่อคลิกไฟล์ LNK ในขณะที่เส้นทาง B เป็นแบบครบวงจรและต้องการเพียงแค่ให้เหยื่อเรียกใช้ไฟล์ปฏิบัติการเท่านั้น

ขั้นตอนที่ 3 – RUSTCLOAK (Rust Loader)

เส้นทางทั้งสองมาบรรจบกันที่นี่ และตอนนี้ RuntimeBroker_update.exe กำลังทำงานอยู่ สิ่งแรกที่ Windows ทำคือค้นหา UnityPlayer.dll ในโฟลเดอร์เดียวกัน ผู้โจมตีใช้ประโยชน์จากจุดนี้โดยการวาง UnityPlayer.dll ที่เป็นอันตรายไว้ในโฟลเดอร์เดียวกัน ด้วยเหตุนี้ Windows จึงโหลด DLL ของผู้โจมตีแทนที่จะเป็น DLL ที่ถูกต้อง

DLL นี้ ซึ่งเราเรียกว่า RUSTCLOAK เป็นโปรแกรมโหลดที่เขียนด้วยภาษา Rust ทำหน้าที่ดำเนินการต่อในลำดับการประมวลผลและเตรียมข้อมูลปลายทางให้พร้อม

สิ่งประดิษฐ์ของนักพัฒนา

หนึ่งในข้อค้นพบสำคัญระหว่างการวิเคราะห์RUSTCLOAKคือข้อผิดพลาดด้านความปลอดภัยในการปฏิบัติงานของผู้โจมตี เส้นทางการสร้าง Rust C:\Users\dell2\.cargo\registry\src\ index.crates.io-1949cf8c6b5b557f\ src\decrypt_SM4.rs ถูกทิ้งไว้ภายในไบนารีในรูปแบบข้อความธรรมดา ทำให้รายละเอียดจากระบบของผู้พัฒนาถูกเปิดเผย:

ข้อมูลนี้เปิดเผยชื่อผู้ใช้ Windows ของนักพัฒนาคือ dell2 และเวอร์ชันไลบรารีเฉพาะที่ใช้ เช่น libsm-0.5.1 สำหรับการเข้ารหัส SM4 และ base64-0.21.7 สำหรับการดำเนินการ Base64

การต่อต้านการวิเคราะห์: การตรวจจับแซนด์บ็อกซ์

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

หากพบการจับคู่ โปรแกรมโหลดจะหยุดทำงานทันทีโดยไม่เรียกใช้เพย์โหลด รายชื่อดังกล่าวประกอบด้วยชื่อที่ใช้กันทั่วไป เช่นDESKTOP-NAKFFMT , JULIA-PCและARCHIBALD-PCซึ่งมักพบเห็นได้ในการตั้งค่าการวิเคราะห์อัตโนมัติ การตรวจสอบนี้ช่วยให้มัลแวร์หลีกเลี่ยงการตรวจจับระหว่างการวิเคราะห์ได้

ห่วงโซ่การถอดรหัสสามชั้น

เมื่อโหลดRUSTCLOAK แล้ว โปรแกรมจะอ่านข้อมูลที่เข้ารหัส (Com.dat) จากดิสก์และประมวลผลผ่านกระบวนการถอดรหัสหลายชั้นก่อนที่จะสามารถเรียกใช้งานได้

ชั้นที่ 1: การถอดรหัส RC4 แบบกำหนดเอง – ขั้นตอนแรกใช้อัลกอริทึม RC4 ที่ได้รับการดัดแปลง คีย์ที่ใช้ในขั้นตอนนี้คือ: F8 83 40 17 1D 66 AA C2 B0 25 A8 6C A0 DD C4 5A

ชั้นที่ 2: การถอดรหัส Base64 – หลังจากขั้นตอน RC4 แล้ว ผลลัพธ์ยังไม่สามารถใช้งานได้โดยตรง เนื่องจากถูกเข้ารหัสในรูปแบบ Base64 ดังนั้นตัวโหลดจึงถอดรหัสเพื่อให้ได้ข้อมูลไบนารีที่แท้จริงสำหรับขั้นตอนต่อไป

ชั้นที่ 3: การถอดรหัส SM4-CBC – ในขั้นตอนสุดท้าย ข้อมูลจะถูกถอดรหัสโดยใช้ SM4 ในโหมด CBC คีย์และเวกเตอร์เริ่มต้นที่ใช้มีดังนี้:

รหัส: CD CE 4F DB 3E 6A F2 44 AC 62 8C F4 96 1F 6B FB
IV: เอฟเอ 70 B1 81 A0 บริติชแอร์เวย์ 5D 46 7A 5D 40 DD 99 B6 9B 42

การประมวลผลในหน่วยความจำผ่านไฟเบอร์ของ Windows

เมื่อกระบวนการถอดรหัสเสร็จสมบูรณ์RUSTCLOAKจะจัดสรรหน่วยความจำโดยใช้ VirtualAlloc และคัดลอกเชลล์โค้ดที่ถอดรหัสแล้วลงไป จากนั้นจะเปลี่ยนสิทธิ์การเข้าถึงหน่วยความจำให้สามารถเรียกใช้งานได้โดยใช้ VirtualProtect ก่อนที่จะรันเพย์โหลด

แทนที่จะสร้างเธรดใหม่ ซึ่งมักถูกตรวจสอบโดยเครื่องมือรักษาความปลอดภัย มันใช้ไฟเบอร์ของ Windows ในการประมวลผล ตัวโหลดจะเรียก CreateFiberEx แล้วจึงเรียก SwitchToFiber เพื่อส่งการควบคุมไปยังเชลล์โค้ด

ระหว่างการตรวจสอบข้อผิดพลาดของตัวโหลด เราพบว่ามันจัดสรรพื้นที่หน่วยความจำขนาดใหญ่และคัดลอกข้อมูลที่ถอดรหัสแล้วเข้าไปในนั้น เมื่อตรวจสอบพื้นที่หน่วยความจำอย่างละเอียด เราพบส่วนหัว PE ที่ถูกต้อง (MZ) ซึ่งยืนยันว่าเชลล์โค้ดนั้นมีไฟล์ปฏิบัติการที่สมบูรณ์ฝังอยู่ภายใน ขนาดของข้อมูลในหน่วยความจำนี้มีขนาดประมาณ 103 KB

เราแยกไฟล์ PE ที่อยู่ในหน่วยความจำนี้ออกมาได้ระหว่างการดีบัก ซึ่งปรากฏว่าเป็นเพย์โหลดสุดท้ายคือAZUREVEILนี่แสดงให้เห็นว่าRUSTCLOAKไม่ได้แค่รันเชลล์โค้ดดิบๆ โดยตรง แต่จะถอดรหัสและโหลดไฟล์ปฏิบัติการฉบับเต็มลงในหน่วยความจำก่อน แล้วจึงถ่ายโอนการทำงานไปยังไฟล์นั้น

ขั้นตอนที่ 4 – AZUREVEIL (เอเจนต์ Adaptix C2)

AZUREVEIL คือเพย์โหลดสุดท้ายและเป็นส่วนที่น่าสนใจทางเทคนิคที่สุดของแคมเปญนี้

หลังจากวิเคราะห์ไฟล์โดยใช้ DIE แล้ว เราพบว่าAZUREVEILเป็นเอเจนต์ Adaptix C2 ที่มีคุณสมบัติครบถ้วน ซึ่งคอมไพล์เป็น DLL 64 บิตโดยใช้ MinGW C++

ระหว่างการวิเคราะห์บน VirusTotal ตัวอย่างดังกล่าวถูกระบุว่าเป็นมัลแวร์โดยผู้จำหน่ายหลายราย โดยการตรวจจับชี้ไปที่การกำหนดค่าฝังตัวที่เชื่อมโยงกับตระกูลมัลแวร์ Adaptix

เราพบว่าAZUREVEIL สามารถเรียกใช้ API ของ Windows ได้ประมาณ 87 รายการในระหว่างการทำงาน โดยใช้วิธีการแฮชแบบ djb2 โดยจะโหลด API เหล่านี้จากไลบรารีหลัก เช่นwininet.dll , Ws2_32.dll , Advapi32.dll , Iphlpapi.dllและmsvcrt.dll

การสื่อสาร C2 ของ Azure Blob Storage

จากการวิเคราะห์ของเรา เราพบว่าAZUREVEILใช้ Microsoft Azure Blob Storage สำหรับการสื่อสารควบคุมและสั่งการ ส่วนที่น่าสนใจคือกลไก C2 เนื่องจากไม่มีเซิร์ฟเวอร์ C2 แบบดั้งเดิมเลย มัลแวร์เพียงแค่สื่อสารกับ Azure Blob Storage ซึ่งเป็นบริการเดียวกันกับที่องค์กรธุรกิจที่ถูกต้องตามกฎหมายหลายพันแห่งทั่วโลกใช้งานอยู่

C2 Endpoint: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net

แทนที่จะใช้โมเดล C2 แบบดึงข้อมูล (pull-based) แบบดั้งเดิมAZUREVEILใช้แนวทางแบบส่งถึงที่ (dead-drop) แทน ผู้โจมตีและระบบที่ติดไวรัสจะไม่สื่อสารกันโดยตรง แต่ทั้งสองฝ่ายจะใช้คอนเทนเนอร์จัดเก็บข้อมูล Azure เดียวกันในการแลกเปลี่ยนข้อมูล

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

ความสามารถในการสั่งการของ AZUREVEIL

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

การดำเนินการระบบไฟล์

• แสดงรายการเนื้อหาในไดเร็กทอรีและไดรฟ์เชิงตรรกะ
• อ่าน ย้าย เปลี่ยนชื่อ และลบไฟล์
• ส่งออกไฟล์ไปยัง Azure Blob Storage
• ลากไฟล์จากเซิร์ฟเวอร์ควบคุม (C2) ไปยังระบบของเหยื่อ
• จัดคิวการดาวน์โหลดไฟล์

การควบคุมกระบวนการและเปลือกหุ้ม

• ดำเนินการคำสั่งเชลล์
• แสดงรายการกระบวนการที่กำลังทำงานและท่อส่งชื่อ
• กำหนดค่าและยุติกระบวนการ
• ยุติกระบวนการหรือปิดท่อส่งข้อมูล

เครือข่ายและการเปลี่ยนทิศทาง

• การส่งต่อพอร์ตและการควบคุมพร็อกซี SOCKS
• การเชื่อมต่อแบบ Pivot ของ TCP และ UDP
• การสื่อสารแบบท่อชื่อ
• การระบุข้อมูลอะแดปเตอร์เครือข่าย (MAC, IP, ประเภท)

ซี2 แมเนจเมนต์

• กำหนดค่าการตั้งค่า C2 ใหม่ในระหว่างการทำงาน
• ควบคุมสถานะการถ่ายโอนไฟล์
• ตรวจสอบระยะเวลาการทำงานของระบบ

การประมวลผลโค้ดในหน่วยความจำ

• เรียกใช้ไฟล์ Beacon Object (BOF) ทั้งหมด
  เก็บไว้ในหน่วยความจำโดยไม่ต้องเขียนลงดิสก์

เอ็นจิ้นการดำเนินการ BOF

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

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

เมื่อได้รับไฟล์ BOF แล้ว AZUREVEIL จะจัดสรรหน่วยความจำและโหลดส่วนต่างๆ ของไฟล์อ็อบเจ็กต์ลงในหน่วยความจำนั้นก่อน จากนั้นจึงดำเนินการย้ายตำแหน่งที่จำเป็นและแก้ไขการอ้างอิงฟังก์ชันโดยใช้การค้นหาแบบแฮชภายใน หลังจากตั้งค่าทุกอย่างเสร็จแล้ว ตัวโหลดจะเรียกใช้จุดเริ่มต้นของไฟล์ BOF โดยตรงภายในกระบวนการของเอเจนต์

ข้อมูลเอาต์พุตใดๆ ที่สร้างขึ้นระหว่างการดำเนินการจะถูกดักจับโดยใช้ named pipe จากนั้นส่งกลับไปยังผู้โจมตีผ่าน Azure Blob Storage วิธีนี้ช่วยให้ผู้โจมตีสามารถเรียกใช้ฟังก์ชันเพิ่มเติมบนระบบและรับผลลัพธ์กลับมาได้ โดยที่ยังคงทำงานอยู่ภายในหน่วยความจำทั้งหมด

โครงสร้างพื้นฐานและการระบุแหล่งที่มา

จากการวิเคราะห์ของเรา เราพบว่าAZUREVEILสื่อสารผ่าน Microsoft Azure Blob Storage โดยสมบูรณ์ ซึ่งเป็นการใช้ประโยชน์จากโครงสร้างพื้นฐานคลาวด์ที่ถูกต้องตามกฎหมายเพื่อการควบคุมและสั่งการ แทนที่จะใช้เซิร์ฟเวอร์ C2 แบบดั้งเดิม ผู้โจมตีอาศัยบัญชีเก็บข้อมูล Azure เฉพาะ: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net

จากการวิเคราะห์เพิ่มเติมพบรายละเอียดเกี่ยวกับการตั้งค่าการจัดเก็บข้อมูลดังต่อไปนี้:

คอนเทนเนอร์: /note/ats/
รูปแบบ Blob: {agent_id}/{timestamp1}_{timestamp2}.bin
รหัสตัวแทน: 345831bc
พอร์ต: 443 (HTTPS)

การสื่อสารทั้งหมดเกิดขึ้นผ่าน HTTPS บนพอร์ต 443 ซึ่งทำให้การรับส่งข้อมูลกลมกลืนกับกิจกรรมปกติของ Azure เนื่องจาก blob.core.windows.net ถูกใช้งานอย่างแพร่หลายโดยแอปพลิเคชันที่ถูกต้องตามกฎหมาย วิธีนี้จึงช่วยให้ผู้โจมตีหลีกเลี่ยงการตรวจจับในระดับเครือข่ายได้

นอกจากนี้ เรายังพบโทเค็น Shared Access Signature (SAS) ที่ถูกกำหนดไว้ตายตัวภายใน encrypted_blob ซึ่งถูกสร้างขึ้นโดยไฟล์ปฏิบัติการ _計畫申請審查結果通知單.exe ซึ่งใช้ในการตรวจสอบสิทธิ์การดำเนินการทั้งหมดบนบัญชีเก็บข้อมูล:

sv=2024-11-04&ss=b&srt=sco&sp=rwdlaciytfx&st=2026-03-19T09:20:44Z&se=2027-03-19T17:35:44Z&spr=https&sig=ECJjJIIE9Ou75dwiHhliC4fWccdBpLX9u580AX9TGwY=

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

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

สรุป

ปฏิบัติการ Dragon Weaveเป็นแคมเปญจารกรรมข้อมูลที่มุ่งเป้าหมายโดยเฉพาะ หนึ่งในลักษณะเฉพาะของแคมเปญนี้คือการใช้ Microsoft Azure Blob Storage เป็นช่องทางควบคุมและสั่งการ (C2) แบบซ่อนเร้น แทนที่จะสื่อสารกับเซิร์ฟเวอร์ C2 ปกติ มัลแวร์จะผสมผสานการรับส่งข้อมูลเข้ากับกิจกรรมบนคลาวด์ปกติ ทำให้ตรวจจับได้ยากขึ้นมาก เพย์โหลดสุดท้าย AZUREVEIL เป็นเอเจนต์ C2 ของ Adaptix ที่มีคุณสมบัติครบถ้วน พร้อมคำสั่งหลังการโจมตี 36 คำสั่ง พร้อมกับความสามารถในการเรียกใช้ BOF ในหน่วยความจำ ทำให้ผู้โจมตีมีความยืดหยุ่นสูงในการเรียกใช้โค้ดเพิ่มเติมและควบคุมระบบโดยไม่ทิ้งข้อมูลใดๆ ไว้บนดิสก์มากนัก

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

SEQRITE การป้องกัน

Lnk.Trojan.50646.GC

โทรจัน.เอเจนต์.S38943638

สคริปต์โทรจัน 50655.SL

สคริปต์โทรจัน 50650.SL

ตัวบ่งชี้การประนีประนอม (IOCs)

ชื่อไฟล์ SHA-256

096372d19b4787e989f44e04c5ecc29885aa927c34ae8666628d6c0eb20bb447	計畫申請審查結果通知單.pdf.lnk
1c56228cbd1bdebb9e5ea55c2749150fee06c865ede4a3754e8bd6843e51d2d4	計畫申請審查結果通知單.exe
080ab9bc2893ba7bad354551604a667af40ed2ae2d042d2323c2bd9ad3122192	UnityPlayer.dll
5ed14c2b7f7433a1a72dd6b668413f935a217ba10b69d89b774a82990fa12fe1	BrowserViewUtility.exe
61f7d9cd2d8ce7df950639b23ce90085b300b0c6dd0d8d934bba8fdecb670f15	RuntimeBroker_update.exe
24aa4e780ccd66cef13da9ef98c32954105cf2a32ec643efab0ba1aa2d6352f4	คอม.ดาต้า
02542a49b3bd6bd2795afb67840acb4557b17e017f7503dd03ebe3aeeb28720e	000b67d70f3876965bb09fd37164b7ccrezervaci.pdf
8ae7c82a3e4f742777e590b25a1c563d19bd9bcba2a387d004aae72c4b2828f9	000b67d70f3876965bb09fd37164b7.pdf
047687548605734348792e2a9d771b6cba42facd0d0d7d44d778290a25848574	1.ดาท
a4e9f9919d62589b57cfa08c9ccb89e386b09f683271373413cd8e8c8c7d1c5a	ว่างเปล่า.vbs
823d5969db3f3b72ebbdce1b78752717ea849884a0fb40d86146416c38e128de	โปรไฟล์.ps1
783661d0f7edb338d2d50be087764d82dbbc9ee7989ddc57db1801e4ec9045b0	azureveil.exe

ตัวบ่งชี้เครือข่าย

คำอธิบายตัวบ่งชี้

note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net	Azure Blob Storage C2

การแมป MITRE ATT&CK

ชั้นเชิง	รหัสเทคนิค	ชื่อเทคนิค
การเข้าถึงเบื้องต้น	T1566.001	ไฟล์แนบ Spearphishing
การกระทำ	T1204.002	ไฟล์ที่เป็นอันตราย – การเรียกใช้งานโดยผู้ใช้
	T1059.001	PowerShell
	T1059.005	ของ Visual Basic
การหลบเลี่ยงการป้องกัน	T1574.002	การโหลด DLL จากด้านข้าง
	T1027	ไฟล์หรือข้อมูลที่ถูกปกปิด
	T1055	กระบวนการฉีด
	T1497.001	การหลีกเลี่ยงการจำลองเสมือน/แซนด์บ็อกซ์
	T1620	การโหลดโค้ดแบบสะท้อน
การค้นพบ	T1083	การค้นหาไฟล์และไดเร็กทอรี
	T1057	การค้นพบกระบวนการ
	T1016	การค้นหาการกำหนดค่าเครือข่ายระบบ
	T1082	การค้นหาข้อมูลระบบ
คำสั่งและการควบคุม	T1102.001	บริการเว็บ – ตัวแก้ไขปัญหาจุดตกหล่น
	T1573	ช่องทางเข้ารหัส
	T1090	หนังสือมอบฉันทะ
	T1105	การถ่ายโอนเครื่องมือขาเข้า
การกรอง	T1041	การรั่วไหลผ่านช่อง C2

Authors

ปรียา พาเทล

การ์ติกกุมาร์ จิวานี