Ransomware .PIZ qua MSSQL: từ brute-force đến Safe Mode và mã hóa dữ liệu

Điểm đáng chú ý nhất của case này không nằm ở phần mở rộng .piz, mà ở toàn bộ chuỗi tấn công diễn ra trước thời điểm dữ liệu bị mã hóa. Các dấu hiệu cho thấy kẻ tấn công đã có giai đoạn dò quét, thử mật khẩu, tận dụng khả năng thực thi trong SQL Server, thiết lập công cụ điều khiển từ xa, sau đó chủ động đưa máy vào Safe Mode để giảm hiệu lực của lớp bảo vệ trước khi thực hiện mã hóa hàng loạt.

1. Tổng quan chuỗi tấn công

Infographic của CyRadar chia sự cố thành 5 giai đoạn. Chuỗi này phù hợp với một mô hình ransomware “hands-on-keyboard”: kẻ tấn công không chỉ thả encryptor ngay lập tức mà có thời gian tương tác trực tiếp với máy chủ, kiểm soát quyền, cài công cụ truy cập và chuẩn bị môi trường trước khi kích hoạt giai đoạn tác động.

2. Vì sao MSSQL là điểm đáng quan tâm?

MSSQL là nền tảng cơ sở dữ liệu quan trọng trong rất nhiều hệ thống ERP, HIS, kế toán và phần mềm nghiệp vụ. Vấn đề không phải nằm ở bản thân SQL Server, mà ở cách triển khai: cổng quản trị phơi Internet, mật khẩu yếu, tài khoản có quyền quá cao, bật các tính năng có khả năng thực thi lệnh hệ điều hành, hoặc cho phép thành phần mở rộng chạy với đặc quyền mạnh.

2.1. Brute-force vào tài khoản SQL sa

MITRE ATT&CK xếp password guessing vào T1110.001. MSSQL/1433 và RDP/3389 đều nằm trong nhóm dịch vụ thường bị thử mật khẩu. Nếu một hệ thống cho phép hàng chục nghìn lần đăng nhập thất bại từ Internet nhưng không có rate-limit, IP reputation, firewall allow-list hoặc cảnh báo SOC, kẻ tấn công có rất nhiều thời gian để thử credential.

2.2. CLR Assembly và khả năng vượt ra khỏi phạm vi database

SQL Server hỗ trợ CLR Integration để chạy code .NET trong Database Engine. Đây là tính năng hợp lệ cho ứng dụng, nhưng nếu bị lạm dụng cùng quyền cao, CLR Assembly có thể trở thành đường thực thi code và persistence. MITRE mô tả abuse của SQL stored procedures/CLR assemblies trong T1505.001 – SQL Stored Procedures.

Microsoft cũng cảnh báo rằng các assembly có quyền EXTERNAL_ACCESS hoặc UNSAFE có khả năng truy cập tài nguyên ngoài database; vì vậy môi trường production cần quản trị chặt việc ký assembly, trusted assembly, quyền tạo assembly và thay đổi cấu hình CLR.

2.3. xp_cmdshell không nên là “công tắc thường trực”

Microsoft cho biết xp_cmdshell mặc định bị tắt trên cài đặt mới và nhìn chung nên duy trì trạng thái disabled nếu không thực sự cần. Nếu một phần mềm legacy bắt buộc sử dụng, nên giới hạn thời gian bật, quyền gọi và giám sát mọi lần thay đổi cấu hình.

3. AnyDesk: phần mềm hợp pháp nhưng có thể trở thành kênh C2

AnyDesk là công cụ remote desktop hợp pháp. Tuy nhiên, sau khi hệ thống đã bị xâm nhập, việc cài một phần mềm remote phổ biến dưới dạng Service giúp kẻ tấn công có một kênh truy cập bền vững và dễ sử dụng. MITRE ATT&CK hiện mô tả nhóm hành vi này tại T1219.002 – Remote Desktop Software.

Điểm phòng thủ quan trọng không phải là “cấm AnyDesk bằng mọi giá”, mà là phân biệt remote tool được doanh nghiệp phê duyệt và remote tool xuất hiện ngoài quy trình. Một server database bỗng sinh service AnyDesk vào nửa đêm, kết nối outbound tới hạ tầng chưa từng thấy, rồi vài phút sau bị reboot vào Safe Mode là chuỗi tín hiệu có độ ưu tiên rất cao.

4. Safe Mode và kỹ thuật vô hiệu hóa phòng thủ

Đưa Windows vào Safe Mode là thủ thuật đã từng được nhiều ransomware operator sử dụng để giảm số lượng service/driver bảo mật được nạp. Trong case này, theo CyRadar, Kaspersky bị vô hiệu hóa và Process Hacker cùng driver liên quan được sử dụng để can thiệp tiến trình bảo vệ. Về ATT&CK, đây phù hợp với nhóm T1562.001 – Impair Defenses: Disable or Modify Tools.

5. Đuôi .PIZ nói được gì — và không nói được gì?

Việc file bị đổi thành .piz xác nhận một đặc điểm quan sát được trong sự cố, nhưng không phải bằng chứng đủ để gán family ransomware. Extension là artefact dễ thay đổi nhất: operator có thể cấu hình khác nhau giữa các nạn nhân, encryptor có thể được rebuild, hoặc một nhóm khác có thể tái sử dụng cùng đuôi.

