CVE-2026-73570: Lỗ hổng Zimbra SNMP RCE bị khai thác để cài mã độc đào coin

Tổng quan

Zimbra đã công bố rằng một số phiên bản Zimbra Collaboration bị ảnh hưởng bởi lỗ hổng thực thi mã từ xa (RCE) không cần xác thực nếu server được cấu hình với tham số snmp_notify. Một thông điệp SMTP được chế tạo đặc biệt gửi tới server Zimbra có thể chạm tới đoạn logic dễ bị tấn công trong trình xử lý thông báo SNMP, và kẻ tấn công có thể đạt được RCE mà không cần xác thực. Lỗ hổng này được định danh là CVE-2026-73570 và được xếp hạng mức độ nghiêm trọng cao với điểm CVSS là 8.9.

Các bằng chứng cho thấy CVE-2026-73570 đang bị khai thác chủ động trong thực tế, và lỗ hổng này đã được bổ sung vào danh sách CISA KEV vào ngày 21 tháng 8 năm 2026.

Điểm đáng lo ngại nhất: đây là lỗ hổng không cần xác thực (unauthenticated) — kẻ tấn công không cần bất kỳ tài khoản hay quyền truy cập nào trên server, chỉ cần gửi một yêu cầu SMTP được chế tạo đặc biệt tới server Zimbra là có thể thực thi lệnh hệ thống với quyền của user zimbra.

Điều kiện để bị ảnh hưởng

Không phải mọi server Zimbra đều bị ảnh hưởng ngay. Lỗ hổng chỉ khai thác được khi hội đủ các điều kiện sau:

• Chạy ZCS phiên bản thấp hơn 10.1.20
• Có cài đặt gói zimbra-snmp (gói tùy chọn, không phải mặc định trên mọi bản cài)
• Đã bật thông báo SNMP thông qua tham số snmp_notify
• Service swatchdog đang chạy (mặc định thường được bật sẵn trên nhiều bản cài)

Về mặt kỹ thuật, luồng khai thác diễn ra như sau: kẻ tấn công gửi một request SMTP có chứa dữ liệu độc hại → dữ liệu này được xử lý như một sự kiện được Zimbra giám sát → thành phần thông báo SNMP xử lý dữ liệu đó nhưng không kiểm tra/lọc đầu vào đúng cách → dữ liệu độc hại lọt vào lệnh shell được thực thi trên server.

Về khả năng bị lợi dụng để cài mã độc đào coin

Cần nói rõ: các báo cáo công khai hiện tại từ CERT Polska, CISA và các hãng bảo mật (SOCRadar, SecurityWeek, TheHackerNews…) xác nhận lỗ hổng đang bị khai thác chủ động trong thực tế và kẻ tấn công có thể thực thi lệnh tùy ý với quyền user zimbra, đủ để cài web shell, đọc trộm dữ liệu email, hoặc triển khai thêm mã độc — nhưng các nguồn này chưa công bố chi tiết cụ thể về payload cryptominer trong chiến dịch này tính đến thời điểm hiện tại.

Tuy vậy, xét về mặt thực tiễn threat intelligence: các lỗ hổng RCE không xác thực trên hạ tầng mail/collaboration công khai trên Internet (như MOVEit, Ivanti, Citrix trước đây) đều có chung một kịch bản hậu khai thác phổ biến — trong đó cài cryptominer (đào Monero/XMR) là một trong những mục đích thường gặp nhất, bên cạnh web shell và botnet, vì server mail thường có cấu hình mạnh, chạy liên tục 24/7 và ít được giám sát tài nguyên chặt chẽ. Vì vậy dù chưa có xác nhận chính thức riêng cho CVE-2026-73570, khả năng bị lợi dụng để đào coin là hoàn toàn hiện thực và nên được đưa vào danh sách kịch bản cần rà soát.

Khuyến nghị xử lý cho quản trị viên

1. Vá ngay lập tức: nâng cấp Zimbra Collaboration Suite lên bản 10.1.20 trở lên.
2. Kiểm tra cấu hình hiện tại trước khi vá, để biết mức độ rủi ro đã từng bị phơi nhiễm:

Kiểm tra nhanh:

su - zimbra -c 'zmcontrol -v'
dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp'
su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'
Nếu thấy zimbraServiceEnabled: snmp và zmlogswatch is running, cần kiểm tra dấu hiệu compromise ngay.

