防护神器Mimikatz对域环境进行渗透的分析

0×00 前言

 

攻击与防御是信息安全中永恒不变的两个话题，在内网安全管理中，如何提升安全防护的等级，即使是刚刚接触安全管理的人也能说出大堆的理论和实践方案，但是有时候你认为理所当然的做法，在实践中却很难推广。

 

原因是在一般企业中，安全管理部门大多数情况下都不能强硬的推销自己的方案，要想实施一套解决方案，不仅需要有理论和最佳实践的支撑，同时需要向安全知识相对薄弱的相关人员证明如果不遵守最佳实践【的确，而非仅仅是可能】可以带来严重的后果，从而说服相关人员能够按照安全部门的思路加强自身的安全管理。

 

在域环境安全渗透测试中，如果能够获取域控系统的最高权限，通常会被认为是最有利的证据。

 

为了实现以上目标，最直接、有效的办法就是找到具有AD管理员权限的账号密码信息。而这时大家首先想到的通常是神器Mimikatz，配合一些小技巧，不需要依赖漏洞提权，只要管理稍微有所松懈，黑客在内网中就可如入无人之境。

 

只要具备某系统管理员权限，在主机中运行Mimikatz就可以直接获取到当前主机中用户的账号密码。

 

如果顺利的话，最终获取到AD管理员账号权限似乎并非难事，那么接下来需要考虑的就是如何利用内网中的风险点，让我们的Mimi可以顺利执行。

 

0×01 可利用的风险点

 

林林总总，内部网络中常见的风险点很多，这里也不准备一一罗列，仅仅列出几个非常常见的、而又足以导致内部系统可以在非常短的时间内沦陷的问题：

账号风险：一般企业中，管理员与弱口令用户的斗争，暂时还看不到终点；

网络风险：很多企业都提供了VPN等途径允许用户远程接入内部网络；内部网络中的访问控制措施不足；

权限分配：为了使用方便，给普通用户授予了本地办公机、甚至服务器的管理员权限；

运维账号：运维管理员使用个人办公账号管理线上服务器、测试服务器；同一管理员同时具备多台服务器管理权限；同一服务器有多个管理员具备管理权限；

系统更新：由于缺乏统一管理，或因所谓影响业务等原因，对服务器补丁更新不够及时；

安全软件：同样基于所谓影响业务等原因，很多服务器未安装任何安全软件；

配置缺陷：如默认服务未关闭、无用服务开启等；

 

0×02 思路

 

域环境中最常见的情况就是：

 

运维账号：运维管理员使用个人办公账号管理线上服务器、测试服务器；同一管理员同时具备多台服务器管理权限；同一服务器有多个管理员具备管理权限；

 

 

 

 

 而我们的思路也正基于此：

 

通过普通User账户A出发，找到User账户可管理的设备A1、A2……，

 

通过A1、A2……挖掘到User账号B、C……，及其可管理的设备B1、B2……，C1、C2……

 

再进一步挖掘，直至获取到管理员Admin账号；

 

当然，在挖掘过程中为了更加有针对性、更加节省时间，我们可以通过对已有账户社工等方式采集更多有效信息加以利用，同时，如已经获得内网域账号，也可采用手机域内组信息、域管理员信息的方式更加有针对性的进行账号挖掘;我们可以优先挑选管理员、研发、测试、高管等可能具备高权限的账号加入到我们的测试字典中。

 

获取域管理员信息：

 

net group “domainadmins” /domain 

 

寻找可用的组\账户：

 

net group /domain

 

net users  /domain

 

 

 

 

0×03 执行

 

根据上述思路，开始进行渗透工作。本文描述的情况基于一个假设，我们已经获取到一个可以登录目标企业内网、访问内部资源的普通user账号；

 

第一步：

根据已知账号口令、常见弱口令生成账号密码字典，本例中使用CrackMapExec工具进行自动测试，可按照domain\user:pass格式生成字典；根据验证，事实上并不需要太过于庞大的字典。

 