Để nhận diện chính xác hơn, đội IR nên thu thập tối thiểu:

• Ransom note nguyên bản, tên file và nội dung.
• 1–3 file trước/sau mã hóa nếu có cặp đối chiếu.
• Header/trailer, marker và entropy của file mã hóa.
• Hash của encryptor, loader, DLL/driver và remote tool.
• Process tree, command line, service, scheduled task, autorun.
• IP/domain/URL liên quan đến RDP, AnyDesk hoặc kênh C2 khác.
• $MFT, $UsnJrnl, $LogFile, Windows Event Logs và log SQL.

6. Mapping MITRE ATT&CK từ dữ liệu công khai

Bảng dưới chỉ là mapping ở mức hành vi từ những gì đã được công bố. Đây không phải kết luận attribution về actor hay family.

7. Những tín hiệu nên đưa vào SIEM/EDR

Thay vì chỉ săn “file ransomware”, doanh nghiệp nên tạo rule dựa trên chuỗi hành vi trước ransomware. Với case này, các tín hiệu có giá trị cao gồm:

8. Bài học phòng thủ — điều gì nên làm khác?

8.1. Không phơi RDP/MSSQL trực tiếp ra Internet

Đây là ưu tiên số một. CISA khuyến nghị hạn chế hoặc loại bỏ RDP trực tiếp; nếu cần remote, nên đặt sau VPN/ZTNA, bật MFA ở lớp truy cập, giới hạn IP, log toàn bộ phiên và tách account quản trị khỏi account người dùng thường.

8.2. Tài khoản SQL phải theo nguyên tắc quyền tối thiểu

Không nên để ứng dụng nghiệp vụ sử dụng sa hoặc login có sysadmin nếu không thật sự cần. Từng ứng dụng nên có login riêng, quyền đúng database cần dùng, không được phép tạo assembly/SQL Agent Job hay thay đổi cấu hình server nếu chức năng nghiệp vụ không yêu cầu.

8.3. MFA cần đặt đúng chỗ

Khuyến nghị “bật MFA” là đúng về mặt chiến lược, nhưng cần triển khai đúng lớp. Với SQL Authentication truyền thống, không thể đơn giản “bật MFA cho tài khoản sa” như với Microsoft 365. Thực tế nên ưu tiên MFA cho VPN/ZTNA, tài khoản AD/Entra, RDP gateway, PAM và các cổng quản trị; đồng thời hạn chế SQL authentication, dùng Windows/AD authentication nơi phù hợp.

8.4. Backup phải tách khỏi blast radius của production

CISA nhấn mạnh backup offline hoặc immutable và phải test restore định kỳ. Nếu backup NAS/share/object storage luôn được mount với credential có quyền xóa/ghi từ chính server production, nó vẫn có thể bị mã hóa hoặc phá hủy cùng lúc với dữ liệu chính.

8.5. Giám sát thay đổi cấu hình quan trọng

Với database server, mọi thay đổi liên quan CLR, xp_cmdshell, OLE Automation, SQL Agent, quyền sysadmin, startup procedure và service account nên có audit trail. Cảnh báo phải được đẩy sang hệ thống độc lập để attacker không thể xóa sạch dấu vết chỉ bằng cách xóa log tại host.

9. Nếu phát hiện server đang bị mã hóa: ưu tiên làm gì?

1. Cô lập mạng ngay nhưng tránh thao tác xóa/reset vội vàng làm mất artefact.
2. Ngắt đường truy cập từ ngoài: RDP, VPN account nghi ngờ, AnyDesk/RMM ngoài kiểm soát, firewall rule bất thường.
3. Giữ nguyên bằng chứng: Event Logs, SQL Logs/Audit, Sysmon/EDR telemetry, $MFT, $UsnJrnl, RAM nếu còn giá trị, sample encryptor/driver/ransom note.
4. Không restore chồng ngay lên hệ thống nhiễm. Dựng vùng phục hồi sạch, xác định persistence trước.
5. Kiểm tra backup theo thứ tự tin cậy: immutable/offline → snapshot độc lập → bản copy tách credential → các nguồn dữ liệu phụ trợ.
6. Định danh ransomware bằng nhiều artefact, không chỉ dựa vào extension.
7. Ưu tiên dữ liệu nghiệp vụ quan trọng như SQL MDF/LDF, HIS/PACS, ERP trước khi xử lý các file ít giá trị hơn.

10. Kết luận

Case do CyRadar công bố là ví dụ rất rõ cho một nguyên tắc: ransomware thường là giai đoạn cuối, không phải giai đoạn đầu của sự cố. Nếu chỉ tập trung vào encryptor và đuôi .piz, đội kỹ thuật sẽ bỏ qua những dấu vết có giá trị nhất: brute-force kéo dài, quyền SQL bị lạm dụng, CLR Assembly, remote desktop hợp pháp bị biến thành C2, Safe Mode và việc vô hiệu hóa lớp bảo vệ.

Đối với doanh nghiệp có SQL Server, ERP/HIS/PACS hoặc hệ thống nội bộ quan trọng, việc giảm bề mặt Internet, tách quyền, hardening SQL, kiểm soát RMM, giám sát thay đổi cấu hình và duy trì backup immutable/offline có giá trị hơn nhiều so với hy vọng một phần mềm antivirus đơn lẻ sẽ chặn được toàn bộ chuỗi tấn công.