1.概述

为了对企业内部计算机、用户等资源进行统一管理，微软提出了活动目录（Active Directory，AD）的解决方案，不同于传统的工作组模式，它最大的优点是可以集中管理，包括统一身份认证、权限控制等

攻击者也可以通过邮件钓鱼等方式控制内网一台机器，之后会进行各种试探，最终目标基本都会到活动目录，因为这里有全部用户信息

---

2.常见攻击方式

SYSVOL与GPP漏洞

SYSVOL为域内共享文件夹，里面保存着与组策略相关的信息，例如登录或注销脚本、组策略配置文件等，域内主机都能访问。域管理员在使用组策略批量管理域内主机时，如果在脚本或配置中引入用户密码，则会产生安全问题。通过对SYSVOL目录搜索vbs、ps1后缀的文件，很快就能找到相应的脚本文件，打开即可发现其中密码。

在早期的实现中，GPP 支持管理员在组策略中设置某些配置（如本地管理员账户的密码）。这些密码会保存在 SYSVOL 目录中的 XML 文件中，并且使用较弱的加密方式（AES-256）进行加密，密码加密密钥是硬编码的。通过公开的加密密钥，攻击者可以解密这些 XML 文件，获取存储在其中的明文密码。这意味着域内的任何经过身份验证的用户都能够从 SYSVOL 中获取这些加密文件，解密后得到管理员设置的密码，进而可能获得更高权限。网上有针对性的利用脚本，可以快速获取SYSVOL目录各类配置文件中的密码，我们提取其解密函数直接利用即可

针对GPP漏洞，微软发布了KB2962486补丁，在配置组策略的机器上打上相应的补丁后，组策略中设置用户名密码的地方是灰色的无法使用。但登录脚本中的明文密码，有人要输微软也拦不住，所以还是需要关注这个问题

MS14-068漏洞

Kerberos 是一种基于对称密钥的身份验证协议，广泛应用于 Windows 域环境中。其身份验证过程主要分为以下步骤：

整个验证过程由三种类型的消息交换组成：验证服务交换，票据授予服务交换，客户端/服务端交换

1. AS-REQ。用户向密钥分发中心（KDC）的验证服务申请TGT（TicketGranting Ticket）。消息包括用户主体名称、域名和预认证信息。该预认证信息是利用用户密码生成的NTLM HASH
2. AS-REP。KDC在收到AS-REQ消息之后，将从数据库中获得该用户的密钥，然后利用该密钥解密预认证信息，验证用户。验证通过后，会生成TGT和会话密钥（Session Key）。该会话密钥又称登录会话密钥，是用户与KDC共享的。TGT中包括登录会话密钥和PAC（特权属性证书）。TGT用KDC的密钥加密，登录会话密钥用用户密钥加密，最后返回给用户。
3. TGS-REQ。如果用户想通过身份认证来访问某个服务（例如IIS），那么会发起TGS-REQ请求，请求中包含TGT以及所请求服务的服务主体名称（Service Principal Name，SPN）。用户收到AS-REP消息之后，利用用户密钥解密登录会话密钥，在证书缓存中保存登录会话密钥。用户准备一个用登录会话密钥加密的认证器（authenticator），连同TGT和服务主体名发送给KDC。
4. TGS-REP。TGS生成服务票据。KDC收到TGS-REQ消息之后，首先用自己的密钥将TGT解密，获得登录会话密钥，然后用它解密认证器，验证用户的有效性。当用户通过验证之后，KDC会生成一个用户与服务共享的会话密钥和一个服务票据。服务票据中包含用户与服务共享的会话密钥的副本和用户PAC，该票据用目标服务账户的NTLM密码哈希进行加密。而会话密钥用登录会话密钥加密。KDC最后将两者返回用户。
5. AP-REQ。用户在收到TGS-REP消息之后，用登录会话密钥解密用户与服务共享的会话密钥，并将该会话密钥保存在证书缓存中。然后，用户准备一个用会话密钥加密的认证器，连同服务票据和一些标志位发送给服务端，申请访问。
6. AP-REP。可选，当用户希望验证提供服务的服务端时，服务端返回该消息。服务端收到AP-REQ消息之后，会用服务的密钥解密服务票据，获得会话密钥，然后利用会话密钥解密认证器获得时间戳，最后验证用户。用户验证通过之后，服务端会生成访问令牌。同时，服务端会检查相互验证标志位是否置位，假如置位，则会利用从认证器中获得的时间戳生成一个新的认证器，然后用会话密钥给认证器加密，最后返回给用户。
7. 用户收到AP-REP消息之后，会用会话密钥解密认证器，验证服务的正确性。除非需要PAC验证（比较少见），目标服务会接受TGS票据中的所有数据，否则，不需要与DC（域控制器）进行通信

