文章 - 缓解Mimikatz风格攻击

前言

如果你像我一样，在渗透测试的某些时候，你在Windows主机上获得了一个session，你也许有机会从该主机dump下账号密码。通常会使用Mimikatz。在原始的版本，Mimikatz从lsass.exe 进程中直接获取凭证（明文或Hash值），经过发展，现在它已经衍生出几个不同的攻击向量。然后，攻击者可以使用这些凭据为“中心点”攻击同网络中的其他资源 ——这通常被称为“横向移动”，其实在大多数情况下，你实际上在“向上移动”到基础设施中更具价值的目标。

后卫/蓝色队员（或蓝队经理）也许会说“这听起来像是恶意软件，难道这不是Antivirus （译者注：防病毒软件）吗？”。有点可惜，只说对了一半—— 恶意软件的确也使用这种攻击方式。例如，Emotet就是这样，它一旦获得凭据和持久访问，通常会将权限传递给其他恶意软件（例如TrickBot或Ryuk）。可悲的是，绕过AV检测已经不是什么难题了，有很多有名的姿势可以绕过AV使用 Mimikatz，BHIS博客做了一些概述：https://www.blackhillsinfosec.com/bypass-anti-virus-run-mimikatz/

那么针对Mimikatz，Windows官方有哪些缓解措施呢？让我们回到最初，当Mimikatz第一次出现时，微软推出了KBKB2871997（在2014年，Windows 7时代的主机）来防御它。
https://support.microsoft.com/en-us/help/2871997/microsoft-security-advisory-update-to-improve-credentials-protection-a

从那时起，这种保护已集成到Windows 8.x，Windows 10和Server 2016+中。

然而即使应用了补丁后，凭据仍然存储在内存中。你仍然需要更改注册表项来禁用此行为：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
UseLogonCredential set 0 （再次说明，这是针对windows7或xp系统）

然而，你会发现这些保护只能防御初始的向量。Mimikatz和微软正在进行一场“猫捉老鼠”游戏，因为Mimikatz的每次更新会有新的攻击向量出现。

SMBv1

如果你启用了SMBv1或未签名的连接，那么有比Mimikatz更加简单地工具去欺骗域控制器 ——简单地说，当你在某个内部网络拿下一台主机后，你只需使用Responder（译者注：kali上的一个嗅探/欺骗工具）：

扫描仍支持SMBv1的主机并采取操作(https://isc.sans.edu/forums/diary/Rooting+Out+Hosts+that+Support+Older+Samba+Versions/22672/)
使用GPO全局禁用SMBv1(https://blogs.technet.microsoft.com/staysafe/2017/05/17/disable-smb-v1-in-managed-environments-with-ad-group-policy/)

指定SMB连接地签名可以缓解Responder风格的攻击：https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always

Mimikatz特定防御

更新Windows服务器上的操作系统

我们经常可以见到原始时代的Server 2008，Windows 7，甚至是Server 2003和XP（在某些情况下是Server 2000！）。不必多言，更新的确更好，较新的Windows Server操作系统具有更好的安全性。如果它不会服务器服务器应用程序正常运行，请更新到Windows Server 2016和Windows 10（如果你足够勇敢，请更新到2019年版本！）

更新活动目录的功能级别

这里重申了第一点。你的活动目录功能级别应当设置成现代版本，否则我们在本文后面讨论的许多企业保护都无法实现。如果你可以更新，请尽可能将活动目录版本提升至2016年以上！

禁用所有服务器和工作站上本地管理员的调试权限

这是一种较新的攻击向量——Windows的“调试模式”，允许你绕过其许多本机保护。它主要是用来解决设备驱动程序和其他操作系统或低级应用程序组件之类的问题。
如果你的主机中有开发人员，他们肯定会反对。问题是只有在运行“真正的”调试器（如IDA）并且正在执行如在已编译的二进制代码中设置断点之类的情况下才会用到这个权限，更常见的更高级语言则不需要这个权限了。像法医一样，调查员们确实需要这些权利，但如果他们想要在他们的域成员工作站上获得这些权利，他们就要回到法医学校去获取。
单独的主机如需禁用此设置，请从MSConfig转到“引导/高级选项”，然后禁用“调试”。较新的操作系统会默认设置。
在组策略中，请到安全设置/本地策略/用户权限分配/调试程序禁用它。
默认情况下是没有配置的。你需要不添加任何用户或组（或仅添加真正需要的组，或者不需要它但必须开启的）

全面禁用WDigest协议

该协议是在XP时代推出的，用于透明的HTTP身份验证，而且在所有的Windows 7/Server 2008主机中仍默认启用。它在Windows 8及更高版本中则默认禁用。

关闭它，请在注册表编辑器中转到HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest ，这里UserLogonCredential和Negotiate的值设置为0（请注意，Server 2016+和Windows 10中不存在“ UseLoginCredential ”）

你还可以添加一些注册表项监视功能，用来检测攻击者是否更改了这些设置。

启用LSA保护（RunAsPPL注册表项）

启用它可以保护LSASS进程使用的内存。要启用此功能，请在注册表中转到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA 设置RunAsPPL为1

风险：因为它试图保护LSASS进程时可能会影响其他组件工作。这是第一个有风险的缓解措施。
缓解该风险：幸运的是，你可以提前部署一些Microsoft的审计设置，用来评估你的操作存在的风险。有关这方面的更多详细信息以及一般设置在这里有：https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

禁用活动目录中的纯文本密码存储

有时，Micosoft会存在一些落后兼容性的东西。比如说“可逆加密”设置选项。回到古时（Windows 2000时代），人们可以利用它破解密钥，当时主要是为了让RADIUS（译者注：远端用户拨入验证服务）工作（当时的IAS，现在是NPS）。遗憾的是，这个设置在今天仍然存在，你可以使用它快速破解获得明文密码。

要禁用此功能，请在组策略中转至：Computer Configuration/Security Settings/Account Policies/Password Policy 把Store Passwords using reversible encryption关闭。

此设置也可在ADAC（活动目录管理控制台）的“细粒度密码策略”部分中操作，在这里请清除该复选框

关于攻击的细节：https://www.blackhillsinfosec.com/your-password-is-wait-for-it-not-always-encrypted/

启用受限制的管理模式

在注册表项中设置DisableRestrictedAdmin和DisableRestrictedAdminOutboundCreds

这可以把你的RDP会话设置为不将凭证存储在主机的内存中。要在受限制的管理模式下启动会话，请按以下方式运行RDP会话：mstsc/restrictedadmin/v:targethost

请注意，你的凭据不会被缓存，因此从RDP会话中你将不能用缓存的凭据“横向移动”到另一台主机。例如，你将无法运行服务器管理器，WMIC，PSRemoting或任何其他活动目录管理工具，你的连接行为将被监视。这是一件好事，因为如果你能突破它，你将会失去保护（oops）

使用注册表项实现：

在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa中设置DWORD值DisableRestrictedAdmin为0。这样就启用了受限模式（默认情况下关闭）

或者在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa中创建一个DWORD值DisableRestrictedAdminOutboundCreds：

此时默认不为0，AdminOutboundCreds是开启的
设置为1，即可关闭AdminOutboundCreds

通过组策略启用限制对远程服务器的凭据委派

这将为GPO范围内的域成员发起的所有RDP会话默认设置为“受限制的管理模式”。这种方法的效果通常优于前面所述的注册表设置。

GPO设置如下：

Computer Configurations > Policies > Administrative Templates > System > Credential Delegation然后把Restrict Delegation of credential to remote servers设置为开启并且Require Restricted Admin。

RDP会话强制开启NLA（网络级别身份验证）

在RDP会话建立之前，NLA会强制通过TLS（译者注：传输层安全性协议）进行RDP身份验证（通过名为CredSSP的控制器）。那么，这个设置并不能减轻Mimikatz本身的影响，因为Mimikatz攻击通常是针对本地计算机。这个设置更像是“防止密码嗅探线路”，所以它可以抵御Responder这一类的攻击。但是，此设置通常会与受限制的管理模式和受保护的用户组一起部署（参阅下面的内容）。

在组策略中强制执行此操作：

服务器：
Computer Configuration/Policies/Administrative Templates/ Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security Enable :开启后将使用网络级别身份验证对远程连接用户进行身份验证。

客户端：Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Connection Client Enable:在客户端配置中，还需要在下拉菜单中选择“如果身份验证失败，请不要连接”。

禁用密码缓存

默认情况下，Windows会缓存最后几次的认证凭据（包括密码哈希值），以防域控制器失效。你可以在以下组策略中禁用此功能：
Computer Configuration -> Windows Settings -> Local Policy -> Security Options -> Interactive Logon:设置要缓存的先前登录次数 - > 0

请注意，如果笔记本电脑的用户需要在离开办公室后使用，这可能会造成一些影响。你可以再VPN客户端设置登陆前强制建立VPN连接，然而如果你要输入WiFi密码，那么这一定会让你头疼。通常可以绑定手机的热点来缓解影响，你还需要实施政策和技术控制中禁止使用公共热点，如酒店或咖啡店WiFi。这是一种简单有效的缓解措施，但需要提前进行一些操作才能发挥作用。

开启Kerberos身份验证

你需要将管理帐户放在“受保护的用户”AD组中，才能开启该验证。

这里有两个关于该主题的“入门”MS文档，开启该保护前请务必先阅读其中之一！
https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to-configure-protected-accounts

MS文档影响概述：
1、已登录到Windows 8.1（或更新版本）以及Windows Server 2012 R2（或更新版本）主机的受保护用户组的成员请注意：

默认凭据委派（CredSSP）：即使委派默认凭据策略是开启的，也不会缓存明文凭据。
Windows摘要：即使启用了缓存明文凭证，也不会缓存。
NTLM ：NTOWF不在缓存
Kerberos长期密钥：登录时会Kerberos要求票据换取票据（TGT），但不会自动重新获取它。
登录离线后：缓存登陆验证不可用

2、如果域功能级别是Windows Server 2012 R2（或更高版本），则该组的成员请注意：

不能使用NTLM身份验证进行验证
在Kerberos预身份验证中不能使用数据加密标准（DES）或RC4密码套件
无法使用如何的委派
无法在4个小时的用户票证（TGTs）失效后再次刷新

总结一下，上述操作可以禁用大多数密码缓存，强制Kerberos身份验证，并禁用DES和RC4密码。
请注意，为服务器或工作站设置此组成员资格将产生一些无法预知的影响（在开始处理此文档之前，请阅读这些MS文档），所以这仅适用于个人帐户。

凭证卫士

顾名思义，它将保护你的凭据。

本质上，如今的CPU将使用固有的虚拟化功能来保护凭据。虽然LSA进程继续在“用户”的内存中运行，但进程本身不再直接存储凭证，它将这些凭据存储在受虚拟化保护的内存中，使用名为“Virtual Secure Mode”的进程存储在另一个“国中国”中。相关过程被称为“LSA Secure Mode”。正如微软说的那样（https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/）， LSA和LSA Secure Mode都是被同一个Hypervisor管理的“虚拟程序”。

凭据卫士的配置有些复杂，下面是一些重点：

安装Windows功能“Hyper-V Hypervisor”和“隔离用户模式”（不需要Hyper-V）
Windows 10 v1607及更高版本中不需它
在组策略中，启用“打开基于虚拟化的安全性”，在该选项中，打开“启用基于虚拟化的代码完整性保护 ”中的“安全启动”。
同样的，在GPO中转到“Computer Configuration/Administrative Templates/System/ Device Guard”，启用“Deploy Code Integrity”。
请注意，你的的CPU需要支持Intel VT或AMD V，并且你需要使用UEFI启动。系统尽可能将使用TPM来保护凭据，除了“基于虚拟化的安全性（VBS）使用TPM保护密钥”之外，这似乎没有很大作用。（如果你有这方面的经验https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-considerations，请联系我！）

我们提到过这是否像是像军备竞赛？在2018年9月，Mimikatz宣布已绕过这种保护措施。在此之前，它是直接从内存中获取hash，mimikatz的绕过仅仅是在传输散列到受保护的内存区域之前盗取凭证。我希望将来Mimikatz可以在使用虚拟化技术总结从LSA安全模式内存空间中获取凭据。因为LSA需要接触到凭据，所以我确信微软已经有API可以实现完全保护（这个API似乎可以访问任何东西）。让我们继续关注，因为卫士和攻击者会继续博弈！

给特定的站点或服务器设置独立的管理员

同样，这个也不能拦截Mimikatz从机器上窃取凭证，它可以做的是防止使用这些凭证横向移动到其他主机，这通常是攻击的终极目标。

在活动目录管理中心（ADAC）的“身份验证策略”选项，可以将服务帐户“固定”到运行该服务的主机。这意味着即使成功获得凭证（使用Mimikatz或其他方法），该帐户（可能是某个特权）也不能轻易导致横向移动。

为管理员和服务帐户设置长而复杂的密码

Mimikatz攻击方法总是在更新。我还没有介绍在实例服务中使用Kerberoasting提取密码的哈希值，这个故事是关于蓝队（捍卫者）比红队（袭击者）更多的情况，请敬请期待，我们将在那里进行攻击。
许多Mimikatz攻击向量都是为了提取密码哈希。你还可以直接爆破获取哈希值，但如果密码是冗长和复杂的（我通常设置服务密码到16个或32个或更多的随机字符），那么破解密码的成本会非常高。使用短语或者简单单词组成密码很难说是错误的，比如“L33tspeak”，它只会延长一点攻击时间。密码长度是最重要的衡量标准，不使用有意义的单词可以让许多黑客删除破解密码的“快捷方式”。请注意，这也是一场军备竞赛，因为GPU硬件影响了“破解成本高昂多少？” ，答案是非常高。

其他防御措施

还可以通过检索一些日志条目来检测Mimikatz，但这非常复杂。我可能会在以后的文章中谈到它。如果没有人限制我，我将来也会介绍一些Mimikatz攻击情景 :-)

小结

从上述内容可以看到，Mimikatz和微软之间过去和将来存在长时间的博弈。我已经介绍完了内容，虽然这只是一个比较完整的“低级”缓解方法，但你应该还是有一些收获。一个坚毅的攻击者可能仍然可以“完成攻击”，但是如果我们实施上述操作或许可以加大进攻难度。不要惊讶，因为使用Mimikatz的自动化恶意软件非常少。如果在几个月里没有曝光新攻击面，我也觉得正常，因为微软会有新的防御。

说也说完了，我还是没有找到一个完全实现了上面的所有内容的AD域。我测试的大多数AD域在实际工作中仍然使用Server 2003或Windows 7（甚至是Server 2000！），因此上面的一些操作没有实际生产环境来检验。

翻译来源：