Phòng thủ Active Directory: Các chiến thuật thực tế chống lại tấn công PtH, Kerberoasting và Golden Ticket

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

Trận địa AD: Những bài học từ chiến dịch thắt chặt bảo mật kéo dài 6 tháng

Gần đây tôi vừa hoàn thành dự án tái cấu trúc môi trường Active Directory (AD) cũ kỹ đã tồn tại 12 năm. Thành thật mà nói, đó từng là một “bữa tiệc” cho các kỹ thuật di chuyển ngang (lateral movement).

Giống như hầu hết các hệ thống doanh nghiệp khác, nó đã phát triển tự phát trong hơn một thập kỷ, để lại một mớ hỗn độn các tài khoản dịch vụ dư thừa quyền hạn và các mã hash NTLM cũ kỹ. Nhiệm vụ của tôi không chỉ dừng lại ở phần mềm diệt virus cơ bản. Tôi cần một chiến lược phòng thủ nhắm trực tiếp vào ba loại tấn công chính: Pass-the-Hash, Kerberoasting và Golden Ticket cực kỳ nguy hiểm.

Để xử lý mớ hỗn độn này, tôi cần khả năng quan sát (visibility) trước khi chạm vào bất kỳ tệp cấu hình nào. Tôi cũng cần các công cụ nhẹ và tin cậy để lập kế hoạch mạng. Ví dụ, khi cô lập các Máy trạm Quản trị Đặc quyền (PAW), tôi đã sử dụng công cụ tính toán subnet tại https://toolcraft.app/vi/tools/developer/ip-subnet-calculator. Nó xử lý các phép tính CIDR trực tiếp trên trình duyệt, phù hợp với quy trình ưu tiên quyền riêng tư mà tôi yêu cầu khi xử lý các chi tiết hạ tầng cốt lõi.

Nhận diện kẻ thù

Phòng thủ bắt đầu từ việc hiểu rõ cách khai thác. Pass-the-Hash (PtH) lợi dụng cách Windows xử lý NTLM; kẻ tấn công không cần mật khẩu của bạn, chỉ cần mã hash nằm trong không gian bộ nhớ LSASS.

Kerberoasting nhắm vào các tài khoản dịch vụ bằng cách yêu cầu một vé dịch vụ (TGS) và bẻ khóa ngoại tuyến — một kỹ thuật yêu thích của tin tặc vì nó gần như không để lại dấu vết. Cuối cùng, tấn công Golden Ticket xảy ra nếu kẻ địch đánh cắp được mã hash của tài khoản KRBTGT. Khi đó coi như “game over”; chúng có thể giả mạo vé và tự cấp quyền domain admin theo ý muốn.

Cài đặt: Lập bản đồ bề mặt tấn công

Khả năng quan sát là yếu tố then chốt. Nếu không thấy đường đi, bạn không thể chặn nó. Tôi chọn BloodHound, một công cụ mã nguồn mở sử dụng lý thuyết đồ thị để tiết lộ các đường dẫn quan hệ ẩn. Bên dưới, it chạy trên cơ sở dữ liệu Neo4j với giao diện React, được cung cấp dữ liệu bởi SharpHound.

Triển khai BloodHound trên Linux

Tôi chạy giao diện BloodHound trên một máy trạm bảo mật riêng biệt. Sử dụng Docker là cách đáng tin cậy nhất để giữ cho cơ sở dữ liệu và ứng dụng đồng bộ mà không gặp phải thảm họa xung đột phụ thuộc (dependency hell):

# Tải và chuẩn bị môi trường BloodHound
git clone https://github.com/BloodHoundAD/BloodHound.git
cd BloodHound/Collectors

# Khởi chạy hệ thống bằng Docker Compose
docker-compose up -d

Khi các container đã hoạt động, bảng điều khiển sẽ nằm ở localhost:8080. Để nạp dữ liệu, tôi chạy SharpHound.exe từ một tài khoản người dùng bình thường, không có đặc quyền. Đây là lúc dữ liệu kiểm tra bắt đầu “kể chuyện”, lập bản đồ tư cách thành viên nhóm và các phiên hoạt động trên toàn bộ domain.

# Thực thi trình thu thập dữ liệu từ cửa sổ PowerShell tiêu chuẩn
.\SharpHound.exe -c All --zipfilename MyDomainAudit.zip

Cấu hình: Đóng các “lỗ hổng”

Đợt kiểm tra đầu tiên là một hồi chuông cảnh tỉnh. Tôi phát hiện ra rằng chỉ cần chiếm được tài khoản của một thực tập sinh bộ phận hỗ trợ (helpdesk), kẻ tấn công có thể leo thang lên Domain Admin chỉ sau đúng 3 bước. Tôi đã triển khai cơ chế khóa nhiều lớp để triệt hạ những con đường đó.

1. Triệt tiêu Pass-the-Hash bằng LSA Protection

Cách tốt nhất để chặn PtH là đảm bảo thông tin đăng nhập không bị lưu vào bộ nhớ đệm (cache) ở những nơi mà các công cụ như Mimikatz có thể tìm thấy. Tôi đã bắt buộc sử dụng LSA ProtectionCredential Guard thông qua Group Policy. Điều này đưa tiến trình LSASS vào một container được bảo vệ.

Mở GPO Editor và đi tới:
Computer Configuration > Administrative Templates > System > Local Security Authority
Thiết lập Configure LSA to run as a PPL thành Enabled.

2. Vô hiệu hóa Kerberoasting

Kerberoasting “sống nhờ” vào mật khẩu yếu. Tôi đã xác định mọi tài khoản có Service Principal Name (SPN) và yêu cầu đổi mật khẩu bắt buộc. Đối với những tài khoản này, tôi tạo các chuỗi 32 ký tự bằng toolcraft.app/vi/tools/security/password-generator. Vì nó chạy hoàn toàn trên trình duyệt, không có chuỗi nhạy cảm nào được gửi qua mạng. Độ hỗn loạn (entropy) cao là cách phòng thủ thực sự duy nhất ở đây.

# Tìm tất cả tài khoản dễ bị tấn công Kerberoasting
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

3. Bảo vệ “chìa khóa vạn năng”

Cách duy nhất để thực sự vô hiệu hóa Golden Ticket là bảo vệ tài khoản KRBTGT. Tôi đã viết một tập lệnh để đổi mật khẩu KRBTGT hai lần mỗi 180 ngày — việc này sẽ xóa lịch sử NTLM và hủy bất kỳ vé giả mạo nào đang tồn tại. Tôi cũng chuyển tất cả Domain Admins vào nhóm Protected Users. Bước đi đơn giản này sẽ vô hiệu hóa NTLM cho các tài khoản đó và bắt buộc sử dụng mã hóa AES cho Kerberos.

Giám sát: “Bật đèn” soi rọi hệ thống

Thắt chặt bảo mật giúp bảo vệ hiện tại, nhưng giám sát mới bảo vệ tương lai. Để bắt được những gì GPO có thể bỏ sót, tôi đã triển khai Sysmon trên toàn domain. Nó cung cấp các chi tiết chuyên sâu mà nhật ký Windows tiêu chuẩn thường bỏ qua.

Phát hiện truy cập thông tin đăng nhập trong thời gian thực

Tôi sử dụng bộ lọc Sysmon để theo dõi Event ID 10 (ProcessAccess) nhắm mục tiêu cụ thể vào lsass.exe. Đây là bằng chứng rõ ràng cho các nỗ lực trích xuất mã hash (hash dumping).

<!-- Bộ lọc Sysmon để phát hiện can thiệp vào LSASS -->
<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
      *[System[(EventID=10)]] and *[EventData[Data[@Name='TargetImage']='C:\Windows\system32\lsass.exe']]
    </Select>
  </Query>
</QueryList>

Đối với Kerberoasting, hãy chú ý Event ID 4769. Nếu mã lỗi là 0x0 và loại mã hóa là 0x17 (RC4), có khả năng ai đó đang cố gắng bẻ khóa vé dịch vụ của bạn. Các môi trường hiện đại nên sử dụng AES (0x12), vì vậy RC4 là một dấu hiệu cảnh báo nguy hiểm.

Khi phân loại các nhật ký này, tôi thường cần xác minh xem mã hash có khớp với mẫu độc hại đã biết hay không. Tôi luôn mở công cụ tạo mã hash tại https://toolcraft.app/vi/tools/developer/hash-generator để nhanh chóng kiểm tra checksum. Nó nhanh hơn việc chạy một công cụ CLI trên máy chủ đang hoạt động.

Lời kết

Sáu tháng sau, biểu đồ BloodHound của chúng tôi đã sạch bóng. Những “con đường tắt” dễ dàng dẫn đến quyền Domain Admin đã biến mất. Bảo mật Active Directory không phải là việc “cài một lần là xong”; đó là việc thu hẹp bề mặt tấn công cho đến khi các hành vi di chuyển ngang trở nên quá lộ liễu để có thể tồn tại. Nếu mật khẩu KRBTGT của bạn đã hơn sáu tháng tuổi, bạn biết việc đầu tiên cần làm vào ngày mai là gì rồi đấy.

Share: