几年来，不断有人利用NTLM中继了大量内容，以提升Windows网络中的特权。
在本文中，我们建议从impacket到已经很好的ntlmrelayx中添加对RPC协议的支持，并探索它提供的新渗透测试方法。
CVE-2020-1113
由于没有针对RPC协议的全局完整性验证要求，中间人攻击者可以将受害人的NTLM身份验证中继到通过RPC协议选择的目标。如果受害者在目标上具有管理特权，则攻击者可以在远程目标上执行代码，这个攻击是在一个完全打了补丁的Windows Server 2016域控制器上测试的。
Compass Security在2020年1月发现了此漏洞，并向Microsoft安全响应中心披露了该漏洞，并将其标识为CVE-2020-1113。
Microsoft在2020年5月星期二的更新中发布了此修复程序，实施的解决方案增加了Task Scheduler Service的完整性要求。不过，该方案不能解决RPC缺少全局完整性要求的问题。
NTLM中继101
下图给出了NTLM中继攻击的简化视图：
攻击者充当客户端的服务器，并充当服务器的客户端。他从客户端消息中提取NTLM身份验证块，并将其放入服务器的修改后的消息中，反之亦然。最后，他可以根据需要使用经过身份验证的会话。
为了使这种攻击奏效，攻击者就必须处于中间人的位置。这可以使用传统的欺骗技术(ARP，DNS，LLMNR和Netbios等)，或者通过一个错误或误用的特性(打印机错误、Juicy Potato等)触发到攻击者机器的连接来实现。
示例回顾
NTLM中继已在多种攻击中使用和重用：
1. 打印机错误：一种从Windows Server触发SMB连接的好方法(与不受约束的委托结合使用特别方便);
2. PrivExchange：或如何从拥有Exchange邮箱的任何用户升级为Domain Admins;
3. 断开MIC ：或如何完全绕过继电器保护。
这些攻击中继了以下协议：
SMB→SMB(打印机错误);
HTTP→LDAP(PrivExchange);
RPC的一些背景知识
定义
1. 远程过程调用(RPC)是指程序在其他地址空间(例如在另一台计算机上)中执行过程。
2. DCE / RPC是由Open Group设计的RPC协议标准;
3. MSRPC(aka MS-RPCE)是Microsoft的DCE / RPC的修改版本;
谁会使用RPC?
RPC用于远程系统管理，WMI基于DCOM，该DCOM使用RPC作为传输方式(有时通过SMB)：
1. 监控和远程管理工具支持WMI(快速搜索将提供例如Solarwinds，NetCrunch，PRTG，LanSweeper，Kaseya等)，并且必须配置特权服务帐户。
注意：此监控解决方案需要具有管理权限的凭据，一旦获取管理权限的凭据，此帐户将尝试连接到网络中的所有主机。
2. 系统管理员还可以使用WMI手动执行远程任务，可能使用特权帐户。
默认情况下，RPC用于Windows防火墙，因为它用于远程管理。
身份验证和完整性
安全服务提供商，依赖RPC的工具使用标准Windows安全提供程序进行身份验证，可能有以下值：
请注意，默认值为WINNT，这意味着NTLM身份验证通过。
认证级别
身份验证级别设置RPC交换中是否存在身份验证和完整性检查：
再次注意，默认值为CONNECT，这意味着没有完整性检查。
幸运的是，大多数基于RPC的协议都具有最低的安全要求(在Microsoft的每个协议文档的第2.1节中都有详细记录)：
MS-SAMR：服务器SHOULD
MS-LSAD：请求者不得使用RPC提供的安全支持提供程序机制(用于身份验证、授权、机密性或防篡改服务)。
不幸的是，其他一些具有较少的限制性要求：
MS-DCOM：服务器应注册[MS-RPCE] 2.2.1.1.7节中指定的一个或多个安全提供程序，安全提供者的选择取决于实现。
MS-TSCH：RPC服务器必须要求RPC_C_AUTHN_GSS_NEGOTIATE或RPC_C_AUTHN_WINNT授权。 RPC客户端必须使用[MS-RPCE] 2.2.1.1.8节中指定的RPC_C_AUTHN_LEVEL_PKT_PRIVACY(值= 6)身份验证级别。
攻击过程
MS-WMI使用MS-DCOM，它是一个很好的攻击载体。然而，由于典型的WMI代码执行需要对多个RPC接口进行身份验证，因此它不是NTLM中继攻击的最佳选择(没有重新身份验证方法)。
MS-TSCH是管理计划任务的协议，在atexec.py中使用，这是否意味着我们可以中继NTLM身份验证并使用预定的任务执行代码?当然是的。
我们修改后的impacket包含以下三个新组件：
1. RPCRelayServer响应传入RPC连接;
2. RPCRelayClient启动到目标的RPC连接;
3. RPCAttack(基于ATExec)在目标上执行代码;
PoC或GTFO
在我们的设置中，攻击者计算机具有IP 172.16.100.21，目标计算机DC是具有最新补丁程序版本的Windows Server 2016，并且具有IP 172.16.100.1。受害用户WINLAB \scooper-da在DC计算机的本地Administrators组中，并使用IP 172.16.100.14从该计算机打开一个SMB连接。
攻击者启动ntlmrelayx.py
攻击者将安装我们的自定义版本的impacket，并在其IP为172.16.100.21的主机上启动该工具，他想在目标172.16.100.1上添加本地管理员(名为compass)：
通过受害者触发连接
受害人从计算机172.16.100.14打开与攻击者计算机的SMB连接，这模仿了管理员使用前面提到的工具访问共享或执行管理任务：
- # net view \\172.16.100.21\noshare\
该工具将启动连接并进行中继，由于中继用户是目标计算机上的本地管理员，因此他有权添加我们的新管理员：
结果，将创建一个新用户并将其添加到本地Administrators组。
中继攻击的破坏力
测试了以下场景：
服务器端的SMB签名(在我们的测试中设置为必需，如默认的DC安装一样)可防止从RPC中继到SMB。在客户端，默认情况下不需要SMB签名，这可以成功中继到RPC。
一些有趣的用例
在对iOS数字取证和事件响应(DFIR)进行例行调查之后，研究人员发现了一些可疑事件，这些事件早在2018年1月就影响了iOS上的默认邮件应用程序。研究人员分析了这些事件，发现了一个影响苹果iphone和ipad的可利用漏洞。ZecOps在很长一段时间内，在企业用户、vip和mssp上检测到该漏洞的多个触发器。
该漏洞的攻击范围包括向受害者的邮箱发送自定义电子邮件，使其能够在iOS 12上的iOS MobileMail应用程序或在iOS 13上发送的邮件中触发该漏洞。
几乎没有可疑事件包括黑客通常使用的字符串(例如414141…4141)，经过确认，我们验证了这些字符串是由电子邮件发送者提供的。值得注意的是，尽管有证据显示证实了受攻击者的电子邮件是由受害者的iOS设备接收和处理的，但本应接收并存储在邮件服务器上的相应电子邮件却丢失了。因此，我们推断这些电子邮件可能已被有意删除。
我们知道从2018年1月开始在iOS 11.2.2上发生了多个触发事件，当前，攻击者可能正在滥用这些漏洞，详情请点此。在研究触发这些漏洞的过程中，我们已经看到一些可疑受害者之间的相似之处。
1.所有经过测试的iOS版本都容易受到攻击，包括iOS 13.4.1;2.根据我们的发现，这些漏洞都是在iOS 11.2.2或更高版本上主动触发的;3.iOS 6及更高版本容易受到攻击，iOS 6于2012年发布，iOS6之前的版本可能也会受到攻击，但我们尚未检查较早的版本。因为在iOS 6发行时，iPhone 5已上市。
漏洞详情
研究人员发现，MIME库中MFMutableData的实现缺少对系统调用ftruncate()的漏洞检查，该漏洞导致越界写入。我们还找到了一种无需等待系统调用ftruncate失败即可触发OOB-Write的方法。此外，我们发现了可以远程触发的堆溢出。众所周知，这两种漏洞都是可以远程触发的。OOB写入漏洞和堆溢出漏洞都是由于相同的漏洞而引发的，即未正确处理系统调用的返回值。远程漏洞可以在处理下载的电子邮件时触发，在这种情况下，电子邮件将无法完全下载到设备上。
受影响的库：/System/Library/PrivateFrameworks/MIME.framework/MIME;易受攻击的函数：-[MFMutableData appendBytes:length:]。
利用漏洞后的异常行为
除了手机邮件应用暂时放缓外，用户观察不到任何其他异常行为。在iOS 12上尝试利用漏洞(成功/失败)之后，用户只会注意到邮件应用程序突然崩溃。在iOS13上，除了暂时的速度下降之外，这不会引起注意。如果随后进行另一次攻击并删除电子邮件，则失败的攻击在iOS 13上不会明显。
在失败的攻击中，攻击者发送的电子邮件将显示消息：“此消息无内容。”
崩溃取证分析，用户经历的部分崩溃(多次崩溃中的一部分)如下;崩溃的指令是stnp x8，x9，[x3]，这意味着x8和x9的值已被写入x3并由于访问存储在x3中的无效地址0x000000013aa1c000而崩溃。
为了找出导致进程崩溃的原因，我们需要看一下MFMutableData的实现。
下面的调用树是从崩溃日志中提取的，只有选定的一些设备才会发生崩溃。通过分析MIME库，-[MFMutableData appendBytes:length:]的伪代码如下：在崩溃发生之前执行以下调用堆栈：如果数据大小达到阈值，则使用文件存储实际数据，当数据更改时，应相应更改映射文件的内容和大小，系统调用ftruncate()被inside -[MFMutableData _flushToDisk:capacity:]调用以调整映射文件的大小。ftruncate的帮助文档是这样说明的：如上所示，如果调用失败，则返回-1，并且全局变量errno指定漏洞。这意味着在某些情况下，此系统调用将无法截断文件并返回漏洞代码。但是，在ftruncate系统调用失败时，_flushToDisk无论如何都会继续，这意味着映射的文件大小不会扩展，执行最终会到达appendBytes()函数中的memmove()，从而导致mmap文件出现超出边界(OOB)的写入。
滥用用户帐户
使用最少的特权来进行渗透测试，对于安全专业人员来说是一个极大的挑战，所以管理员必须使用高权限帐户处理所有事情。
RPC→RPC：你从监控工具获得连接，并在其他主机上获得管理员访问权限。
滥用计算机帐户
有时(通常是在旧的Exchange服务器上)，一个计算机帐户是另一台计算机的管理员。
此BloodHound捕获显示了一个常见的情况，即用一个计算机账户管理给其他计算机。
RPC→RPC：如果你在受害计算机上具有低特权会话，则可以使用RottenPotato触发与攻击者计算机的RPC连接并将其中继到目标。
SMB→RPC：受害者计算机如果激活后台处理程序服务，你可以使用打印机错误触发与攻击者计算机的SMB连接，并将其中继到目标。
编码
我们将于6月中旬将对impacket的修改推送到以下GitHub存储库，请你注意查看：
https://github.com/CompassSecurity/impacket
缓解措施
此攻击依赖于几个漏洞，CVE-2020-1113只是其中之一。以下是一些解决潜在漏洞的缓解措施：
1. 及时修补你的Windows!
2. 通过GPO对整个网络中的客户端和服务器强制执行数据包签名;
3. 检查你的Active Directory ACL：应该使用最小特权原则;
4. 网络分段可以帮助防止中继攻击。
5. 立即停止使用NTLM。
以下想法可以改善ntlmrelayx中对RPC的支持：
1. 支持会话重用：RPC攻击目前只有一次机会，不能像SMB那样通过socks代理保存和重用会话。
2. 开发更多的RPC攻击：使用未经分析的MS-DCOM，MS-WMI或其他协议，有可能使攻击的工作范围超出CVE-2020-1113。
3. 支持更多的RPC接口：某些客户端将在身份验证之前执行未经身份验证的RPC调用。 PoC目前仅支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。
可以找到其他向量来获得传入的RPC连接：
Remote Juicy Potato：在“打印机错误”的线索中发现一个错误会很有趣，该错误会触发通过RPC远程验证到给定主机的调用。
