malwareuk

Phân tích chiến dịch tấn công máy chủ MSSQL: 3 lớp backdoor & mã độc fileless nằm vùng hơn 6 tuần

Không cần malware phức tạp hay lỗ hổng 0-day đắt giá — đôi khi kẻ tấn công chỉ cần một dịch vụ cấu hình sai và đủ kiên nhẫn.

Đội ngũ CyRadar SOC vừa khép lại một ca điều tra mà càng đào sâu, càng thấy có nhiều lớp hơn dự đoán ban đầu. Tại một tổ chức khách hàng, máy chủ Database nội bộ đã âm thầm bị chiếm quyền và duy trì kết nối C2 trong hơn một tháng, trong khi mọi lớp phòng thủ truyền thống — AV, tường lửa, giám sát thông thường — đều không hề hay biết.

Cùng CyRadar lật lại từng lớp của chiến dịch này, và cả những chỗ mà một kết luận ban đầu tưởng chừng hợp lý lại hoá ra chưa đúng.

01. Sự cố bắt đầu như thế nào?

10 giờ 47 phút sáng, đội vận hành nhận được cảnh báo: CPU máy chủ Database tăng vọt, gần như treo máy. Vào kiểm tra, chúng tôi thấy một thứ không nên có ở đó — một tiến trình powershell.exe lạ, được một SQL Server Agent job gọi đi gọi lại liên tục.CyRadar bắt đầu truy vết ngược dựa trên log hệ thống và phát hiện: kẻ tấn công đã nằm vùng âm thầm hơn 6 tuần trước đó.

02. Xác định xâm nhập ban đầu

Manh mối đầu tiên chỉ thẳng vào xp_cmdshell — thủ tục mở rộng khét tiếng cho phép SQL Server chạy lệnh hệ điều hành. Nghe rất hợp lý, vì đây đúng là “con đường” quen thuộc trong hầu hết các case tấn công thông qua MSSQL.Nhưng đối chiếu lại log thì có gì đó không khớp: xp_cmdshell chỉ được bật lên sau lần xâm nhập đầu tiên hơn một tháng. Tức là ở đúng thời điểm kẻ tấn công thực thi lệnh thành công lần đầu, xp_cmdshell còn chưa hề được kích hoạt.Đào sâu hơn vào phần log còn sót lại, CyRadar tìm ra đường đi thật sự: kẻ tấn công đã chiếm được một tài khoản SQL có đặc quyền cao (sysadmin, hoặc chí ít đủ quyền thao tác trong database msdb), rồi dùng chính quyền đó tạo một SQL Server Agent Job chạy subsystem PowerShell. Không cần bật cấu hình rủi ro nào cả — job này trông chẳng khác gì một tác vụ backup hay bảo trì bình thường. Đó là lý do nó lẩn được suốt hơn một tháng trời.Câu hỏi tiếp theo mới là câu hỏi đáng giá: tài khoản đặc quyền đó, kẻ tấn công lấy ở đâu ra? Lần theo dữ liệu mã độc, CyRadar phát hiện một chuỗi kết nối mà mã độc dùng để tự cài lại persistence mỗi khi bị gián đoạn — sử dụng tài khoản “pac***” với mật khẩu “123”.Tài khoản này vốn được tạo ra để phục vụ một phần mềm nghiệp vụ nội bộ, nhưng lại bị cấp dư quyền so với mức cần thiết — đủ để tạo SQL Job, đủ để bật CLR Assembly. Một mật khẩu yếu, cộng với một tài khoản được trao nhiều quyền hơn nó xứng đáng có — chính hai điều tưởng chừng nhỏ nhặt ấy đã tự mở cửa cho kẻ tấn công xâm nhập vào.

03. Thiết lập 3 lớp backdoor chồng lên nhau

