Hướng Dẫn Kiểm Tra & Loại Bỏ Rootkit Ustar và Cryptominer Monero Qua Tor

Kiểm tra và loại bỏ rootkit ustar là việc cần ưu tiên khi VPS Ubuntu xuất hiện những dấu hiệu bất thường như CPU tăng cao, liên tục phát sinh kết nối TCP outbound đến các IP lạ, trong khi các lệnh kiểm tra như ps hay ss lại không hiển thị tiến trình đáng ngờ. Đây có thể là dấu hiệu server đã bị rootkit LD_PRELOAD che giấu cryptominer Monero hoạt động thông qua Tor. Một trong những vị trí quan trọng cần kiểm tra đầu tiên là /etc/ld.so.preload. Trong bài viết này, InterData sẽ hướng dẫn bạn từng bước xác định dấu hiệu xâm nhập, loại bỏ rootkit và cryptominer, đồng thời gia cố lại VPS để hạn chế nguy cơ tái nhiễm.

Dấu hiệu nhận biết VPS đã bị nhiễm rootkit ustar và cryptominer

Nếu VPS Ubuntu của bạn có CPU cao liên tục mà không rõ ứng dụng nào gây ra, đồng thời xuất hiện nhiều kết nối TCP outbound tới IP lạ (cổng 443, 3333 hoặc 9100) nhưng ss -tnp lại hiện cột Process trống dù đang chạy quyền root — đó là dấu hiệu rất mạnh của rootkit ẩn tiến trình. Việc đầu tiên cần làm là kiểm tra file /etc/ld.so.preload.

Bảng triệu chứng – ý nghĩa – hành động

Triệu chứng	Ý nghĩa	Hành động
CPU 80–100% liên tục, không rõ ứng dụng nào	Có tiến trình ngầm chiếm tài nguyên (thường là miner)	Kiểm tra /etc/ld.so.preload ngay → Bước 2
ss -tnp có kết nối outbound nhưng cột Process trống (dù đang root)	PID tiến trình đang bị rootkit ẩn khỏi /proc	Xác nhận rootkit LD_PRELOAD → Bước 2, 3
ps aux “trông sạch” nhưng máy vẫn nóng/chậm	ps bị hook — không tin được	Gỡ ld.so.preload rồi chạy lại ps → Bước 3
Kết nối ra cổng 3333, 9100 hoặc địa chỉ .onion	Mining pool (Monero thường dùng cổng 3333) hoặc kết nối qua Tor	Cô lập → diệt → Bước 4, 5, checklist khắc phục
File /etc/ld.so.preload chứa đường dẫn lạ	Gần như chắc chắn bị cài rootkit userland	Phân tích lib → gỡ preload → lộ PID → Bước 2, 3

Nếu bạn chưa quen với các lệnh kiểm tra trên terminal, hãy tham khảo các câu lệnh cơ bản trong Linux trước khi bắt đầu. Các lệnh trong bài đều chạy trên Ubuntu/Debian; trên CentOS/RHEL logic tương tự nhưng đường dẫn log có thể khác.

Rootkit ustar và miner Monero qua Tor hoạt động ra sao?

Để kiểm tra & loại bỏ rootkit ustar, bạn cần hiểu chuỗi tấn công của nó. Dưới đây là quy trình hoạt động đã được quan sát trên một ca xử lý thật (VPS Ubuntu 24.04). Các biến thể khác có thể dùng tên file, port, IP khác — nhưng cơ chế cốt lõi giống nhau.

Chuỗi tấn công theo giai đoạn

1. Xâm nhập ban đầu — SSH brute-force: Kẻ tấn công dò mật khẩu root qua SSH (CWE-521 — mật khẩu yếu). Hàng chục nghìn lần thử từ nhiều IP, cuối cùng đoán đúng và đăng nhập thành công. Đây là hình thức tấn công brute force phổ biến nhất trên VPS mở SSH mặc định.
2. Cài persistence — systemd unit: Tạo service ustar.service với Restart=always, đảm bảo miner tự khởi động lại nếu bị kill hoặc server reboot. Service này gọi dropper để tải lại binary mỗi khi chạy.
3. Tải dropper giả ảnh: Dropper dùng wget tải file từ C2 server (ví dụ đã quan sát: 75.102.23.196 trên các cổng khác nhau), file đặt tên giả dạng ảnh PNG (8no.png, k32.png…). File thực chất chứa 2 payload ghép nối, tách ra bằng byte offset.
4. Payload A — rootkit LD_PRELOAD (~9–10 KB): Một shared library nhỏ hook hàm readdir64() bằng dlsym(). Khi được ghi vào /etc/ld.so.preload, nó tự động load vào mọi tiến trình mới trên hệ thống. Mọi lệnh dùng readdir() để duyệt thư mục — bao gồm ps, ls, find, top — đều bị chặn, không thấy PID và file của miner.
5. Payload B — cryptominer Monero (~30 MB): Binary XMRig-class đào Monero (XMR), kết nối mining pool qua dịch vụ ẩn Tor (.onion:3333). File đặt tại /.ustarN (N tăng dần mỗi lần tải lại: /.ustar0, /.ustar1…). Cache Tor xuất hiện dưới /tmp/.<hash>/ chứa guards.json, circuit_timeouts.json, dir.sqlite3.

