在活動目錄中進行的誘捕與反誘捕的攻防較量

安全技術 · 發表 2018-11-08 11:30:10

摘要：幾年前，我參與了幾個月的企業誘捕解決方案的開發和測試專案。在此期間，我積攢了一些在活動目錄中實施誘捕和釣魚檢測的經驗，並意識到在活動目錄中實施誘捕的關鍵點主要集中在honeyuser/honeytoken /honeycredentials上。像dcept等工具就是利用的這些攻擊點，戴爾開源的...

幾年前，我參與了幾個月的企業誘捕解決方案的開發和測試專案。在此期間，我積攢了一些在活動目錄中實施誘捕和釣魚檢測的經驗，並意識到在活動目錄中實施誘捕的關鍵點主要集中在honeyuser/honeytoken /honeycredentials上。像dcept等工具就是利用的這些攻擊點，戴爾開源的工具稱為 DCEPT（Domain Controller Enticing Password Tripwire，域控制誘導加密絆網），是一種能夠用來檢測嘗試入侵本地Windows域和活動目錄的攻擊者的蜜罐伺服器安全技術。如果我們想在攻擊的域名列舉階段就利用相關工具來檢測出攻擊，會遇到很多困難，不過這正是我本文要解決的問題。

誘捕與反誘捕的攻防遊戲

對於攻擊者來說，就是想方設法欺騙使用者開啟惡意附件或點選惡意連結。一旦進入攻擊環境，攻擊者就會試圖截獲使用者的憑證，並通過其他裝置來混入現有的日誌和流量。

而對於安防人員來說，有一種檢測攻擊的辦法就是所謂的“釣魚執法”：通過向攻擊者提供他們想要的服務、許可權或正在尋找的資訊，來讓他們上鉤。很多攻擊者在心裡上，都會天然的認為被攻擊者是愚蠢的、沒有防禦意識的且計算機技術比較差，發現不了他們的惡意意圖。通常情況下，他們認為自己也比安防人員更聰明、更有天賦。在這些心理的作用下，他們往往以為只要自己一出手，就可以迅速獲得自己想要的東西，比如迅速獲得Direct活動目錄min許可權。

所以，安防人員正是基於此向攻擊者故意展示他們想看到的內容。例如，偽裝成將密碼設定為類似於“123…”的“弱智”使用者，讓他們進入到蜜罐中。

給攻擊者釋放的誘餌最好是以下四個：

1.攻擊目標足夠多，以便攻擊者列舉物件；

2.易於配置；

3.攻擊端不需要進行配置更改；

4.不應該觸發正常的管理活動；

上面的第4點是最難實現的。如果安防人員的目標是列舉，則必須使攻擊者的活動或使用的工具凸顯出來，以避免誤報。

部署具有誘餌屬性的攻擊環境

那麼，我們如何通過活動目錄中的內建工具實現上述攻擊者所需的攻擊屬性呢?我們可以使用使用者組策略設定ADAccess事件日誌，配置攻擊者感興趣的物件並過濾掉誤報資訊。

活動目錄訪問所需的使用者組策略設定過程是Windows Settings | Security Settings | Advanced Audit Policy Configuration | DS Access – Audit Directory Service Access。

以上設定在每次訪問活動目錄物件時都會導致安全事件4662，日誌記錄需要在物件級別進行配置。對於這種配置，我們需要修改物件的SACL並新增相關的ACE。

你可以通過檢視 ofollow,noindex">AddAuditAccessObjectAce函式，來完整理解ACE。

我會在本文所講的樣本中，設定完全針對使用者使用'ReadProperty''success'時的安全審計，這有助於檢測針對該使用者的任何列舉。

Deploy-Deception

雖然這些設定可以使用使用者介面完成，但是多虧了Shell/">PowerShell和ActiveDirectory模組，它才得以實現自動化。

為了自動化設定具有有趣屬性和鮮為人知的屬性的誘餌物件，以避免誤報，我編寫了Deploy-Deception。它是一個PowerShell模組，利用ActiveDirectory模組輕鬆高效地部署誘餌，你可以在 Github 上找到具體的部署過程。

下面，我會詳細介紹如何在攻擊的不同階段設定不同型別的目標誘餌。

列舉：以使用者物件為誘餌

使用者物件是最有趣的物件，其中的一些使用者屬性是攻擊者最感興趣的:

1.從來沒有更改過的密碼或比較“弱智”的密碼；

2.信任的Delegation(委託)機制， Delegation是一種實現機制:一個物件轉發或者委託一個請求給另一個物件；

3.擁有SPN的使用者，SPN(Service Principal name)伺服器主體名稱。SPN是服務在使用Kerberos身份驗證的網路上的唯一識別符號,它由服務類、主機名和埠使用者組成；

4.被明確標記出的密碼；

5.屬於高許可權使用者組的使用者；

6.對其他使用者、使用者組或Container(容器)物件具有ACL許可權的使用者；

我可以使用Deplou-UserDeception函式來建立一個含有以上誘餌因素的假使用者。本文中我建立了一個名為'usermanager'的假使用者，其密碼從來沒有更改過，如果有攻擊者讀取它的任何屬性，就會記錄在4662事件中。

PS C:\> Import-Module C:\Deploy-Deception\Deploy-Deception.psd1
PS C:\> Create-DecoyUser -UserFirstName user -UserLastName manager -Password Pass@123 | Deploy-UserDeception -UserFlag PasswordNeverExpires –Verbose

請注意，真實的使用者物件都是在域中建立的。且在實踐中，上面所述的因素的觸發非常頻繁，因為每當有人讀取使用者usermanager的任何屬性時，都會啟用我設定的預設日誌記錄。這意味著即使有人簡單的列出域中的所有使用者，也會記錄在4662。這意味著，觸發以上所述誘餌的所有操作(包括正常的操作) 都會啟用日誌記錄。比如以下操作：

1.net user /domain命令，我們在新增域使用者時，有時會有使用者沒有新增，或者已新增的使用者名稱拼寫錯誤。這時，我們想查一下目前域中所有的使用者，就是使用的這個命令；

2.Get-WmiObject -Class Win32_UserAccount命令，用此命令查詢帳戶狀態（$User.Status）；

3.Get-ADUser -Filter * (MS ActiveDirectory module) 命令；

4.Get-NetUser (PowerView) 命令；

5.查詢使用者，聯絡人和使用者組的使用者介面命令；

不過，這種大範圍的誘捕行為，會讓我無法區分攻擊者的列舉行為和正常活動行為。攻擊者所使用的列舉工具有一些特別之處，就是它們喜歡儘可能多的提取攻擊物件的資訊(這樣做是因為他們不希望重複連線到域控制器)。這意味著如果我現在要對一個不常見的屬性進行觸發並審計，只有通過一些列舉工具產生的列舉行為才會觸發日誌記錄，以免存在誤報。在觀察了所有屬性列表後，我發現有很多這樣的屬性，我從中選擇了一個具有代表性的屬性 -x500uniqueIdentifier (使用者介面D為 d07da11f-8a3d-42b6-b0aa-76c962be719a)

這樣，我現在就可以刪除之前新增的ACE了，重新添加了一個僅在x500uniqueIdentifier屬性被讀取時才觸發日誌記錄的新ACE。

PS C:\> Deploy-UserDeception -DecoySamAccountName usermanager -RemoveAuditing $true -Verbose
PS C:\> Deploy-UserDeception -DecoySamAccountName usermanager -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose

只有類似PowerView之類的工具（或者類似ADExplorer之類的工具）才會觸發這種審計，這些工具會獲取物件的所有屬性。雖然這並不能把攻擊行為和正常行為完美的區別開來，但也是一個巨大的進步了。

如果你對自己的誘捕技術很有信心，確信你的監控或管理工具不會讀取所觸發物件的所有屬性，那麼你也可以設定類似SPN之類的屬性，只有當讀取SPN（或者所有屬性）時才會觸發日誌記錄。

PS C:\> Create-DecoyUser -UserFirstName user -UserLastName manager-spn -Password Pass@123 | Deploy-UserDeception -SPN 'MSSQLSvc/dc' -GUID f3a64788-5306-11d1-a9c5-0000f80367c1 -Verbose

