近期暴露面巡检中 ProxyShell 链路仍被用于入口验证与横向探测

背景

最近几轮授权渗透和暴露面复核里，仍能看到 Exchange 旧漏洞链路被当作初始入口验证点，尤其是 ProxyShell 相关路径探测、Autodiscover 异常请求、以及对 ECP/OWA 的批量指纹识别。这个现象不算新漏洞新闻，但属于近期攻防态势里比较稳定的趋势：攻击者不一定追求新 CVE，更多是利用未完整修复、边界设备放行过宽、日志留存不足的老入口。

本文只讨论授权环境下的验证、排查和修复建议，不提供可直接用于未授权入侵的利用链细节。重点放在新闻动态里更有价值的部分：近期可观察到的攻击面变化、日志留痕、验证边界和处置方法。

问题定位

在授权渗透测试或安全巡检中，如果目标暴露 Exchange 服务，建议先明确三个边界：

• 是否仍对公网开放 /owa/、/ecp/、/autodiscover/、/mapi/ 等路径。
• Exchange 版本和补丁是否覆盖 ProxyShell 相关修复，不能只看系统补丁，要看 Exchange CU/SU 状态。
• IIS 日志、Exchange 日志、Windows 事件日志是否足够回溯最近 30 到 90 天的访问记录。

一个常见问题是：资产侧显示 Exchange 已打补丁，但 IIS 日志里仍存在大量历史探测；另一个问题是反向代理、WAF 或负载均衡隐藏了真实客户端 IP，导致后续溯源和封禁失效。

技术分析

近期看到的探测通常有几个特征：

• 请求集中在 /autodiscover/autodiscover.json、/ecp/、/powershell/、/mapi/ 等路径。
• User-Agent 较杂，有批量扫描器特征，也有伪装成常见浏览器的请求。
• 同一来源 IP 会先做版本探测，再尝试异常路径组合。
• 若边界代理未保留 X-Forwarded-For，IIS 日志中只会看到代理 IP，增加排查难度。

排查时不要只按 500 错误查，也要关注 200、302、401、403。很多扫描器并不一定触发明显错误，尤其是在认证前接口上，401 本身也可能说明路径存在并被识别。

操作步骤

建议按以下流程处理，适合授权渗透测试、应急复核和红队后的蓝队验证：

• 确认资产：从 CMDB、证书透明日志、DNS 解析、边界代理配置中确认 Exchange 暴露域名。
• 确认版本：在内网管理侧查看 Exchange 版本、CU、SU，避免仅通过外部 Banner 判断。
• 检查日志：重点看 IIS W3C 日志、Exchange HttpProxy 日志、PowerShell 日志和 Windows 安全日志。
• 判断异常：基于路径、时间、源 IP、状态码、User-Agent 聚合分析。
• 验证边界：只做非破坏性验证，不上传文件、不写入 Web 目录、不尝试获取邮箱数据。
• 修复复核：补丁、访问控制、代理头、日志留存、EDR 告警规则同步检查。

代码/命令示例

下面是一个用于授权环境日志排查的 PowerShell 示例，用来从 IIS 日志中筛选 Exchange 相关异常路径。路径需要按实际环境修改：

$LogPath = "C:\inetpub\logs\LogFiles\W3SVC1\*.log"
$Patterns = @(
    "autodiscover.json",
    "/ecp/",
    "/powershell/",
    "/mapi/",
    "X-BEResource",
    "X-AnonResource"
)

Get-ChildItem $LogPath | ForEach-Object {
    Select-String -Path $_.FullName -Pattern $Patterns -SimpleMatch
} | ForEach-Object {
    $line = $_.Line
    if ($line -notmatch "^#") {
        $parts = $line -split " "
        [PSCustomObject]@{
            LogFile   = $_.Path
            Time      = ($parts[0] + " " + $parts[1])
            ClientIP  = $parts[8]
            Method    = $parts[3]
            UriStem   = $parts[4]
            UriQuery  = $parts[5]
            Status    = $parts[11]
            UserAgent = $parts[9]
        }
    }
} | Sort-Object Time | Export-Csv .\exchange_suspicious_iis.csv -NoTypeInformation -Encoding UTF8

如果前面有 Nginx 或其他反向代理，需要确认是否正确传递真实 IP。Nginx 示例：

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

同时建议在 IIS 日志字段中记录 X-Forwarded-For，否则后续只能看到代理地址。Windows 上可通过 IIS 管理器的 Logging 配置添加自定义字段，字段名一般为 X-Forwarded-For，来源选择 Request Header。

重点日志位置

风险与修复建议