Vì sao đào Monero qua Tor? Monero sử dụng thuật toán RandomX ưu tiên CPU (không cần GPU), phù hợp tài nguyên VPS. Giao dịch Monero mặc định ẩn danh. Kết nối pool qua Tor (.onion) khiến traffic không bị phát hiện bởi các rule firewall dựa trên IP — vì traffic đi qua mạng Tor relay, không kết nối thẳng tới pool.

Vì sao ps và ss bị đánh lừa?

File /etc/ld.so.preload là cơ chế hợp lệ của Linux dynamic linker (ld.so): mọi shared library được liệt kê trong file này sẽ được load trước tất cả thư viện khác khi một chương trình ELF khởi chạy. Rootkit lợi dụng điều này để chen vào một lib hook readdir64() — hàm mà ps, ls, find dùng để liệt kê nội dung thư mục /proc. Hook này lọc bỏ entry của PID miner, nên ps không bao giờ “thấy” tiến trình đó.

Tuy nhiên, các lệnh như stat, file, cat, kill -0 gọi syscall trực tiếp (không dùng readdir()) nên không bị hook. Đây chính là cách để bypass rootkit và lộ tiến trình ẩn — sẽ trình bày chi tiết ở Bước 3.

Quy trình kiểm tra & loại bỏ rootkit ustar từng bước

Thực hiện các bước theo đúng thứ tự dưới đây. Mỗi bước có lệnh copy-paste và tiêu chí để kết luận trước khi sang bước tiếp. Toàn bộ lệnh chạy bằng quyền root.

Bước 1: Khảo sát nhanh

Thu thập thông tin hệ thống, kiểm tra kết nối mạng và tiến trình đang ngốn CPU:

uname -a; cat /etc/os-release
ss -tnp state established        # để ý IP lạ, cổng 3333/9100, cột Process trống dù đang root
ps aux --sort=-%cpu | head -30

Đọc kết quả: Nếu ss -tnp hiện nhiều dòng kết nối outbound mà cột Process trống dù bạn đang chạy quyền root — đây là dấu hiệu rất mạnh rằng PID tiến trình đang bị ẩn bởi rootkit. Sang Bước 2 ngay.

Nếu ps aux hiện tiến trình lạ chiếm CPU cao (tên chứa .onion, --url, --user, --pass, hoặc nằm ở đường dẫn /.ustar*) thì rootkit có thể chưa được cài hoặc đã bị gỡ. Vẫn kiểm tra ld.so.preload ở Bước 2 để chắc chắn.

Bước 2: Kiểm tra rootkit LD_PRELOAD

Đây là bước then chốt. File /etc/ld.so.preload trên một server sạch thường không tồn tại hoặc rỗng.

cat /etc/ld.so.preload            # có đường dẫn lạ = gần như chắc chắn dính
ls -la /đường/dẫn/bị/nghi         # nếu ls báo "No such file" nhưng path lại nằm trong ld.so.preload → mâu thuẫn = xác nhận
file /đường/dẫn/bị/nghi           # file/stat luôn đọc được (không bị hook)
strings -n 8 /đường/dẫn/bị/nghi | grep -iE 'readdir64|proc/%s/stat|dlsym'

Lưu ý: Thay /đường/dẫn/bị/nghi bằng đường dẫn thực tế mà cat /etc/ld.so.preload trả về. Ví dụ đã quan sát: đường dẫn trỏ tới một file .so nằm ở thư mục gốc.

Đọc kết quả:

• cat /etc/ld.so.preload trả về một đường dẫn tới file .so lạ → gần như chắc chắn bị cài rootkit.
• ls -la báo “No such file” trong khi file vẫn đọc được → mâu thuẫn này xác nhận readdir() đã bị hook (vì ls dùng readdir, còn file dùng syscall trực tiếp).
• strings tìm thấy readdir64, dlsym, hoặc proc/%s/stat → xác nhận đây là lib rootkit hook liệt kê thư mục.