如果此時生成的日誌記錄還是讓你很迷惑，那可以使用如下命令以下命令僅在讀取假使用者裡的DACL(自由訪問控制列表)誘餌屬性時，才會被記錄在4662事件中。

PS C:\> Create-DecoyUser -UserFirstName user -UserLastName manager-control -Password Pass@123 | Deploy-UserDeception -UserFlag AllowReversiblePasswordEncryption -Right ReadControl -Verbose

列舉：以計算機物件為誘餌

我們還可以以計算機物件為誘餌，可以在域中建立假的用於誘捕的計算機物件，而不需要將真實的計算機對映到該物件中。即便如此，我還是建議使用真實的計算機或者虛擬機器來部署計算機物件誘餌，以避免露餡。

攻擊者感興趣的一些計算機物件屬性包括:

1.舊的作業系統；

2.有趣的SPN；

3.Delegation(委託)機制的設定；

4.具有高許可權的使用者組成員；

先看看如何使用Deploy-Deception模組進行的一些誘餌部署，在此期間，我可以使用Deploy-DecoyComputer函式。

PS C:\> Create-DecoyComputer -ComputerName revert-web -Verbose | Deploy-ComputerDeception -PropertyFlag TrustedForDelegation -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a-Verbose

上面的命令可以建立一個計算機物件誘餌，該物件啟用了Unconstrained Delegation屬性，每當有攻擊者讀取該物件誘餌的x500uniqueIdentifier屬性或者所有相關屬性時，就會被記錄在4662事件中。

PS C:\> Deploy-ComputerDeception -DecoyComputerName comp1 -PropertyFlag TrustedForDelegation -Right ReadControl -Verbose

上面的命令使用現有的計算機物件並設定Unconstrained Delegation屬性，每當有人讀取DACL或計算機的所有屬性時，就會觸發日誌記錄。

我還可以使用 DCShadow 來修改計算機物件誘餌，使其看起來像是DC（域控制器）。

列舉：以使用者組物件為誘餌

我還可以以使用者組物件為誘餌，攻擊者感興趣的使用者組要具備以下屬性：

1.有趣的名稱(比如類似admins、administrators之類的名稱)；

2.這個使用者組的成員也是高許可權使用者組的成員，或者具有攻擊者感興趣的使用者屬性；

3.具有高許可權的使用者組成員；

以使用者組物件為誘餌是個非常有趣的誘捕方法，我可以讓誘餌使用者成為誘餌使用者組的成員，從而建立更細緻化的誘餌元素。通過這種方法，攻擊者對誘餌組成員的列舉以及誘餌使用者的列舉操作都會被被記錄在日誌裡，接下來我會介紹如何使用登入限制來避免誤用使用者的許可權，將正常的使用者行為和攻擊行為分開。

因此，在下面的命令中，我會建立了一個使用者名稱為'dnsmanager'的誘餌使用者組，且使用者使用的密碼永遠有效，當攻擊者讀取密碼時，就會被記錄在相關日誌中。另外，我還建立了一個名為“Forest Admins”的誘餌使用者組，並假定dnsmanager使用者為該組成員，將“Forest Admins”使用者組加入內建的dnsadmins使用者組中。一旦有人讀取dnsmanager的屬性，就會觸發日誌記錄，我使用的就是Deploy-GroupDeception來完成這個過程的。

PS C:\> Create-DecoyUser -UserFirstName dns -UserLastName manager -Password Pass@123 | Deploy-UserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose 
PS C:\> Create-DecoyGroup -GroupName 'Forest Admins' -Verbose | Deploy-GroupDeception -AddMembers dnsmanager -AddToGroup dnsadmins -GUID bc0ac240-79a9-11d0-9020-00c04fc2d4cf -Verbose

列舉和內網滲透(lateral movement)：以許可權使用者物件為誘餌

我還可以以許可權使用者物件為誘餌，以監測攻擊者的列舉和內網滲透)行為，具體過程就是建立具有高許可權的誘餌使用者，如成為域管理組的一員，具有執行DCSync的許可權等。

但這種誘捕方法也存在著一定的風險，就是一旦被攻擊者發現高許可權使用者是誘餌，則攻擊者可以反過來捕獲這些高許可權，執行更深度的攻擊。為了避免這種情況的發生，我們可以使用一些保護措施:

1.將Logon Workstation設定為一個並不是真實存在的計算機上；

2.拒絕誘餌使用者的反登入；

有了上述兩種保護，誘餌使用者就不能使用任何型別的登陸憑證（如密碼、雜湊等）來登入，這意味著，攻擊者無法使用誘餌使用者的任何許可權。

做好這些誘捕準備後，我就可以使用deploy-privilegeduserscam來建立具有高許可權的使用者誘餌。

PS C:\> Create-DecoyUser-UserFirstName dec -UserLastName da -Password Pass@123 | Deploy-PrivilegedUserDeception -Technique DomainAdminsMemebership -Protection DenyLogon -Right ReadControl –Verbose

我使用上面的命令建立了一個名為“decda”的使用者，並讓該使用者成為域管理組的一員，但該使用者不能登入任何計算機。任何列出使用者的DACL或列出所有屬性的嘗試都會導致4662日誌的生成。

登入失敗的介面如下圖所示：

雖然登陸失敗，但還是會在域控制器上記錄4768(故障)事件。對於像OverPass-The-Hash這樣的攻擊，就不會生成如此詳細的錯誤。

另一個選項是將LogonWorkstation設定為現實中並不存在的計算機，但我們可以使用和真實主機名類似的名稱。

PS C:\> Create-DecoyUser-UserFirstName dec -UserLastName da -Password Pass@123 | Deploy-PrivilegedUserDeception-Technique DCSyncRights -Protection LogonWorkStation revert-webserver1 -Right ReadControl -Verbose

我可以使用上面的命令建立一個名為“decda”的誘餌使用者，該使用者具有提供DCSync的許可權，另外，我會將LogonWorkStation設定為真實不存在的裝置。如果使用者憑證被攻擊者盜取並被重用，就會出現與DenyLogon類似的錯誤並生成4768事件。

這兩種保護技術也可以用於非活動目錄帳戶, 恕我直言，這比在記憶體中留下錯誤的密碼或雜湊值更好。當我在捕獲內網滲透的攻擊時，這兩種保護技術可以與其他技術相結合，讓攻擊者以一種更簡單的方法（使用Deploy-UserDeception的-PasswordInDescription選項）檢索到誘餌使用者的憑證。然後，我可以使該使用者成為高許可權使用者，並使用上述保護措施。

PS C:\> Create-DecoyUser-UserFirstName new -UserLastName da -Password Pass@123 | Deploy-UserDeception -PasswordInDescription 'The new password is Pass@123' -Verbose
PS C:\> Deploy-PrivilegedUserDeception -DecoySamAccountName newda -Technique DomainAdminsMemebership -Protection DenyLogon -Right

上面的第一個命令負責建立一個名為“newda”的新使用者，將其描述為The new password is Pass@123字串。而第二個命令則是讓“newda”成為域管理組的一員，並設定為拒絕使用者登入的狀態，一旦有人讀取DACL或newda的所有屬性，就會被記錄在日誌中。

由於無需使用特殊工具就可以從描述資訊中獲得密碼，因此攻擊者很容易觸發這些誘餌。在討論具有許可權的使用者時，還必須討論關於ACL（訪問控制列表）的問題，這個問題很重要。如果某個使用者含有操控其他使用者的許可權，那麼攻擊者肯定會對這個使用者感興趣。(確保ACL的安全，包括域物件和其他安全性，都是安全監控的重要一環)。

我們可以使用Deploy-SlaveDeception來設定一些誘餌使用者，讓其中一個使用者對其他使用者擁有完全控制或使用的許可權。這正是攻擊者感興趣的目標，他們可以利用這些使用者列舉和內網滲透。

我可以使用如下命令，捕獲列舉行為。

PS C:\> Create-DecoyUser -UserFirstName master -UserLastName user -Password Pass@123 | Deploy-UserDeception -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
PS C:\> Create-DecoyUser -UserFirstName slave -UserLastName user -Password Pass@123 | Deploy-UserDeception -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
PS C:\> Deploy-SlaveDeception -SlaveSamAccountName slaveuser -DecoySamAccountName masteruser -Verbose