Dấu hiệu Zimbra đã bị khai thác

Trong các case bị khai thác, malware thường được đặt trong /dev/shm vì đây là tmpfs, có thể ghi nhanh và dễ bị admin bỏ sót.

Kiểm tra:

ls -la /dev/shm
crontab -l -u zimbra
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep

Các file đáng nghi thường gặp:

/dev/shm/.khp
/dev/shm/.khp_ts
/dev/shm/.rguard
/dev/shm/idle
/dev/shm/javab
/dev/shm/ksmd

Vì sao mã độc cứ tự tạo lại?

Chỉ xoá file trong /dev/shm thường không đủ. Malware có thể quay lại vì nhiều nguyên nhân:

• Process malware vẫn còn chạy trong RAM.
• Cron user zimbra chạy lại /dev/shm/.khp mỗi phút.
• Script .rguard hoặc idle tự bảo vệ payload.
• SNMP/logwatch vẫn bật nên attacker có thể khai thác lại CVE.

Vì vậy thứ tự xử lý đúng phải là:

Chặn nguồn tái nhiễm
→ Backup evidence
→ Kill process malware
→ Xoá cron độc
→ Quarantine file malware
→ Verify sạch
→ Recovery dịch vụ Zimbra nếu cần
→ Patch/upgrade Zimbra

Cách xử lý CVE-2026-73570 và malware Zimbra

Các lệnh dưới đây nên chạy bằng user root. Trước khi thao tác trên server production, nên backup và hiểu rõ tác động của từng bước.

Bước 1: Dừng nguồn tái nhiễm

systemctl stop cron
su - zimbra -c 'zmlogswatchctl stop'
su - zimbra -c 'zmswatchctl stop'
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'

Việc disable SNMP/logwatch là điểm quan trọng nhất trong quá trình containment. Nếu chưa patch Zimbra, không nên bật lại các thành phần này.

Bước 2: Backup lại thông tin mã độc

mkdir -p /root/incident-zimbra

cp -a /dev/shm/.khp \
      /dev/shm/.khp_ts \
      /dev/shm/.rguard \
      /dev/shm/idle \
      /dev/shm/javab \
      /dev/shm/ksmd \
      /root/incident-zimbra/ 2>/dev/null