第二步：

利用密码字典，探测可能获取管理员权限的系统；这里利用扫描工具，探测利用密码字典可访问的Windows共享服务。原因是默认共享通常在较多的系统中并未关闭，同时基于我们的假设：可能存在同一设备具备多个管理员、或者同一管理员管理多台设备的情况。

 

crackmapexec.py IPRANGE-C /wordlist/dict –shares

 

很快，扫描有了结果：

 

 

 

 

第三步：

invoke-Mimikatz.ps1脚本是大家使用比较多的脚本，利用它可以通过远程执行Mimikatz的方式尝试Dump用户凭据。在本文中我们同样利用CrackMapExec工具执行：

 

crackmapexec.py IP-C  /wordlist/dict –mimikatz

 

可以看到通过10.X.X.52又获取到了一个新的用户账号密码。

 

 

 

 

 

 

 

第四步：

利用以上思路继续重复尝试，不断将新获得的用户名密码加入字典中，最终可获取到所需的权限。同时，即使没有能够获取到管理员权限，通过这些账号密码已经足够挖掘出企业内部大量敏感信息。

 

0×04 防御措施验证

 

在企业内网安全管理中，证明了问题存在不是一件值得高兴的事情，我们的问题才刚刚开始，找到有效的防御办法并付诸实施才是我们的最终目的。

 

关于神器Mimikatz如何防御的文章很多，但是防御效果究竟如何，因为缺乏实际验证，一直没有可信的解决方案提供给公司IT人员使用。

 

Freebuf《如何防御“神器”Mimikatz窃取系统密码？》http://www.freebuf.com/tools/96209.html一文相对较为全面的介绍了几种解决方案。本文有针对性的进行了验证，对于其中遇到的问题也一一列出。

 

第一：

Active Directory 2012 R2功能级别，将用户加入受保护的用户组(ProtectedUsers)。

 

按照此方法操作：找到users中的Protected Users，将需要保护的用户加入到受保护用户组中：

 

 

 

 

用此用户登录服务器，已经不能抓取此用户的密码：

 

 

 

 

用此用户登录客户机，当客户机未联网时，将不能使用域账号登录

 

 

 

系统联网后可以正常登录；

 

 

 

 

结论：Protected Users组对保护少量一直处于联网状态的AD等服务器管理员账号是有效的，但用来保护普通用户存在一定的局限。

 

第二步：安装KB2871997

 

针对非2012 R2等服务器，文中提供的另一种保护方法是，安装KB2871997更新，并修改注册表。

 

经过检查确，由于本例中测试的用户已经加入Protected Users，可以看到再已安装KB2871997补丁后，Win7等系统中即刻可以实现如下效果，用户密码已经不能被抓取到：

 

 

 

 

第三步：

去除内存中的存储空间

 

针对未加入Protected User组中的用户，通过安装补丁，并修改注册表：

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

 

中建立UseLogonCredential，并设置值为0达到防护的效果。

 

 

 

 

正当我们认为已经可以成功防御Mimikatz神器的时候，情况突然发生了变化，客户机中的Outlook登录后，再次执行sekurlsa::logonpasswords，发现仍可以利用MS OUTLOOK获取用户名和密码，无论是否加入受保护的用户组中、是否安装补丁、修改注册表。上述防护措施失效。

 

0×05总结

上述防护方案针对AD功能级别升级到2012、更新了系统补丁、加入了受保护用户组(Protected Users)的账号是可以起到一定的防护作用的。

但是该账户的使用必须受到严格的限制，不应同时管理多台服务器、或者同时作为员工个人办公账号使用，否则保护仍将失效。同时办公机脱离域环境的使用也将受到限制。

基于前两点，不建议将个人办公账号加入受保护用户组(Protected Users)。

只有实施全面的安全管理措施，才能真正的降低安全风险，至少需要针对0×01中提到风险点实施控制措施，具体实现不再一一赘述。