TGT默认保存在内存里，而且有效期为10小时。如果攻击者拿到了用户的TGT，并将其导入自己的内存，就可以冒充用户获得访问权限，这种攻击方法又叫票据传递（Pass The Ticket，PTT）

微软在 2014年爆出一个高危漏洞CVE-2014-6324（对应微软为MS14-068），即KDC服务器无法正确地验证签名，导致一些kerberos服务票据被伪造。如果通过伪造票据可以直接将普通的域用户变成域管理员权限

这个过程中最显著的特点就是向KDC请求的数据中没有PAC，导致KDC在生成PAC的时候使用了域用户密码进行MD5而不是HMAC-MD5，然后KDC在内部处理出现问题，生成了一个新的TGT，之后，将伪造的PAC插入自己的授权数据中，最后，将这个TGT发送给用户。这样用户就获得了域管理员权限。

针对MS14-068这个高危漏洞，微软发布了KB3011780补丁，打上补丁后就无法被攻击者利用了。

Kerberoast攻击

任何通过Active Directory验证的域用户都可以查询具有服务主体名称（SPN）的用户账户。这使得攻击者能够访问网络上的计算机，并能够确定支持Kerberos身份验证的所有服务账户及其用途。

黑客可以使用有效的域用户的身份验证票据（TGT）去请求运行在服务器上的一个或多个目标服务的服务票据。KDC在活动目录中查找SPN，并使用与SPN关联的服务账户加密票据，以便服务能够验证用户是否可以访问。请求的Kerberos服务票据的加密类型是RC4_HMAC_MD5，这意味着服务账户的NTLM密码哈希用于加密服务票据。黑客将收到的TGS票据离线进行破解，即可得到目标服务账号的HASH，我们把这个称为Kerberoast攻击

黑客进行此类攻击，一般会先进行SPN扫描，特别关注MSSQL、Exchange等服务

Kerberoasting 攻击之所以特别有效，主要有以下几个原因：

• 服务账户密码不定期更改：大多数服务账户的密码设置后长期不变，甚至永不过期。因此，攻击者可以花时间进行离线暴力破解，不需要担心密码很快失效。
• 服务账户通常拥有较高权限：许多组织中的服务账户具有高权限，甚至有可能是域管理员的成员。这意味着一旦攻击者破解成功，便可获得非常高的访问权限。
• 攻击隐蔽性强：Kerberoasting 攻击不会生成明显的网络流量或警告。SPN 扫描是通过查询域控制器（LDAP）来完成的，而不是直接扫描每个服务的 IP 和端口，因此不会触发网络层面的检测工具。此外，域内的任何用户都可以合法地请求 TGS 服务票据，因此这种行为在域环境中看起来是正常的。
• 离线暴力破解：TGS 服务票据的加密方式是 RC4_HMAC_MD5，这意味着票据是用服务账户的 NTLM 哈希加密的。攻击者一旦获取了 TGS，可以在离线环境中进行暴力破解，而不需要进一步与网络交互，也不会引起网络安全监控系统的注意。

内网横移抓取管理员凭证

当黑客控制了内网一台机器后，往往会想办法获得域管理员凭证。通过所控制的机器，进一步定位域管理员信息，例如，当前域管理员账号有哪些，谁是真正的域管理员，在哪登录过等。

比较常用的办法是抓本地密码，一旦域管理员在本地登录（包括使用runas或远程桌面连接），都能轻松地抓取到

除了抓取外，还可以使用键盘记录类程序来记录输入的账号密码。如果在所控制的机器上没有抓到管理员密码，黑客往往会在内网进行更多的尝试，也就是我们经常说的“横向移动”，一般的步骤如下：

