Kerberoasting, khai thác các hệ thống chưa vá – một ngày trong cuộc đời của một Red Teamer
Phạm vi
Gần đây, chúng tôi đã tiến hành đánh giá nhóm "Red Team" cho một khách hàng là doanh nghiệp lớn nơi có các trường hợp được phép sử dụng máy tính xách tay cứng của khách hàng hoặc thử kết nối máy tính xách tay của chúng tôi với mạng (mặc dù họ đã có hệ thống Kiểm soát Truy cập Mạng tại chỗ). Bài đăng trên blog này liệt kê các nỗ lực của chúng tôi để vượt qua các điều khiển bảo mật, nâng cao đặc quyền và di chuyển qua mạng của chúng tôi, đồng thời đảm bảo rằng SOC không nhận các hoạt động của chúng tôi. Với mục đích của blog này, tôi sẽ sử dụng tên ảo cho ngân hàng là SPB-Groups. Cùng Bizfly Cloud khám phá thông tin qua bài viết này nhé!
Ngày 1: Nâng cấp sơ bộ
Chúng tôi đã được cung cấp một hệ thống với Windows 7x64 và một người dùng có tên là SPB-RANDOM-USER. Người dùng không phải là quản trị viên và có các đặc quyền vô cùng hạn chế trên mạng. PowerShell đã bị chặn trên tất cả các điểm cuối. Họ đã có Symantec AV và Windows Security Essentials (MSE) trên hệ thống nhất định được cập nhật đầy đủ cho đến nay. Ngoài ra, các đại lý Cisco NAC cũng đã được triển khai để ngăn chặn truy cập trái phép từ laptop bên ngoài vào mạng của khách hàng. Tất cả các cổng USB đã bị tắt, Wi-Fi đã được bật nhưng không có quyền truy cập Internet.
Vì vậy, điều đầu tiên chúng tôi bắt đầu làm là tìm ra nếu có bất kỳ cấu hình sai nào trong hệ thống đã cho, qua đó chúng tôi có thể chuyển đặc quyền của chúng tôi cho quản trị viên cục bộ. Chúng tôi không thể tìm thấy gì vì hầu hết mọi thứ đã bị chính sách nhóm chặn lại. Chúng tôi quyết định chia toàn bộ nhiệm vụ thành hai phần. Đồng nghiệp của tôi bắt đầu phân tích các cách khác nhau để bỏ qua các cơ chế bảo mật trên laptop trong khi tôi bắt đầu tìm cách truy cập vào mạng thông qua laptop cá nhân của mình.
Khi tìm kiếm các bản vá lỗi sử dụng lệnh dưới đây:
wmic qfe list full /format:htable > Updates.html
Chúng tôi nhận thấy rằng máy khách dễ bị tổn hại đến Meltdown (CVE-2017-5715) và Windows COM Privilege Escalation (CVE-2017-0213). Tôi nhanh chóng bắt đầu tìm kiếm một POC cho một trong những khai thác trực tuyến. Để nắm giữ một Meltdown kể từ khi nó vừa được phát hành và chỉ có một POC quyết định liệu hệ thống có dễ bị tổn thương hay không là vô cùng khó. Sử dụng POC để viết một khai thác Meltdown tùy chỉnh là điều cuối cùng chúng tôi quyết định rằng chúng tôi sẽ làm khi mọi thứ khác thất bại; vì nó sẽ khá tốn thời gian. Tuy nhiên, tôi tìm thấy một nhị phân làm việc cho CVE-2017-0213 mà tôi đã tải lên ở đây https://github.com/paranoidninja/Pandoras-Box/tree/master/windows_exploits. Mã nguồn ban đầu của khai thác có thể được tìm thấy ở đây https://github.com/WindowsExploits/Exploits/tree/master/CVE-2017-0213. Bây giờ chúng tôi đã có một khai thác mà có thể làm việc, nhưng có một nguy cơ là AV phát hiện nó và cảnh báo cho SOC mà chúng tôi rõ ràng muốn tránh điều đó. Trước khi thử nghiệm khai thác, chúng tôi quyết định ngắt kết nối máy khỏi mạng của họ và kết nối với điểm phát sóng cá nhân của chúng tôi để tải lên các tệp nhị phân của khai thác qua HTTP. Vì vậy, tôi đã sửa đổi các khai thác để tránh phát hiện AV nhưng MSE khá mạnh để dò ra vấn đề và không biết mất bao lâu để chúng tôi có thể khắc phục.
Hiện tại chúng tôi đang bị mắc kẹt với một chiếc laptop mà chúng tôi không thể khai thác và không thể kết nối nó với mạng vì nó sẽ gửi cảnh báo về phát hiện AV. Vì vậy, trong khi đồng nghiệp của tôi đang cố gắng tìm cách vượt qua hàng rào cảnh báo AV, tôi đã cố gắng xem liệu tôi có thể bỏ qua bảo mật NAC và truy cập vào mạng trên laptop cá nhân của tôi hay không. Chúng tôi đã có một Cisco IP Phone trong phòng, nơi chúng tôi ngồi và sau đó tôi làm mọi thứ cần làm để xem liệu tôi có thể truy cập vào mạng LAN thông qua đó hay không. Tôi thấy rằng Xác thực đã được cho phép mà không cần bất kỳ password nào. Vì vậy, tôi vô hiệu hóa xác thực, thay đổi chế độ thành Non-Secure và tìm thấy địa chỉ MAC của IP Phone. Sau đó tôi giả mạo địa chỉ MAC trên laptop cá nhân của Windows theo cách như dưới đây.
Device Manager-> Network Adapters -> Ethernet Adapter -> Advanced -> Network Address -> Value
Bây giờ trước khi kết nối máy tính của tôi với mạng, tôi đã quyết định thay đổi tên máy chủ của mình thành một cái gì đó khớp với giản đồ máy chủ của công ty để tôi có thể ẩn máy tính xách tay của mình ở chế độ đơn giản trong nhật ký proxy / tường lửa, giống như SPB-ComputerName. Sau đó tôi kết nối cáp mạng LAN và "boom"! Tôi nhận được một địa chỉ IP và tôi đã được kết nối với mạng của họ.
Bước tiếp theo là tìm ra vị trí của AD / DC, DNS Servers. Quan trọng hơn việc tìm kiếm DC Forest là tìm ra các máy chủ key business có chứa các ứng dụng kinh doanh chính.
Ngày 2: Rogue Scanning
Khởi đầu ngày làm việc của ngày 2 thật đáng thất vọng. Chúng tôi trở lại vị trí của khách hàng chỉ để tìm ra hệ thống chính đã được giao cho chúng tôi đã kết nối trở lại với mạng WiFi của văn phòng. Điều này có nghĩa rằng AV đã đẩy tất cả các cảnh báo đã được nêu ra trong quá trình thử nghiệm khai thác trong một ngày trở lại. Một vấn đề khác là khi chúng tôi mở laptop, chúng tôi thấy rằng các bản vá lỗi mới đã được cài đặt và hệ thống được khởi động lại tự động. Meltdown có thể được vá ngay bây giờ.
Chúng tôi nghĩ đến việc chỉ cần giữ hệ thống sang một bên và nhắm mục tiêu mạng từ máy tính cá nhân của tôi. Thay vì sử dụng Nmap hoặc một số công cụ khác để quét, chúng tôi quyết định trực tiếp kiểm tra bộ nhớ cache ARP và netstat của hệ thống cục bộ. Chúng tôi tìm thấy một hệ thống với quy ước đặt tên SPB-DC08 và SPB-RDS30. Nhìn vào quy ước đặt tên đó, chúng tôi đã có thể xác định rằng quy tắc đầu tiên là DC và thứ hai là Remote Desktop Server. Máy chủ RDS30 này trở thành máy chủ nhảy được sử dụng để kết nối với các phân đoạn máy chủ khác nhau. Sau đó, chúng tôi đã sử dụng mô-đun PowerShell có tên Get-ADComputer trên máy tính xách tay cá nhân của mình để truy vấn AD để có danh sách máy tính từ chính AD. Thực hiện được bước này sẽ đảm bảo rằng chỉ có các hệ thống hợp pháp được truy vấn và nó sẽ giữ cho chúng ta tránh quét bất kỳ mồi nhử nào (nếu có).
Trong khi truy vấn đang chạy, chúng tôi đã nghĩ đến việc cố gắng kết nối qua RDP với máy chủ RDS30 với người dùng mặc định mà chúng tôi đã cung cấp. Chúng tôi đã kết nối thành công với máy. Nó là một máy chủ Windows 2008 không có cài đặt AV. Tuy nhiên, PowerShell vẫn bị chặn. Nếu chúng tôi muốn tiếp tục thì phải lấy PowerShell và chạy trên máy. Đa phần Windows AppLocker và Group Policy chặn PowerShell thông qua băm tệp. Điều này có nghĩa là nếu tôi có thể sử dụng một nhị phân tùy chỉnh để gọi PowerShell DLL qua winAPI, nó chắc chắn sẽ hoạt động. Do đó, chúng tôi đã sử dụng tệp tin PowerShDLL DLL để gọi PowerShell DLL qua CMD thay vì trực tiếp gọi exe của PowerShell qua rundll32. Với điều này, chúng tôi có thể dễ dàng bỏ qua các chính sách bảo mật / khóa của Windows Group Policy App và nhận được một Bảng điều khiển PowerShell.
Một lần, chúng tôi đã có quyền truy cập PowerShell trong chính miền, chúng tôi bắt đầu liệt kê User SPN để thực hiện Kerberoasting. Chúng tôi đã sử dụng kịch bản lệnh GetUserSPN.ps1 của PowerShell để lấy danh sách tất cả các SPN của người dùng.
Ngoài ra, chúng tôi nghĩ đến rằng nếu hệ thống trước đó của chúng tôi dễ bị tổn hại đến CVE-2017-0213 thì các bản vá cần được triển khai trên tất cả các hệ thống thông qua SCCM. Và vì không có cài đặt AV, chúng tôi sẽ có thể tăng đặc quyền của mình. Chúng tôi đã chuyển nhị phân CVE từ hệ thống của mình qua RDP sang đích từ xa, thực thi nó và "boom"!
Tôi đã thêm một người dùng mới làm quản trị viên cục bộ bền bỉ mà tôi có thể kết nối qua Psexec.exe trong trường hợp người dùng hiện tại của tôi bị chặn vì nó đã kích hoạt AV trước đó. Sự bền bỉ kiên trì là một điều khá quan trọng khi bạn thực hiện đánh giá red team.
Bây giờ bước tiếp theo tốt nhất là kết xuất thông tin đăng nhập của hệ thống. Tôi đã sử dụng Procdump.exe như dưới đây. Mục đích là sử dụng lượng tệp nhị phân độc hại ít nhất có thể. Kể từ khi Procdump được chính thức ký bởi Microsoft, có ít khả năng nó bị coi là độc hại.
Khi kết xuất được tạo, chúng tôi sao chép nó trở lại hệ thống của chúng tôi và sử dụng Mimikatz để kết xuất các tín dụng cục bộ.
P.S: Tên người dùng, tên miền, rootkeys, mật khẩu, ID xác thực mà bạn có thể thấy bên dưới tất cả đã được sửa đổi thành những tên ảo. Đây không phải là hình ảnh thực mà chỉ được thực hiện để trông thật để làm cho nó có liên quan đến blog này.
Bây giờ chúng tôi đã có quyền truy cập vào khoảng 8-9 thông tin đăng nhập, hầu hết trong số họ là người dùng bình thường, tuy nhiên chúng tôi vẫn còn cách khá xa để có được quản trị viên miền hoặc quản trị viên ứng dụng. Nhưng đây là một khởi đầu tốt. Bây giờ đến lúc chúng tôi quyết định bắt đầu di chuyển về phía bên. Chúng tôi bắt đầu liệt kê các hệ thống khác bằng cách đoán và truy vấn tên DC mà chúng tôi đã thu thập trước đó. Vì vậy, nếu một tên hệ thống là RDS30, sau đó phải có các thông số tương ứng khác như rds01, rds02, rds03,.... Vì vậy, tôi đã viết một kịch bản đơn giản để thực hiện nslookup trên DC trong một vòng lặp trên tất cả các máy này để xem những máy nào tồn tại để tôi có thể sử dụng các thông tin đăng nhập để di chuyển về phía bên trong toàn tổ chức.
Ngoài ra, chúng tôi đã tìm thấy rất nhiều người dùng đăng nhập với tên miền / máy tính với tên SPB-ERP, SPB-IT-HR, SPB-CC-DBADMIN ngoài 8-9 người dùng bị xâm phạm ở trên. Đây là khi chúng tôi nhận ra rằng đây không phải là người dùng thực. Đây là những người sử dụng mồi nhử và nếu chúng tôi sử dụng nó, nó sẽ ngay lập tức đưa ra một cảnh báo. Vì vậy, chúng tôi quyết định chỉ sử dụng những người dùng trong miền hiện tại, mang tính hợp pháp bởi quy ước đặt tên hoặc đã đăng nhập chỉ 2-3 ngày và bằng cách xem thông tin đăng nhập cuối cùng trong Mimikatz.
Ngày 3: Chuyển động về phía bên
Vì vậy, một điều chúng tôi quyết định là chúng tôi sẽ không sử dụng cùng một creds để đăng nhập vào các máy khác nhau. Vì vậy, chúng tôi bắt đầu đăng nhập với các creds khác nhau mỗi khi chúng tôi RDP chuyển sang các hệ thống khác. Ví dụ: - Nếu chúng ta có người dùng như SPB-user1, SPB-user2, SPB-user3 và các máy như SPB-system1, SPB-system2, SPB-system3; chúng tôi đã di chuyển như thế này:
Đăng nhập vào SPB-system1 với SPB-user1 thông qua RDP
Đăng nhập vào SPB-system2 từ SPB-system1 qua SPB-user2 qua RDP
Đăng nhập vào SPB-system3 từ SPB-system2 từ SPB-system1 qua SPB-user3 qua RDP và cứ thế
Về cơ bản, chúng tôi có 10 hệ thống sâu, có hệ thống chậm và kết nối mạng chậm nhưng nó giữ mọi thứ yên tĩnh và nằm ở phía bên ngoài radar. Mỗi hệ thống chúng tôi đăng nhập, chúng tôi đã xem xét C: \ Users để xem liệu có người dùng mới nào đã đăng nhập vào hệ thống gần đây hay không (Thay đổi ngày và giờ của thư mục bằng tên người dùng). Chúng tôi chỉ khai thác hệ thống để trích xuất creds, nếu có bất kỳ người dùng tốt nào ở đó như DC-Admin, Support-Admin hoặc SAP Admin. Theo cách này, chúng tôi đã đạt được khoảng 60 hệ thống RDS thu thập gần 90-100 người dùng đã đăng nhập vào hệ thống.
Cuối cùng, chúng tôi đã tìm thấy người dùng RDS và người dùng này có quyền truy cập vào hầu hết hệ thống RDS với đặc quyền cao hơn một chút so với người dùng thông thường mà chúng tôi đang sử dụng. Chúng tôi cũng tìm thấy một bảng excel trong một ổ đĩa C: \ của RDS Desktop với tên "Thông tin người dùng". Khi tôi mở nó lên nó chứa tên người dùng và mật khẩu của tất cả các quản trị viên cục bộ của các hệ thống RDS. Lần này quả thực tôi đã trúng mánh rồi! Vì vậy, gần như tất cả các máy chủ RDS được tạo ra ở thời điểm này.
Kể từ khi chúng tôi có quyền truy cập vào hầu hết các máy chủ RDS, chúng tôi có 2 tùy chọn. Một trong những cái chính là để đợi một số admin đăng nhập vào RDS, kiểm tra tất cả các thư mục người dùng và sau đó một lần nữa kết xuất mật khẩu. Hoặc chúng ta có thể chạy Bloodhound để tìm phiên hoạt động của người dùng cho các máy tính khác nhau. Cuối cùng, thay vì làm chúng 1 cách thủ công, chúng tôi quyết định sử dụng BloodHound. Chúng tôi đã tải xuống mã nhị phân net đã được biên dịch của BloodHound và chạy nó trên một trong các máy chủ RDS SPB-RDS46. Và thật lạ kỳ. BloodHound đã cung cấp cho chúng tôi một danh sách các phiên hoạt động của người dùng và hệ thống họ đang đăng nhập ở hiện tại.
P.S: Hình ảnh chỉ mang tính tượng trưng
Sau khi kiểm tra các chi tiết trong bloodhound, chúng tôi thấy rằng một trong những quản trị viên VMWare đã đăng nhập vào RDS53. Chúng tôi nhanh chóng nhảy vào máy chủ đó nhằm tìm ra rằng tất cả các bản cập nhật đã được cài đặt trên hệ thống và nó yêu cầu nhắc nhở để khởi động lại hệ thống để áp dụng các bản cập nhật. Chúng tôi đã trì hoãn nó trong 10 phút và thấy thư mục C: \ Users mà một quản trị viên SCCM đã đăng nhập gần đây vào hệ thống chỉ mới 30 phút trước. Chúng tôi đã nhanh chóng thực hiện cùng một khai thác CVE-2017-0213, chạy Procdump và kết xuất creds cục bộ. Và cuối cùng, chúng tôi đã tìm thấy quản trị viên VMWare cũng như quản trị viên SCCM. Có vẻ như các bản cập nhật không được áp dụng cho đến khi hệ thống được khởi động lại và quản trị viên SCCM đã đăng nhập để chạy Microsoft Baseline Security Analyzer cho các bản vá vẫn đang chạy trong chương trình phụ trợ. Chúng tôi đã có tên máy chủ VMWARE với kịch bản lệnh Get-ADComputer PowerShell mà chúng tôi đã chạy trước đó. Chúng tôi đã cho RDP vào Hệ thống với người dùng quản trị VMWare và tìm thấy một weblogin cho VMWare Management Server. Chúng tôi đã kích hoạt cổng thông tin và cố gắng sử dụng cùng một số creds mà chúng tôi đã tìm thấy trước đây và hiện tại chúng tôi là Quản trị viên VMWare và đã có quyền kiểm soát tất cả các hệ thống ảo trong Trung tâm dữ liệu.
Cập nhật (để báo cáo rõ ràng hơn): Chúng tôi sau đó tiến hành trích xuất vé SPN bằng cách sử dụng PowerShell mà chúng tôi đã bỏ qua trước đó và cũng sử dụng Impacket cho Kerberoasting và sau đó brute forced vé để có được các thông tin. Bằng việc làm này chúng tôi đã có thể truy cập vào các hệ thống khác bằng cách sử dụng tài khoản dịch vụ và sau đó kết xuất các thông tin đăng nhập qua procdump và nhận creds cho DC-Admin và cũng là mã băm KTBTGT. Vấn đề là trong 2 ngày qua tôi phải chuyển sang một dự án khác và đồng nghiệp của tôi đã thực hiện các bước này để lấy DC. Vì vậy, tôi chỉ giải thích phần của mình trên blogpost.
Chúng tôi gần như đã cho phép tất cả người dùng được kết nối với máy chủ như SCCM admins, Few HR và các cá nhân trong lĩnh vực IT, người dùng RDS và tất cả người dùng máy chủ VMWare. Buồn cười ở chỗ là những sai lầm đơn giản hay sự biến mất ngay cả một bản vá đơn giản cũng có thể dẫn đến sự hủy hoại cả một hệ thống. Chỉ khi NAC được triển khai đúng cách, tất cả điều này có thể là không thể vì hệ thống khác do khách hàng cung cấp thực sự vô giá trị với tất cả các bảo mật mà họ đã áp dụng.
Gợi ý
1. NAC là điểm chính của compromise ở đây. Nếu NAC không được cài đặt, thậm chí không nên gán địa chỉ IP cho máy tính xách tay cá nhân của tôi. Ngoài ra, người dùng mới đã được tạo và đưa lại cho chúng tôi hoạt động có quyền truy cập cấp thấp đối với một số Máy chủ Jump. Về cơ bản, điều này có nghĩa là có một AD không phù hợp được thực hiện theo đó một số nhân viên mới sẽ được gán mặc định cho một nhóm có quyền truy cập vào máy chủ. Các phân đoạn người dùng và máy chủ phải được tách biệt hoàn toàn và không được phép kết nối với RDP hoặc kết nối với bất kỳ máy chủ nào trừ khi có nhu cầu kinh doanh tuyệt đối.
2. Một vấn đề khác là không có sự bảo vệ điểm cuối vượt quá tác nhân chống virus được triển khai. Một công cụ UEBA hoặc một công cụ EDR hoặc thậm chí chỉ đơn giản là Sysmon với một số công cụ phân tích mã nguồn mở để phân tích những gì đang xảy ra trong chương trình phụ trợ sẽ có thể giúp nhận dạng mọi hoạt động.
3. Và phần chính là không có wdigest nào được phép bật lên trên các máy chủ mà chúng tôi đã kết xuất các thông tin đăng nhập. Nếu có, thì chúng tôi sẽ chỉ tìm thấy mã băm của mật khẩu chứ không phải thông tin đăng nhập rõ ràng trong bãi chứa. Ngoài ra, khi chúng tôi thu thập thông tin DC qua Kerberoasting, chúng tôi đã phải xóa thông tin đăng nhập từ tickets mà chúng tôi đã chụp. Và các passwords mà các nhân viên sử dụng sẽ có thể dễ dàng bị crack bằng cách sử dụng wordlist. Vì vậy, sử dụng các password phức tạp cho các tài khoản dịch vụ vẫn là một điều khiển bảo mật rất quan trọng.
4. Ngoài ra, chú ý theo dõi các cuộc tấn công Kerberoasting hiện là gợi ý hữu hiệu nhất cho đến hiện tại.
link gốc :http://niiconsulting.com/checkmate/2018/05/kerberoasting-exploiting-unpatched-systems-a-day-in-the-life-of-a-red-teamer/
Theo Bizfly Cloud chia sẻ
>> Có thể bạn quan tâm: Patch (Bản vá) - Những điều bạn phải biết