上面的第一個命令和第二個命令分別負責建立名為masteruser和slaveuser的使用者，並且只在攻擊者讀取模糊屬性時進行安全稽核並被記錄到日誌中。第三個命令負責為slaveuser使用者提供masteruser使用者的GenericAll許可權。在域中對這兩個物件進行列舉或掃描感興趣的acl的任何攻擊都將觸發4662事件。

為了捕獲攻擊者的內網滲透行為，我們可以使用masteruser的PasswordInDescription選項，或者使用其他能讓攻擊者容易獲取誘餌使用者憑證的簡單方法。而我使用的是則是有點冒險的方法，就是讓攻擊者能截獲masteruser使用者的許可權(請在使用前仔細考慮風險)。如果masteruser修改了slaveuser的DACL，除了在使用honeytoken/honeyuser時觸發的任何其他警報外，我們還會得到一個4662日誌。

PS C:\> Create-DecoyUser -UserFirstName master -UserLastName user -Password Pass@123
PS C:\> Create-DecoyUser -UserFirstName slave -UserLastName user -Password Pass@123
PS C:\> Deploy-SlaveDeception -SlaveSamAccountName slaveuser -DecoySamAccountName masteruser -Verbose
PS C:\> Deploy-UserDeception -DecoySamAccountName slaveuser -Principal masteruser -Right WriteDacl -Verbose

在上面的命令中，一旦masteruser修改slaveuser的DACL，就會生成4662事件。

列舉：以域和域林之間的信任（ForestTrust）物件為誘餌

這個誘捕辦法目前還沒有實現自動化，但是有很多有趣的可能性!例如，我可以設定一個具有誘捕屬性的域林之間的信任（ForestTrust） (我在本文把它稱為blue forest)。攻擊者可以在這個誘餌中，列舉使用者、計算機和使用者組，但這些物件不具有訪問任何其他資源的許可權。這可以通過使用選擇性身份驗證建立域林之間的信任來實現，我只在DC上設定了Allowed to Authenticate選項，其他主機上未設定該選項。這將允許攻擊者列舉域和域林之間的信任物件，但他們不能訪問其他計算機上的資源。

攻擊者是否具有識破這些誘餌的能力？

那麼，攻擊者如何識別哪些攻擊物件是真實的，哪些攻擊物件是陷阱或誘餌呢?正如我在文章開頭提到的，我在過去幾個月裡測試了多種誘捕解決方案，在這些方案中，具有許多容易被識破的誘捕物件：

1.objectSID：該物件必須轉化成DomainSID-RID格式，某些企業在誘捕時，並沒有這樣做，往往被攻擊者一眼識破。如果我們發現objectSID不包含DomainSID-RID格式，那麼請仔細調查該誘餌物件。

2.lastLogon, lastlogontimestamp：使用者誘餌可以通過檢視這些屬性來識別。如果有一個高許可權的使用者從未進行過登入 (lastLogon的值為31/12/1600，這比LargeInteger日期的最早時間還要早)，那麼它很有可能是一個誘餌。

3.logonCount：雖然不如lastLogon那麼有效，但它也是一個很好的識別誘餌的方法。

4.whenCreated：它與lastLogon和logonCount物件相結合，就可以成為一個很好的識別指標。如果一個使用者已經建立了很長時間，但從未登入過，那很可能就是一個誘餌。因此在真實中，企業應儘量避免使用這些殭屍或休眠使用者，以防暴露自己的防禦計劃。

5.badPwdCount、badPasswordTime：只要是人類使用者，都有大意輸錯密碼的時候。如果某個使用者從來沒輸錯過密碼（即Badpwdcount值為0，或者錯誤密碼屬性異常），那麼很可能這是一個誘餌物件。

6.將很多誘餌物件的屬性同時集中設定在一起：真正的攻擊目標是不會有這麼多攻擊屬性的，建議企業不要刻意對一個誘餌物件設定太多誘捕屬性，這也很容易被發現。

