# Từ SSH Botnet Đến “Ổ” Đào Coin: Lần Theo Dấu Vết Một Chiến Dịch Cryptomining

Phần lớn dữ liệu thu được từ một honeypot SSH internet-facing là nhiễu: dò mật khẩu liên tục, hoặc bot đăng nhập thành công rồi tải payload xuống chạy ngay lập tức. Nhưng ngày 27/6/2026, honeypot của SANS Internet Storm Center ghi nhận một phiên khác biệt — một bot đăng nhập bằng quyền root, thực hiện khảo sát phần cứng máy chủ hết sức bài bản, rồi ngắt kết nối mà không tải xuống hay chạy bất kỳ file nào. Không malware, không cơ chế persistence, không giai đoạn hai.

## Executive Summary

Nhìn thoáng qua, một phiên không để lại payload dễ bị coi là tấn công thất bại hoặc vô nghĩa — nhưng thực tế đây là hành vi có chủ đích: **định giá mục tiêu trước khi quyết định có đáng để triển khai payload hay không**. Toàn bộ chuỗi lệnh bot chạy chỉ tập trung thu thập các chỉ số quyết định giá trị của một máy để đào tiền mã hóa: số nhân CPU, model CPU, có GPU NVIDIA hay không, dung lượng RAM, và khả năng leo quyền root không cần mật khẩu qua `sudo -S`. Không có bất kỳ lệnh nào liên quan tới DDoS, phá hoại hay đánh cắp dữ liệu — đây rõ ràng là bước triage phục vụ cryptomining hoặc resource-hijacking, không phải botnet DDoS thông thường.

Rủi ro thực sự không nằm ở phiên này, mà ở phiên tiếp theo: nếu máy "đạt chuẩn" (đủ RAM, có GPU, chiếm được root), kẻ tấn công nhiều khả năng sẽ quay lại với payload miner phù hợp ở một thời điểm khác — hoặc chuyển thông tin cho một công cụ/toán tử khác xử lý tiếp. Với các đội SOC và người vận hành honeypot, bài học quan trọng nhất là: **một phiên chỉ chạy lệnh discovery và không thả file không đồng nghĩa với vô hại** — nó có thể là nửa đầu của một cuộc tấn công hai giai đoạn, và cách duy nhất để nối được nửa sau với nửa đầu (khi kẻ tấn công đổi IP) là dựa vào fingerprint của SSH client, cụ thể là HASSH.

## Sensor và diễn biến phiên

Honeypot ghi nhận sự việc là một cảm biến DShield chạy trên Raspberry Pi 4, sử dụng Cowrie SSH honeypot đặt trên một địa chỉ internet-facing. Cowrie giả lập một shell Linux đủ thuyết phục, chấp nhận đăng nhập bằng mật khẩu yếu, và ghi lại toàn bộ lệnh kẻ tấn công chạy cùng metadata kết nối như IP nguồn và fingerprint SSH client.

Phiên tấn công diễn ra rất ngắn: một bot từ địa chỉ **91.92.40.13** kết nối tới dịch vụ SSH, đăng nhập bằng root/123123 ngay lần thử đầu tiên, chạy đúng hai lệnh, rồi ngắt kết nối sau khoảng 8 giây. Hai chi tiết đáng chú ý ngay từ đầu: SSH client tự nhận diện là một chương trình viết bằng Go (`SSH-2.0-Go`) thay vì client thông thường, và toàn bộ phiên chỉ kéo dài vài giây — cả hai đều là dấu hiệu của automation, không phải người thao tác trực tiếp.

## Bot thu thập những gì

Thay vì chuỗi lệnh tải-và-chạy (download-and-run) quen thuộc, bot này chạy một cuộc khảo sát phần cứng. Lệnh đầu tiên thu thập: hệ điều hành và phiên bản kernel, kiến trúc CPU, số nhân CPU, model CPU; sau đó dùng `lspci` để tìm card đồ họa, tìm riêng từ khóa NVIDIA; đọc uptime hệ thống; liệt kê các lần đăng nhập gần nhất qua `last`. Toàn bộ kết quả được in ra dưới dạng field có nhãn rõ ràng (`UNAME`, `ARCH`, `CPUS`, `CPU_MODEL`, `GPU`, `LAST`) — đúng định dạng mà một bot tự động dùng để đóng gói thông số nạn nhân, phục vụ việc parse tự động và ra quyết định ở phía kẻ tấn công.

