Posted inSecurity

Phân tích mã độc tự động với Sandbox CAPEv2 trên Linux: Xây dựng phòng kích nổ cô lập để trích xuất IOC

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Vấn đề thực tế: Điểm nghẽn xử lý sự cố lúc 2:00 sáng

Chuông báo động réo liên hồi lúc 2:14 sáng. Firewall biên của chúng tôi phát hiện một HTTPS beacon gửi dữ liệu ra ngoài với dung lượng 140 KB mỗi 45 giây tới một dải ASN chưa được phân bổ (AS212238). Ba phút sau, agent EDR đã cách ly một binary được thả xuống từ máy trạm của phòng kế toán: billing_update_v8.exe. VirusTotal hiển thị tỷ lệ nhận diện 0/72. Chúng tôi đang phải đối mặt với một dropper mới được biên dịch và đóng gói (packed) bằng crypter tùy biến.

Thời gian không còn nhiều. Trưởng nhóm SOC cần những câu trả lời cụ thể: Binary này kết nối tới hạ tầng C2 nào? Liệu nó có thả thêm payload ransomware thứ cấp hay Cobalt Strike stager không? Nó có đang dump LSASS không? Và quan trọng nhất: những chỉ số thỏa hiệp (IOC) nào có thể đẩy lên firewall Palo Alto trước khi trời sáng để ngăn chặn tấn công lan rộng (lateral movement)?

Việc dịch ngược (disassemble) shellcode đa giai đoạn trong Ghidra hoặc x64dbg vào lúc 2 giờ sáng thường mất từ ba đến bốn tiếng. Chuỗi tĩnh (static strings) không mang lại thông tin gì do binary đã bị đóng gói bằng crypter tùy chỉnh. Trong khi đó, việc thực thi nó trên một máy thử nghiệm tạm bợ lại tiềm ẩn rủi ro lộ sang VLAN quản trị hoặc kích hoạt các vòng lặp sleep lẩn tránh của mã độc.

Phân tích nguyên nhân gốc rễ: Vì sao phân tích động tự phát dễ thất bại

Khi đội ngũ ứng phó sự cố gặp bế tắc trong đợt bùng phát mã độc, nguyên nhân thường bắt nguồn từ ba lỗ hổng mang tính hệ thống trong kiến trúc sandbox:

1. Nhận diện dấu vết Hypervisor và môi trường ảo hóa

Các loader hiện đại quét tìm dấu vết hypervisor chỉ trong vài giây. Chúng truy vấn registry để tìm chuỗi khớp với HARDWARE\Description\System\BIOS (như ‘QEMU’ hoặc ‘VBOX’), kiểm tra tiền tố MAC mặc định của nhà cung cấp (52:54:00), và đếm số lượng nhân CPU. Nếu phát hiện trình gỡ lỗi (debugger) hoặc môi trường ảo hóa, binary sẽ rơi vào trạng thái ngủ trong 24 giờ hoặc chỉ khởi chạy một tiến trình máy tính (calc) vô hại.

2. Sai lệch Snapshot và dữ liệu đo kiểm (Telemetry) không đồng nhất

Phân tích tự phát trên các hypervisor dành cho máy trạm phụ thuộc nhiều vào thao tác hoàn tác thủ công. Chỉ cần chuyên viên phân tích quên revert lại snapshot sạch, các registry key còn sót lại sẽ làm sai lệch lần chạy tiếp theo. File bắt gói tin PCAP cũng bị trộn lẫn với telemetry nền của máy host, buộc chuyên viên phải lọc thủ công các luồng DNS hợp lệ ngay giữa thời điểm sự cố căng thẳng.

3. Payload ẩn trong bộ nhớ

Các sandbox truyền thống chỉ giám sát hoạt động bề mặt: cây tạo tiến trình, cơ chế duy trì persistence trên registry và các truy vấn DNS thô. Các loader hiện đại lại tiêm trực tiếp payload đã mã hóa vào các tiến trình hợp lệ như svchost.exe hoặc explorer.exe thông qua kỹ thuật process hollowing hoặc thread hijacking. Nếu không có khả năng tự động giải nén (unpack) trong bộ nhớ cùng các API hook sâu ở tầng kernel, bạn sẽ không bao giờ trích xuất được khối cấu hình thực sự của mã độc.