Kẻ tấn công không chỉ duy trì một lớp truy cập mà thiết lập 3 lớp backdoor, được triển khai ở các thời điểm khác nhau. Mục đích là nếu một lớp bị phát hiện và vô hiệu hóa, các lớp còn lại vẫn đảm bảo quyền truy cập:

  • 1 SQL Agent Job — lớp nền, âm thầm chạy PowerShell, tạo điểm bám đầu tiên.
  • 2 xp_cmdshell — được bật hơn một tháng sau, cho phép thực thi lệnh OS trực tiếp và thuận tiện hơn cho các thao tác trên máy nạn nhân.
  • 3 CLR Assembly Backdoor (systemasap.sqlclr) — lớp tinh vi nhất, chạy ngay trong tiến trình SQL Server nên khó bị phát hiện bởi các công cụ giám sát thông thường. Assembly cũng được cấu hình để tự nạp lại sau mỗi lần máy chủ khởi động.

Ba lớp, ba thời điểm, nhưng cùng một mục đích: duy trì quyền truy cập ngay cả khi một trong các lớp khác bị phát hiện và xử lý.

04 Tấn công fileless & dấu vết đào coin

Rà soát sâu hơn trên máy chủ, đội điều tra tìm thấy thêm hai kiểu dấu vết khác — và cả hai đều thuộc dạng khó bắt.Thứ nhất là mã độc fileless: toàn bộ payload chỉ là các đoạn PowerShell mã hoá base64, chạy hoàn toàn trong bộ nhớ RAM, thi thoảng tương tác qua vài file tạm trong C:\Windows\Temp rồi biến mất. Không có file thực thi cố định nằm trên máy để rà quét — máy chủ cũng có cài AV nhưng không ghi nhận log AV phát hiện.Thứ hai là dấu vết đào coin: một driver phần cứng mức thấp — WinRing0x64.sys — được nạp vào hệ thống, loại driver quen thuộc mà giới đào tiền ảo và rootkit hay lợi dụng để âm thầm chiếm dụng tài nguyên CPU/GPU.

05 IOC (Indicators of Compromise)

Danh sách domain và IP C2:

06 Bài học và khuyến nghị cho doanh nghiệp

Từ case này, có mấy điều đáng để bất kỳ đội vận hành database nào kiểm tra lại chính hệ thống của mình:

  • 1 xp_cmdshell không phải là duy nhất. Tắt nó đi là chưa đủ — vì như đã thấy ở trên, SQL Agent Job và CLR Assembly hoàn toàn có thể thay thế. Nên rà soát định kỳ cả hai: các Agent Job lạ, và các CLR Assembly mang quyền UNSAFE.
  • 2 Nguyên tắc quyền tối thiểu (Least Privilege). Tài khoản phục vụ ứng dụng tuyệt đối không nên có quyền sysadmin, hay bất kỳ quyền nào cho phép tạo Job/bật CLR. Một login chỉ cần đọc-ghi một database cụ thể thì không có lý do gì được cấp nhiều hơn thế.
  • 3 Đừng bao giờ expose cổng MSSQL (1433) ra thẳng Internet. Đặt sau firewall/VPN, giới hạn IP được phép kết nối, và bật khoá tài khoản khi phát hiện dò quét.
  • 4 Quản lý chặt credential của phần mềm bên thứ ba. Đảm bảo thông tin kết nối được mã hoá, không lưu dạng plaintext trong các file cấu hình (.inf, .config…).
  • 5 Đầu tư EDR và giám sát hành vi. Với mã độc fileless, quét file hash gần như vô dụng — cần giải pháp theo dõi hành vi PowerShell thực sự (Script Block Logging, behavioral monitoring).
  • 6 Tập trung log về SIEM, và giữ đủ lâu. Một chiến dịch nằm vùng 6 tuần chỉ có thể truy vết trọn vẹn nếu log còn đó khi cần đến.

📞 Hệ thống của bạn có đang xuất hiện tiến trình lạ, hay chỉ đơn giản là một cảm giác “có gì đó không ổn”?

Đội ngũ CyRadar SOC luôn sẵn sàng đồng hành rà soát, ứng cứu sự cố (Incident Response) và tư vấn an ninh mạng tổng thể cho doanh nghiệp.

👉 Liên hệ ngay với CyRadar để được tư vấn & hỗ trợ kỹ thuật!