Mở đầu

Cùng với NTLM, Kerberos là một giao thức xác thực trong AD. Cơ chế hoạt động của nó được xem là phức tạp hơn, chặt chẽ hơn, được sinh ra và trở thành công cụ xác thực mặc định/tiêu chuẩn từ Windows 2000 trở đi.

Một số điểm yếu của NTLM khiến nó bị thay thế bởi Kerberos:

Không hỗ trợ MFA
Password được lưu trữ trên DC không có “salt”. Do đó hệ thống dễ bị ảnh hưởng bởi các cuộc tấn công Brute-force.
NTLM Hash không phải là một thuật toán mã hóa mạnh
NTLM Relay Attack, NTLM pass-the-hash attack…

Tuy nhiên NTLM vẫn được phát triển qua từng phiên bản HĐH và được xem như một giao thức ‘backup’. Nếu Kerberos không xác thực được người dùng, hệ thống sẽ cố gắng sử dụng NTLM để thay thế.

Một số môn võ phổ biến để có thể đấm Kerberos trong AD:

Kerberoasting
AS-REP Roasting
Golden Ticket
Silver Ticket
Pass-The-Ticket

Ban đầu tác giả tính giới thiệu sơ lược và bao quát tất cả các môn phái trên nhưng do kiến thức rộng và còn cần tìm hiểu thêm nhiều nên quyết định chỉ tập trung vào 1 phương thức, đó là AS-REP Roasting.

Nguyên lý Kerberos Authentication

Đầu tiên nói sơ qua về nguyên lý xác thực, về cơ bản thì đây là các bước để authen khi sử dụng Kerberos :

(mô hình đánh số các bước dựa theo phần mô tả bên dưới)

Bước 1: User cấp username, password và domain name cho máy client.
Bước 2: Client tiến hành đóng gói thông tin thành 1 package hoặc có tên khác là ‘authenticator’, chứa các thông tin liên quan tới client, bao gồm username, ngày giờ (timestamp)… Ngoài username ra thì tất cả các info khác đều được mã hoá bằng password của người dùng.
Bước 3. Client gửi encrypted authenticator đó tới KDC (Key Distribution Center).
Bước 4. KDC check xem username nào đang gửi request tới, rồi nó lấy password của username đó đang được lưu trong databases, tiến hành decrypt thằng ‘authenticator’ với password đó. Nếu KDC có thể decrypt được thì danh tính của thằng user được xác minh là đúng.
Bước 5. Nếu verify thành công thì thằng KDC (cụ thể là AS – Authentication Server) sẽ tạo ra 1 ticket, nó cũng được encrypted và gửi lại về client (encrpyt bằng key của KRBTGT (key này chính là hash của password krbtgt user trên AD)), ticket đó được gọi là Ticket Granting Ticket (TGT).
Bước 6. Ticket sau khi nhận được lưu trữ trong Kerberos tray của client và được sử dụng để truy cập vào Server trong 1 thời gian nhất định (thường là 8 tiếng). Đến đây thì người dùng đã được xác thực trong domain.
Bước 7. Nếu Client cần truy cập vào một Server/service khác, nó sẽ gửi ticket gốc (TGT) tới KDC + yêu cầu truy cập tài nguyên mới.

Bước 8. Thằng KDC sẽ decrypt ticket bằng key của nó (thông qua ticket thì KDC có thể verify được rằng user’s identity đã được confirm trước đó).
Bước 9. KDC tạo và gửi 1 updated ticket để client truy cập tài nguyên mới (Ticket này cũng được mã hóa bằng key của KDC), hoặc nói đúng hơn là dùng hash password của dịch vụ đích cần truy cập. Lý do hash password service được sử dụng để encrypt / decrypt GTS ticket là vì đó là thông tin bí mật duy nhất được chia sẻ duy nhất giữa service và KDC / Domain Controller.
Bước 10. Client lưu ticket vào Kerberos tray và gửi bản sao tới Server cần xác thực.
Bước 11. Server mới dùng password riêng của mình để decrypt ticket.
Bước 12. Nếu decrpyt được => ticket hợp lệ, sau đó server dựa vào ACL (access control list) để cấp quyền cần thiết cho client.

AS-REP Roasting

Phương thức khai thác này khá phổ biến mặc dù đòi hỏi phải đạt điều kiện cần thiết, nó tập trung vào khai thác bước 3,4,5 ở mô hình trên.

Trước tiên nói sơ qua về một thuộc tính thú vị của lớp người dùng là UserAccountControl (UAC) (khác với cơ chế User Account Control để tránh thực thi các chương trình nâng cao trong máy Windows).

Thuộc tính UserAccountControl chứa một loạt các flags liên quan đến bảo mật và domain, một trong số đó được sử dụng ở kịch bản tấn công đề cập trong bài đăng này:

DONT_REQUIRE_PREAUTH -> Tài khoản không yêu cầu Kerberos pre-authentication.
Phần lớn trường hợp được sử dụng khi người dùng muốn xác thực ở các ứng dụng không hỗ trợ Kerberos pre-authentication.

Khi thuộc tính này được bật, bất kỳ ai cũng có thể gửi AS-REQ của người dùng trên và nhận được phản hồi AS-REP với phần mã hóa có thể bị bẻ khóa để đánh cắp mật khẩu.

Đồng nghĩa với việc không cần domain account để thực hiện tấn công, chỉ cần kết nối được đến DC. Tuy nhiên vẫn phải fuzzing được username của account.

Phần tiếp theo sẽ đi vào tấn công AS-REP Roasting trong môi trường lab. Mô hình lab tương tự như ở bài viết https://sec.vnpt.vn/2022/10/build-a-basic-active-directory-lab-for-penetration-testing/

Trước tiên ở máy DC target, chọn user bất kỳ và tick chọn option “Do not require Kerberos preauthentication”.

Ở bước khai thác, đặt tình huống chỉ có thông tin ip target. Đầu tiên cứ quét nmap để xem nó có gì.

Có thể thấy kerberos của Domain Controller đang listen ở port 88. Có nghĩa là có thể sử dụng kerbrute để check các username trong domain. Tuy nhiên vẫn cần thêm các thông tin của domain và một wordlist gồm các account tiềm năng.

Ở kết quả trong ảnh trên cũng cho thấy hệ thống đang chạy SMB và tất nhiên là chúng ta sẽ muốn thử dành ra một chút thời gian thực hiện SMB Enumeration thông qua một vài công cụ phổ biến có thể kể đến SMBMap, enum4linux, crackmapexec,…

Ở đây lấy được domain name chính xác. Trỏ host từ ip DC đến domain này để dễ dàng thao tác về sau.

Ping thử đến domain:

Tiếp theo là bước chuẩn bị wordlist user, đặt tình huống đang khai khác hệ thống trong khu vực Việt Nam nên username rất có thể đặt dựa theo tên riêng Việt Nam, từ đó có thể tạo wordlist user theo cơ sở này.

Đầu tiên tìm các word list tên riêng trên github, pastebin, …

Tiếp theo viết 1 script xóa các dấu câu, viết liền, hoán đổi vị trí, thêm thắt để được một wordlist như sau (phần này mình làm đơn giản, có thể thêm các option nữa như viết hoa chữ cái đầu, họ hoặc tên đệm chỉ để một chữ cái,……)

Cuối cùng có được list account như hình dưới:

Sử dụng Kerbrute để tìm các username thực có thể đăng nhập:

Kết quả show ra được các user hợp lệ và có tồn tại trong domain như ảnh trên. Noice!

Exploiting ASRepRoasteable users

Đối với ASRepRoasting, hiệu quả nhất có thể sử dụng script impacket-GetNPUsers trong impacket-collection, một bộ công cụ “must-have” khi pentest Active Directory.

Vì chưa có thông tin xác thực nào nên chúng ta cần chọn option 4 với usersfile là file chứa các username vừa tìm được ở trên:

Tìm được AS_REP hash của user tung.nguyen

Hai user còn lại không thể khai thác do không set thuộc tính DONT_REQ_PREAUTH .

Để rõ hơn cuộc tấn công thì cùng xem lại các gói tin trong whire shark được cài đặt trên DC.

Chú ý đến các gói tin AS-REQ và AS-REP:

Gói tin AS-REQ gửi đến authentication server(đặt trong DC luôn) yêu cầu ticket cho user tung.nguyen:

Do đã set DONT_REQUIRE_PREAUTH nên gói tin AS-REP sẽ được trả về từ server và bao gồm encrypted password hash trong trường “Encrypted part” của gói tin:

Sau khi đã có được user key hay chính xác là encrypted password hash. Có thể mang đi giải mã bằng các công cụ crack như JTR, hashcat,…

Phần ASRepRoasting attack đã hoàn thành từ bước này. Một số ví dụ về những gì có thể làm với các thông tin xác thực này:

Sử dụng LDAP để dump thêm các thông tin trong domain
Dùng Bloodhound để mô phỏng các đường dẫn đến Domain Admins
Dùng impacket để khởi tạo pseudo-shells
Check xem thông tin xác thực này có thể sử dụng ở các service khác không (SSH, website authentication, FTP, SMB)
vân vân, mây mây

Ví dụ trong trường hợp này LDAP đang chạy ở port 389 và có thông tin xác thực hợp lệ nên có thể sử dụng LDAPDomainDump để truy xuất các thông tin trong domain:

KẾT

Có rất nhiều cách thú vị hơn để tiếp tục khai thác nhưng đây được coi là 1 khởi đầu tốt. Các phần tiếp theo sẽ đi vào khai thác sâu hơn hoặc sử dụng các phương thức còn lại để khai thác Kerberos .

3.696 lượt xem