Kỹ thuật Kerberoasting diễn ra thế nào?

Mắt xích 1: Tại sao lại xuất hiện "Service Account" (Tài khoản dịch vụ)?

Trên hệ điều hành Windows, bất kỳ chương trình nào muốn vận hành cũng bắt buộc phải chạy dưới ngữ cảnh của một tài khoản nhất định (nhằm giúp hệ điều hành phân quyền đọc/ghi dữ liệu, tài nguyên).

• Với ứng dụng người dùng (Word, Chrome...): Chạy bằng chính tài khoản của người dùng đang đăng nhập và thao tác trực tiếp trên máy.
• Với các dịch vụ chạy ngầm 24/7 trên máy chủ (SQL Server, Web Server, dịch vụ Backup...): Vốn phải tự động hoạt động liên tục ngay cả khi không có bất kỳ ai đăng nhập vào máy chủ.
  • Mặc định, Windows cung cấp sẵn các tài khoản cục bộ như NT AUTHORITY\LOCAL SERVICE. Tuy nhiên, tài khoản nội bộ này chỉ có giá trị trên chính chiếc máy đó, hoàn toàn bất lực khi cần tương tác, lấy dữ liệu hay xác thực qua mạng với các máy chủ khác trong doanh nghiệp.
  • Giải pháp của Admin: Quản trị viên tạo một tài khoản người dùng bình thường trong Active Directory (ví dụ: svc_sql), đặt mật khẩu cho nó, sau đó cấu hình dịch vụ SQL Server chạy dưới danh nghĩa tài khoản này. Tài khoản domain được chỉ định dùng riêng để vận hành ứng dụng/dịch vụ như vậy gọi là Service Account (Tài khoản dịch vụ).

Mắt xích 2: Tại sao phải gắn "SPN" (Service Principal Name) vào tài khoản đó?

Khi dịch vụ SQL Server trên máy chủ SRV01 đã chạy dưới danh nghĩa tài khoản svc_sql, cơ chế xác thực Kerberos trong mạng nội bộ sẽ đối mặt với một vấn đề:

1. Khi một nhân viên trong công ty muốn kết nối tới cơ sở dữ liệu trên máy chủ SRV01, máy của nhân viên đó chỉ biết địa chỉ logic: "Tôi muốn kết nối tới dịch vụ MSSQL trên máy chủ SRV01".
2. Máy nhân viên gửi yêu cầu lên máy chủ quản lý trung tâm (Domain Controller - DC): "Cấp cho tôi vé dịch vụ (TGS ticket) để làm việc với MSSQL/SRV01".
3. Theo nguyên lý bảo mật của Kerberos, DC bắt buộc phải dùng mật khẩu (dạng NTLM hash) của tài khoản đang vận hành dịch vụ đó (svc_sql) để mã hóa chiếc vé, sau đó gửi trả vé cho nhân viên. Khi nhân viên cầm vé này nộp cho máy chủ SRV01, dịch vụ trên SRV01 mới dùng chính mật khẩu của mình để giải mã vé và xác nhận danh tính.
4. Vấn đề phát sinh: Việc cài đặt cho SQL Server chạy dưới danh nghĩa svc_sql chỉ diễn ra cục bộ trên máy chủ SRV01. Trong khi đó, Domain Controller (DC) là một máy chủ quản lý danh bạ độc lập — DC hoàn toàn không tự động biết được dịch vụ MSSQL trên máy SRV01 đang do tài khoản nào đứng tên vận hành để lấy đúng mật khẩu ra mã hóa vé.
5. Giải pháp: Quản trị viên phải đăng ký một chuỗi định danh duy nhất vào Active Directory gọi là SPN (Service Principal Name) gắn trực tiếp vào tài khoản svc_sql:

   SPN: MSSQL/SRV01 $\longrightarrow$ liên kết với tài khoản svc_sql Nhờ có SPN, mỗi khi có ai hỏi xin vé vào MSSQL/SRV01, DC chỉ cần tra cứu danh bạ, thấy trỏ về svc_sql là lấy ngay NTLM hash của svc_sql ra để khóa vé lại.

Mắt xích 3: Tại sao cơ chế trên lại tạo ra lỗ hổng Kerberoasting?

Bản chất Kerberoasting là kỹ thuật khai thác sự kết hợp của 2 cơ chế mặc định trong kiến trúc Kerberos:

1. DC không xác thực quyền truy cập dịch vụ khi cấp vé: Khi một Domain User bất kỳ gửi yêu cầu xin vé truy cập MSSQL/SRV01, DC không kiểm tra xem người dùng này có được phép dùng SQL Server hay không (quyền truy cập do chính máy chủ dịch vụ tự kiểm tra sau khi nhận vé). Nhiệm vụ của DC chỉ đơn thuần là: "Bạn là một tài khoản hợp lệ trong Domain? Bạn muốn vé vào MSSQL/SRV01? Tôi sẽ lấy NTLM hash của svc_sql mã hóa vé (TGS-REP) và giao cho bạn."
2. Danh bạ SPN là thông tin công khai: Bất kỳ tài khoản người dùng nào trong Domain cũng có quyền truy vấn DC để lấy danh sách toàn bộ các tài khoản có gắn SPN, sau đó tự do gửi yêu cầu xin cấp vé dịch vụ cho tất cả các SPN đó.

Kỹ thuật Kerberoasting diễn ra thế nào?

Kẻ tấn công chỉ cần chiếm được quyền kiểm soát của một tài khoản Domain User thấp nhất:

• Bước 1: Gửi truy vấn tới DC để liệt kê toàn bộ tài khoản có gắn SPN trong mạng.
• Bước 2: Yêu cầu DC cấp vé (TGS-REP) cho các tài khoản dịch vụ mục tiêu.
• Bước 3: Nhận vé về máy cá nhân nhưng không dùng để kết nối dịch vụ, mà trích xuất vé ra để tấn công dò mật khẩu ngoại tuyến (offline brute-force) bằng các công cụ chuyên dụng như Hashcat hoặc John the Ripper. Vì quá trình dò mật khẩu diễn ra hoàn toàn trên máy của kẻ tấn công nên không lo bị khóa tài khoản (lockout) hay kích hoạt cảnh báo đăng nhập thất bại trên hệ thống.

Mắt xích 4: Tại sao mật khẩu của Service Account lại mang rủi ro chí mạng?

Sau khi bẻ khóa thành công chiếc vé và thu được mật khẩu dạng rõ của svc_sql, kẻ tấn công thường nắm giữ lợi thế rất lớn do 2 thói quen quản trị phổ biến trong thực tế:

1. Mật khẩu Service Account thường rất yếu: Do việc thay đổi mật khẩu tài khoản dịch vụ đòi hỏi phải cập nhật lại cấu hình ở nhiều ứng dụng và tiềm ẩn nguy cơ gián đoạn hoạt động hệ thống, quản trị viên thường ngại đổi định kỳ. Mật khẩu thường được đặt một lần, dùng qua nhiều năm, đặt mật khẩu đơn giản, dùng chung cho nhiều dịch vụ hoặc thậm chí đặt trùng với username. Điều này khiến các công cụ bẻ khóa mật khẩu offline đạt tỷ lệ thành công rất cao.
2. Service Account thường bị cấp dư thừa đặc quyền: Nhằm tránh các lỗi phát sinh do thiếu quyền khi ứng dụng tương tác giữa các máy chủ, quản trị viên thường có thói quen thêm tài khoản dịch vụ vào nhóm Local Administrators trên nhiều máy, hoặc thậm chí cho thẳng vào nhóm Domain Admins (trực tiếp hoặc thông qua cơ chế lồng nhóm - nested group).
   • Nếu tài khoản thuộc nhóm Domain Admins / Local Admin: Kẻ tấn công ngay lập tức chiếm quyền kiểm soát toàn bộ máy chủ dịch vụ hoặc toàn bộ Domain.
   • Nếu tài khoản chỉ có quyền hạn thông thường: Kẻ tấn công vẫn có thể tự rèn vé dịch vụ (craft service ticket) để mạo danh quyền quản trị cao nhất (sysadmin) đối với chính dịch vụ đó. Ví dụ với MSSQL/SRV01, kẻ tấn công kết nối vào dịch vụ SQL dưới quyền sysadmin, kích hoạt thủ tục mở rộng xp_cmdshell và thực thi mã tùy ý (RCE) để chiếm quyền điều khiển máy chủ SRV01.

Tóm tắt cốt lõi cần nhớ:

• SPN là gì? Cầu nối chỉ định: Dịch vụ X do Tài khoản dịch vụ (Service Account) nào vận hành.
• DC mã hóa vé TGS bằng gì? Bằng chính NTLM hash (mật khẩu) của tài khoản dịch vụ đó.
• Bản chất Kerberoasting: Bất kỳ Domain User nào cũng xin được vé TGS $\longrightarrow$ Đem vé về máy riêng bẻ khóa offline $\longrightarrow$ Chiếm mật khẩu tài khoản dịch vụ có đặc quyền cao.