Bước 3: Lộ tiến trình đào coin bị ẩn (bypass rootkit)

Nguyên lý: hook chỉ ảnh hưởng tiến trình mới sinh ra sau khi ld.so.preload được load. Gỡ file preload, rồi chạy lại ps — lúc này ps mới là tiến trình “sạch”, không bị hook, sẽ thấy mọi PID kể cả tiến trình miner trước đó bị ẩn.

mv /etc/ld.so.preload /root/ld.so.preload.rootkit.bak   # giữ làm bằng chứng, không xóa hẳn
ps aux --sort=-%cpu | head -50                          # tiến trình ẩn lộ ra

Đọc kết quả: Sau khi gỡ preload, ps aux sẽ hiện tiến trình chiếm CPU cao — thường có argv chứa .onion, hoặc tham số miner (--url, --user, --pass), hoặc đường dẫn /.ustar*. Ghi lại PID, đường dẫn binary, và tham số dòng lệnh để dùng trong các bước tiếp.

Cách thay thế nếu chưa dám gỡ preload: Dùng kill -0 $PID (syscall trực tiếp, không qua readdir) để brute-force kiểm tra PID nào đang tồn tại, rồi so với danh sách từ ps -eo pid. PID nào kill -0 trả về success nhưng không có trong ps chính là tiến trình bị ẩn. Tuy nhiên trên server bận, PID liên tục đổi chủ nên cách này dễ nhiễu — ưu tiên gỡ preload.

Bước 4: Truy tìm persistence (systemd, cron, rc.local)

Mã độc thường cài persistence để tự khởi động lại sau khi bị kill hoặc server reboot. Với biến thể ustar đã quan sát, persistence chính là systemd unit ustar.service có Restart=always. Bạn cần dùng systemctl để quản lý dịch vụ VPS và rà soát toàn bộ nguồn persistence khác:

crontab -l -u root; ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly
systemctl list-unit-files --state=enabled
systemctl cat ustar.service          # đọc ExecStart; dropper thường tự tải lại binary nếu bị xóa nhờ Restart=always
cat /etc/rc.local
grep -rl 'LD_PRELOAD' /etc/profile /etc/profile.d/ /etc/environment ~/.bashrc
find / -xdev -newermt '2026-08-01' -type f -not -path '/proc/*' -not -path '/var/log/*'

Lưu ý: Thay ustar.service bằng tên service lạ thực tế trên máy bạn — biến thể khác có thể dùng tên service khác. Thay ngày trong -newermt bằng thời điểm bạn nghi ngờ bắt đầu bị xâm nhập.

Quan trọng: Lệnh find cũng dùng readdir() — nên nếu bạn chưa gỡ ld.so.preload ở Bước 3, kết quả find không tin được. Chỉ dùng find để tham khảo, không kết luận “sạch” dựa trên nó.

Bước 5: Xác định vector xâm nhập

Nếu không xác định và vá lỗ hổng gốc, mã độc sẽ quay lại. Kiểm tra log SSH để xác nhận brute-force:

grep -a 'Accepted' /var/log/auth.log* | tail -40
grep -ac 'Failed password' /var/log/auth.log*
grep -E 'PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf
systemctl is-active fail2ban
journalctl -u ustar.service --no-pager | head -20    # nguồn tải dropper thường lộ ở đây

Đọc kết quả: Hàng chục nghìn Failed password kết hợp với nhiều Accepted password for root từ các IP dân dụng/di động rải rác, PermitRootLogin yes, không có Fail2ban → kết luận vector là SSH brute-force vào root (CWE-521 — mật khẩu yếu). Đây không phải CVE trong ứng dụng cụ thể — đơn giản là mật khẩu root dễ đoán và SSH để mở mặc định.

Trong log journalctl của service lạ, bạn thường thấy lệnh wget tải dropper từ IP C2. Ví dụ đã quan sát: 75.102.23.196 trên nhiều cổng khác nhau, tên file kiểu 8no.png, k32.png. Trên máy bạn, IP và tên file có thể khác.

Checklist loại bỏ rootkit ustar và cryptominer triệt để (6 mục)

Sau khi đã điều tra và xác nhận bị nhiễm, thực hiện 6 mục sau theo đúng thứ tự. Thứ tự rất quan trọng: diệt persistence trước khi kill tiến trình — nếu không, service có Restart=always sẽ respawn miner ngay lập tức.