• 补丁层面：确认 Exchange CU/SU 已更新到受支持版本。很多环境只打 Windows 更新，不更新 Exchange 安全更新，这是常见误区。
• 暴露面控制：公网只开放必要入口，管理类路径建议通过 VPN、零信任网关或固定源 IP 访问。
• 日志留存：IIS 和 Exchange 日志至少保留 90 天，磁盘不足时优先做集中采集，不要简单关闭日志。
• 代理配置：保留真实客户端 IP，并在 SIEM 中基于 X-Forwarded-For 建规则。
• 权限边界：限制 Exchange 服务器本地管理员数量，检查是否存在异常邮箱导出权限、应用模拟权限。
• 检测规则：对 autodiscover.json 异常组合、X-BEResource、X-AnonResource、异常远程 PowerShell 建立告警。
• 复盘验证：修复后再次从外部做非破坏性验证，确认异常路径不可被利用，日志也能准确记录来源。

经验上，Exchange 类入口最大的风险不只是单点漏洞，而是“补丁不完整 + 公网暴露 + 日志不可回溯 + 权限边界松散”的组合。授权测试时应把验证重点放在链路闭环，而不是单纯证明某个 CVE 是否存在。

总结

从近期攻防动态看，老漏洞链路仍是外部入口的重要组成部分，尤其在 Exchange、VPN、边界代理这类长期暴露服务上更明显。对企业侧来说，新闻价值不只在“又有扫描活动”，而在于能否把情报转成可执行动作：确认资产、核实补丁、检查日志、收紧访问、验证修复。授权渗透测试中也建议以最小影响方式完成验证，避免把漏洞复现变成不必要的业务风险。

这个链路现在确实还经常被拿来做“探活 + 找可横向资产”，尤其是暴露在公网的老 Exchange 或曾经补丁不完整的节点。排查时不要只看是否打了 KB，建议把“是否被打过”和“是否仍可被利用”分开看。

几个比较有效的检查点：

• IIS 日志：重点看 /autodiscover/autodiscover.json、/mapi/nspi/、/powershell/、/ecp/ 的异常组合访问，尤其是同一源 IP 短时间内串联访问。
• Exchange PowerShell 虚拟目录：确认不该公网开放的 /powershell 没有暴露，或者至少有反代层访问控制。
• 异常 WebShell：重点查 aspnet_client、owa/auth、ecp 目录下新增的 .aspx。
• 横向探测痕迹：被打中的 Exchange 往往会继续访问内网 445、135、5985、389、88、3389，防火墙或 EDR 流量日志里能看到。

可以先用下面几个命令做快速筛查：

# 1. 搜 IIS 日志中的 ProxyShell 常见路径
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\u_ex*.log" `
  -Pattern "autodiscover\.json|/mapi/nspi|/powershell|/ecp/.*\.js|X-Rps-CAT|Email=autodiscover" |
  Select-Object Path,LineNumber,Line

# 2. 查 Exchange 目录下近期新增/修改的 aspx
Get-ChildItem "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy" -Recurse -Include *.aspx |
  Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-30)} |
  Select-Object FullName,Length,LastWriteTime

Get-ChildItem "C:\inetpub\wwwroot\aspnet_client" -Recurse -Include *.aspx |
  Select-Object FullName,Length,LastWriteTime

# 3. 看是否有异常 PowerShell 进程链
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-PowerShell/Operational"; Id=4103,4104} |
  Where-Object {$_.Message -match "New-MailboxExportRequest|Set-OabVirtualDirectory|webshell|DownloadString|Invoke-WebRequest"} |
  Select-Object TimeCreated,Id,Message

# 4. 查 WinRM / 远程命令相关痕迹
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624} |
  Where-Object {$_.Properties[8].Value -in 3,10} |
  Select-Object TimeCreated,Message

如果环境里有 SIEM，可以加一条简单相关规则：同一源 IP 在 10 分钟内访问过 autodiscover.json，随后访问 /powershell 或 /ecp，优先级可以拉高。

index=iis sourcetype=iis
(uri_path="/autodiscover/autodiscover.json" OR uri_path="/powershell*" OR uri_path="/ecp*")
| stats values(uri_path) as paths min(_time) as first max(_time) as last count by src_ip, cs_user_agent
| where mvcount(paths) >= 2 AND like(mvjoin(paths, ","), "%autodiscover%") AND (like(mvjoin(paths, ","), "%powershell%") OR like(mvjoin(paths, ","), "%ecp%"))
| convert ctime(first) ctime(last)

处置上建议注意两点：

1. 不要只删 WebShell。如果发现落地文件，要同步查是否创建了异常邮箱导出请求、计划任务、本地用户、Exchange RBAC 角色变更。
2. 收敛 Exchange 出站权限。很多入口验证之后会马上做内网探测，Exchange 服务器不应该能随意访问所有内网段的 SMB/WinRM/RDP。至少限制到必要 DC、邮件网关、备份系统。

另外，如果前面有 WAF/反代，建议把 /powershell、/ecp、/mapi 的访问日志也拉出来对齐时间线。很多时候源站 IIS 只看到反代 IP，真正的攻击源和 UA 特征在边界层日志里。