Settra: khi ransomware dùng chính công cụ quản trị từ xa để ở lại

Tóm tắt

Settra là chủng ransomware xuất hiện từ tháng 6/2026, hoạt động theo mô hình tống tiền kép. Huntress cho biết chưa đủ bằng chứng để khẳng định đây là một hoạt động ransomware-as-a-service.

Điều đáng học ở Settra không nằm ở phần mã hóa mà ở giai đoạn hậu xâm nhập. Kẻ tấn công cài MeshAgent, một công cụ RMM hợp lệ, làm kênh duy trì quyền truy cập; nạp driver dễ tổn thương để tác động vào phần mềm bảo mật; rồi chạy một chuỗi lệnh phá sạch khả năng khôi phục của Windows trước khi mã hóa. Toàn bộ giai đoạn này dùng công cụ có sẵn hoặc hợp lệ, gần như không có malware nào để phát hiện theo chữ ký.

Hành động ưu tiên:

• Lập danh sách RMM được phép trong tổ chức và cảnh báo với mọi RMM ngoài danh sách đó, kể cả khi binary có chữ ký hợp lệ.

• Đẩy event log ra SIEM theo thời gian thực. Settra xóa 12 loại log trên máy nạn nhân; log đã forward là bản sao duy nhất còn lại.

Hai sự cố Huntress phân tích

Tháng 7/2026, doanh nghiệp bán lẻ và dịch vụ tiêu dùng. EDR phát hiện MeshAgent đã bị đổi tên thành mvtcs.exe. Ngày hôm sau, file ransomware được chạy từ C:\Perflogs, mã hóa dữ liệu với đuôi .locked và để lại ghi chú RESTORE_FILES.txt.

Tháng 9/2026, doanh nghiệp sản xuất. Agent của Huntress được cài vào lúc cuộc tấn công đang diễn ra, nên đội phân tích quan sát được phần sau của chuỗi. Lần này MeshAgent để nguyên tên mặc định, ransomware chạy từ thư mục Documents của nạn nhân, đuôi file là .locked_wip.

Ở cả hai sự cố, đường vào ban đầu không xác định được. Các báo cáo công khai khác về Settra nói tới VPN bị xâm nhập và tài khoản bị lộ, nhưng đó không phải điều Huntress quan sát trực tiếp.

MeshAgent: RMM hợp lệ làm kênh điều khiển

MeshAgent là thành phần agent của MeshCentral, nền tảng quản trị từ xa mã nguồn mở. Settra dùng nó làm kênh duy trì và điều khiển ở cả hai sự cố:

Sự cố	Tên file	C2
Tháng 7	mvtcs.exe (đổi tên)	45.13.122[.]7
Tháng 9	tên mặc định	193.5.65[.]114

Việc dùng RMM thay cho backdoor tự viết mang lại ba lợi thế cho kẻ tấn công:

• Binary hợp lệ, có chữ ký. Không kích hoạt phát hiện theo chữ ký, và nhiều tổ chức đặt ngoại lệ cho công cụ quản trị.

• Traffic trông như hoạt động quản trị bình thường. Kênh điều khiển của RMM được thiết kế để chạy ổn định qua firewall và proxy.

• Lẫn vào công cụ sẵn có. Tổ chức nào cũng có vài công cụ RMM, nhất là khi thuê ngoài IT. Một agent lạ dễ bị cho là của nhà thầu nào đó. Hệ quả cho bên phòng thủ: phát hiện không thể dựa trên "đây có phải malware không", mà phải dựa trên "công cụ này có được phép ở đây không".

BYOVD để hạ phòng thủ trên máy

Ở sự cố tháng 9, kẻ tấn công nạp driver gdrv.sys theo kỹ thuật bring-your-own-vulnerable-driver, nhằm tác động vào phần mềm bảo mật đang chạy và làm dịch vụ antivirus dừng hoạt động.

Driver được nạp ở kernel nên có thể can thiệp vào tiến trình bảo vệ mà quyền admin thông thường không làm được. Đây là lý do danh sách chặn driver (Microsoft Vulnerable Driver Blocklist hoặc danh sách riêng của EDR) nên được bật chứ không để mặc định.

Phá khả năng khôi phục

Điểm đáng chú ý là các lệnh này được nhúng ngay trong file ransomware, không phải script rời. Kẻ tấn công không cần quay lại gõ tay.

Lệnh	Tác dụng với nạn nhân
reagentc /disable	Tắt Windows Recovery Environment, chặn đường khôi phục hệ điều hành
diskpart (chạy theo script)	Xóa recovery partition, khiến việc khôi phục tại chỗ không còn khả thi
cipher /w:D:\	Ghi đè vùng trống trên ổ đĩa, phá khả năng phục hồi file đã xóa bằng công cụ forensic
ipconfig /flushdns	Xóa cache DNS, làm mất một nguồn dấu vết phục vụ điều tra

Ba lệnh đầu nhắm vào khả năng phục hồi, lệnh cuối nhắm vào khả năng điều tra. Với đội SOC, reagentc /disable và cipher /w: là hai lệnh gần như không bao giờ xuất hiện trong vận hành bình thường, nên rất đáng làm rule cảnh báo mức cao.

Xóa log, và một lỗi chính tả

Ở sự cố tháng 9, kẻ tấn công cố xóa 12 loại event log:

Application                                            Security
System                                                 Setup
ForwardedEvents
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Microsoft-Windows-TerminalServices-RDPClient/Operational
Microsoft-Windows-Sysmon/Operational
Microsoft-Windows-PowerShell/Operational
Microsoft-Windows-WinRM/Operational
Microsoft-Windows-TaskScheduler/Operational
Microsoft-Windows-Defender/Operational

Danh sách này cho thấy kẻ tấn công hiểu rõ nguồn bằng chứng nào quan trọng: Sysmon, PowerShell, WinRM, Task Scheduler và Terminal Services là những log mà đội DFIR dựa vào nhiều nhất.

Nhưng có một chi tiết thú vị: mục cuối bị gõ sai thành Microsoft-Windows-Windows-Defender/Operational. Tên log không tồn tại nên lệnh thất bại, và log của Windows Defender sống sót. Trong một vụ mà mọi thứ khác đã bị xóa, đây có thể là nguồn bằng chứng còn lại duy nhất.

Mã hóa

File ransomware được đặt tên theo domain của chính nạn nhân, kèm hậu tố _win64.exe. Cách đặt tên này cho thấy payload được build riêng cho từng mục tiêu, tức là kẻ tấn công đã khảo sát môi trường trước khi triển khai.

Vị trí chạy khác nhau giữa hai vụ: C:\Perflogs ở vụ tháng 7 và thư mục Documents của người dùng ở vụ tháng 9. C:\Perflogs là thư mục hệ thống ít khi có file thực thi hợp lệ, nên bất kỳ tiến trình nào chạy từ đó đều đáng điều tra ngay.

Đuôi file đổi từ .locked sang .locked_wip, ghi chú đòi tiền giữ nguyên tên RESTORE_FILES.txt.

Nhận định

.locked_wip nhiều khả năng là dấu vết của bản build chưa hoàn thiện. Hậu tố "wip" thường mang nghĩa work in progress. Nếu đúng vậy, nhóm này đã triển khai một bản đang phát triển vào môi trường thật. Kết hợp với lỗi chính tả trong danh sách log, bức tranh là một nhóm hoạt động nhanh nhưng kiểm soát chất lượng lỏng.

Lỗi chính tả đó cũng nói lên mức độ tự động hóa. Danh sách log được gõ tay chứ không sinh tự động từ wevtutil el. Với đội phòng thủ, đây là lời nhắc rằng kẻ tấn công vẫn mắc lỗi, và việc thu thập log ngay lập tức sau sự cố có thể cứu được nhiều hơn dự kiến.

Tên máy trạm WIN-LIVFRVQFMKO xuất hiện ở nhiều sự cố trước đó. Huntress ghi nhận tên máy này gắn với các vụ khác từ trước. Đây là dạng chỉ dấu rẻ nhưng hiệu quả: nếu tên máy trạm lạ này xuất hiện trong log xác thực hay log RDP của bạn, đó là tín hiệu đáng điều tra.

Không biết đường vào là vấn đề lớn nhất. Cả hai sự cố đều không xác định được bước đầu tiên. Với bên phòng thủ, điều này có nghĩa là không thể trông vào một biện pháp duy nhất. Phải bao phủ cả VPN, tài khoản bị lộ và MFA cùng lúc.

Liên hệ Việt Nam

• RMM phổ biến trong mô hình thuê ngoài IT. Nhiều doanh nghiệp Việt Nam giao hạ tầng cho nhà thầu, và mỗi nhà thầu mang theo công cụ riêng. Trong môi trường như vậy, một agent RMM lạ rất dễ bị bỏ qua vì "chắc của bên kia".

• Doanh nghiệp sản xuất là nhóm mục tiêu quen thuộc. Đây là ngành có chi phí downtime cao, khiến khả năng trả tiền chuộc lớn hơn. Việt Nam có mật độ nhà máy trong chuỗi cung ứng toàn cầu rất cao.

• Log thường chỉ nằm trên endpoint. Nhiều tổ chức chưa forward event log ra SIEM hoặc chỉ forward một phần. Khi kẻ tấn công xóa log tại chỗ, khả năng điều tra gần như mất hẳn.

• VPN vẫn là cửa ngõ chính. Với mô hình làm việc kết hợp, tài khoản VPN không bật MFA vẫn còn khá nhiều.

Khuyến nghị

• Lập danh sách RMM được phép và cảnh báo với mọi công cụ RMM ngoài danh sách, đặc biệt là MeshAgent/MeshCentral. Cảnh báo nên dựa trên hành vi (agent kết nối ra IP lạ) chứ không chỉ tên file, vì Settra đã đổi tên binary ở một trong hai vụ.

• Bật danh sách chặn driver dễ tổn thương (Microsoft Vulnerable Driver Blocklist, HVCI nếu phần cứng hỗ trợ) và giám sát sự kiện nạp driver mới ở kernel.

• Tạo rule mức cao cho các lệnh phá khôi phục: reagentc /disable, cipher /w:, diskpart chạy kèm script, và wevtutil cl hoặc Clear-EventLog với nhiều log liên tiếp.

• Forward event log ra SIEM theo thời gian thực, ưu tiên Security, Sysmon, PowerShell, WinRM và Terminal Services, đúng những log nằm trong danh sách Settra nhắm tới.

• Cảnh báo với tiến trình chạy từ C:\Perflogs và các thư mục hệ thống tương tự. Đây là rule đơn giản, ít false positive và có giá trị vượt ra ngoài chiến dịch này.

• Nạp IOC vào SIEM/EDR: IP 45.13.122[.]7 và 193.5.65[.]114, tên file mvtcs.exe và gdrv.sys, tên máy trạm WIN-LIVFRVQFMKO, đuôi file .locked và .locked_wip, tên ghi chú RESTORE_FILES.txt, cùng mẫu tên file thực thi <domain-nạn-nhân>_win64.exe. Huntress không công bố hash mẫu.

Tài liệu tham khảo

• Huntress (Harlan Carvey, Lindsey O'Donnell-Welch) — Ready, Settra, Go: New Settra Ransomware Variant Deploys MeshAgent RMM (17/09/2026): https://www.huntress.com/blog/new-settra-ransomware-variant

• IT Security Guru — New Settra Ransomware Strain Deploys MeshAgent RMM for Persistence (17/09/2026): https://www.itsecurityguru.org/2026/09/17/new-settra-ransomware-strain-deploys-meshagent-rmm-for-persistence/

• Infosecurity Magazine — New Settra Ransomware Variant Deployed in Attacks on Retail and Manufacturing: https://www.infosecurity-magazine.com/news/settra-ransomware-retail/

• SOC Prime — Settra Ransomware Uses MeshAgent RMM for Persistence: https://socprime.com/active-threats/ready-settra-go-new-settra-ransomware-variant-deploys-meshagent-rmm/