1. 获得一台域主机的权限
2. Dump内存获得用户hash
3. 通过pass the hash尝试登录其他主机
4. 继续搜集hash并尝试远程登录
5. 获得域管理员账户hash，登录域控，最终成功控制整个域

黑客在内网多台机器上跳来跳去，看上去非常复杂，但网上有很方便的工具（例如CEW），通过扫描C段来发现有哪些机器，定位哪些机器当前账号有权限访问，哪些机器共享了文件，哪些机器域管理员登录过并将hash给dump下来，有了hash就可以进行传递哈希攻击了。一些聪明的攻击者甚至会故意破坏一些文件；导致诸如Office软件不正常，诱使域管理员在该机器上登录。

针对域内计算机本地管理员密码一致带来的安全问题，有的企业在组策略里用脚本修改本地管理员密码，通过一定的算法来生成本地密码，例如按计算机名、年份+月份、计算机序列号等算法，这也是一个折中的方案

但是如果能用上一些加密保护措施（如微软PowerShell中的ConvertTo-SecureString）对密码进行保护就更好了。另外，微软公司在这块也做了不少努力，从Windows XP的不允许禁用默认管理员，到 Windows 7可以允许用户禁止，再到Windows 10的默认禁止，还提供了LAPS方案****（其核心思想是自动为每个域中计算机的本地管理员账户设置复杂、唯一的密码，并定期更改密码，避免使用统一的本地管理员密码带来的安全风险https://learn.microsoft.com/en-us/previous-versions/mt227395(v=msdn.10)?redirectedfrom=MSDN）

内网钓鱼与欺骗

对处于同一个网段内的目标，攻击者可能还会采用ARP欺骗、DHCP欺骗等中间人攻击技术。

我们都知道当请求一个地址时，先会看本地配置文件，如hosts中是否有记录，没有再会去检查本地DNS缓存，还没有就去向DNS请求。如果DNS名称解析失败了呢？微软从Vista开始新增了链路本地多播名称解析（LLMNR）技术，即当DNS名称服务器请求失败时，系统就会通过LLMNR或Net-BIOS名称服务（NBT-NS）技术进行请求查询，这个过程即是向网络中发送广播包。如果这个时候攻击者侦听网络流量并主动响应，就会有相应的流量送往攻击者所控制的机器。

Responder是一个非常著名的中间人利用工具，使用非常方便，针对那些没有禁用LLMNR和NetBIOS的计算机，可以欺骗目标访问到Responder提供的SMB或者HTTP服务。SMB有个特点，即当用户在资源管理器里访问类似\\IP\File的时候，会默认将当前用户密码凭证送到SMB服务进行认证，失败了才会弹出需要输用户密码的对话框，但此时SMB服务器已经收到了相应数据，通过抓包即能获取到用户凭证。有了这个凭证，再进一步利用Hashcat等工具进行破解就有可能得到能利用的用户密码。
在实际渗透过程中，往往会配合钓鱼进行，例如：

• 在共享上放置特殊的目录，当用户点到这个目录的时候会自动请求攻击的SMB
• 在doc里插入文件，然后将相应的链接改为UNC路径，通过内网邮件发送给对方
• 利用PDF的GoTobe和GoToR功能，让对方打开PDF时自动请求SMB服务器上的文件等。

一般企业内部员工看到内部的邮件或公用共享文件夹都会放松警惕，当点开之后，当前用户密码登录凭证已经被人拿到。

关于这方面的攻击手法非常多，详情见：

https://osandamalith.com/2017/03/24/places-of-interest-in-stealing-netntlm-hashes/

针对内网欺骗或中间人攻击，比较有效的方案是：

1、MAC绑定

将设备的IP地址和MAC地址绑定在一起，确保设备使用特定的网络接口进行通信。通过这种方式，可以防止MAC地址欺骗或ARP欺骗攻击

2、禁用LLMNR和Net-BIOS

禁用 LLMNR 和 NetBIOS 后，计算机会依赖更安全的DNS进行名称解析，减少被欺骗或重定向的风险

3、启用SMB签名

在默认情况下，SMB通信的数据不进行签名或加密，这使得攻击者可以在网络中间人攻击中篡改SMB流量。启用 SMB 签名后，攻击者即便拦截了SMB流量，也无法篡改数据包内容，避免了诸如中间人攻击、会话劫持等安全威胁

