一、概述
有部分企业朋友问我，域控服务器上安装了EDR或HIDS是不是就okay了，非也。域控是企业内网重要的基础设施，横跨OS和基础应用层面。需要熟悉企业内网基础设施建设、域控协议(主要是Kerberos协议和window访问控制模型)原理及攻击手法，才能做出有效的防御。
市面上有很多渗透域控利器，比较知名的有ADFind、ADmod、CrackMapExec、Bloodhound、mimikatz、Impacket、PowerSploit等；微软发布过专门针对AD域控的监控系统Advanced Threat Analytics （简称ATA），详情见https://docs.microsoft.com/zh-cn/advanced-threat-analytics/what-is-ata. 但了解到，ATA对中国大陆地区是不单独售卖，而是植入到Defender ATP商业版中捆绑销售。
如何在没有商业工具的帮助下，也能有效检出针对域控的渗透行为，是本文今天介绍的重点。
二、如何检测？
做防守的，一定要换位思考，攻击者渗透域控，最终是要拿下什么？
渗透域控最终的目标是，拿下域管身份、域管身份、域管身份！！！
-
获取域内用户帐号票据；—-攻击者利用域用户票据，在域内环境横向渗透；
-
获取服务票据；—-攻击者访问基于域认证的服务，如微软系统的TFS、SharePoint、Exchange邮箱等；
-
控制入域机器；—-攻击者通过GPO下发恶意策略控制入域机器；
-
劫持内网任意域名；—不少企业会使用AD DNS做内网域名解析，如能劫持内网域名，甚至可以瘫痪整个内网；
所以，攻击队攻击域控，绝不只是拿下企业内几台域控机器这么简单，这只是攻击者打开企业内网的一道门槛，更多的骚操作才刚刚开始。
作为防守方，我们不止是要了解攻击者的常规攻击域控的手法，还要熟知域控在企业基础设施中扮演的角色以及内网中上下游的访问关系，才能做好域控的检测；
三、检测方案
3.1 保护“域管”帐号，做好域内高权限帐号访问规则
该类监控规则属于“判白”模型，即不看漏洞利用过程，也不看攻击者的操作手法，只看该行为是不是提前约定的白行为（如高权限帐号仅允许堡垒机登录、高权限帐号对应的票据仅允许存在于域控服务器上、高权限帐号的清单未发生非预期变更、高权限帐号密码也未发生非预期变更)，存在非白名单行为的操作，需要联系域控运维人员核对。
“判白”模型，可防御针对域控的0DAY攻击；防守方在研究防御规则时，最好优先规划”判白“类模型，可有效减少漏水case.
3.1.1 提前收集信息，用于监控模型
|
高权限帐号是指隶属于以下组里面的帐号，需要提前收集这些帐号：
Enterprise Key Admins (注：window 2016域控才有该组)
Key Admins (注：window 2016域控才有该组)
域控服务器IP清单以及机器名，需要提前收集, 如；
机器名：DC01.CONSOL.COM 对应IP: 10.0.0.1
机器名：DC02.CONSOL.COM 对应IP: 10.0.0.2
|
3.1.2 检测高权限帐号的访问源是否来自指定源
|
检测日志：Window安全日志eventID: 4776、4768、4769、4624、5140
1）监控“NTLM验证高权限帐号”监控策略：监控4776日志(成功).
监控逻辑：EventID=4776 and TargetUserName in（“高权限帐号列表”）and workstation not in (“域控机器名清单”) and Status = “0x0” .
2）监控“Keberos TGT验证高权限帐号”策略：监控4768日志(成功).
监控逻辑：EventID=4768 and TargetUserName in（“高权限帐号列表”）and ServiceName !=”krbtgt” and Status=”0x0″ and IpAddress !=”::1″ and IpPort !=0.
3）监控“Keberos ST验证高权限帐号”策略：监控4769日志(成功).
备注：理论上ST是服务帐号票据，这里不排除域运维人员将高权限帐号配置为SPN帐号。
监控逻辑：EventID=4769 and TargetUserName in(“高权限帐号列表@域名”）and Status = “0x0″ and IpAddress !=”::1″ and IpPort !=0.
4）监控“高权限帐号登录成功”策略：监控4624日志(成功).
监控逻辑1：EventID=4624 and TargetUserName in(“高权限帐号列表”）and TargetDomainName = “DC域名” and LogonTyep in（7，10） and IpPort !=0 and IpAddress not in (“堡垒机IP”);
监控逻辑2：EventID=4624 and TargetUserName in（“高权限帐号列表”）and TargetDomainName = “DC域名” and LogonTyep not in（7,10） and IpPort !=0 and IpAddress not in (“::1”,”127.0.0.1″,“堡垒机IP”, 域控服务器IP清单”)；
提醒策略3：EventID=4624 and TargetUserName in （“高权限帐号列表”）and TargetDomainName = “DC域名” and LogonTyep in （2） and IpPort =0 ###部分企业的域控是通过云虚机部署，一般也会通过webcosole vnc 方式登录，出现该登录时，需要及时和域控运维人员确认；
提醒策略4：EventID=4624 and TargetUserName in（“高权限帐号列表”）and TargetDomainName = “DC域名” and LogonTyep in（7，10）and IpPort !=0 and IpAddress in (“堡垒机IP”); ###企业的域控大多是控制通过堡垒机来登录出现该登录时，需要及时和域控运维人员确认；
5）监控“高权限帐号使用远程网络共享方式访问”策略：监控5140日志(成功).
监控逻辑1：EventID=5140 and SubjectUserName in（“高权限帐号列表”）and SubjectDomainName = “DC域名” and IpPort !=0 and IpAddress not in (“::1”,”127.0.0.1″,”域控服务器IP清单”) ;
|
3.1.3 检测是否有提权行为——即普通用户提权至高权限帐号
|
检测日志：Window安全日志eventID: 4728、5136
1) 监控“普通域用户加入全局安全组”策略：监控4728日志.
监控逻辑：TargetUserName in (“Enterprise Admins”,”Domain Admins”,”Schema Admins”,”Administrators”,”Enterprise Key Admins”,”Key Admins”) and TargetDomainName = “DC域名”;
2) 监控“普通域用户提权高权限帐号组”策略：监控5136日志.
监控逻辑：ObjectDN RegEX (“^CN=Enterprise Admins.*|^CN=Domain Admins.*|^CN=Schema Admins.*|^CN=Administrators.*|^CN=Enterprise Key Admins.*|^CN=Key Admins.*|”) and AttributeLDAPDisplayName =”member” and OperationType=”%%14674″;
|
3.1.4 检测对高权限帐号的变更操作_包括域管密码修改、密码重置
|
检测日志：Window安全日志eventID: 4723日志(帐密更改)、4724日志(帐密重置)
1）监控“高权限帐号密码被修改”：监控4723日志.
监控逻辑：TargetUserName in (“高权限帐号清单”) and TargetDomainName = “DC域名”
2）监控”高权限帐号密码被重置“：监控4724日志.
监控逻辑：TargetUserName in (“高权限帐号清单”) and TargetDomainName = “DC域名”
|
3.2 监控高权限帐号的高风险行为，做好异常行为操作模型
该类监控规则属于”判黑“模型，需要防守方研究针对域控的漏洞利用过程，以及业内曝光的攻击手法，防守方需要复现这些手法，观察域控日志和流量，最终制定防御模型。了解域控类相关的攻击手法，看这两个网站就够了：
https://github.com/ShutdownRepo/The-Hacker-Recipes/tree/master/ad
https://adsecurity.org
3.2.1域信息探测
| 域结构探测：大部分渗透攻击者在对域控渗透之前，需要了解企业内域结构信息，比如有几套域、查找域林级别、域控操作系统版本、域控列表，以便为后续横向过程中提供更多准备； |
|
1.远程探测，如本示例中利用Sharphound.exe进行探测，该操作中获取到的每条域信息，都会触发一次ldap认证。短时间内会产生大量4624日志，登录类似是3；
SharpHound.exe -c all –ldapusername user1 –ldappassword xxxx –skipportscan -d contoso.com –domaincontroller 10.0.0.1
图片来源：https ://twitter.com/SadProcessor
规则一：检测短时间内4624，网络类型3的认证频率
检测日志：Window安全日志eventID: 4624
select TargetUserName,count(TargetUserName) from AD_Eventlogs where eventID=4624 and LogonType=”3″ and time_interval<10min group by TargetUserName,IpAddress；
其中time_interval是由日志中system节点SystemTime前后日志中值相减得出；上述查询结果中，count值大于等于10(运营中调整)，告警输出，重点排查；
2.本地命令执行：入域机器上，执行 nltest /domain_trusts. 该操作会产生Security 4624日志和Sysmon 1日志；
规则二：检测入域机器上4624日志(黑客远程到该机器)和Sysmon1（执行命令）
检测日志：Window安全日志eventID: 4624，Sysmon 1日志
逻辑1：select TargetUserName, SystemTime from AD_Eventlogs where eventID=4624 and LogonType=”3″ and IpAddress in (“域控机器名清单”)；检测在此时间点后的一定时间内，查看sysmon行为日志，大部分渗透, 在最开始的阶段会进行域结构信息搜集；
逻辑2：eventID=1 and Image contains “nltest.exe” and OriginalFileName = “nltestrk.exe” and CommandLine contains “domain_trusts”
|
| ADCS证书服务探测：枚举AD CS证书模板、证书颁发机构和其他配置。以方便后期通过域控证书来进行渗透，比如影子票据、黄金证书等 |
|
攻击向量，可参考https://github.com/ly4k/Certipy.
1）eventID=4624 and LogonType=”3″ ==> 提取IpAddress，TargetUserName，SubjectUserName, SystemTime；
2）eventID=5140 and ShareName contains “*IPC$” ==>提取IpAddress，SubjectUserName，SystemTime；
监控上述1）中的IpAddress和2)中IpAddress相等，且1）中TargetUserName和2)中SubjectUserName相等；
|
3.2.2域凭据获取
| 密码喷洒攻击：对域内多个帐号尝试登录，一旦验证成功即可破解出密码； |
| 攻击向量：详情见https://github.com/ropnop/kerbrute
检测日志：安全日志eventID 4768、4771
(eventID = 4768 or eventID = 4771）and ServiceName contains “krbtgt” and Status!=”0x0″ ==> 输出SystemTime，TargetUserName, IpAddress
上述SystemTime一定时间范围内（如10分钟），针对同一来源 IpAddress，出现TargetUserName 超过30次以上，告警输出，重点排查；
攻击向量：详情见https://github.com/ShutdownRepo/smartbrute
规则二：利用Ldap or SMB协议进行密码喷洒
eventID=4625 and LogonTyep =”3″ ==> 输出SystemTime，TargetUserName,IpAddress
上述SystemTime一定时间范围内(如10分钟)，针对同一来源 IpAddress，出现TargetUserName 超过30次以上，告警输出，重点排查；
|
| 利用Kerberos协议窃取TGT票据: 攻击者通常也会想法设法去获取用户的TGT票据，用该票据在线KDC请求相应的ST票据，获取域内相应服务器的访问权。 |
|
攻击向量：详情见https://www.hackingarticles.in/abusing-kerberos-using-impacket/
使用impacket工具集getTGT.py来获取某个用户的TGT票据。
规则一：窃取高权限帐号TGT票据；由于正常用户认证也会请求TGT票据，避免噪音太大，这里聚焦对高权限帐号的监控；
监控逻辑：eventID = 4768 and TargetUserName in (“高权限帐号清单”) and TargetDomainName = “DC域名” and ServiceName = “krbtgt” and Status = “0x0” and IpAddress not in (“域控机器名清单”)
|
| 利用Kerberos协议窃取ST票据：获取相应服务的ST票据，获得相应的访问权 |
|
攻击向量：利用域控管理员dadmin身份申请获取域控的ldap服务
规则一：利用高权限帐号获取ST票据；获取ST票据的日常应用场景也很多，为避免噪音，这里聚焦对高权限帐号的监控；
监控逻辑：eventID=4769 and TargetUserName in（“高权限帐号列表”）and IpPort != “0” and Status = “0x0”
|
| 利用证书认证来窃取域用户票据 |
|
攻击向量：攻击者请求用户的证书，利用私钥证书继而获取用户的TGT；详情见https://github.com/ly4k/Certipy
检测日志：4886(收到证书申请), 4887(颁发用户证书）, 4768（利用证书密钥进行登录）
逻辑3：eventID = 4768 and lower(SeriveName) = “krbtgt” and strlen(CertSerialNumber)>20
|
| 利用DCSync窃取域内票据 |
|
攻击向量：利用mimiktaz进行dcsync. 看到这里，也许有人会说，mimakatz工具拉黑不就可以防御了么。其实市面上能够dcsync导出域内票据的工具太多了(如powerview.ps1、impacket工具集里面的secretsdump.py等)，穷举所有工具拉黑也不现实。
监控逻辑：具备DCSync能力的用户，需拥有以下ACL权限；
‘DS-Replication-Get-Changes’ = 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
‘DS-Replication-Get-Changes-All’= 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
‘DS-Replication-Get-Changes-In-Filtered-Set’ = 89e95b76-444d-4c62-991a-0facbeda640c
(Properties contains “DS-Replication-Get-Changes”
or Properties contains “DS-Replication-Get-Changes-All”
or Properties contains “DS-Replication-Get-Changes-In-Filtered-Set”
or Properties contains “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2”
or Properties contains “1131f6aa-9c07-11d1-f79f-00c04fc2dcd2”
or Properties contains “89e95b76-444d-4c62-991a-0facbeda640c”)
and AccessMask = “0x100” and SubjectUserName not contains(“NT AUT”)
and SubjectUserName not contains(“MSQL_”)
备注：4662日志有一个非常不好的地方，就是不记录DCSync的源IP。如需要能更精确的获取DCSync的来源IP，可以安装DCSYNCMONITORSERVICE.exe服务（详情见https://github.com/shellster/DCSYNCMonitor）。当出现DCSync操作时，则应用日志会输出来源IP，详情见截图。如DC SYNC FROM: 后面的IP并非来自域控服务器清单，则大概率是攻击者行为；
|
说明：经过上述的日志截图标注，相信大家对window 安全日志和sysmon日志字段有一些了解，考虑到文章长度有限以及本人实在不想再重复截图标注字段这类体力劳动，下面的防御规则中，将不再体现window日志截图。
注：更多Window日志字段介绍，可参考https://docs.microsoft.com/zh-cn/windows/security/threat-protection/auditing/security-auditing-overview
3.2.3横向移动
|
PTHPTTPTK攻击: 攻击者利用抓取到的哈希、票据以及加密后的aeskey发起身份认证；
|
|
攻击向量：攻击者抓到入域机器呢内存中的高权限账号的凭证，发起ntlm、kerberos、smb认证；
逻辑1: eventID = 4624 and TargetUserName in （“高权限帐号列表”）and TargetDomainName = “DC域名” and LogonType =”3″ and IpPort !=0
逻辑2: eventID = 4769 and TargetUserName in（“高权限帐号列表”）and IpPort != “0” and Status = “0x0”
逻辑3: eventID=5140 and SubjectUserName in （“高权限帐号列表”）and SubjectDomainName = “DC域名” and IpPort !=0 and IpAddress not in (“::1”,”127.0.0.1″,”域控服务器IP清单”) ;
|
|
|
|
攻击向量：添加权限。攻击者利用GPO 更改INF内容来添加权限或修改GptTmpl的文件（路径：“\DC.comSysVolDC.comPolicies{PolicyGUID}MachineMicrosoftWindows NTSecEditGptTmpl.inf” ）
eventID = 5136 and AttributeLDAPDisplayName = “gPCMachineExtensionNames” and AttributeValue contains(“827D319E-6EAC-11D2-A4EA-00C04F
79F83A”) and AttributeValue contains(“803E14A0-B4FB-11D0-A0D0-00A0C90F574B”)
逻辑1: eventID = 5136
and (AttributeLDAPDisplayName contains(“gPCMachineExtensionNames”
or AttributeLDAPDisplayName contains(“gPCUserExtensionNames”))
and AttributeValue contains(“42
B5FAAE-6536-11D2-AE5A-0000F87571E3″)
and (AttributeValue contains(“40B66650-4972-11D1-A7CA-0000F87571E3”) or AttributeValue contains(“40B6664F-4972-11D1-A7CA-0000F87571E3”)
逻辑2: eventID = 5145 and ShareName contains(“\*SYSVOL”) and (RelativeTargetName endswith(“scripts.ini”) or RelativeTargetName endswith(“psscripts.ini”))and AccessList contains(“%%4417*”)
and (AttributeLDAPDisplayName contains(“gPCMachineExtensionNames”
or AttributeLDAPDisplayName contains(“gPCUserExtensionNames”))
and AttributeValue contains(“CAB54552-DEEA-4691-817E-ED4A4D1AFC72”)
and AttributeValue contains(“AADCED64-746C-4633-A97C-D61349046527”)
逻辑2: eventID = 5145 and ShareName contains(“\*SYSVOL”) and RelativeTargetName endswith(“ScheduledTasks.xml”) and AccessList contains(“%%4417*”)
|
|
黄金票据银票据：黄金票据是伪造TGT并且有效的获得任何Kerberos服务；银票据是伪造TGS获得指定服务器上的服务；
|
|
1. 黄金票据由krbtgt加密，最终需要访问域控(KDC) 进行认证，所以上述针对PTT的监控逻辑也可以覆盖该场景；
2. 银票据可直接跳过域控(KDC)访问对应的服务器，这意味着可永远不去访问域控，任何事件日志都在目标服务器上，仅采集域控日志，很难检测。
1) 历史曝光的MS4-068漏洞方式利用银票据，可通过补丁或升级到Windows 2016及以上版 本域控来避免；
2)如果攻击者利用银票据访问域控上的服务，比如为cifs服务创建一张ST票据, 则可以复用上述PTHPTTPTH监控逻辑来检测，尤其是排查5140日志；
|
|
影子票据: windows server2016引入了基于密钥的信任模型，新的特性也引入新的攻击面。在 Black Hat Europe 2019 期间， Michael Grafnetter提出了几种攻击，其中包括涉及修改msDS-KeyCredentialLink的域持久性技术。
|
|
攻击向量：Elad Shamir发布了一个名为Whisker的工具，攻击队利用该工具将生成证书和非对称密钥，并将此信息存储在msDS-KeyCredentialLink属性中。生成的证书可以与 Rubeus 一起使用，以获取该帐号的TGT票据进一步扩大攻击。详情见https://pentestlab.blog/2022/02/07/shadow-credentials/
规则一：检测帐号被添加msDS-KeyCredentialLink属性
监控逻辑：eventID = 5136 and AttributeLDAPDisplayName Contains(“msDS-KeyCredentialLink”)
监控逻辑：eventID = 4768 and lower(SeriveName) = “krbtgt” and strlen(CertSerialNumber)>20
|
3.2.4权限维持
| 委派攻击: 域控支持配置将域内用户的权限委派给服务帐号，使得服务帐号能以用户的权限在域内展开活动。攻击者可以基于这一配置特性，获取指定机器的TGT票据，服务的ST票据，甚至是黄金票据等； |
|
攻击向量一：攻击者利用机器帐号进行委派攻击；该场景最经典的攻击是利用非约束委派+Spooler打印机服务来强制指定的主机进行连接，获取指定主机的TGT票据。详情可参考tifkin, enigma0x3和harmj0y在2018年提出的攻击思路https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory，其中P39～P51有细叙；
相关PoC见https://github.com/leechristensen/SpoolSample；
规则一：检测机器账号被配置为委派（包括非约束、约束委派）；
监控逻辑：监控有哪些非预期机器账号被配置为委派（下述2种日志都可以监控）；
逻辑1: eventID =4742 and NewUacValue != “0x100″ and SubjectUsername !=”NT AUTHORITY” and TargetUsername endswith(“$”) and SubjectUsername !=TargetUsername
逻辑2:eventID = 5136 and AttributeLDAPDisplayName Contains(“msDS-AllowedToDelegateTo”)
攻击向量二：利用服务帐号委派攻击；该场景最经典的攻击就是利用约束委派生成黄金票据，进而获取到域管TGT票据。攻击者通常利用设置S4U2Proxy、S4U2self权限服务帐号，一旦配置访问了目标SPN是krbtgt/CONTOSO.COM, 即可给任何账号签发TGT票据，包括域管TGT.
规则二：检测服务帐号被配置为委派（包括非约束、约束委派）
逻辑1: eventID = 4738 and NewUacValue != “0x10”
and SubjectUsername != “白名单帐号” ###安全运营人员基于企业内网环境添加白名单帐号；
逻辑2: eventID = 4738 and lower(AllowedToDelegateTo) contains “krbtgt” ## 检测委派访问到krbtgt，即新型黄金票据攻击；
逻辑3: eventID =4769 and TransmittedServices != “-” and strlen(TransmittedServices ) >1; ##检测有没有设置S4U2Proxy；
逻辑4: eventID =4769 and strsplit(TargetUserName,”@”)[0] = ServiceName; ##检测有没有设置S4U2Self；
攻击向量三：基于资源的约束委派攻击，即渗透者常用的RBCD攻击；如果在krbtgt账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性中设置某个用户账户的SID，那么攻击者可以据此攻击获取一个有效TGT，意味着得到黄金票据；
规则三：检测帐号属性被添加msDS-AllowedToActOnBehalfOfOtherIdentity属性
监控逻辑：监控是否有帐号属性被修改，添加msDS-AllowedToActOnBehalfOfOtherIdentity属性。
逻辑2:eventID = 5136 and AttributeLDAPDisplayName Contains(“msDS-AllowedToActOnBehalfOfOtherIdentity”)
|
|
ACL后门：这里ACL指的是Windows系统的访问控制模型(Access Control Model), 即控制进程访问一些安全对象，并非指网络防火墙ACL策略。想了解ACL方面知识，详情看https://www.anquanke.com/post/id/212163；
近几年，针对域控ACL的攻击常在各大论坛被提到，尤其是针对一些特殊权限的利用，如GenericAll、GenericWrite、WriteOwner、WriteDACL等
|
|
攻击向量：通过ldap协议连接上域控ACL配置界面进行操作，设置GenericAll、GenericWrite、WriteOwner、WriteDACL等特殊权限。相关工具可参考详https://www.ytria.com/ezsuite/aclez/download/ 和 http://www.ldapexplorer.com/en/manual/107070211-editor-ms-accesscontrolentry.htm 下载
监控逻辑：eventI D=5136 and lower(AttributeLDAPDisplayName) = “ntsecuritydescriptor” and
AttributeValue startswith(“O:DAG:DAD:PAI”);
|
| AdminSDHolder后门，包括AdminSDHolder SDProp例外添加后门
理论上，这也是ACL后门的范畴。之所以单独拿出来说，是因为很多论坛和博客都有专门介绍这块渗透姿势，有攻就有防，所以也讲下这块的防御姿势；
|
|
攻击向量: 利用对AdminSDHolder有WriteDACL权限的账户，添加ACL
Admod.exe -b “CN=AdminSDHolder,CN=System,DC=contoso,DC=com” “SD##ntsecuritydescriptor::{GETSD}{+D=(A;;GA;;;contosotest1)}”
规则一：检测检测AdminSDHolder后门，服务对象被更改。
监控逻辑：eventID = 5136 and ObjectDN contains(“CN=AdminSDHolder,CN=System”)
监控逻辑：eventID = 5136 and AttributeValue RegEx(“[0-9]{15}([1-9a-f]).*”) and strlen(AttributeValue)>15
|
3.2.5数据收割
| 获取本地账号票据文件SAM以及域帐号票据文件NTDS.dit |
|
攻击向量：攻击者获取到域控服务器的控制权后，在后渗透阶段，通常会通过卷影复制读取本地账号票据文件SAM以及域帐号票据文件NTDS.dit，以便于获取更多帐号的身份；详情见https://blog.netwrix.com/2021/11/30/extracting-password-hashes-from-the-ntds-dit-file/
规则一：检测SAM、NTDS.dit文件被恶意读取
and lower(CommandLine) contains(‘windowsntdsntds.dit’ , ‘configsam’ , ‘configsecurity’ , ‘configsystem ‘ , ‘repairsam’ , ‘repairsystem’ , ‘repairsecurity’ , ‘configRegBacksam’ , ‘configRegBacksystem’ , ‘configRegBacksecurity’)
(OriginalFileName =’Cmd.Exe’ or OriginalFileName =’PowerShell.EXE’ or OriginalFileName = ‘COPY.EXE’) and lower(CommandLine) Contains(‘ copy ‘ , ‘ xcopy ‘ , ‘ copy-item ‘ , ‘ move ‘ , ‘ cp ‘ , ‘ mv ‘)
lower(OriginalFilename) endswith(‘esentutl.exe’) and lower(CommandLine) contains(‘vss’, ‘ /m ‘,’ /y ‘)
|
| Lsass进程触碰攻击：攻击者尝试导出lsass进程内存中的票据数据； |
|
攻击向量：这方面的攻击工具太多了，黑客也可以自编写一些工具，来覆盖这块攻击详情见https://github.com/outflanknl/Dumpert，所以简单的拉黑工具及其哈希，是无法达到最佳监控效果；
但最终都绕不过要导出lsass.exe进程的内存数据，然后解密破解，获取哈希凭证。
eventID = 10 and GrantedAccess in (“0x40″,”0x100000″,”0x1410″,”0x1010″,”0x1438″,”0x143a”,”0x1418″,”0x1f0fff”,”0x1f1fff”,”0x1f2fff”,”0x1f3fff”,”0x1fffff”) and CallTrace contains(“dbghelp”)
and not (SourceImage startswith(‘C:ProgramDataMicrosoftWindows Defender’) and SourceImage not endswith(‘MsMpEng.exe’))
and not (SourceImage Contains(‘C:WINDOWSsystem32taskmgr.exe’,’C:WindowsSystem32perfmon.exe’))
and not (SourceImage Contains(‘C:WindowsSystem32svchost.exe’) and CallTrace contains(‘C:ProgramDataMicrosoftWindows DefenderDefinition Updates{‘, ‘}mpengine.dll+’)
and GrantedAccess = ‘0x1418’)
and not (SourceImage startswith(‘C:Program FilesWindowsApps’) and SourceImage endswith(‘GamingServices.exe’) and GrantedAccess(‘0x1410′,’0x410’))
and not (SourceImage endswith(‘PROCEXP64.EXE’,’PROCEXP.EXE’,’C:WINDOWSsystem32taskhostw.exe’,’MBAMInstallerService.exe’) and GrantedAccess Contains(‘0x1410′,’0x410′,’0x40’)
and not (SourceImage startswith(‘C:ProgramDataVMwareVMware Tools’) and SourceImage endswith(‘vmtoolsd.exe’)
and not (SourceImage =’C:WINDOWSsystem32svchost.exe’ and GrantedAccess = ‘0x100000’)
and not ((SourceImage =’C:WINDOWSsystem32wbemwmiprvse.exe’ or SourceImage = ‘C:Windowssyswow64MsiExec.exe’ or SourceImage = ‘C:WindowsSystem32msiexec.exe’) and (GrantedAccess =’0x1410′ or GrantedAccess = ‘0x410’))
and not ((SourceImage endswith(‘thor.exe’, ‘thor64.exe’,’aurora-agent.exe’,’aurora-agent-64.exe’) and (GrantedAccess= ‘0x40’ or GrantedAccess= ‘0x1010’))
and not (SourceImage endswith(‘explorer.exe’) and GrantedAccess= ‘0x401’)
and not ((SourceImage= ‘C:Windowssystem32wininit.exe’ or SourceImage= ‘C:WindowsSystem32lsass.exe’) and GrantedAccess= ‘0x1000000’)
and not ((SourceImage=’C:Windowssystem32MRT.exe’) and (GrantedAccess = ‘0x1410’ or GrantedAccess = ‘0x1418’)
and not (SourceImage startwith(‘C:Program Files (x86)MicrosoftEdgeApplication’) and SourceImage endswith(‘Installersetup.exe’))
and not (SourceImage endswith(‘AppDataLocalWebExWebexHost.exe’) and GrantedAccess=’0x401′)
and not ### 更多加白场景，比如服务器上安装的杀软，hids等工具，需要运营人员基于实际情况补充；
规则二：通过任务管理UI界面转储lsass.exe进程；
监控逻辑：eventID = 11 and Image contains “taskmgr.exe” and lower(TargetFilename) contains “lsass.dmp”
规则三：通过pstools工具，如prodump导出lsass.exe进程内存信息；
监控逻辑：eventID = 1 and lower(CommandLine) contains (“-accepteula”,”/accepteula”)
更多票据方面的监控逻辑，详情见：https://2017.zeronights.org/wp-content/uploads/materials/ZN17_Kheirkhabarov_Hunting_for_Credentials_Dumping_in_Windows_Environment.pdf
|
四、企业内没有SOC，如果防御?
企业如没有部署SOC，也可以使用下列链接中针对域控的开源审计平台，自编译后部署。
https://github.com/snorrikris/ADchangeTracker
https://www.codeproject.com/Articles/1002714/Active-Directory-change-tracking
按照上述监控逻辑，建立定时任务进行查询；一旦查出可疑日志数据，即开展排查；
五、域控检测进阶模型
5.1. 域控防御任重道远
希望本篇文章能起到抛砖引玉的效果，让大家对域控的防御有更多的启发，上述监控规则并非是一成不变，需要结合企业内网环境进行配置，同时也需要不断演进。这些规则可用于防御常见的入侵手法，但资深的攻击者：
-
尽可能使用白行为（贴近企业内业务运维路径）方式入侵，比如拿下堡垒机，从堡垒机提取登录域控的RDP客户端配置文件中的密码，顺着路径登录域控；
-
将自己的入侵手法隐匿于日常业务噪音中，比如企业有使用微软系产品（Exchange，SharePoint等），利用这些平台发起喷洒攻击、NTLM-Relay攻击等，而这些平台在工作日，也有不少员工敲错按键，输入错误的密码（企业内员工基数越多大，验证帐号错误的次数也就相应越多），所以之前的喷洒模型就会出现噪音，如果一味的在规则中加白，只会漏过这类隐藏的攻击；
如何检测？需要进阶的防御模型, 比如多类维度的数据关联分析，基于图论的离线分析模型等。期待在后续篇章和大家一起探讨，也欢迎大家多留言、多交流。
5.2. 公众号初衷
“攻不知防，防不知攻”，经历了这么多年的攻防演练，还有不少甲方企业没缓解这个局面，其实挺尴尬的；
首先，不少安全渗透从业者，拿下靶标后，给出甲方企业的修复建议都是比较笼统，甚至一些渗透从业者都没见过IT基础设施的日志，也就无从谈起能给出多少可落地的防御方式；
其次，国内很多企业的防御模型基本不对外公开，各个甲方企业也是封闭造轮子，都觉得自己造的轮子才是最牛逼的，同时，也担心防御规则的外泄会给攻击者带来可趁之机；国内的网站，随便一搜都是一大把的渗透教程，开黑工具的使用技巧；但可落地、有深度的防御，却寥寥无几.
相反，在国外有很多开源社区和企业会选择联防联控，梳理攻击手法和防御规则，比如ATT&CK(链接见https://attack.mitre.org/)和Sigma规则(覆盖了Win、Linux、MacOS、流量以及云端各方面的通用规则,链接见https://github.com/SigmaHQ/sigma/tree/master/rules)；
真心期待国内企业也能如此，我深信：好的防御模型一定要经过多人打磨，一定是经得起挑战的；
“攻是术，防是道，期待更多的志同道合的朋友一起探讨企业内网防御建设之道”，是本公众号的初衷。
原文始发于微信公众号（布鲁队）：攻防演练之域控检测篇