So sánh giải pháp: Lựa chọn pipeline phân loại và xử lý phù hợp

Các đội ngũ kỹ sư bảo mật thường cân nhắc ba kiến trúc chính khi chuẩn hóa quy trình phân loại tự động:

  • SaaS Sandbox thương mại (Any.Run, Hybrid Analysis): Triển khai nhanh chóng với chi phí vận hành tối thiểu. Tuy nhiên, việc tải file nội bộ lên có nguy cơ làm lộ dữ liệu nhạy cảm ra các nguồn tìm kiếm công khai. Các gói API theo nhu cầu cũng tốn từ $5.000 đến $12.000 mỗi năm cho một vị trí chuyên viên.
  • Cuckoo Sandbox cũ: Từng là tiêu chuẩn mã nguồn mở, nhưng dự án gốc gần như đã ngừng phát triển từ năm 2019. Môi trường chạy Python 2.7 của nó gây ra xung đột dependency nghiêm trọng trên Ubuntu 22.04 LTS trở lên. Đồng thời, nó thiếu các cơ chế giảm thiểu kỹ thuật lẩn tránh hiện đại và không có bộ trích xuất cấu hình bộ nhớ tích hợp sẵn.
  • CAPEv2 (Config And Payload Extraction): Một bản fork cộng đồng chạy Python 3 đang phát triển tích cực từ Cuckoo. CAPEv2 hook các lệnh gọi hệ thống ở tầng ntdll, dump bộ nhớ tiến trình chính xác tại các điểm ngắt khi unpack và chạy các module parser chuyên dụng. Nó trích xuất cấu hình dạng plaintext—như Cobalt Strike watermark, thông tin đăng nhập của AgentTesla và địa chỉ C2 của RedLine—trực tiếp thành định dạng JSON có cấu trúc.

Giải pháp tối ưu: Xây dựng Lab CAPEv2 Headless trên Ubuntu với KVM/QEMU

Để loại bỏ điểm nghẽn trong khâu phân loại sự cố, chúng tôi đã xây dựng một máy chủ Ubuntu chuyên dụng 16 nhân, 64 GB RAM chạy CAPEv2 trên nền KVM/QEMU, được cô lập hoàn toàn trên một virtual network bridge chỉ giao tiếp với host (host-only).

Giai đoạn 1: Gia cố máy Host và cài đặt các dependency cho Hypervisor

Khởi tạo một máy chủ Ubuntu LTS đã bật ảo hóa phần cứng. Xác minh các extension CPU bằng lệnh egrep -c '(vmx|svm)' /proc/cpuinfo (kết quả trả về phải từ 1 trở lên).

Việc phân tách thông tin xác thực an toàn giữa host sandbox, cơ sở dữ liệu và các máy ảo guest là điều tối quan trọng. Hãy tạo mật khẩu riêng biệt dài 24 ký tự bằng một công cụ chạy offline trên trình duyệt như trình tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator. Nhờ xử lý entropy hoàn toàn ở phía client qua WebCrypto, mật khẩu cơ sở dữ liệu và hypervisor socket của bạn sẽ không bao giờ bị truyền qua các mạng bên ngoài.

# Cài đặt KVM, libvirt, PostgreSQL và các gói bắt gói tin mạng
sudo apt update && sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients \
    bridge-utils python3-pip python3-dev python3-venv git postgresql libpq-dev \
    tcpdump tshark libmagic1 libssl-dev

# Khởi động các dịch vụ hypervisor và phân quyền cho người dùng
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm $USER

Giai đoạn 2: Thiết lập môi trường Python cho CAPEv2

Tạo một tài khoản hệ thống chuyên dụng để chạy các tiến trình sandbox theo nguyên tắc đặc quyền tối thiểu (least privilege):

sudo useradd -m -s /bin/bash cape
sudo usermod -aG libvirt,kvm cape
sudo su - cape

git clone --depth 1 https://github.com/kevoreilly/CAPEv2.git ~/CAPEv2
cd ~/CAPEv2

python3 -m venv ~/cape-env
source ~/cape-env/bin/activate
pip install --upgrade pip setuptools wheel
pip install -r requirements.txt

# Tải về các signature từ cộng đồng và rule Yara mới nhất
python utils/community.py -a -f

Giai đoạn 3: Cô lập mạng và định tuyến bắt lưu lượng