4、配置好WPAD相应的DNS记录等

攻击者可以通过控制WPAD的DNS或DHCP响应，提供恶意代理配置文件，将网络流量引导至攻击者控制的代理服务器，进行中间人攻击。在DNS中配置正确的WPAD记录，确保只有合法的代理服务器能够提供代理配置文件。如果不使用WPAD，则应禁用WPAD

用户密码猜解

域里的账号，一般会设置账号安全策略，例如密码长度、锁定次数等，暴力破解容易触发锁定机制从而被发现，于是有了密码喷洒技术。

喷洒这个词语很形象，当攻击开始时，往往会从列表中的第一个密码开始。第一个密码用于尝试对活动目录中的每个用户进行身份验证。针对活动目录中的每个用户，攻击者都会尝试用这个密码进行登录，当所有用户都使用该密码进行了测试后，就会自动转到下一个密码，执行重复的测试。假设活动目录中的每个用户的测试上限次数为5次，那么攻击者会为每个用户进行4个不同密码的尝试，直到锁定计算器时间超了再继续。

当发生以上暴力猜解密码时，域控服务器就会默认产生大量的登录失败事件（事件ID为4625），如果开启了相关的审核策略，还会有大量的凭据验证失败事件（事件ID为4776）。需要对此类事件进行监控，并进行关联告警，这样就能很快定位到内网的攻击源。

获取AD数据库文件

当拿到域管理员权限后，攻击者往往会导出所有用户HASH便于进一步利用，比较常用的方法包括用Mimikatz抓取HASH，或者利用DCSync远程转储。还有一些办法是直接导出ntds.dit（一般有ntdsutil导出、利用Volume Shadow Copy导出等方法），因为这个文件即是AD数据库文件，该文件由三个主表组成 — 数据表、链接表和SD表

导出域数据库后，可以使用DSInternal脚本导出用户哈希，导出的HASH可以直接利用Mimikatz进行PTH攻击

除了直接在域控上导出ntds.dit外，还有一些方法可以获得ntds.dit，例如备份共享、准备配置成域控的服务器、虚拟化平台等

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772829(v=ws.10)

---

3.权限维持手段

krbtgt账号与黄金票据

其实域中每个用户的票据都是由krbtgt的密码Hash来计算生成的，因此只要黑客拿到了krbtgt的密码Hash，就可以随意伪造票据，进而使用票据登录域控制器。使用krbtgt用户hash生成的票据被称为黄金票据（Golden Ticket），此类攻击方法被称为票据传递（PTT）攻击

黄金票据的原理是，通过伪造TGT，没有与KDC进行AS-REQ、AS-REP通信，直接进行TGS-REQ，向KDC进行请求以获得票据

安全策略一般会要求域内的普通账号定期进行修改，或者域管理员发现入侵行为而修改了所有管理员密码，但往往会忽视krbtgt这个账号。这时候，攻击者利用原先导出的krbtgt的HASH生成黄金票据，导入系统缓存便可以继续控制活动目录。利用Mimikatz的kerberos::golden功能将krbtgt的HASH导入并生成票据，如图：

利用此票据即可访问域控上的文件。还可以利用DCSync功能远程导出其他用户哈希

服务账号与白银票据

白银票据（Silver Tickets）是伪造Kerberos票据授予服务（TGS）的票据，也称服务票据，这中间与域控制器没有通信，即没有AS-REQ、AS-REP、TGS-REQ、TGS-REP过程，所以只在应用服务端才会有相应日志

通常服务账号也不会修改，所以只要导出服务账号的HASH，就能利用此HASH生成白银票据，利用方法与黄金票据类似。与黄金票据不同的是，白银票据是伪造TGS，这意味着该票据仅限于特定服务器上的服务使用。

利用DSRM账号

除了krbtgt、服务账号之外，域控上还有一个目录服务还原模式（DSRM）账户，其密码在DC安装的时候就需要进行设置，所以一般不会被修改。微软对DSRM账号进行了限制，只允许在控制台登录。通过对DSRM的研究人们发现，DSRM其实是一个可用的本地管理员账号，而且修改了如下注册表键值：

HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior

将DSRMAdminLogonBehavior改为2，就可以通过网络验证并登录到DC。有了这一点，就可以利用导出的HASH结合PTH方式，持续控制DC，即使域内用户密码都进行了修改

建议定期修改每台域控的DSRM账号，并且是唯一的，同时需要对DSRMAdmin-LogonBehavior注册表键值进行监控。

利用SID History属性

每个用户账号都有一个关联的安全标识符（SID），这个SID用于跟踪安全主体在访问资源时的账户与访问权限，例如，系统默认管理员SID值为500，不管怎么改名这个SID也不会变。

为了支持AD迁移，微软设计了SID-History属性，SID History允许一个账户的访问被有效地克隆到另一个账户。这是非常有用的，其目的是确保用户在从一个域移动（迁移）到另一个域时能保留原有的访问权限。当DomainA中的用户迁移到DomainB时，会在DomainB中创建一个新的用户账户，DomainA用户的SID将添加到DomainB用户账户的SID历史属性中。这将确保DomainB用户仍然可以访问DomainA中的资源

攻击者们发现，SID History可以在同一个域中工作，即DomainA中的常规用户账户可以包含DomainA SID，假如这个DomainA SID是一个特权账户或组，那就可以在不作为域管理员成员的情况下授予常规用户域管理员权限，相当于一个后门

维权步骤：

1. 获取特权账户的 SID：攻击者首先需要获取域管理员账户或其他高权限账户的 SID。
2. 篡改用户的 SID History：通过工具（如 Mimikatz），攻击者将特权账户的 SID 添加到普通用户账户的 SID History 中。
3. 获得域管理员权限：一旦成功篡改，普通用户的 SID History 中就包含了特权账户的 SID。Windows 通过 SID History 验证权限时，普通用户会被视为拥有特权账户的权限，从而能够访问管理员级别的资源，尽管该用户并未显式属于域管理员组。

相应的策略是监控4738事件，已更改的属性中会列出SID历史。也可以定期检查SID History的异常账号

利用组策略

组策略可以方便地对AD中计算机和用户进行管理。组策略可以包括安全选项、注册表项、软件安装以及启动和关闭脚本等，域成员默认情况下每隔90分钟刷新一次组策略设置（域控制器为5分钟）。这意味着组策略会强制在目标计算机上配置相关的设置。如果黑客拿到了域管权限，也可以通过修改组策略来控制域内的计算机和用户

例如，执行登录脚本，创建计划任务，部署安装恶意软件等。即使使用了LAPS方案来保证每台计算机本地管理员密码不一致，拿到域控权限的黑客也可以通过在组策略里配置脚本，自动收集所有计算机本地管理员账号LAPS密码

还有一个需要注意的是SYSVOL目录的权限，默认域内认证用户只读，如果SYSVOL目录或下面的子目录权限被攻击者故意修改为特定用户可写，会发生什么事情呢？我们知道组策略包括两个组件：一个是组策略容器，它存储在AD中；另一个是组策略模板，它存储在SYSVOL中，需要两者相结合这个组策略才能生效。也就是说，如果在SYSVOL中写入一个脚本，但没有在组策略中引用是不会造成危害的。但是如果修改一个引用的脚本，在其中引入一些其他功能，例如添加恶意用户、导出用户HASH等，是非常危险的。

AD内默认有两个组策略：一个是针对全局的Default Domain Policy；另一个是针对DC的DefaultDomain Controllers Policy，其UUID都是固定的，也就是说在SYSVOL目录是固定的文件夹。一些脚本考虑到通用性会修改这两目录的权限，需要特别注意。

利用AdminSDHolder

每个活动目录域中都有一个AdminSDHolder对象，它位于域的System容器中。设置AdminSDHolder的目的是防止特权用户和重要的组被无意地修改。引入这样的机制之后，那些Protected groups和它们的成员都得到了更进一步的安全保护

通过修改Admin-SDHolder属性，将一个普通用户添加到“安全”选项卡里，并赋予其所有权限或者修改权限。这样我们就可以在普通主机上远程管理AD的权限了

利用SSP

