本文是根據 Group-IB 專家幾年前進行的一次非常成功的滲透測試編寫的：發生了一個可以改編為寶萊塢電影的故事。 現在，讀者的反應可能是：“哦，另一篇公關文章，又在描述這些，它們有多好，別忘了買一個滲透測試。” 嗯，一方面，確實如此。 然而，這篇文章的出現還有很多其他原因。 我想展示滲透測試人員到底在做什麼，這項工作有多麼有趣和重要，專案中可能會出現什麼有趣的情況，最重要的是，用真實的例子展示現場材料。
為了恢復世界謙虛的平衡，一段時間後我們將寫一篇進展不順利的滲透測試。 我們將展示公司中設計良好的流程如何能夠防範各種攻擊，甚至是準備充分的攻擊，僅僅因為這些流程存在並且實際有效。
對於本文中的客戶來說，一切總體上非常好，根據我們的感覺，至少比俄羅斯聯邦 95% 的市場要好，但有一些小細微差別，形成了一長串事件，首先導致了一份很長的工作報告，然後是這篇文章。
那麼，讓我們儲備爆米花，歡迎來到偵探故事。 單字 - 帕維爾·蘇普魯紐克現任IB集團「審計與諮詢」部技術經理。
第 1 部分. 波奇金醫生
2018年有一個客戶——一家高科技IT公司，它本身為許多客戶提供服務。 想要得到以下問題的答案：是否可以在沒有任何初始知識和存取權限的情況下透過 Internet 取得 Active Directory 網域管理員權限？ 我對任何社會工程學都不感興趣（），他們無意故意幹擾工作，但他們可能會意外 - 例如，重新加載工作異常的伺服器。 另一個目標是識別盡可能多的針對外周的其他攻擊媒介。 該公司定期進行此類測試，現在新測試的截止日期已經到來。 這些條件幾乎是典型的、充分的、可以理解的。 讓我們開始吧。
有一個客戶的名稱 - 讓它成為“公司”，以及主要網站 。 當然，客戶的稱呼有所不同，但在本文中，一切都將是客觀的。
我進行網路偵察 - 找出客戶註冊的位址和網域，繪製網路圖，以及如何將服務分發到這些位址。 我得到的結果是：超過 4000 個即時 IP 位址。 我查看了這些網路中的網域：幸運的是，絕大多數都是針對客戶的客戶的網絡，我們對它們並不正式感興趣。 客戶也這麼認為。
仍然有一個具有 256 個位址的網絡，此時已經了解了按 IP 位址劃分的網域和子網域的分佈，有有關掃描連接埠的信息，這意味著您可以查看感興趣的服務。 同時，各種掃描器都會在可用的 IP 位址上並分別在網站上啟動。
有很多服務。 通常，這對滲透者來說是一種喜悅，也是對快速勝利的期待，因為服務越多，攻擊範圍就越大，找到神器就越容易。 快速瀏覽一下這些網站，大多數都是全球大公司的知名產品的網頁介面，從表面上看，它們不受歡迎。 他們要求輸入使用者名稱和密碼，搖出用於輸入第二個因素的字段，要求 TLS 用戶端證書，或將其發送到 Microsoft ADFS。 有些根本無法透過網路存取。 對於某些人來說，您顯然需要擁有一個支付三份薪水的特殊付費客戶，或者知道要輸入的確切 URL。 讓我們跳過另一個逐漸沮喪的一周，在嘗試「突破」已知漏洞的軟體版本、搜尋網路路徑中的隱藏內容和來自 LinkedIn 等第三方服務的洩露帳戶、嘗試使用它們猜測密碼的過程中。就像挖掘自寫網站的漏洞一樣——順便說一句，根據統計，這是當今最有希望的外部攻擊媒介。 我會立即記下隨後開火的電影槍。
因此，我們找到了兩個從數百個服務中脫穎而出的網站。 這些網站有一個共同點：如果您不按網域進行細緻的網路偵察，而是正面尋找開放連接埠或使用已知 IP 範圍定位漏洞掃描器，那麼這些網站將逃脫掃描，並且根本不會被掃描。無需知道DNS 名稱即可可見。 也許它們至少在早些時候被錯過了，而且我們的自動工具沒有發現它們有任何問題，即使它們直接發送到資源。
順便說一句，關於以前推出的掃描器的一般發現。 讓我提醒您：對於某些人來說，「滲透測試」相當於「自動掃描」。 但這個專案的掃描器什麼也沒說。 嗯，最大程度是中等漏洞（嚴重程度為 3 中的 5）：某些服務上存在錯誤的 TLS 憑證或過時的加密演算法，以及大多數網站上的點擊劫持。 但這不會幫助您實現目標。 也許掃描器在這裡會更有用，但讓我提醒您：客戶自己可以購買此類程式並用它們進行測試，並且從令人沮喪的結果來看，他已經檢查過。
讓我們回到“異常”站點。 第一個類似於非標準位址的本機 Wiki，但在本文中將其設為 wiki.company[.]ru。 她還立即要求輸入登入名稱和密碼，但透過瀏覽器中的 NTLM 進行。 對於用戶來說，這看起來就像一個要求輸入用戶名和密碼的禁慾視窗。 這是不好的做法。
一個小筆記。 由於多種原因，外圍網站中的 NTLM 很糟糕。 第一個原因是 Active Directory 網域外洩。 在我們的例子中，它也被證明是company.ru，就像「外部」DNS 名稱一樣。 了解這一點後，您可以仔細準備一些惡意內容，使其僅在組織的網域電腦上執行，而不是在某些沙箱中執行。 其次，驗證透過 NTLM 直接通過網域控制站（令人驚訝，對吧？），具有「內部」網路原則的所有功能，包括阻止帳戶超過密碼輸入嘗試的次數。 如果攻擊者發現登入訊息，他會嘗試輸入密碼。 如果您配置為封鎖帳戶輸入不正確的密碼，它將起作用並且帳戶將被封鎖。 第三，不可能在這種認證中增加第二個因素。 如果有讀者還知道怎麼做，請告訴我，這真的很有趣。 第四，容易受到哈希傳遞攻擊。 ADFS 的發明，除此之外，就是為了防止這一切。
Microsoft 產品有一個不好的功能：即使您沒有專門發布此類 NTLM，它至少也會預設安裝在 OWA 和 Lync 中。
順便說一下，本文作者曾經用同樣的方法，不小心在短短一小時內封鎖了一家大型銀行約1000個員工的帳戶，當時臉色有些蒼白。 銀行的IT服務也很蒼白，但一切都圓滿結束，我們甚至被稱讚是第一個發現這個問題並迅速果斷解決的。
第二個網站的地址「顯然是某種姓氏.company.ru」。 透過谷歌找到的，第10頁是這樣的。 該設計來自 XNUMX 年代初中期，一位受人尊敬的人正在主頁上查看它，如下所示：
這裡我拍了一張《狗的心》的劇照，但相信我，它有點相似，甚至顏色設計也是相似的色調。 讓網站被稱為 preobrazhensky.company.ru.
這是泌尿科醫生的個人網站。 我想知道泌尿科醫生的網站在一家高科技公司的子域上做什麼。 快速深入 Google 後發現，這位醫生是我們客戶法人實體之一的共同創辦人，甚至貢獻了約 1000 盧布的授權資本。 該網站可能是多年前創建的，並且使用客戶的伺服器資源作為託管。 該網站早已失去了相關性，但由於某種原因，它長期運作。
就漏洞而言，網站本身是安全的。 展望未來，我會說這是一組靜態資訊 - 簡單的 html 頁面，其中插入了腎臟和膀胱形式的插圖。 「破壞」這樣的網站是沒有用的。
但下面的網頁伺服器更有趣。 從HTTP Server頭來看，它有IIS 6.0，這表示它使用Windows 2003作為作業系統。 掃描器先前已發現，與同一 Web 伺服器上的其他虛擬主機不同，這個特定的泌尿科醫生網站回應 PROPFIND 命令，這意味著它正在執行 WebDAV。 順便說一句，掃描器返回的信息帶有“信息”標記（用掃描器報告的語言來說，這是最低的危險） - 通常會簡單地跳過這些事情。 結合起來，這產生了一個有趣的效果，直到對Google 進行另一次挖掘後才被揭示：與Shadow Brokers 集相關的罕見緩衝區溢出漏洞，即CVE-2017-7269，該漏洞已經有現成的漏洞利用。 換句話說，如果您使用 Windows 2003 並且 WebDAV 在 IIS 上運行，則會出現問題。 儘管 2003 年在生產環境中運行 Windows 2018 本身就是一個問題。
該漏洞最終出現在 Metasploit 中，並立即使用向受控服務發送 DNS 請求的負載進行測試 - Burp Collaborator 傳統上用於捕獲 DNS 請求。 令我驚訝的是，它第一次就成功了：收到了 DNS 剔除。 接下來，嘗試透過連接埠 80 建立反向連接（即從伺服器到攻擊者的網路連接，可以存取受害者主機上的 cmd.exe），但隨後發生了慘敗。 連結沒有成功，在第三次嘗試使用網站後，所有有趣的圖片都永遠消失了。
通常，後面會跟一封類似「顧客，醒醒，我們把所有東西都丟掉了」的信。 但我們被告知該網站與業務流程無關，並且像整個伺服器一樣毫無理由地在那裡工作，並且我們可以隨意使用此資源。
大約一天后，該網站突然開始自行運作。 在 IIS 6.0 上從 WebDAV 建立了一個工作台後，我發現預設設定是每 30 小時重新啟動 IIS 工作進程。 也就是說，當控制權退出 shellcode 時，IIS 工作進程結束，然後它重新啟動幾次，然後休眠 30 小時。
由於第一次反向連接到 tcp 失敗，我將此問題歸因於連接埠關閉。 也就是說，他假設存在某種防火牆，不允許傳出連線通過外部。 我開始運行 shellcode，搜尋許多 tcp 和 udp 端口，但沒有效果。 透過 Metasploit 的 http(s) 進行反向連線載入不起作用 - meterpreter/reverse_http(s)。 突然，與相同連接埠 80 的連接建立，但立即斷開。 我將此歸因於仍然虛構的 IPS 的行為，它不喜歡 meterpreter 流量。 鑑於與連接埠 80 的純 tcp 連接未通過，但 http 連接卻通過，我得出結論，系統中以某種方式配置了 http 代理。
我甚至嘗試透過 DNS 進行 meterpreter（謝謝 感謝您的努力，挽救了許多專案），回想起最初的成功，但它甚至在展台上都不起作用 - shellcode 對於這個漏洞來說太大了。
事實上，它看起來像這樣：3 分鐘內嘗試 4-5 次攻擊，然後等待 30 小時。 如此連續三週。 我甚至設定了提醒，以免浪費時間。 此外，測試環境和生產環境的行為也存在差異：漏洞有兩種類似的利用方式，一種來自 Metasploit，另一種來自互聯網，由 Shadow Brokers 版本轉換而來。 所以，只有Metasploit進行了實戰測試，只有第二個進行了台架測試，這使得調試更加困難，很傷腦筋。
最後，透過 http 從給定伺服器下載 exe 檔案並在目標系統上啟動它的 shellcode 被證明是有效的。 shellcode 足夠小，可以容納，但至少它可以工作。 由於伺服器完全不喜歡 TCP 流量，並且檢查了 http(s) 是否存在 meterpreter，因此我決定最快的方法是透過此 shellcode 下載包含 DNS-meterpreter 的 exe 檔案。
這裡又出現了一個問題：當下載一個exe檔時，如同嘗試所示，無論是哪一個，下載都會中斷。 同樣，我的伺服器和泌尿科醫生之間的某些安全設備不喜歡內部帶有 exe 的 http 流量。 「快速」的解決方案似乎是更改 shellcode，以便它可以動態混淆 http 流量，從而傳輸抽象的二進位資料而不是 exe。 最終攻擊成功，透過瘦DNS通道收到控制權：
我立即意識到我擁有最基本的 IIS 工作流程權限，這讓我什麼都不做。 這是 Metasploit 控制台上的樣子：
所有滲透測試方法都強烈建議您在獲得存取權限時需要增加權限。 我通常不會在本地執行此操作，因為第一次訪問被簡單地視為網路入口點，並且危害同一網路上的另一台電腦通常比在現有主機上升級權限更容易、更快。 但這裡的情況並非如此，因為 DNS 通道非常狹窄，並且不允許流量清理。
假設這台Windows 2003 伺服器還沒有針對著名的MS17-010 漏洞進行修復，我透過meterpreter DNS 隧道將流量傳輸到連接埠445/TCP 到本機主機（是的，這也是可能的），並嘗試透過以下方式運行之前下載的exe漏洞。 攻擊有效，我收到了第二個連接，但具有系統權限。
有趣的是，他們仍然試圖保護伺服器免受 MS17-010 的侵害 - 它在外部介面上禁用了易受攻擊的網路服務。 這確實可以防止通過網路的攻擊，但是來自本地主機內部的攻擊起作用了，因為您不能快速關閉本地主機上的 SMB。
接下來，新的有趣細節被揭曉：
- 擁有 SYSTEM 權限，您可以輕鬆地透過 TCP 建立反向連線。 顯然，停用直接 TCP 對於受限的 IIS 使用者來說是一個嚴格的問題。 劇透：IIS 用戶流量以某種方式雙向封裝在本地 ISA 代理中。 具體如何操作，我沒有重現。
- 我位於某個「DMZ」（這不是 Active Directory 網域，而是工作群組） - 這聽起來很合乎邏輯。 但我沒有得到預期的私有（「灰色」）IP 位址，而是一個完全「白色」的 IP 位址，與我之前攻擊的 IP 位址完全相同。 這意味著該公司在 IPv4 尋址領域已經很老了，以至於它有能力根據該方案維護 128 個「白色」位址的 DMZ 區域，而無需 NAT，如思科 2005 年手冊中所述。
由於伺服器很舊，Mimikatz 保證直接從記憶體工作：
我獲取了本地管理員密碼，透過 TCP 傳輸 RDP 流量並登入舒適的桌面。 由於我可以對伺服器做任何我想做的事情，所以我刪除了防毒軟體，發現只能透過 TCP 連接埠 80 和 443 從 Internet 存取該伺服器，並且 443 並不繁忙。 我在 443 上設定了 OpenVPN 伺服器，為我的 VPN 流量添加 NAT 功能，並透過我的 OpenVPN 以無限的形式直接存取 DMZ 網路。 值得注意的是，具有一些非禁用 IPS 功能的 ISA 透過連接埠掃描阻止了我的流量，為此必須用更簡單且更相容的 RRAS 來取代它。 因此，滲透測試人員有時仍然需要管理各種事情。
細心的讀者會問：“第二個網站怎麼樣？一個帶有 NTLM 身份驗證的 wiki，關於它的文章已經寫了很多了？” 稍後會詳細介紹這一點。
第 2 部分. 仍然沒有加密？ 那我們已經來找你了
這樣，就可以存取DMZ網段了。 您需要去網域管理員那裡。 首先想到的是自動檢查 DMZ 段內服務的安全性，特別是因為現在有更多服務可供研究。 滲透測試期間的典型情況：外部邊界比內部服務受到更好的保護，並且當在大型基礎設施內部獲得任何訪問權限時，僅因為該域開始被訪問，就更容易獲得域中的擴展權限。其次，在擁有數千台主機的基礎設施中，總是會存在一些關鍵問題。
我透過 OpenVPN 隧道透過 DMZ 為掃描器充電，然後等待。 我打開報告——同樣沒什麼嚴重的，顯然有人在我之前經歷過同樣的方法。 下一步是檢查 DMZ 網路內的主機如何通訊。 為此，首先啟動常用的 Wireshark 並偵聽廣播請求，主要是 ARP。 整天收集ARP資料包。 事實證明，該段使用了多個網關。 這稍後會派上用場。 透過結合 ARP 請求和回應的數據以及連接埠掃描數據，除了那些以前已知的服務（例如 Web 和郵件）之外，我還找到了本地網路內部用戶流量的出口點。
由於目前我無法存取其他系統，也沒有用於企業服務的單一帳戶，因此決定使用 ARP 欺騙從流量中至少找出一些帳戶。
Cain&Abel 在泌尿科醫生的伺服器上啟動。 考慮到已識別的流量，選擇最有可能進行中間人攻擊的對，然後透過短期啟動 5-10 分鐘來接收一些網路流量，並使用計時器重新啟動伺服器以防結冰。 正如笑話中所說，有兩個訊息：
- 好的：大量憑證被捕獲，並且整個攻擊有效。
- 缺點：所有憑證均來自客戶自己的客戶。 在提供支援服務時，客戶專家會連接到不總是配置流量加密的客戶的服務。
結果，我獲得了很多在專案背景下無用的憑證，但作為攻擊危險的演示絕對有趣。 大公司的邊界路由器具有 telnet、將所有資料的調試 http 連接埠轉送到內部 CRM、從本機網路上的 Windows XP 直接存取 RDP 以及其他蒙昧行為。 結果是這樣的 .
我還發現了一個有趣的機會來收集交通信件，就像這樣。 這是一封現成的信件的範例，該信件從我們的客戶發送到其客戶的 SMTP 端口，同樣沒有加密。 某個安德烈要求他的同名者重新發送該文檔，該文檔被上傳到雲端盤，並在一封回覆信中包含登入名稱、密碼和連結：
這是對所有服務進行加密的另一個提醒。 不知道誰以及何時會專門讀取和使用您的資料 - 提供者、另一家公司的系統管理員或這樣的滲透測試人員。 我對許多人可以簡單地攔截未加密流量的事實保持沉默。
儘管取得了明顯的成功，但這並沒有讓我們更接近目標。 當然，有可能坐很長時間並找出有價值的信息，但事實上它不會出現在那裡，而且就網路的完整性而言，攻擊本身風險很大。
在再次深入研究服務後，我想到了一個有趣的想法。 有一個名為 Responder 的實用程式（很容易找到該名稱的使用範例），它透過「毒害」廣播請求，透過各種協定（例如 SMB、HTTP、LDAP 等）激發連接。 以不同的方式，然後要求每個連接的人進行身份驗證並進行設置，以便通過 NTLM 並以對受害者透明的模式進行身份驗證。 大多數情況下，攻擊者以這種方式收集 NetNTLMv2 握手訊息，並使用字典從中快速恢復使用者網域密碼。 在這裡，我想要類似的東西，但用戶坐在“牆後”，或者更確切地說，他們被防火牆隔開，並透過 Blue Coat 代理叢集存取 WEB。
還記得嗎，我指定了 Active Directory 網域與「外部」網域一致，即 company.ru？ 因此，Windows，更準確地說是 Internet Explorer（以及 Edge 和 Chrome），如果用戶認為該網站位於某個“Intranet 區域”，則允許用戶透過 NTLM 在 HTTP 中透明地進行身份驗證。 「內部網路」的標誌之一是存取「灰色」IP 位址或短 DNS 名稱（即不含點）。 由於他們擁有一台具有「白色」IP 和 DNS 名稱 preobrazhensky.company.ru 的伺服器，並且網域電腦通常會透過 DHCP 接收 Active Directory 網域後綴以簡化名稱輸入，因此他們只需在網址列中寫入 URL ，以便他們找到通往受感染泌尿科醫師伺服器的正確路徑，不要忘記這現在被稱為「內部網路」。 也就是說，同時在用戶不知情的情況下向我提供用戶的 NTLM 握手。 剩下的就是迫使客戶端瀏覽器考慮聯繫該伺服器的迫切需求。
精彩的 Intercepter-NG 實用程式來救援（感謝 ）。 它允許您即時更改流量，並且在 Windows 2003 上運作良好。它甚至具有僅修改流量中的 JavaScript 檔案的單獨功能。 計劃進行一種大規模的跨站點腳本編寫。
使用者透過 Blue Coat 代理程式存取全球 WEB，定期快取靜態內容。 透過攔截流量，很明顯他們正在全天候工作，無休止地請求頻繁使用的靜態，以加快高峰時段內容的顯示速度。 此外，BlueCoat還有一個特定的User-Agent，它可以清楚地將其與真實使用者區分開來。
Javascript 已準備好，使用 Intercepter-NG，在晚上用 Blue Coat 的 JS 檔案執行每個回應一個小時。 該腳本執行了以下操作：
- 透過User-Agent確定目前瀏覽器。 如果是 Internet Explorer、Edge 或 Chrome，它仍然可以工作。
- 我一直等到頁面的 DOM 形成。
- 使用表單的 src 屬性將不可見影像插入 DOM 中 :8080/NNNNNNN.png，其中 NNN 是任意數字，因此 BlueCoat 不會快取它。
- 設定一個全域標誌變數以指示注入已完成，無需再插入影像。
瀏覽器嘗試載入此圖像；在受感染伺服器的連接埠 8080 上，一條 TCP 隧道正在等待它到達我的筆記型電腦，其中正在運行相同的回應程序，要求瀏覽器透過 NTLM 登入。
從 Responder 日誌來看，人們早上來上班，打開工作站，然後在不知不覺中集體開始訪問泌尿科醫師的服務器，同時還不忘記「耗盡」NTLM 握手。 一整天的握手如雨般落下，顯然為恢復密碼的明顯成功的攻擊積累了材料。 響應程序日誌如下所示：
使用者大規模秘密存取泌尿科醫生伺服器
你可能已經注意到，整個故事是建立在「一切都很好，但隨後有一個無賴，然後是克服，然後一切都成功」的原則之上的。 所以，這裡有一個無賴。 在五十種獨特的握手方式中，沒有一種被透露。 這考慮到了這樣一個事實：即使在處理器已失效的筆記型電腦上，這些 NTLMv2 握手也會以每秒數億次嘗試的速度進行處理。
我必須用密碼變異技術、一張顯示卡、一本更厚的字典來武裝自己，然後等待。 很長一段時間後，多個密碼形式為「Q11111111....1111111q」的帳戶被曝光，這表明所有用戶曾經被迫想出一個很長的不同大小寫的密碼，這也是應該的變得複雜。 但你騙不了經驗豐富的用戶，這就是他讓自己更容易記住的方法。 總共約有 5 個帳戶遭到洩露，其中只有一個帳戶擁有對服務的任何有價值的權利。
第 3 部分：Roskomnadzor 的反擊
這樣，我們就收到了第一個網域帳戶。 如果您在閱讀了很長一段時間後還沒有睡著，您可能會記得我提到過不需要第二個身份驗證因素的服務：它是一個具有 NTLM 身份驗證的 wiki。 當然，首先要做的就是進入那裡。 深入挖掘內部知識庫很快就帶來了成果：
- 該公司擁有一個 WiFi 網絡，使用可存取本地網路的網域帳戶進行身份驗證。 根據目前的資料集，這已經是一個有效的攻擊媒介，但您需要親自前往辦公室並位於客戶辦公室範圍內的某個位置。
- 我發現了一項指令，根據該指令，如果使用者位於本地網路內並且自信地記住了他的網域登入名稱和密碼，則允許...獨立註冊「第二因素」身份驗證裝置。 在這種情況下，「內部」和「外部」由使用者對該服務的連接埠的可存取性決定。 該連接埠無法從 Internet 訪問，但可以透過 DMZ 存取。
當然，「第二個因素」立即以我手機上的應用程式的形式添加到受感染的帳戶中。 有一個程式可以透過「批准」/「不批准」按鈕大聲向手機發送推送請求，也可以在螢幕上默默地顯示 OTP 代碼以供進一步獨立輸入。 此外，說明書認為第一種方法是唯一正確的方法，但與 OTP 方法不同，它不起作用。
隨著「第二個因素」被打破，我能夠在 Citrix Netscaler Gateway 中存取 Outlook Web Access 郵件和遠端存取。 Outlook中的郵件中出現了驚喜：
在這張罕見的照片中，您可以看到 Roskomnadzor 如何幫助滲透測試人員
這是著名的「粉絲」封鎖 Telegram 後的頭幾個月，當時擁有數千個位址的整個網路無情地無法存取。 很明顯為什麼推送沒有立即起作用，為什麼我的「受害者」沒有發出警報，因為他們在開放時間開始使用她的帳戶。
任何熟悉Citrix Netscaler的人都會想像它通常以這樣的方式實現：只能向用戶傳達一個圖片界面，盡量不給他提供啟動第三方應用程序和傳輸數據的工具，百般限制操作通過標準控制外殼。 我的“受害者”，由於他的職業，只得到了1C：
稍微繞了一下1C接口，我發現那裡有外部處理模組。 它們可以從介面加載，並將根據權限和設定在客戶端或伺服器上執行。
我要求我的 1C 程式設計師朋友創建一個可以接受字串並執行它的處理。 在1C語言中，啟動一個程序看起來像這樣（摘自網際網路）。 您是否同意 1C 語言的語法以其自發性令俄語人士驚嘆不已？
處理執行得很完美；結果證明它是滲透測試人員所說的「外殼」——Internet Explorer 是透過它啟動的。
早些時候，在郵件中發現了一個允許您訂購前往該地區通行證的系統的地址。 我訂購了一張通行證，以防我不得不使用 WiFi 攻擊媒介。
網路上有傳言說客戶辦公室還有美味的免費餐飲，但我還是比較喜歡遠端發動攻擊，這樣比較平靜。
AppLocker在運行Citrix的應用程式伺服器上被激活，但被繞過。 同一個 Meterpreter 是透過 DNS 載入和啟動的，因為 http(s) 版本不想連接，而且當時我不知道內部代理位址。 順便說一句，從這一刻起，外部滲透測試基本上完全變成了內部滲透測試。
第 4 部分：使用者的管理員權限不好，好嗎？
滲透測試人員在取得網域使用者會話控制權時的首要任務是收集有關網域中權限的所有資訊。 有一個 BloodHound 實用程序，可自動允許您透過 LDAP 協定從網域控制站下載有關使用者、電腦、安全群組的信息，並透過 SMB 下載有關哪個使用者最近登入、何處以及誰是本機管理員的資訊。
奪取網域管理員權限的典型技術看起來被簡化為單調操作的循環：
- 根據已捕獲的網域帳戶，我們轉到具有本機管理員權限的網域電腦。
- 我們啟動 Mimikatz 並取得最近登入該系統的網域帳戶的快取密碼、Kerberos 票證和 NTLM 雜湊值。 或者我們刪除 lsass.exe 進程的記憶體映像，並在我們這邊執行相同的操作。 這適用於低於 2012R2/Windows 8.1 且預設設定的 Windows。
- 我們確定受感染的帳戶在何處擁有本機管理員權限。 我們重複第一點。 在某個階段，我們取得整個網域的管理員權限。
“週期結束”，正如 1C 程式設計師會在這裡寫的那樣。
因此，我們的使用者原來只是一台裝有 Windows 7 的主機上的本機管理員，該主機的名稱包含「VDI」或「虛擬桌面基礎設施」一詞，即個人虛擬機器。 大概，VDI服務的設計者的意思是，由於VDI是使用者的個人作業系統，即使使用者隨意改變軟體環境，主機仍然可以「重裝」。 我還認為總的來說這個想法不錯，我去了這個個人VDI主機並在那裡安了一個窩：
- 我在那裡安裝了一個 OpenVPN 用戶端，它透過網路建立了一條通往我的伺服器的隧道。 客戶端必須被迫通過相同的 Blue Coat 網域身份驗證，但 OpenVPN 做到了，正如他們所說，「開箱即用」。
- 在 VDI 上安裝 OpenSSH。 好吧，說真的，沒有 SSH 的 Windows 7 是什麼？
這就是現場的樣子。 讓我提醒您，這一切都必須透過 Citrix 和 1C 來完成：
促進對相鄰電腦的存取的一種技術是檢查本地管理員密碼是否匹配。 幸運的是：預設本機管理員（突然被稱為管理員）的 NTLM 雜湊值會透過對鄰近 VDI 主機（其中有數百台）的雜湊傳遞攻擊而被取得。 當然，攻擊立刻就擊中了他們。
這就是 VDI 管理員兩次搬起石頭砸自己腳的地方：
- 第一次是當 VDI 電腦沒有納入 LAPS 時，基本上保留了大規模部署到 VDI 的映像中相同的本機管理員密碼。
- 預設管理員是唯一容易受到哈希傳遞攻擊的本機帳戶。 即使使用相同的密碼，也可以透過使用複雜的隨機密碼建立第二個本機管理員帳戶並阻止預設帳戶來避免大規模洩露。
為什麼 Windows 上有 SSH 服務？ 很簡單：現在OpenSSH伺服器不僅提供了一個方便的互動式命令shell而不干擾使用者的工作，而且還提供了VDI上的socks5代理程式。 透過這個襪子，我透過 SMB 連接並從所有數百台 VDI 電腦收集快取帳戶，然後在 BloodHound 圖表中尋找使用它們的網域管理員的路徑。 由於有數百台主機可供我使用，我很快就找到了這種方法。 已取得網域管理員權限。
這是來自網路的圖片，顯示了類似的搜尋。 連線顯示管理員所在位置以及登入位置。
順便說一下，請記住專案一開始的條件—「不要使用社會工程學」。 因此，我建議考慮一下，如果仍然可以使用平庸的網路釣魚，那麼所有具有特效的寶萊塢將會被切斷多少。 但就我個人而言，做這一切對我來說非常有趣。 我希望您喜歡閱讀本文。 當然，並不是每個專案看起來都那麼引人入勝，但整個工作非常具有挑戰性，不允許它停滯不前。
可能有人會有疑問：如何保護自己？ 即使這篇文章也描述了許多技術，其中許多技術甚至 Windows 管理員都不知道。 不過，我建議從陳腐的原則和資訊安全措施的角度來看它們：
- 不要使用過時的軟體（還記得一開始的Windows 2003嗎？）
- 不要開啟不必要的系統（為什麼會有泌尿科醫師的網站？）
- 自己檢查使用者密碼的強度（否則士兵......滲透測試人員會這樣做）
- 不同帳號沒有相同的密碼（VDI 妥協）
- 和另一個
當然，這很難實現，但在下一篇文章中我們將透過實踐證明這是完全可能的。
來源： www.habr.com