crontab -l -u zimbra > /root/incident-zimbra/zimbra-cron-before.txt 2>&1
ps auxf > /root/incident-zimbra/ps-before.txt
ss -tunap > /root/incident-zimbra/ss-before.txt
sha256sum /root/incident-zimbra/* > /root/incident-zimbra/sha256.txt 2>/dev/null

Bước 3: Kill process malware

pkill -9 -u zimbra -f 'khp|rguard|javab|idle|ksmd'

Bước 4: Xoá cron độc

crontab -l -u zimbra | grep -v '/dev/shm/.khp' | crontab -u zimbra -

Bước 5: Quarantine file malware

mkdir -p /root/quarantine-zimbra

mv /dev/shm/.khp \
   /dev/shm/.khp_ts \
   /dev/shm/.rguard \
   /dev/shm/idle \
   /dev/shm/javab \
   /dev/shm/ksmd \
   /root/quarantine-zimbra/ 2>/dev/null

Bước 6: Bật lại cron

systemctl start cron
systemctl is-active cron

Chỉ bật lại cron. Không bật lại zmlogswatch, zmswatch hoặc SNMP nếu chưa patch Zimbra.

Kiểm tra sau khi dọn

ls -la /dev/shm
crontab -l -u zimbra | grep /dev/shm
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp || echo SNMP_DISABLED'

Kết quả mong muốn:

• /dev/shm trống.
• Không còn cron gọi /dev/shm/.khp.
• Không còn process javab, rguard, idle.
• SNMP đã disabled.

Nếu Zimbra MySQL hoặc mailbox bị lỗi

Sau khi bị malware hoặc reboot đột ngột, Zimbra có thể gặp lỗi:

mailbox Stopped
mysql.server is not running
service webapp Stopped
zimbra webapp Stopped
zimbraAdmin webapp Stopped
zimlet webapp Stopped

Kiểm tra MySQL:

su - zimbra -c 'zmcontrol status'
su - zimbra -c 'mysql.server status'
ss -ltnp | grep 7306
tail -n 200 /opt/zimbra/log/mysql_error.log

Nếu MySQL bị kẹt ở crash recovery hoặc còn stale socket, có thể recovery nhẹ theo hướng backup trước rồi cho MySQL tự tạo lại socket và tc.log.

Backup trước khi recovery

mkdir -p /root/zimbra-mysql-backup

cp -a /opt/zimbra/log/mysql_error.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ibdata1 /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ib_logfile* /root/zimbra-mysql-backup/ 2>/dev/null

Recovery MySQL nhẹ

su - zimbra -c 'zmmailboxdctl stop'

mv /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/mysql.sock.bak 2>/dev/null
mv /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/tc.log.bak 2>/dev/null

su - zimbra -c 'mysql.server start'
sleep 20
su - zimbra -c 'mysql.server status'

su - zimbra -c 'zmmailboxdctl start'
sleep 40
su - zimbra -c 'zmcontrol status'

Kết quả mong muốn:

mysql is running
mailbox Running
service webapp Running
zimbra webapp Running
zimbraAdmin webapp Running
zimlet webapp Running

Có mất dữ liệu mail không?

Các bước dọn malware, disable SNMP/logwatch, kill process và quarantine file trong /dev/shm không đụng đến dữ liệu mail.

Dữ liệu mail Zimbra thường nằm tại:

/opt/zimbra/store/

Database Zimbra nằm tại:

/opt/zimbra/db/data/

Riêng bước recovery MySQL có thao tác với tc.log và mysql.sock, vì vậy cần backup trước. Đây không phải thao tác xoá mailbox, nhưng vẫn cần cẩn thận vì liên quan database metadata.

Kiểm tra các file JSP

Sau khi xử lý xong các phần trên cũng nên xem xét các tệp được tạo bởi người dùng Zimbra trong 30 ngày qua. Các thư mục quan trọng nhất cần điều tra là /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ và /tmp/. Các tệp JSP không mong muốn, tập lệnh thực thi, kho lưu trữ hoặc nội dung ứng dụng được sửa đổi gần đây tại các vị trí này có thể cho thấy việc dàn dựng payload hoặc thiết lập quyền truy cập.

find /opt/zimbra/jetty/webapps -type f \( -name "*.jsp" -o -name "*.jspx" \) -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort

Các file JSP này là backdoor hiện vẫn còn trong jetty webapps. Nên cần backup evidence rồi quarantine/xoá các JSP độc khỏi cả 2 path:

/opt/zimbra/jetty/webapps/zimbra/
/opt/zimbra/jetty_base/webapps/zimbra/

TS=$(date +%Y%m%d_%H%M%S)
INC=/root/incident-zmmail-jsp-webshell-$TS
QUA=/root/quarantine-zmmail-jsp-webshell-$TS

mkdir -p "$INC" "$QUA"

# Lưu danh sách + hash
find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jetty_base/webapps/zimbra \
  -xdev -type f \( -iname '*.jsp' -o -iname '*.jspx' \) -mtime -30 \
  -print > "$INC/suspicious-jsp-list.txt"

xargs -a "$INC/suspicious-jsp-list.txt" sha256sum > "$INC/suspicious-jsp-sha256.txt"

# Backup mẫu
while read f; do
  mkdir -p "$INC/files$(dirname "$f")"
  cp -a "$f" "$INC/files$f"
done < "$INC/suspicious-jsp-list.txt"

# Quarantine khỏi webroot
while read f; do
  mkdir -p "$QUA$(dirname "$f")"
  mv "$f" "$QUA$f"
done < "$INC/suspicious-jsp-list.txt"

# Verify
find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jetty_base/webapps/zimbra \
  -xdev -type f \( -iname '*.jsp' -o -iname '*.jspx' \) -mtime -30 -print

Rủi ro có thể gặp

• Nếu file nào là JSP hợp lệ/custom thì có thể ảnh hưởng chức năng webmail custom.
• Nhưng các tên random và nội dung exec/base64/AES cho thấy gần như chắc là webshell.
• Không ảnh hưởng dữ liệu mail.
• Không cần restart ngay, nhưng sau quarantine nên verify webmail.

Việc cần làm sau khi hệ thống chạy lại

• Giữ SNMP/logwatch tắt nếu chưa patch.
• Theo dõi /dev/shm trong 30-60 phút.
• Theo dõi crontab user zimbra.
• Theo dõi CPU/load và outbound connection.
• Kiểm tra mail queue.
• Update/patch Zimbra lên bản đã vá CVE.
• Chỉ bật lại SNMP/logwatch sau khi đã patch và kiểm tra an toàn.

Kiểm tra queue:

/opt/zimbra/common/sbin/postqueue -p | tail -n 40

Lưu ý quan trọng

Một điểm cần lưu ý sau khi tắt SNMP/logwatch để giảm thiểu CVE-2026-73570 là zmlogswatch và zmswatch có thể tự chạy lại sau thời điểm logrotate hằng ngày hoặc sau khi zmcontrol restart.

Nguyên nhân là trong cấu hình logrotate của Zimbra thường có các dòng postrotate tự gọi zmlogswatchctl restart và zmswatchctl restart; đồng thời service logger vẫn nằm trong zimbraServiceEnabled. Vì vậy, sau khi tắt tạm thời, quản trị viên nên kiểm tra lại trạng thái các dịch vụ này định kỳ, đặc biệt sau 00:00 hoặc sau khi restart Zimbra.

Nếu cần chặn triệt để trong giai đoạn chưa vá, có thể backup rồi comment các dòng restart trong /etc/logrotate.d/zimbra và /opt/zimbra/conf/zmlogrotate, đồng thời cân nhắc remove logger khỏi zimbraServiceEnabled. Việc này giúp tránh logwatch tự bật lại và tái mở vector khai thác, nhưng có thể làm Admin Console mất một phần thống kê/monitoring.

Cách tắt zmlogswatch/zmswatch để tránh tự bật lại:

Lưu ý: Việc tắt logger, zmlogswatch và zmswatch có thể khiến Admin Console hiển thị trạng thái logger/monitoring màu đỏ hoặc mất một phần biểu đồ thống kê. Tuy nhiên trong giai đoạn chưa vá CVE-2026-73570, đây là biện pháp cần thiết để tránh logwatch tự bật lại và tái mở vector khai thác. Sau khi nâng cấp lên bản đã vá, quản trị viên có thể khôi phục cấu hình từ file backup và bật lại logger nếu cần.

Trước tiên backup cấu hình logrotate của Zimbra:

cp -a /etc/logrotate.d/zimbra /etc/logrotate.d/zimbra.bak.$(date +%F-%H%M%S)
cp -a /opt/zimbra/conf/zmlogrotate /opt/zimbra/conf/zmlogrotate.bak.$(date +%F-%H%M%S)

Sau đó mở 2 file:

/etc/logrotate.d/zimbra
/opt/zimbra/conf/zmlogrotate

Tìm 2 dòng: (Thường nằm dòng thứ 85 và 99)

su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true
su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Comment lại thành:

# su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true
# su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Tiếp theo tắt logger service khỏi danh sách service enabled:

su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled logger'

Sau đó tắt các process logwatch/swatch hiện tại:

su - zimbra -c 'zmlogswatchctl stop'
su - zimbra -c 'zmswatchctl stop'
su - zimbra -c 'zmlocalconfig -e snmp_notify=no'

Kiểm tra lại:

su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'
su - zimbra -c 'zmlocalconfig snmp_notify'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp" || echo "LOGGER_SNMP_DISABLED"'

Kết quả

zmlogswatch is not running.
zmswatch is not running.
snmp_notify = no
LOGGER_SNMP_DISABLED

Tóm tắt quy trình xử lý

1. Kiểm tra /dev/shm, process và crontab.
2. Dừng cron, zmlogswatch, zmswatch.
3. Disable SNMP trong Zimbra.
4. Backup evidence.
5. Kill process malware.
6. Xoá cron độc.
7. Quarantine file malware.
8. Bật lại cron.
9. Verify malware không tái tạo.
10. Recovery MySQL/mailbox nếu cần.
11. Theo dõi queue và service.
12. Patch/upgrade Zimbra.

Kết luận

CVE-2026-73570 là một lỗ hổng nghiêm trọng do tính chất không cần xác thực và đang bị khai thác chủ động trên diện rộng. Với các server Zimbra đang quản lý, việc vá lên 10.1.20 cần được coi là ưu tiên khẩn cấp, đi kèm với rà soát dấu hiệu xâm nhập chứ không chỉ đơn thuần cập nhật phiên bản rồi bỏ qua giai đoạn trước đó.