SSPI是Windows系统在执行认证操作时所使用的API，而SSP可以理解为一个DLL，用来实现诸如NTML、Kerberos、Negotiate、Credential等身份认证。在系统启动的时候SSP会被加载到lsass.exe进程，基于LSA本身的可扩展特性，如果自定义一个恶意的DLL也会在系统启动的时候被加载到lsass.exe

Mimikatz里就带有一个mimilib.dll的文件，将这个文件拷贝到系统system32目录，并修改如下注册表项：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages将mimilib.dll加入到Security Packages值的最下面，然后重启域服务器即可生效，它会将记录到的用户密码保存到特定的文件中

如果将密码文件写到SYSVOL共享目录某个文件里，就可以长久控制域服务器

利用Skeleton Key

SSP后门需要重启才能生效，神器Mimikatz提供了Skeleton Key功能，即在域控上执行misc::skeleton后，正常的用户都可以用万能密码正常登录

执行后，在普通域内主机上测试，发现可以用Mimikatz这个万能密码登录，但注意权限还是原来用户的权限

利用PasswordChangeNofity

SSP与Skeleton Key都需要用到Mimikatz，黑客又研究出一种新的方法，即通过Hook PasswordChangeNotify拦截修改的账号密码

当修改域控密码时，LSA会先调用PasswordFilter判断新密码是否符合复杂度要求，如果符合则调用PasswordChangeNotify在系统上同步更新密码。如果将Hook PasswordChangeNofity的恶意代码注入LSA进程，当有密码修改时即可进行记录（将密码保存在普通用户可访问的SYSVOL目录，或者将密码通过HTTP或DNS外发等）

---

4.活动目录的安全解决方案

活动目录整体架构及相关规范

1、域名架构

大型企业里，一般都会建立较多的子域，建议的架构：

包括总部在内的所有分支机构，都是一个根域的子域，根域基本上是空的，不对用户直接提供服务，再结合子域之间的信任关系控制。这样的设计可以解决一个问题，假设一个AD管理员的账号密码被别有用心之人获得，也只能影响一个域，无法影响整个企业所有域

2、物理安全方面

• AD管理员应重视域控制器物理安全，采取必要措施保护存有AD数据库或备份的磁盘、磁带，特别是位于较低安全等级机房的域控制器
• 对于以物理机形式运行的域控制器，应使用本地存储和硬件RAID。故障硬盘在交予外部组织前必须进行消磁
• 对于以虚拟机形式运行的域控制器，应注意对虚拟磁盘文件、虚拟机备份文件的保护。建议启用BitLocker对域控制器系统分区进行加密保护

3、网络与操作安全方面

• 除转发DNS查询外，禁止域控制器访问互联网
• AD管理员禁止在域控制器上使用浏览器访问互联网
• DC服务器建议升级至Windows Server 2016，AD管理员所用电脑建议升级至Win-dows 10，并做好补丁管理工作
• 严禁使用个人电脑直接远程桌面访问域控制器，建议通过堡垒机、KVM、控制台等方式进行运维
• 不应在域控制器上安装和运行同域控制器功能无关或未经验证的软件
• 域控制器的目录服务还原模式（DSRM）管理员密码，需要妥善保管，建议每年度使用NTDSUTIL工具（set dsrm password）进行一次重置

4、AD管理员账户方面

• AD管理员账户只能由被授权的管理员使用，使用者需对其账户使用的合规性负责，并应采取必要措施避免账户密码泄露
• AD管理员只能使用分配的管理员账户进行AD管理工作，不允许多个AD管理员共用同一账户
• AD管理员不能将分配的AD管理员账户作为个人日常工作账户使用，不能将个人日常工作账户提升为AD管理员账户
• AD管理员账户只允许在域控制器上登录
• 未经审批，禁止在域控制器之外的计算机上使用AD管理员账户登录
• AD管理员账户命名要符合规范，例如XXADAdminYY，XX为分支机构，YY为编号，主要是为了方便管理与辨识
• 对一些容易引起问题的账号进行专门处理，包括加域操作、域控制器备份操作、安全日志归档压缩计划、域内机器安装软件授权等，都需要建立专用账号，避免以域管理员身份在终端机器上执行相关操作
• 有条件的企业，建议对域管理员账号启用双因素认证，例如，结合硬件加密狗使用，这样就可以有效避免域管理员账号密码与其他人混用

