在活動目錄中進行的誘捕與反誘捕的攻防較量
幾年前,我參與了幾個月的企業誘捕解決方案的開發和測試項目。在此期間,我積攢了一些在活動目錄中實施誘捕和釣魚檢測的經驗,並意識到在活動目錄中實施誘捕的關鍵點主要集中在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。
你可以通過查看AddAuditAccessObjectAce函數,來完整理解ACE。
我會在本文所講的樣本中,設置完全針對用戶使用"ReadProperty""success"時的安全審計,這有助於檢測針對該用戶的任何枚舉。
Deploy-Deception
雖然這些設置可以使用用戶界面完成,但是多虧了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-DeceptionDeploy-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日誌的生成。
對於內網滲透來說,他們使用了DenyLogon保護。這意味著即使用戶的密碼、哈希或密鑰被攻擊者獲取,他們也不可能重用這些憑證。為了在誘餌用戶的憑證被使用期間,捕獲到有意義的日誌,我需要啟用如下組策略:Configuration|Windows Settings|Security Settings|Advanced Audit Policy Configuration|Audit Policies|Account Logon | Audit Kerberos Authentication Service | Failure
登錄失敗的界面如下圖所示:
雖然登陸失敗,但還是會在域控制器上記錄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上的演講文稿以及相關視頻。
※最新發現!NOKKI惡意軟體與朝鮮Reaper組織有關
※NUUO網路視頻攝錄機Peekaboo漏洞:CVE-2018-1149、CVE-2018-1150
TAG:嘶吼RoarTalk |