#	Hạng mục	Chi tiết thực hiện
1	Cô lập	Chặn outbound tới IP/domain C2: ufw deny out to 75.102.23.196 (thay bằng IP thực tế trên máy bạn). KHÔNG default-deny toàn bộ outbound trên production — sẽ gãy email, license-check, payment gateway. Inbound chỉ mở đúng cổng đang dùng.
2	Diệt malware	systemctl stop ustar.service && systemctl disable ustar.service && systemctl mask ustar.service → kill -9 <PID-miner> → Xóa hết file cùng họ: /.ustar* (kể cả bản cũ /.ustar0, /.ustar1…) → Xóa /etc/ld.so.preload (đã mv ở Bước 3) → Xóa thư mục cache Tor lạ trong /tmp/.* chứa guards.json → Xác minh sạch bằng Bước 1–3.
3	Đổi mật khẩu root	Sinh mật khẩu ngẫu nhiên mạnh (tối thiểu 16 ký tự, trộn chữ hoa/thường/số/ký tự đặc biệt). Dùng chpasswd hoặc passwd root. Verify: mở một phiên SSH test riêng, đăng nhập bằng mật khẩu mới, xác nhận thành công trước khi đóng phiên hiện tại.
4	Fail2ban + đổi port SSH	Cài Fail2ban chống brute-force SSH (jail sshd, maxretry ~5). Mở port SSH mới song song port cũ → verify vào được bằng port mới → mới đóng port cũ. Ubuntu 24.04 dùng ssh.socket → nhớ systemctl daemon-reload + restart cả socket lẫn service.
5	Kiểm tra authorized_keys	Với mọi user có home directory: cat ~/.ssh/authorized_keys. Đối chiếu ngày sửa đổi file với thời điểm nghi xâm nhập. Key lạ = kẻ tấn công đã để backdoor SSH key → xóa ngay.
6	Vá hệ thống	apt-get update && apt-get -y upgrade. Kiểm tra /var/run/reboot-required — nếu có, HỎI quản trị viên trước khi reboot production. Reboot không báo trước có thể gây downtime ngoài kế hoạch.

Nên gỡ tại chỗ hay dựng lại VPS sạch?

Đây là câu hỏi lớn nhất sau khi phát hiện bị nhiễm. Câu trả lời phụ thuộc vào mức độ xâm nhập và yêu cầu tin cậy của hệ thống. Không có đáp án “luôn đúng” — nhưng có tiêu chí rõ ràng để quyết định.

Tiêu chí	Gỡ tại chỗ	Dựng lại sạch trên VPS mới
Mức độ xâm nhập	Chỉ có rootkit userland (LD_PRELOAD) + miner, không có kernel module lạ, không có thay đổi trong initramfs	Nghi ngờ kernel rootkit, nhiều binary hệ thống bị sửa, hoặc không rà hết được persistence
Thời gian bị chiếm	Phát hiện sớm (vài giờ đến 1–2 ngày)	Không rõ bị từ khi nào, hoặc đã nhiều tuần
Dữ liệu trên server	Có dữ liệu khó migrate, chấp nhận rủi ro còn sót	Có thể deploy lại từ source/backup
Yêu cầu tin cậy	Server dev/test, không xử lý dữ liệu nhạy cảm	Production chạy thanh toán, dữ liệu khách hàng, hoặc cần audit trail sạch
Kết luận	Có thể gỡ nếu xác nhận rà hết persistence + vá SSH + xác minh lại sạch bằng Bước 1–3	Khuyến nghị mặc định khi server đã bị chiếm quyền root — an toàn hơn so với dọn thủ công

Với server đã bị chiếm quyền root, dựng lại sạch thường là lựa chọn khôn ngoan hơn. Kẻ tấn công có root có thể đã sửa đổi bất kỳ file nào trên hệ thống — kể cả các công cụ bạn đang dùng để kiểm tra. Nếu bạn chọn gỡ tại chỗ, phải xác minh lại bằng Bước 1–3 sau mỗi thao tác gỡ, và chạy thêm rkhunter hoặc chkrootkit để quét bổ sung.

Phòng ngừa tái nhiễm vá đúng lỗ hổng gốc sau khi loại bỏ rootkit ustar

Gỡ rootkit mà không vá lỗ hổng gốc thì vài tiếng hoặc vài ngày sau sẽ bị lại. Với biến thể ustar, vector là SSH brute-force vào root — nên phòng ngừa tập trung vào gia cố SSH và giám sát.

Tắt đăng nhập root bằng mật khẩu, chuyển sang SSH key

Đây là biện pháp quan trọng nhất. Tham khảo chi tiết trong hướng dẫn cách bảo mật SSH cho VPS. Sửa file /etc/ssh/sshd_config:

