背景
15号这天我通过了 RTO I 的考试。细想 RTO I 考试的 Lab，好像 Windows Defender（以下简称 WD）的保护做的比 OSEP 考试时还要好，更加严格。
回想起 9 月考 OSEP 的时候，只要你的 Payload 在文件创建（On-Disk Detection）阶段不被 WD flag，那么内存执行阶段并没有触发任何 WD 的检测动作。
这篇文章，我会把 OSEP 中的绕过机制放在 RTO Lab 里一一尝试。第一，考察一下所学是否可以致用；第二，如果不行，能否找到解决方案。
声明
文章没有映射任何考试内容，请不要将文章中的信息作为备考依据。
RTO I Windows Defender （Windows 10）
我们 Host 4个 beacon 文件（1个http_x64.exe, 1个http_x64.xprocess.bin，1个smb_x64.ps1，1个tcp-local_x64.dll）。
我们在 Lab 里下载任意一个，看一下 WD 的反应。
exe 被 flag 并删掉了。
raw 没能幸存。
powershell 没能幸存。
dll 同样没能幸存。
四种 Payload 和对应的 WD 检测类型如上。Windows Defender 成功检测到了默认的 Cobalt Strike Payload。如何使用 Arsenal-Kit 绕过 WD 不在本章讨论范围，参考HackTricks。
Windows Defender On-Disk Detection 绕过
On-Disk Detection
第一步我们要解决的问题就是如何将我们的 Payload 丢到目标机器上而不被检测。
我们将用 C# Shellcode Runner 做测试。
首先生成一个 meterpreter payload（连接到 localhost，之后会用 nc 测试 shellcode 是否成功执行）。
msfvenom -p windows/x64/meterpreter/reverse_https LHOST=127.0.0.1 LPORT=443 -f csharp
塞到代码中。
然后用 VirtualAlloc，CreateThread 执行这个 shellcode。
在没有做任何绕过的情况下，把这个编译（Release，x64）好的文件直接丢到目标机器上看结果。
目标 Lab 不能传输文件，文本只能拷入，所以用如下方式。
certutil -encode payload.exe hi.txt
复制 payload.txt 到目标机器。
certutil -decode hi.txt hi.exe
被检测到了。
第一关是 Signature Detection，shellcode 没有做任何处理，很大可能是 shellcode 直接被检测到了。
简单做下 Casar Cipher 处理。每个字节位移 9 个位置（OFFSET = 9）。
9 个位移之后的 shellcode。
替换掉原来的 shellcode，然后反向操作，在执行时还原 shellcode。
现在的 shellcode 相当于简单 obfuscate 了一下。再次尝试。
还是被检测到。
两个猜想，要么就是 shellcode 简单的处理不足以绕过 Siganature Detection；要么就是 Signature Detection 已经成功绕过，但是 Behavioral Detection 检测到了还原之后的 shellcode。
尝试绕过 Behavioral Detection。
上非标准 Win32API VirtualAllocExNuma（Behavioral Detection 不会模拟此类 API）。
还是被检测到了。
再上 Time Delay（为了保证用户体验，防护机制不会长时间等待，而会跳过诸如 Sleep 等方法，直接模拟之后的代码）。
这次，成功绕过 On-Disk Detection。
基于以上信息，WD 的检测思路应该是先 Signature Detection，没问题的话，上 Behavioral Detection，如果都没问题，就不会 flag 这个文件。
再次验证，把 VirtualAllocExNuma 去掉，对 shellcode 也不做位移处理。只用 Time Delay 的方法。
放到目标机器上测试。
被检测到。说明第一步 Signature Detection 没有过关。
那处理一下 shellcode。
成功绕过检测。
猜想正确。
In-Memory Detection
成功绕过 On-Disk 之后，执行阶段会有内存检测吗？
尝试一下（因为有 AppLocker，拷贝到 \windows\tasks 执行）。
并没有。
放一个 nc.exe 到机器上测试 shellcode 是否成功执行。
这里更改一下 shellcode 的端口到 4444，忘了没有 Admin 权限不能监听 443 端口。
msfvenom -p windows/x64/meterpreter/reverse_https LHOST=127.0.0.1 LPORT=4444 -f csharp
监听 4444 端口。
运行 hi.exe。
收到 meterpreter 连接。
如果目标机器有网络连接，那么就能拿到一个 meterpreter shell 了（不过 Stager 可能被检测到，这里也没法测试，以后有机会再模拟这种情况）。
测试运行 Cobalt Strike 原生 Payload
既然这样的 shellcode 能成功执行，那么 hexdump 出 Cobalt Strike 的原生 Payload，是不是就能执行并拿到 beacon。
这里 hexdump 出 http_x64.xprocess.bin。
hexdump -ve '"0x" 1/1 "%02x,"'
Caesar cipher。
做同样的反向处理，并执行。
编译，放到目标机器上。
同样放到 DataCenter 2022 上，测试会不会被删除。
健在。
那么运行起来看一下会不会被检测到。
文件没有被删除。
总结
这篇文章尝试了一下在 PEN300 课程之外的环境里面，Windows Defender 绕过的应用效果。在 RTO Lab 中看了一下 WD 的 Exclusion 设置，并没有添加任何文件和文件夹。意味着 WD 的运行应该就是真实环境中的那样，并没有任何干预。
之后，再次用相同的 Payload 在 Data Center 2022 上做了一样的测试。
Cobalt Strike 生成的 http_x64.exe 被检测到并删除，而我们的 Payload 健在。
运行起来，虽然看不到输出，但是等一段时间 hi.exe 超时了之后，文件也都没有被删除，说明了内存中也没有被检测到。
至此可以感觉到，Windows Defender 的绕过还是非常简单的。其实有点超乎我的预料，有点太简单了。这意味着可以无视 WD 的存在，随意执行 shellcode。
那么在第三方杀软在场的情况下，这样的绕过表现如何，择日再测。
另外，这里可能对于 In-Memory Detection 有一点误解。In-Memory Detection 说的应该只是 AMSI 相关的检测，是针对 PoweShell，JScript，以及网络下载的数据（DownloadData）等的拦截和查杀。这可能就是为什么 On-Disk 只要绕过了，执行 shellcode 没有任何阻力的原因。以后进一步验证。
KEEP CALM AND HACK AWAY！