5、安全审核方面

• 域控制器安全日志大小应设置为200MB以上，建议不超过500MB，并进行安全日志归档设置。配置安全日志属性，启用“日志满时将其存档，不覆盖事件”。生成的安全日志归档文件默认位于%Systemroot%\System32\winevt\logs目录。应及时对日志归档文件压缩并保存在系统分区之外，避免归档文件耗尽系统分区磁盘空间。安全日志归档文件应保留至少12个月。未经归档备份，不应清除安全日志。
• AD管理员应对域控制器上的安全日志进行定期抽查，检查内容包括

1️⃣ 安全日志事件是否连续，是否有缺失，是否有安全日志清除事件

2️⃣ “账户管理”和“策略更改”事件，确认是否为授权操作

3️⃣ AD管理员账户的登录事件，确认是否为授权登录

• 所有域控需要安装SOC客户端，将系统上的安全日志转发到SOC进行分析处理

技术体系运营

1、违规登录报警

域控管理员不允许在其他地方登录，一旦登录就需要报警

1️⃣ 获取所有域控清单：

dsquery.exe * forestroot -attr "cn" "distinguishedName" "dNSHostName" "whenCreated" "whenChanged" -filter "(&(objectclass=server)(objectcategory=server))" -q -L -limit 0 > domain_controllers.csv

2️⃣ 获取所有域上的管理员账号：（objectSid=S-1-5-32-544 是一个特定的管理员组的 SID，我们可以根据这个进行匹配）

dsquery.exe * -attr "sAMAccountName" "sAMAccountType" "userPrincipalName" "userAccountControl" "objectCategory" "member" "lastLogon" "whenCreated" "whenChanged" "description" -filter "(&(objectSid=S-1-5-32-544))" -q -L -limit 0 > admin_accounts.csv

3️⃣ 在SOC上定制相应的CASE监控登录，当有触发528或4624事件，登录用户是管理员列表中的，来源是非堡垒机之外的IP，都需要进行报警

2、有效性验证

技术手段上可以通过开发脚本扫描所有域控，触发验证日志和验证事件，图形化展示，每日Review报表即可轻松发现问题。

Nmap扫描器smb-brute.nse是一个针对SMB暴力猜解的脚本，我们构造相应的用户密码字典对所有域控跑一遍即可产生相应的事件。在SOC上制订针对性的验证 CASE，结合图形化展示可以清楚地知道哪个域控触发了事件，哪个域控没触发事件

3、其他注意事项

AD的日志量非常大，由于配置不当或者网络原因，会导致日志延迟或丢失问题，也需要有相应的一致性比对和可用性监控脚本，统一展示对比结果和可用性情况

另外，针对域控各种不合规进行整改，安排专人跟进，这样效果会比较好

外围平台安全

1、虚拟化平台

很多企业将域控服务器部署在虚拟化平台上，一旦虚拟化平台被攻陷，所有域账号都可能被盗取，风险非常大

相应的安全方案，包括几方面：

• 确保虚拟化平台本身的安全，包括平台的版本不存在高危漏洞，平台上的账号权限管理与敏感操作监控等
• 对AD服务器启用BIOS保护，防止直接挂PE盘进入，启用BitLocker加密，防止vmdk被人拷贝直接进入系统等
• 有条件的企业，尽量使用新版的操作系统，增加了一些安全功能，例如哈希加密、Credential Guard、Shielded VM和虚拟机TPM技术、将密钥保存在虚拟TPM里等

2、身份认证集成

有条件的企业，建议通过SSO系统来对接，各种应用系统对接SSO，而SSO再与AD对接，尽量通过Kerberos协议来实现用户认证，避免使用LDAP认证

如果特殊应用（例如C/S）无法走基于Web的SSO系统，而必须使用LDAP方式，建议使用SSL进行加密，最好是双向认证。

被渗透后的要做的

• 重置krbtgt账号密码
• 重置DSRM账号密码
• 重置重要服务账号密码
• 检查账号SID History属性
• 检查组策略配置以及SYSVOL目录权限
• 检查AdminSDHolder相关安全账号

为了防止各种后门程序或注册表项被修改，建议直接废弃现有DC，新搭一套将数据同步回来