Mã độc tuyệt đối không được phép định tuyến ngược trở lại mạng quản trị. Hãy thiết lập một bridge nội bộ (virbr1) với dải địa chỉ 192.168.122.0/24 cùng các quy tắc NAT được kiểm soát chặt chẽ. Cấp quyền bắt gói tin thô cho công cụ phân tích mà không cần chạy CAPEv2 dưới quyền root:

# Masquerade lưu lượng gửi ra ngoài của máy guest qua interface WAN (eth0)
sudo iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -s 192.168.122.0/24 -j ACCEPT

# Cấp quyền bắt gói tin cho tcpdump mà không cần toàn quyền root
sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

Giai đoạn 4: Thiết lập máy ảo Guest và tạo Snapshot chuẩn ban đầu

Cài đặt Windows 10 x64 bên trong KVM với 4 vCPU và 8 GB RAM. Để tránh việc mã độc kích hoạt cơ chế lẩn tránh ngoài ý muốn:

  • Vô hiệu hóa vĩnh viễn Windows Defender, SmartScreen và các thông báo UAC qua gpedit.msc.
  • Cài đặt các phần mềm người dùng thông thường: Google Chrome, Adobe Acrobat Reader, VLC và Microsoft Office. Thêm vào desktop các bảng tính mồi nhử và tạo sẵn lịch sử duyệt web.
  • Sao chép guest agent (~/CAPEv2/agent/agent.py) vào C:\agent.py và cấu hình để tự động khởi chạy khi khởi động với quyền nâng cao bằng Windows Task Scheduler.

Xác nhận guest agent phản hồi qua cổng HTTP 8000, sau đó tạo một snapshot chuẩn sạch ban đầu:

# Kiểm tra kết nối tới agent từ Linux host
curl -s http://192.168.122.105:8000

# Tạo snapshot lưu trạng thái RAM khi VM đang chạy
virsh snapshot-create-as --domain win10-analyst \
    --name clean_base \
    --description "Bản snapshot phân tích chuẩn sạch" \
    --atomic --running

Giai đoạn 5: Cấu hình profile cho Hypervisor

Ánh xạ các tham số của máy ảo guest trong thư mục cấu hình của CAPEv2 tại ~/CAPEv2/conf/kvm.conf:

[kvm]
ds_type = kvm
interface = virbr1
machines = win10-analyst

[win10-analyst]
label = win10-analyst
ip = 192.168.122.105
snapshot = clean_base
platform = windows
arch = x64

Giai đoạn 6: Gửi mẫu phân tích và tự động trích xuất cấu hình

Khởi chạy dịch vụ xử lý cốt lõi và bật dashboard quản trị:

# Terminal 1: Khởi chạy worker phân tích chính
source ~/cape-env/bin/activate
python cuckoo.py

# Terminal 2: Khởi chạy giao diện web
source ~/cape-env/bin/activate
python web/manage.py runserver 0.0.0.0:8000

Gửi mẫu mã độc đáng ngờ qua CLI kèm các cờ dump bộ nhớ và unpack của CAPE:

python utils/submit.py --package exe --timeout 120 \
    --options "cape=1,procmemdump=1" /tmp/billing_update_v8.exe

Xác thực các IOC đã trích xuất

Chưa đầy 90 giây, máy ảo đã khởi động, thực thi binary, unpack payload đã giải mã trong bộ nhớ và hoàn tác về snapshot ban đầu. Parser Cobalt Strike của CAPEv2 đã tự động trích xuất cấu hình beacon:

{
  "cape": {
    "family": "CobaltStrike",
    "configs": {
      "C2_Server": "198.51.100.44:443",
      "User_Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
      "Watermark": 4261821,
      "SleepTime": 45000,
      "Jitter": 15
    }
  },
  "network": {
    "dns": [{"request": "cdn-cache-sync.org", "type": "A"}],
    "hosts": ["198.51.100.44"]
  }
}

Đến 2:28 sáng, playbook SOAR tự động của chúng tôi đã tiếp nhận đầu ra JSON này. Hệ thống đã thêm 198.51.100.44 và cdn-cache-sync.org vào danh sách chặn tại biên mạng doanh nghiệp, triệt tiêu hoàn toàn chỗ đứng của kẻ tấn công nhiều giờ trước khi nhân viên đầu tiên quẹt thẻ vào văn phòng.

Share:
Tags: