一、前言
2018年1月24日,Benjamin Delpy和Vincent Le Toux这两名安全研究人员在BlueHat IL安全会议期间公布了针对活动目录(AD,Active Directory)基础架构的一种新型攻击技术:DCShadow。利用这种技术,具有适当权限的攻击者可以创建恶意域控制器,将恶意对象复制到正在运行的Active Directory基础架构中。
在本文中我们会介绍这种攻击方法所依赖的基础技术,顺便讨论其对现有AD基础架构所造成的安全影响。最后,我们也会分析红蓝对抗中蓝队如何检测这类攻击活动。
二、DCShadow的创新点
红队或者攻击者之所以想突破AD基础架构,主要是想在不引起安全检测告警的情况下获取用户及主机凭据。
为了实现这一目标,随着时间的推移,人们开发出了多种攻击技术,如LSASS注入、滥用Shadow Copy功能、解析NTFS卷、ESENT操作、敏感属性操作等。大家可以访问ADSecurity.org了解更多细节,这个网站已经归纳的非常好了。
在这些攻击方法中,有一种方法与DCShadow攻击有关。DCSync攻击方法于2015年推出,这种攻击需要依靠域管理员(Domain Admins)或者域控制器(Domain Controllers)组中的成员实现对域控制器(DC)的数据复制操作(为了完成这一任务,攻击者需要掌握GetChangeAll权限,默认情况下管理员账户以及DC都具备该权限)。实际上,根据MS-DRSR规范中关于域控制器数据复制的描述,这些组可以通过GetNCChanges RPC向DC请求复制AD对象(包括用户凭据信息)。大家可以阅读ADSecurity.org上的这篇文章了解更多攻击细节。
图1. 使用mimikatz工具发起DCSync攻击
DCSync攻击也有不足之处,比如攻击者无法在目标AD域中注入新的对象。当然,攻击者依然可以使用Pass-The-Hash(哈希传递)技术接管管理员账户,然后再注入对象,但这个过程更加麻烦、步骤繁琐,因此蓝队很有可能会捕捉到这个攻击行为。DCShadow攻击方法对DCSync做了些改进,因此能够弥补这些缺点。
在DCShadow攻击中,攻击者无需复制数据,只需要在目标基础架构中注册新的域控制器,以便注入AD对象或者修改已有的对象(替换该对象的属性内容)。使用恶意域控制器并不是一个新的点子,人们之前已经多次提到过这种方法,但这些方法需要较“粗鲁”的一些技术的配合(比如安装Windows Server虚拟机),同时还需要登录到正常的域控制器上以便虚拟机能升级为目标域的DC,这些方法并不是特别理想。
图2. 升级为DC过程中生成的日志事件
为了理解DCShadow背后的天才想法,我们需要理解DC到底是什么,以及DC在AD基础架构中具体的注册过程。
三、域控制器(DC)
根据MS-ADTS(Active Directory Technical Specification,活动目录技术规范)中的描述,AD是依赖于某些专用服务的一种multi-master(多主)架构。其中,DC负责托管与AD对象有关的数据,你可以将DC看成一种服务或者提供该服务的服务器。多个DC之间可以协同工作,以确保在本地对AD对象的修改能正确同步到所有的DC上。
当DC以RW DC角色运行时, DC中包含域配置(Configuration)的完整命名上下文(naming context,NC)副本、schema(架构)、以及该域对应的森林(forest)的一个域名上下文。这样一来,每个RW DC就会拥有域的所有对象,包括凭据数据以及各种秘密数据(如私钥或者会话密钥)。因此在红蓝对抗中,是个人都知道DC是蓝队应重点保护唯一元素(有各种方法可以访问DC,管理员账户或者权限只是其中的两种方式)。
四、DC所提供的服务
如果我们从技术原理角度详细描述DC,这个过程可能会比较复杂,对理解DCShadow攻击而言帮助不大。简单起见,如果某台服务器可以提供如下4个关键组件,那么我们就可以称之为域控制器:
1、能够复制自身信息的一个数据库引擎(也就是说,我们可以通过LDAP协议访问该数据库,并且该数据库实现了符合MS-DRSR以及MS-ADTS规范的几种RPC)。
2、可以通过Kerberos、NTLM、Netlogon或者WDigest协议访问的身份认证服务器。
4、支持认证的DNS服务器(可选),客户端可以通过该服务器来定位相关资源。
图3. DC提供的各种服务
五、活动目录复制
除了这些服务外,我们的域控制器必须在目录基础架构中注册,以便另一个DC将其当成支持数据复制的一台源服务器。NTDS服务上运行着名为Knowledge Consistency Checker(KCC,知识一致性检查)的一个进程,可以完成数据复制任务。
KCC的主要功能是生成并维护站点内复制以及站点间复制的拓扑。也就是说,KCC进程可以决定DC之间的链接关系,以创建有效的复制过程。对于站点内复制,每个KCC会生成自己的复制链接。对于站点间复制,每个站点上的KCC会生成所有的复制链接。这两种复制模式如下图所示:
图4. 两类复制过程
默认情况下,每隔15分钟KCC就会启动AD复制拓扑的绘制过程,以实现一致性和定时传播。KCC通过每个AD对象所关联的USN来识别活动目录中出现的改动,确保复制拓扑中不会出现被孤立的域控制器。有趣的是,在这之前Windows可能已经通过RPC(如DrsAddEntry)或者SMTP(仅适用于Schema以及Configuration)完成AD复制过程。
图5. 注册表中关于复制时间间隔的键值
为了将新的服务器注入复制拓扑中,DCShadow背后的研究人员做了许多工作,其中最关键的就是成功识别出完成该任务所需的最少改动,这样就可以滥用这一过程,悄悄实现恶意信息的注入。
六、DCShadow的工作过程
DCShadow攻击的目的是注册一个新的域控制器,实现恶意AD对象的注入,以便创建后门或者获取各种类型的非法访问渠道及权限。为了实现这一目标,DCShadow攻击必须修改目标AD基础架构的数据库,授权恶意服务器成为复制过程中的一员。
6.1 注册新的域控制器
根据 MS-ADTS规范中的描述,AD数据库中使用nTDSDSA类的对象来表示域控制器,该对象始终位于域的配置(configuration)命名上下文中。更确切地说,每个DC都存储在站点容器内(objectclass为sitesContainer),是server对象的子节点。
图6. 蓝色框中为存储NTDS-DSA对象的容器,红色框中为NTDS-DSA对象
经过简单查看,我们发现NTDS-DSA对象只能是server对象的子对象,而server对象只能是organization或者server对象的子对象:
1、server对象只能存储在serversContainer对象中,而后者只能在Configuration NC中找到。
2、organization对象只能存放在locality、country或者domainDNS对象中,这些对象可以在域的NC中找到。
图7. 可以创建ntds-dsa对象的位置
这样一来,域控制器(nTDSDSA对象)只能在Configuration或者Domain NC中创建。在实际环境中,貌似只有站点容器(sitesContainer对象)中会存储nTDSDSA对象。由于KCC依靠站点信息来计算复制拓扑,因此只使用这些对象也符合常理。需要注意的是,我们无法使用LDAP协议来创建nTDSDSA对象。
说到这里你可能已经猜到,DCShadow攻击的主要步骤是在schema的Configuration区中创建一个新的server及nTDSDSA对象。做到这一点后,攻击者就可以生成恶意复制数据,并将这些数据注入到其他域控制器中。
知道DCShadow攻击的操作过程后,我们需要理解具备哪种权限才能在Configuration区中创建nTDSDSA对象。快速查看权限方面信息后,我们发现只有BUILTINAdministrators、DOMAINDomain Admins、 DOMAINEnterprise Admins以及NT AUTHORITYSYSTEM具备目标容器的控制权限。
图8. Server对象的默认访问权限
因此我们可以得出一个结论:DCShadow攻击技术并不属于权限提升漏洞范畴,而是滥用活动目录的一种机制。红队无法借此获得特权,但可以将其当成另一种方法,在活动目录中的达成持久化目标或者执行非法操作。因此,我们可以将其归类到AD持久化技术中,而非需要修复的漏洞。
6.2 信任新的域控制器
如前文所述,DCShadow攻击需要在Configuration区中添加新的nTDSDSA对象,以将其注册为复制过程中的新成员。然而,单单添加这个对象并不足以让我们的恶意服务器启动复制过程。实际上,为了成为复制过程的一员,我们需要满足两个前提条件:
1、被其他服务器信任,也就是说我们需要拥有有效的身份认证凭据。
2、支持身份认证,以便需要复制数据时其他DC能够连接到我们的恶意服务器。
恶意服务器可以通过有效的计算机账户成为可信的AD服务器。Kerberos SPN属性可以为其他DC提供身份认证支持。因此,每个nTDSDSA对象会通过serverReference属性链接到computer对象。
图9. serverReference属性可以充当nTDSDSA对象及其对应的computer对象的桥梁
虽然理论上我们有可能使用用户账户完成这个任务,但使用计算机账户貌似更加方便,也更为隐蔽。事实上,利用这种方法我们可以实现服务器在DNS环境中的自动注册(这样其他DC就可以定位到我们的资源)、自动设置所需的属性以及自动管理身份认证秘钥。
这样一来,DCShadow就可以使用合法的计算机账户通过其他DC的身份认证。虽然computer对象以及nTDSDSA对象同样可以帮我们通过其他DC的身份认证,但我们还是需要让其他DC连接到恶意服务器,从该服务器上复制恶意信息。
我们可以使用Kerveros Service Principal Name(SPN,服务主体名称)来满足最后一个条件。许多文章中已经介绍过SPN方面的内容,Kerberos服务(KDC)需要使用SPN所关联的计算机账户来加密Kerberos票据。对我们而言,DCShadow可以在合法的computer对象上添加SPN,以通过身份认证。
在这方面工作上,Benjamin Delpy以及Vincent Le Toux发挥了非常关键的作用,他们找到了复制过程中所需的最小SPN集合。根据他们的研究成果,我们只需要两个SPN就可以让其他DC连接到恶意服务器:
1、DRS服务类(非常有名的GUID:E3514235–4B06–11D1-AB04–00C04FC2DCD2);
2、Global Catalog服务类(包含“GC”字符串)。
比如,我们的恶意服务器(在alsid.corp域中DSA GUID为8515DDE8–1CE8–44E5–9C34–8A187C454208的roguedc)所需的两个SPN如下所示:
E3514235–4B06–11D1-AB04–00C04FC2DCD2/8515DDE8–1CE8–44E5–9C34–8A187C454208/alsid.corp
GC/roguedc.alsid.corp/alsid.corp
图10. 带有DC SPN的恶意计算机账户
发起攻击时,DCShadow会将这两个SPN设置为目标计算机账户。更确切地说,DCShadow会使用DRSAddEntry RPC函数来设置这两个SPN(大家可以参考CreateNtdsDsa的函数文档,下文中会进一步介绍MS-DRSR RPC的更多细节)。
现在我们可以将恶意域控制器注册到复制过程中,也能通过其他DC的身份认证。接下来我们需要让DC使用我们提供的恶意数据启动复制过程。
6.3 注入恶意对象
经过前期的准备,我们已经收集到了完成复制过程中注册任务所需的所有信息,接下来我们来看一下DCShadow如何将恶意信息注入到DNS基础架构中。
根据 MS-DRSR规范中的描述,为了提供恶意数据,恶意域控制器必须实现某些RPC函数,即:IDL_DRSBind、IDL_DRSUnbind、IDL_DRSGetNCChanges以及IDL_DRSUpdateRefs。微软在公开规范文档中提供了这类IDL函数,现在Benjamin Delpy开发的Mimikatz工具中已经集成了这些函数。
DCShadow攻击的最后一个步骤就是启动复制过程。为了完成这一任务,我们可以采用如下两种策略:
1、等待其他DC上的KCC进程来启动复制过程(需要15分钟的延迟);
2、调用DRSReplicaAdd RPC函数启动复制过程。这样可以修改repsTo属性的内容,马上启动数据复制过程。
图11. MS-DRSR规范中有关DRSReplicaAdd IDL的描述
使用IDL_DRSReplicaAdd RPC发起复制过程是DCShadow攻击的最后一个步骤,这样我们就可以将任意数据注入到目标AD基础架构中。完成该任务后,想在域环境中添加任何后门就易如反掌(比如在管理员组中添加新成员,或者在可控用户账户上设置SID历史记录)。
6.4 整体过程
DCShadow整体攻击过程如下图所示。
图12. DCShadow攻击过程
七、DCShadow对蓝队策略的影响
根据有关研究报告的说法,负责AD安全监管的蓝队通常需要收集相关事件日志,他们可以配置域内主机,将主机的日志推送到中心SIEM进行后续分析处理。
图13. 通过WinRM事件转发协议实现事件日志推送的SIEM架构
这种方法面临一些问题,第一个问题是只有合法的计算机才会将日志推送到日志收集器上。在DCShadow攻击中,只有攻击者的主机上才会生成与新数据注入过程有关的事件日志,而这台主机明显不会向SIEM发送事件。这样一来,由于合法主机上生成的事件日志非常少,因此DCShadow能实现静默攻击效果。
实际上,在本文中我们也提到过,攻击者将恶意数据信息注入目标AD之前,需要先执行几个操作。不幸的是,搭建恶意DC过程中涉及到的AD修改动作很少会纳入日志策略中。比如,日志策略中基本上不会考虑Configuration NC修改事件。蓝方可以针对这类改动操作发出警告,但需要区分相关事件是与恶意活动有关,还是与正常的AD操作有关,这个过程需要花费较多时间,实际操作起来并不容易。
蓝队需要全面重新设计已有的防护策略,将重心从日志分析转移到AD配置分析。最直接的方法就是监控复制动作(DrsGetNCChanges RPC更改操作)。实际上,默认情况下域的root(根)对象上的SACL条目会保存除域控制器以外的扩展权限的使用记录。这种情况下,蓝队很容易就能识别出来使用用户账户或者非DC主机的复制操作。然而,我们不觉得这是最为有效的一种方法。从我们的视角来看,为了检测DCShadow攻击,蓝队需要采用如下3中策略:
1、仔细检查schema中的Configuration区。站点容器中的nTDSDSA对象必须与Domain Controllers组织单元(organizational unit,OU)中的正常域控制器相匹配(更严格条件下,需要与管理团队手动维护的一个DC清单相匹配)。在前者中出现但没有在后者中出现的任何对象都值得怀疑。需要注意的是,恶意nTDSDSA对象会在非法对象发布后立刻被删除。为了有效检测这种攻击手段,蓝队所使用的检测机制需要能够检测到对象创建过程。
2、在前文中我们提到,DC需要提供身份认证服务。为了发布改动信息,恶意DC需要提供能通过Kerberos访问的服务。也就是说,该DC会包含以“GC/”字符串开头的SPN(服务主体名称)。此外,攻击这也会用到著名的RPC 接口(GUID:E3514235–4B06–11D1-AB04–00C04FC2DCD2)。提供该服务但又不在DC OU中的主机也非常可疑。
3、攻击者需要较高权限才能使用DCShadow技术。蓝队可以分析并监控Configuration区中的权限信息,确保除了管理员之外,没有其他人能够更改这些信息。此外,如果非特权实体获得了DACL权限,这很有可能是出现后门的一种特征。
八、总结
再次强调一下,本文介绍的DCShadow并不是漏洞,而是将非法数据注入AD基础架构的一种新型方法。
不具备高权限的攻击者无法使用该方法来提升权限,也无法获取目标AD的管理访问权限。我们需要明确的一条底线是:如果我们的AD环境已经正确配置过并且处于安全状态,那么我们不需要采取任何紧急行动来进一步防护。
面对DCShadow技术,我们不需要打上紧急补丁,也不需要应用特殊配置,这一点与WannaCry/NotPetya事件响应处置过程有所不同。
由于DCShadow不是漏洞,因此微软也不会发布更新来封堵该方法。如果想对付这种技术则需要改变AD的现有工作方式,这样一来也会给系统运行带来不便。之前公布DCSync攻击方法的研究人员以及微软也没有发布任何补丁来封堵该方法,因为该方法用到的都是合法的API,“修复”该缺陷就意味着禁用DC复制机制。俗话说的好,不要没事找事,何况AD现在仍在正常运行中。
然而,新的攻击方法已经公布,任何人都可以使用,这一点值得大家好好思考。高权限的攻击者可以借助该方法悄悄发起攻击,因此我们应该更新检测策略来检测这种攻击。传统的事件日志分析方法可能无法检测到DCShadow攻击活动,为了有效检测这类行为,我们需要持续监视AD数据库,隔离非法的更改操作。这也是Alsid正在做的工作,我们已经可以保护客户免受这类攻击影响。大家可以访问www.alsid.eu了解我们如何应对这个安全风险。
发表评论
您还未登录,请先登录。
登录