最好的識別方法就是將懷疑是誘餌的物件與正常執行的物件進行比較，例如，如果攻擊者懷疑域中所有計算機列表中的某個計算機物件是一個誘餌，那麼他們就會將其與域控制器的屬性或當前所使用的裝置屬性進行比較。真實的dc總是在logonserver環境變數中列出。真實的DC始終位於logonserver環境變數中。對於使用者物件，內建DA的RID始終為500，攻擊者可以將其與他們懷疑的某個使用者物件進行比較。

如果某些誘捕解決方案不會在域中建立真實的物件，那麼攻擊者可以使用WMIC來獲取域資訊，顯示正確的物件，排除經過偽造的物件。

攻擊者如何避過誘捕進行攻擊？

我開頭就講過，攻擊者總是認為使用者目標或安防人員都是“弱智”，只要他們一出手就沒有辦不成的事情，除了這種優越心裡外，他們還喜歡坐享其成。殊不知，驕兵必敗，因此，攻擊者需要改變他們的狂妄心態，在複雜的企業網路中行動時，加著幾分小心。

1.企業網路通常都非常複雜，如果輕而易舉的獲取自己的攻擊目標，則要提高警惕；

2.避免使用自動化列舉工具，除非攻擊者非常瞭解這些工具在後臺的工作原理；

3.避免獲取DA許可權的誘惑，專注本身的攻擊目標，因為DA許可權是攻擊者渴望獲取的最高許可權，對於此誘惑，一般人很難抗拒。

安防人員如何防止自己設定的誘餌被識別

如果使用真實的域物件，被識別出的概率就會減少。例如，沒有對映到真實計算機的計算機物件，就很容易被識別出來。

如前所述，對於誘餌使用者物件，至少要讓其經常進行登入會話操作，避免其成為殭屍使用者。

讓我們看一個簡單的例子，有一個著名的誘餌識別指令碼叫做 HoneypotBuster 。現在讓我會建立一個誘餌DA，並執行此指令碼進行識別。

可以發現，我設定的誘餌DA被發現了。Deploy-PrivilegedUserDeception有一個選項'CreateLogon'，此引數使用誘餌DA使用者啟動和停止DC上的計算器，填充使用者的登入相關屬性。而如果要使用此引數，必須將LogonWorkstation保護設定為執行模組的DC，這樣你就可以隨時更改使用者的行為。

PS C:\> Create-DecoyUser -UserFirstName dec -UserLastName da -Password Pass@123 | Deploy-PrivilegedUserDeception -Technique DomainAdminsMemebership -Protection LogonWorkStation -LogonWorkStation revert-dc -CreateLogon –Verbose

我可以使用如上命令會建立名為decda的使用者，使其成為Domain Admins組的一員，不過我會限制其登入到DC，之後，我使用該使用者建立一個登入會話，這樣就會在DC上建立配置檔案。現在，如果執行HoneypotBuster，看看此誘餌能否被發現。

可以看到，FakeRank誘餌物件的懷疑度被降到了50。HoneypotBuster使用了一個排名系統來評測誘餌物件的偽造度，如果一個使用者的logonCount小於6，那麼肯定是誘餌。如果我將decda的logonCount設定為6，用它的憑證啟動這個程序6次，那麼它就不會被懷疑了。

PS C:\> Create-DecoyUser -UserFirstName dec -UserLastName da -Password Pass@123 | Deploy-PrivilegedUserDeception -Technique DomainAdminsMemebership -Protection LogonWorkStation -LogonWorkStation revert-dc -CreateLogon -logonCount 6 -Verbose

很明顯，現在如果我執行HoneypotBuster, 就會發現它並沒有檢測到decda!

不過這是針對HoneypotBuster工具的避免被識破的辦法，未來我還將致力於使用虛擬化技術來部署誘餌，比如藉助OU物件。OU(Organizational Unit，組織單位)是可以將使用者、組、計算機和其它組織單位放入其中的AD容器，是可以指派組策略設定或委派管理許可權的最小作用域或單元。通俗一點說，如果把AD比作一個公司的話，那麼每個OU就是一個相對獨立的部門。

如果想對本文的講述有更直觀的瞭解，請檢視我在BruCON上的演講文稿以及相關視訊。

在活動目錄中進行的誘捕與反誘捕的攻防較量

您可能也會喜歡…