Lệnh thứ hai kiểm tra máy có nhiều hơn 1 GB RAM hay không, bằng cách đọc `/proc/meminfo` và so sánh với ngưỡng 1.048.576 KB. Lệnh này được chạy qua `sudo -S`, đồng thời đưa lại chính mật khẩu vừa dùng để đăng nhập nhằm kiểm tra xem có thể leo quyền root đầy đủ mà không cần prompt hay không.

Điểm mấu chốt nằm ở sự kết hợp của các chỉ số này. Một botnet DDoS thông thường không quan tâm máy nạn nhân có card đồ họa gì. Việc đếm số nhân CPU, đọc model CPU, tìm riêng GPU NVIDIA, và đặt ngưỡng tối thiểu về RAM là hồ sơ đặc trưng của hoạt động triage phục vụ cryptomining hoặc resource-hijacking — vì miner chỉ đáng triển khai trên những máy đủ mạnh, nên kẻ vận hành đo đạc trước, và (nhiều khả năng) chỉ gửi miner tới những host đạt chuẩn. Bước kiểm tra `sudo` cho bot biết liệu nó có thể chiếm toàn quyền máy trước khi thực sự cam kết triển khai gì đó.

![Mô hình trinh sát trước, quyết định sau](https://isc.sans.edu/diaryimages/images/Adam_Cann_pic2.png align="center")

## Hai bot khác nhau, cùng một mật khẩu yếu

Đây cũng là ví dụ tốt cho thấy vì sao việc fingerprint client lại quan trọng. Trong cùng tháng đó, honeypot còn ghi nhận một chiến dịch SSH hoàn toàn khác: một loader đăng nhập, tải một file ELF từ server của kẻ tấn công bằng chuỗi fallback `curl` → `wget` → `/dev/tcp`, rồi gia nhập một botnet DDoS. Chiến dịch này xoay vòng qua nhiều IP nguồn và nhiều server C2 khác nhau, nhưng fingerprint HASSH của SSH client lại không đổi — nhờ đó có thể gộp các phiên rải rác thành một chiến dịch duy nhất. Bot trinh sát miner nói trên có client và HASSH hoàn toàn khác, cho thấy đây là một tác nhân riêng biệt, không phải cùng một chiến dịch đổi chiến thuật.

![Hai tác nhân riêng biệt trên cùng một honeypot, phân biệt qua fingerprint client](https://isc.sans.edu/diaryimages/images/Adam_Cann_pic3.png align="center")

## Một phiên không thả file — có thực sự vô hại?

Câu hỏi mà phiên này đặt ra rất đơn giản: khi một lần đăng nhập chỉ chạy lệnh discovery rồi rời đi mà không để lại gì, liệu nó có vô hại? Câu trả lời là không. Một phiên chỉ-trinh-sát thường là nửa đầu của một cuộc tấn công hai giai đoạn: kẻ vận hành định giá mục tiêu ngay lúc đó, rồi quay lại sau với payload phù hợp, hoặc chuyển mục tiêu cho một công cụ khác xử lý tiếp. Coi các phiên không thả payload là nhiễu nền đồng nghĩa với việc bỏ lỡ giai đoạn "dò xét" (casing) vốn luôn đi trước một vụ xâm nhập thực sự.

Điều này đáng lưu tâm bởi lẽ đội ngũ phòng thủ và người vận hành honeypot tự nhiên có xu hướng ưu tiên các phiên có thả file, vì chúng rõ ràng là độc hại. Các phiên chỉ "nhìn quanh" rất dễ bị bỏ qua. Ví dụ này cho thấy hoạt động discovery tự nó có thể là một tín hiệu cảnh báo sớm có giá trị, và một fingerprint như HASSH có thể nối liền hoạt động trinh sát âm thầm với payload ồn ào hơn xuất hiện sau đó, ngay cả khi kẻ tấn công đổi địa chỉ IP.

Nhóm được hưởng lợi trực tiếp từ phát hiện này gồm: các nhà phân tích SOC đang triage hoạt động SSH, người vận hành honeypot/cảm biến DShield, và quản trị viên của bất kỳ host Linux hay cloud nào expose ra internet. Bất kỳ hệ thống nào dùng mật khẩu SSH yếu hoặc mặc định đều là ứng viên cho đúng kiểu định giá này.

## Khuyến nghị

*   Rà soát log xác thực SSH tìm các phiên đăng nhập root thành công có thời lượng cực ngắn (vài giây) đi kèm chuỗi lệnh thu thập thông tin hệ thống (`uname`, `lscpu`/`/proc/cpuinfo`, `lspci`, `uptime`, `last`) — đặc biệt nếu các trường kết quả được gán nhãn rõ ràng kiểu `UNAME=`, `CPU_MODEL=`, `GPU=`.
    
*   Đối chiếu ngay các địa chỉ IP đã đăng nhập thành công bằng mật khẩu yếu/mặc định với danh sách IOC bên dưới (91.92.40.13) và chặn tạm trên firewall nếu trùng khớp.
    
*   Kiểm tra các máy chủ SSH internet-facing đang dùng `root/123123` hoặc các cặp user/password mặc định tương tự — đổi mật khẩu ngay lập tức.
    
*   Vô hiệu hóa đăng nhập root qua SSH (`PermitRootLogin no`) trên toàn bộ host expose ra internet nếu chưa thực hiện.
    

*   Bật cảnh báo cho hành vi "bulk hardware discovery" trong phiên SSH: đọc CPU model, tìm GPU NVIDIA qua `lspci`, kiểm tra `/proc/meminfo` so với một ngưỡng cụ thể — đây là pattern khá đặc thù, ít khi xuất hiện trong hoạt động vận hành hợp pháp.
    
*   Triển khai fail2ban hoặc cơ chế rate-limit tương đương để chặn IP sau một số lần đăng nhập sai liên tiếp.
    
*   Thu thập và lưu trữ HASSH fingerprint của các SSH client kết nối tới honeypot/host giám sát, dùng để liên kết các phiên trinh sát rải rác qua nhiều IP về cùng một tác nhân.
    
*   Rà soát cấu hình `sudo` trên các host quan trọng để đảm bảo không cho phép `sudo -S` chạy không cần prompt với mật khẩu tái sử dụng từ phiên đăng nhập.
    

*   Chuyển hoàn toàn sang xác thực SSH bằng khóa (key-based authentication), loại bỏ xác thực bằng mật khẩu trên các host internet-facing.
    
*   Giới hạn phạm vi expose SSH: đặt sau VPN hoặc giới hạn theo danh sách địa chỉ IP đã biết thay vì mở cho toàn bộ internet.
    
*   Với các host đã từng "vượt qua" một phiên định giá kiểu này (đủ RAM, có GPU, chiếm được root), giám sát chủ động mức sử dụng CPU/GPU bất thường kéo dài và các kết nối ra ngoài tới mining pool.
    
*   Xây dựng quy trình triage honeypot/log SSH coi các phiên chỉ-discovery (không thả payload) là tín hiệu cần điều tra thêm, thay vì tự động phân loại là nhiễu nền — đặc biệt khi phiên có fingerprint client bất thường như `SSH-2.0-Go`.
    

## Chỉ báo xâm nhập (IOC)

| Loại | Giá trị |
| --- | --- |
| IP nguồn | `91.92.40.13` (VirusTotal: 11 malicious, 5 suspicious; ASN 197170 – TechTies Inc.; dải `91.92.40.0/24`; Hà Lan) |
| SSH client | `SSH-2.0-Go` |
| HASSH | `2ec37a7cc8daf20b10e1ad6221061ca5` |
| Credential sử dụng | `root` / `123123` |
| Hành vi | Khảo sát phần cứng hàng loạt (số nhân & model CPU, tìm GPU NVIDIA, uptime, `last`), kiểm tra `/proc/meminfo` với ngưỡng >1GB RAM, kiểm tra leo quyền root qua `sudo -S` |

## Tài liệu tham khảo

*   Adam Cann (SANS.edu BACS Student), "Reconnaissance First: An SSH Bot That Sizes Up Your Hardware Before Deploying a Miner \[Guest Diary\]", SANS Internet Storm Center, 30/07/2026: https://isc.sans.edu/diary/33198
    
*   Fail2ban, tài liệu chính thức: https://en.wikipedia.org/wiki/Fail2ban
    
*   DShield / SANS ISC, dự án cảm biến honeypot cộng đồng: https://github.com/DShield-ISC/dshield
    
*   SANS.edu, chương trình Bachelor's Degree in Applied Cybersecurity (BACS): https://www.sans.edu/cyber-security-programs/bachelors-degree/