在《WMI攻守之道》中，我们通过分析WMI产生的流量数据了解到WMI通过DCE/RPC协议进行通信，这个协议主要由DCOM远程激活机制和NTLM身份认证。DCOM远程激活是WMI远程连接的必要步骤，所以可以通过检测DCOM远程激活，进而检测WMI连接。

在DCSync技术没有出现之前，攻击者要想拿到域内用户的hash，就只能在域控制器上运行 Mimikatz 或 Invoke-Mimikatz去抓取密码hash，但是在2015 年 8 月份， Mimkatz新增了一个主要功能叫"DCSync"，使用这项技术可以有效地 "模拟" 域控制器并从目标域控上请求域内用户密码hash。这项技术为当下域渗透提供了极大地便利，可以直接远程dump域内hash，另外也衍生出很多的攻击方式，所以我想专门做一项DCSync技术的专题。

学习beacon生成和调试分析和检测beacon的过程中的一些记录。

注册表是windows的重要数据库，存放了很多重要的信息以及一些应用的设置，对注册表进行监控并防止篡改是十分有必要的。在64位系统下微软提供了CmRegisterCallback这个回调函数来实时监控注册表的操作，那么既然这里微软提供了这么一个方便的接口，病毒木马自然也会利用，这里我们就来探究其实现的原理和如何利用这个回调函数进行对抗

Windows Management Instrumentation(Windows 管理规范) 即WMI，是微软实现的基于Web的企业管理(WBEM)。WMI使用通用信息模型(CIM)来表示系统、应用程序、网络、设备和其他托管组件。WMI支持本地和远程访问。WMI底层基于分布式组件对象模型(DCOM)或者Windows远程管理(WinRM)。程序员们可以使用脚本语言(例如powershell)，或者C++，通过COM技术与WMI进行交互。本文行文仓促，如有错误，请各位积极指正。

基于资源的约束委派（Resource Based Constrained Delegation，RBCD）是在 Windows Server 2012 中新引入的功能，与传统的约束委派相比，它不再需要拥有 SeEnableDelegationPrivilege 特权的域管理员去设置相关属性，并且将设置委派的权限交换给了服务资源自身，即服务自己可以决定谁可以对我进行委派。基于资源的约束性委派的关键在于 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的设置。

我们知道一般EDR对可疑程序进行监控一般都会采用往程序里注入到检测的进程中，通过hook一些敏感的3环API来判断程序是否进行一些恶意操作，那么我们可以通过添加流程缓解措施和漏洞利用保护参考来实现保护，从而防止EDR的dll注入对进程进行检测。

2022 年 5 月 10 日，微软发布补丁修复了一个 Active Directory 域权限提升漏洞（CVE-2022–26923，Certifried）。该漏洞是由于对用户属性的不正确获取，允许低权限用户在安装了 Active Directory 证书服务（AD CS）服务器角色的 Active Directory 环境中将权限提升至域管理员。这一漏洞最早由安全研究员 Oliver Lyak（@ly4k_）在 2021 年 12 月 14 日通过 Zero Day Initiative 向微软报告，Microsoft 在 2022 年 5 月的安全更新中对其进行了修补。

ETW全称为Event Tracing for Windows，即windows事件跟踪，它是Windows提供的原生的事件跟踪日志系统。由于采用内核层面的缓冲和日志记录机制，所以ETW提供了一种非常高效的事件跟踪日志解决方案，本文基于ETW探究其攻与防的实现

本篇文章大部分翻译并复现自 Will Schroeder（@harmj0y）和 Lee Christensen（@tifkin_） 在 2021 年的 BlackHat 大会上所发布的白皮书 《Certified Pre-Owned - Abusing Active Directory Certificate Services》，其中详细介绍了关于 Active Directory Certificate Services 的滥用方法，关于 Active Directory 证书服务的攻击方法第一次系统性的进入我们的视野。

我们要想在32位下实现进程保护很简单，通过SSDT hook重写函数即可实现，但是在64位系统下因为引入了PG和DSE的原因，导致SSDT hook实现起来处处受限。但微软同样为了系统安全，增加了一个对象回调函数的接口，利用该回调可以实现对对象请求的过滤保护自身的进程，目前大部分64位下的安全软件保护机制都是基于该方法，我们深入进行探究

一般的shellcode加载到内存都是通过LoadLibrary和GetProcAddress来获取函数进行shellcode加载，亦或是通过VirtualAllocEx远程申请一块空间来放入shellcode的地址进行加载。为了隐蔽，攻击者通常会通过PEB找到InLoadOrderModuleList链表，自己去定位LoadLibrary函数从而规避杀软对导入表的监控。攻击者先把shellcode加密，在写入时解密存放到内存空间，使用基于文件检测的方法，是无能为力的，那么这种无落地的方式，最终都会在内存中一览无余。

我们知道在x64里面，从3环进入0环会调用syscall，那么如果是32位的程序就需要首先转换为x64模式再通过syscall进入0环，这里就会涉及到一系列64位寄存器的操作，我们通过探究其实现原理来达到隐藏数据和反调试的效果。

攻与防都是相对的，只有掌握细节才能更好的对抗。

首先，我们来整体了解一下实际用户请求访问域内某个服务时会经过哪些步骤：

1、用户将AS-REQ数据包发送给KDC（Key Distribution Centre，密钥分发中心，此处为域控），进行身份认证。
2、KDC验证用户的凭据，如果凭据有效，则返回TGT（Ticket-Granting Ticket，票据授予票据）。
3、如果用户想通过身份认证，访问某个服务（如CIFS），那么他需要发起（Ticket Granting Service，票据授予服务）请求，请求中包含TGT以及所请求服务的SPN（Service Principal Name，服务主体名称）。
4、如果TGT有效并且没有过期，TGS会创建用于目标服务的一个服务票据。服务票据使用服务账户的凭据进行加密。
5、用户收到包含加密服务票据的TGS响应数据包。
6、最后，服务票据会转发给目标服务，然后使用服务账户的凭据进行解密。