.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
TGT是CAS 為用戶簽發的登錄ticket，也是用於驗證用戶登錄成功的唯一方式。 TGT 封裝了Cookie 值以及Cookie 值對應的用戶信息，CAS 通過Cookie 值（TGC）為key 查詢緩存中有無TGT（TGC:TGT（key:value）），如果有的話就說明用戶已經登錄成。
獲得對公司網絡資源的未經授權訪問的最複雜但最有效的方法之一是使用偽造證書進行攻擊。攻擊者創建這樣的證書來欺騙密鑰分發中心(KDC)授予對目標公司網絡的訪問權。此類攻擊的一個示例是ShadowCredential(msDS-KeyCredentialLink屬性)技術，該技術允許攻擊者通過修改受害者的msDS-KeyCredentialLink屬性並向其添加授權證書來登錄用戶帳戶。這種攻擊很難被檢測到，因為攻擊者不是竊取憑證，而是使用合法的Active Directory (AD)機制和配置漏洞。
儘管如此，緩解使用偽造證書的攻擊是可能的。在分析了託管檢測與響應服務MDR的數據後，研究人員確定了網絡中此類攻擊的幾個跡象，並開發了一個能夠查找AD中工件的概念驗證實用程序，以及可以添加到SIEM中的一些檢測邏輯規則。不過，我們有必要首先簡單介紹一下基於證書的Kerberos身份驗證的特點。
AD中的Kerberos身份驗證和實現過程在基於Active Directory的現代企業網絡中，資源管理是通過Kerberos協議執行的。只有當用戶能夠向網絡內的任何服務（對象）提供KDC頒發的票證（下圖中的Msg E）時，用戶才能訪問該對象。發送服務票證的KDC組件稱為票證授予服務器(TGS)。此外，用戶只有在擁有ticket Granting ticket (TGT)(下圖中的Msg B)時才會從KDC接收TGS票證。本質上，TGT是成功的用戶身份驗證的證明，通常虛通過密碼驗證。
Kerberos身份驗證方案但是，有一種方法可以在不知道密碼的情況下獲得TGT，即使用證書。為此，KDC必須信任所提供的證書，並且該證書必須與TGT中請求的主題相關。 Kerberos的這一部分稱為用於初始身份驗證的公鑰加密(PKINIT)，如果公司網絡中有為域用戶頒發證書的證書頒發機構，那麼設置身份驗證就非常容易。
但還有另一種方法，例如，要利用Microsoft Hello For Business功能，如基於PIN的授權或人臉識別，不過前提是登錄的設備必須具有自己的AD證書，以便KDC可以基於該證書頒發TGT。但是，並非所有具有活動目錄的網絡都具有證書頒發機構。這就是創建msDS-KeyCredentialLink屬性的原因，可以在其中編寫證書。 KDC將信任該證書並頒發TGT。這是一個很好的解決方案，擴展了Microsoft Active Directory的功能。
然而，基於上述邏輯，將msDS-KeyCredentialLink屬性寫入某個對象的主體也將能夠獲得該對象的票證，這就是問題所在。
攻擊是如何展開的？讓我們舉例說明一種可能的攻擊場景:
1.主體logan_howard對AD域中的任何屬性都有寫入權限，它使用Whisker將公鑰寫入域控制器對象(AD -gam$)的msDS-KeyCredentialLink屬性。
2.主體接收發送給域控制器的TGT(使用Rubeus工具包)。
3.在提交此TGT時，主體獲得TGS票證，以同步域(MS-DRSR：目錄複製服務遠程協議)中的密碼信息。
4.作為主體，攻擊者從域管理員帳戶(administrator)“同步”哈希，以冒充管理員，以便獲得對數據的訪問權限並在公司網絡內部橫向移動。這種攻擊稱為DCSync，並使用mimikatz。
工件查找我們不關注如何讓KDC信任特定的證書，包括被盜的或偽造的證書，而是關注TGT發送時的情況。這會觸發域控制器上的事件4768：請求了Kerberos身份驗證票證(TGT)。該事件可能包含用於身份驗證證書裡的工件，包含三個字段：CertIssuerName、CertSerialNumber和CertThumbprint。這些域是我們接下來要重點介紹的。
為方便起見，我們將在ELK集群的Kibana接口中處理所有事件。默認情況下，Logstash實際上知道如何將Event 4768的位字段轉換為列表中特定於票證的值數組，這也使得搜索更快更順暢。我們建議你參考官方的WinLogBeat設置指南，使用一組Docker配置來快速啟動和運行你的ELK實驗室。
在測試環境中，我們基於使用Whisker生成的偽造證書創建了幾個TGT請求事件。下面是這些事件在測試環境中的示例：
在MDR服務的框架內，研究人員每週觀察到數十萬個基於證書的票證請求事件。研究人員可以依據這些樣本，分析出一些攻擊模式：
攻擊的很大一部分是由Microsoft Azure Active Directory的基於證書的票證請求組成的（下圖中聚合的“Azure”行）。不過這些都不重要，可以使用Kibana接口中具有CertIssuerName字段值的正則表達式輕鬆地過濾它們。
還有許多事件用於Microsoft Hello For Business證書(“Hello4B self gen”行)使用的證書。在這種情況下，將證書數據寫入msDS-KeyCredentialLink屬性，並以編程方式生成密鑰(NCRYPT_IMPL_SOFTWARE_FLAG)。它們通常有一個以“CN=”開頭的名稱和一個兩位數的序列號，通常是01。
如果計算機有一個存儲在受信任的平台模塊中的密鑰（“TPM註冊”行），那麼使用該密鑰的證書也可以用正則表達式來描述，因此我們對此不感興趣。
但最常見的情況可能是使用Microsoft證書頒發機構頒發的證書（“Windows服務器CS角色頒發”行）。可以在運行Microsoft Windows服務器版本的計算機上啟用此服務。值得注意的是，如果你自己監控本地基礎設施，並且不是MSSP，你會發現通過CertIssuerName值過濾掉這種情況要容易得多——您的CA服務器的名稱(很可能是林中每個域的唯一名稱)。實際上，即使是大型公司網絡也只有相當少的CA能夠頒發證書。但是，即使你是一個MSSP，為了過濾掉所有客戶端PKI服務器的名稱仍然不會有太大麻煩。現在來看其他領域的一些模式。
此時，也可能存在第三方PKI實現，其證書在頒發票證時受到Kerberos服務器的信任。例如，監控時遇到了Lanaco公司開發的專業軟件。
使用真實數據，讓我們看看可以過濾掉哪些查詢。為此，我們可以使用上述正則表達式構建以下聚合：
卡巴斯基MDR服務中基於證書的票證請求事件的聚合
查看“Rest”行，其中包含剩餘的未過濾事件(其中13個)，注意CertIssuerName字段。
未過濾的基於證書的票證請求事件的擴展列表
Whisker代碼分析在如上示例中，證書是在帶有默認參數的Whisker實用程序中生成的。有關生成自簽名證書的過程的描述，請參閱此處。
Whisker試圖將其證書作為Microsoft Hello For Business證書（在程序生成的情況下，是一對密鑰）。但是，原始證書(當Windows PC獨立生成證書以使用此功能時)包含一個錯誤：CertIssuerName字段中的可分辨名稱（DA）表示法使用格式“CN=…”。攻擊者的工具包沒有此錯誤，這是可疑的。
第二和第三行可以與測試台的數據進行比較，但要在MDR產品系統中進行。
我們可以直接向Kibana添加一個Painless腳本，該腳本可以查找CertIssuerName和TargetAccountName之間不區分大小寫的匹配所導致的所有4768個事件。
有10個這樣的事件，它們都與Whisker實用程序的使用有關。
使用票證標誌搜索字段現在，讓我們考慮在任意時間間隔內測試台上的事件中的winlog.event_data.TicketOptionsDescription字段，在此期間，偽造和合法的TGT請求都會發生。
引人注目的是沒有名稱規範化標誌，這在Kerberos基礎設施中起著重要作用。問題是服務或帳戶可以有多個主名稱。例如，如果一台主機有多個名稱，那麼基於它的服務可能有多個服務主體名稱(Service Principal names, spn)。為了使客戶機不必為每個名稱請求票證，KDC可以在憑據檢索過程中向它提供映射信息。啟用名稱規範化標誌時請求此功能。理論上講，如果設置了“canonicalize”選項，KDC可以在響應和TGT中修改客戶端和服務器的名稱和SPN。但在發現的示例中，卻沒有類似標識，這很可疑。讓我們找到所有使用PKINIT(基於證書)請求但卻沒有此標識的票證。以下是研究人員根據卡巴斯基MDR產品數據創建的請求。
以上是Whisker + Rubeus在測試台(AD-Gam主機)上的活動(過去30天)以及在測試ADCS設置中的一組漏洞時所做的工作，我們將其合併為ADCS ESC或Certified Pre-Owned。此外，還有一個通過證書名稱過濾的誤報和一個發送到客戶端的事件。
讓我們看看Rubeus的例子，看看為什麼在票證請求中沒有設置名稱規範化標誌。
事實證明，Rubeus並不是故意進行這個操作的。同樣地，對於使用Kerberos的安全分析人員來說，Impacket是事實上的標準工具包。這就解釋了為什麼會出現上述可以現象。由於代碼的簡單性和流行性，這樣的實用程序非常多。
msDS-KeyCredentialLink屬性我們可以比較兩個屬性：一個是在Hello for Business配置期間合法設置的，另一個是由Whisker設置的。他們之間是有區別的。在比較這些屬性時，研究人員編寫了一個工具，可以讓你從非法屬性設置中找到該工件。
你可以在開發環境中下載並使用此實用程序，調試時，嘗試查找並比較“好”和“壞”屬性中的關鍵差異。
注意事項：
1.msDS-KeyCredentialLink屬性是否具有DeviceId（GUID格式）？如果是這樣，再加上域中沒有具有此ID的對象，那就很可疑了。如果存在這樣一個對象，並且它屬於Azure AD連接器，那麼這可能是一個正常情況；
2正常情況下，Flags字段不包含MFANotUsed，但在合法案件中通常是這樣；
3.KeyMaterial的長度不超過270字節；4.KeyApproximateLastLogonTimeStamp和KeyCreationTime幾乎相同。然而，這一參數不太可靠，最好不要使用。
總結上述攻擊雖然隱蔽性較強，但在使用偽造證書時可以被檢測到。通過本文介紹的基礎設施(理想情況下包括所有活動密鑰的列表)和監控將有助於安全專家進行防護。通過本文介紹的程序還能夠發現使用偽造證書的常見模式和攻擊結果，並簡化搜索過程。