PermitRootLogin prohibit-password    # chỉ cho root login bằng key, cấm mật khẩu
PasswordAuthentication no            # tắt xác thực mật khẩu cho tất cả user

Trước khi restart SSH, hãy chắc chắn bạn đã thêm public key vào ~/.ssh/authorized_keys và test đăng nhập bằng key trên một phiên mới. Mất key mà đã tắt password = khóa mình ngoài server.

Đổi port SSH

Không phải biện pháp bảo mật thật sự (security through obscurity), nhưng giảm đáng kể lượng bot quét brute-force tự động — phần lớn chỉ quét port 22. Quy trình an toàn: mở port mới song song port cũ → verify đăng nhập được bằng port mới → mới đóng port cũ.

Cài Fail2ban

Fail2ban giám sát log SSH và tự động ban IP sau một số lần đăng nhập sai. Cấu hình jail sshd với maxretry = 5 là điểm khởi đầu hợp lý. Hướng dẫn chi tiết trong bài cài đặt Fail2ban chống brute-force SSH.

Firewall, backup và giám sát

Cấu hình UFW hoặc iptables chỉ mở đúng port cần thiết (SSH port mới, HTTP/HTTPS, port ứng dụng). Tham khảo thêm các biện pháp tổng hợp trong bài bảo mật VPS Linux.

Thiết lập backup/snapshot định kỳ để khi sự cố xảy ra, bạn có thể khôi phục nhanh thay vì gỡ thủ công. Đây là lúc Cloud Server phát huy giá trị — snapshot tức thì, khôi phục trong vài phút, cô lập dịch vụ trên các instance riêng biệt.

Câu hỏi thường gặp (FAQ)

Làm sao biết VPS có bị nhiễm rootkit hay không?

Chạy cat /etc/ld.so.preload — nếu file chứa đường dẫn tới một shared library lạ, gần như chắc chắn bị cài rootkit userland. Kết hợp kiểm tra: CPU cao không rõ nguyên nhân, ss -tnp có kết nối outbound nhưng cột Process trống dù đang root. Đừng chỉ dựa vào ps — nó có thể đã bị hook.

Vì sao ps và ss không thấy tiến trình đào coin?

Rootkit LD_PRELOAD hook hàm readdir64() — hàm mà ps, ls, find dùng để liệt kê nội dung /proc. Hook này lọc bỏ entry PID của miner, nên các lệnh này “không thấy” tiến trình đó. Gỡ file /etc/ld.so.preload rồi chạy lại ps sẽ thấy miner lộ ra ngay.

Rootkit ustar và /etc/ld.so.preload là gì?

/etc/ld.so.preload là file cấu hình của Linux dynamic linker — mọi thư viện được liệt kê trong đó sẽ load trước tất cả thư viện khác khi chương trình ELF khởi chạy. Rootkit ustar lợi dụng cơ chế này để ghi một lib hook readdir64() vào file đó, ẩn tiến trình miner và các file liên quan (/.ustar*) khỏi mọi công cụ liệt kê thư mục.

Gỡ rootkit xong có bị đào coin lại không?

Có — nếu bạn không vá lỗ hổng gốc. Trong hầu hết các ca, vector là SSH brute-force vào root do mật khẩu yếu. Gỡ miner mà vẫn để PermitRootLogin yes + mật khẩu yếu + không Fail2ban thì kẻ tấn công sẽ quay lại trong vài giờ. Phải tắt đăng nhập root bằng mật khẩu, chuyển sang SSH key, đổi port, cài Fail2ban.

Bị chiếm quyền root rồi, có bắt buộc cài lại VPS không?

Không bắt buộc, nhưng khuyến nghị. Kẻ tấn công có root có thể sửa bất kỳ file nào — kể cả công cụ kiểm tra. Nếu chỉ là rootkit userland (LD_PRELOAD) + miner, phát hiện sớm, rà hết persistence và vá SSH, thì gỡ tại chỗ có thể chấp nhận được. Với production xử lý dữ liệu nhạy cảm hoặc không rõ bị từ khi nào, dựng lại sạch an toàn hơn.

Nội dung mang tính tham khảo cho mục đích phòng thủ và ứng cứu sự cố. Tên file, port, tên service và hành vi mã độc có thể khác giữa các biến thể, phiên bản hệ điều hành và môi trường thực tế. Với máy đã bị chiếm quyền root, dựng lại sạch từ nguồn tin cậy thường an toàn hơn dọn thủ công. Hãy sao lưu bằng chứng, kiểm thử trên môi trường tách biệt và cân nhắc nhờ chuyên gia an toàn thông tin trước khi áp dụng cho production.