Report Type: EXP

Threat Category: Actively Exploited Microsoft Exchange Server OWA XSS and Spoofing Vulnerability

Assessment Date: May 15, 2026

Primary Impact Domain: Enterprise Communications Integrity

Secondary Impact Domains: Mailbox-Control Abuse; Business Email Compromise Exposure; Sensitive Communications Exposure; Identity and Session Assurance; Exchange Administrative-Control Governance; Legal, Compliance, and Executive-Trust Risk

Affected Asset Class: On-Premises Microsoft Exchange Server, Outlook Web Access, Exchange-Hosted Mailboxes, High-Value Mailboxes, Exchange Administrative Controls, Hybrid Exchange Infrastructure

Threat Objective Classification: Communications-Integrity Degradation, Mailbox-Control Manipulation, Sensitive-Message Access, Message Redirection, Concealment, Fraud Enablement, and Conditional Host-Level Escalation

BLUF

‍ Microsoft Exchange Server XSS and spoofing activity through Outlook Web Access creates enterprise risk by weakening confidence in trusted email access, mailbox interaction, and Exchange communications governance. The risk is driven by abuse of OWA-rendered content, spoofed interface context, authenticated sessions, mailbox rules, forwarding controls, delegate access, mailbox permissions, transport rules, and administrative workflows that can make unauthorized communications access or manipulation more plausible. The threat posture is elevated because the activity may resemble normal webmail use, mailbox administration, helpdesk support, compliance work, hybrid Exchange operations, or approved configuration changes. Executive action is required to validate Exchange exposure, confirm patch and mitigation status, prioritize high-value mailboxes, preserve evidence, review suspicious mailbox-control changes, and determine whether OWA-centered activity created business email compromise, sensitive communications exposure, legal, compliance, operational, or executive-trust risk.

Executive Risk Translation

Microsoft Exchange Server XSS and spoofing activity through Outlook Web Access shifts business risk from a narrow webmail vulnerability concern to an enterprise communications-integrity issue. The primary concern is not only whether Exchange is vulnerable, but whether OWA access, mailbox rules, forwarding behavior, delegate permissions, transport configuration, identity sessions, and Exchange administration can still be trusted after suspicious activity. If abuse occurred, response may expand into high-value mailbox scoping, forwarding and rule review, delegate and permission validation, identity-session review, transport-rule assessment, administrator activity review, executive communications analysis, legal review, compliance assessment, and board-level reporting. This creates financial, operational, data-protection, fraud, legal, compliance, and governance exposure beyond the Exchange server itself.

S3 — Why This Matters Now

· Exchange can appear available and stable while unauthorized mailbox access, forwarding, delegation, or transport changes undermine trust in business communications.

· OWA is a high-value exposure surface because it provides access to executive communications, financial workflows, legal correspondence, security alerts, helpdesk messages, shared mailboxes, service mailboxes, and hybrid-administration functions.

· XSS and spoofing activity can create meaningful business impact without immediate malware execution, web-shell placement, credential dumping, or confirmed server takeover.

· CISA KEV inclusion confirms active exploitation and strengthens remediation urgency, especially for federal agencies, regulated organizations, and risk-managed enterprises that prioritize vulnerabilities based on known exploitation.

· Mailbox rules, forwarding, delegate access, mailbox permissions, transport rules, and message access can support fraud, monitoring, concealment, data exposure, or business-process manipulation.

· Legitimate webmail use, mailbox administration, helpdesk activity, compliance workflows, migration work, and hybrid management can resemble suspicious activity without strong business context.

· Investigation confidence depends on whether the organization can reconstruct OWA access, mailbox changes, administrator actions, identity sessions, and high-value mailbox activity with sufficient evidence.

S4 — Key Judgments

· Microsoft Exchange Server XSS and spoofing activity through OWA creates a high-priority communications-integrity and mailbox-control risk when suspicious webmail interaction can be converted into unauthorized access, forwarding, delegation, permission changes, transport manipulation, or sensitive-message review.

· The primary business risk is loss of confidence that Exchange-hosted communications, mailbox access, administrative changes, and high-value mail workflows remain trustworthy.

· The strongest enterprise risk signal is suspicious OWA activity followed by mailbox-rule creation, forwarding behavior, delegate changes, mailbox permission changes, suspicious message access, identity misuse, administrative changes, or unusual Exchange server behavior.

· OWA exposure or affected-version status alone should not be treated as confirmed compromise, but it requires urgent review when combined with suspicious session behavior, mailbox-control changes, identity concerns, or administrative activity.

· High-value mailbox involvement materially increases risk, especially where executive, finance, legal, security, helpdesk, shared, service, or hybrid-administration mailboxes are affected.

· Host compromise should not be assumed unless independent evidence supports escalation beyond OWA and mailbox-control abuse.

· Executive risk reduction depends on patch validation, OWA exposure management, high-value mailbox prioritization, mailbox and administrator audit readiness, identity-session review, and clear classification of suspicious activity.

S5 — Executive Risk Summary

Business Risk

Microsoft Exchange Server XSS and spoofing activity through OWA can create material communications-integrity, fraud, data-protection, operational, legal, compliance, and security-governance risk when suspicious webmail interaction leads to unauthorized mailbox access, forwarding, inbox-rule creation, delegate changes, mailbox permission changes, transport-rule manipulation, sensitive-message review, or administrative abuse. Risk increases when affected mailboxes belong to executives, finance teams, legal teams, security teams, helpdesk functions, shared operational groups, service accounts, or hybrid Exchange administrators.

Technical Cause

The risk is driven by abuse of Outlook Web Access rendering, spoofed interface context, authenticated session behavior, mailbox-control workflows, Exchange administrative paths, and supporting identity context. Suspicious activity may include abnormal OWA access, unusual session behavior, mailbox-rule creation, forwarding configuration, delegate modification, mailbox permission changes, transport-rule changes, suspicious message access, Exchange administrative activity, or abnormal Exchange behavior following OWA-centered activity.

Threat Posture

The threat posture is elevated because OWA-centered abuse may not resemble conventional malware execution or server takeover. The risk is amplified when OWA is internet-facing, Exchange patch state is uncertain, high-value mailboxes are exposed, mailbox audit logging is incomplete, administrator activity is poorly documented, identity visibility is weak, forwarding and delegation baselines are immature, or Exchange control-plane changes are not tightly governed. Successful abuse may create business email compromise, sensitive communications exposure, fraud enablement, compliance pressure, or executive-trust concerns without a clear host-compromise pattern.

Executive Decision Requirement

Executives must require validation of Exchange patch and mitigation status, OWA exposure, high-value mailbox risk, mailbox audit coverage, administrator audit coverage, identity-session visibility, forwarding and delegation governance, transport-rule review, Exchange administrative-change control, log retention, and investigation readiness. Response leadership should also confirm that suspicious OWA, mailbox, identity, administrative, and Exchange activity is reviewed historically rather than closed solely because there is no malware, web shell, or confirmed host compromise.

S6 — Executive Cost Summary

Microsoft Exchange Server XSS and spoofing activity through OWA creates financial exposure based on Exchange exposure, high-value mailbox involvement, mailbox-control change scope, forwarding and delegation risk, transport-rule impact, identity-session uncertainty, audit-log completeness, sensitive communications exposure, business email compromise potential, legal or regulatory obligations, and the degree to which suspicious activity may have enabled unauthorized communication access, redirection, monitoring, fraud, or downstream misuse.

Low Impact Scenario

Rapid assessment confirms Exchange systems are patched or mitigated; OWA exposure is understood; mailbox, administrator, identity, and web-access records are available; no suspicious OWA activity is tied to mailbox rules, forwarding, delegate changes, permission changes, transport-rule modification, administrative abuse, unusual message access, identity misuse, or abnormal Exchange behavior; and high-value mailboxes show no unauthorized access or control-plane changes. Response remains limited to patch validation, exposure review, targeted hunting, mailbox-control sampling, high-value mailbox assurance, and executive tracking; estimated impact $250K to $1M.

Moderate Impact Scenario

One or more Exchange environments show suspicious OWA activity, unfamiliar session behavior, mailbox-control changes, forwarding or delegate anomalies, permission changes, transport-rule concerns, identity concerns, administrative activity, telemetry gaps, or high-value mailbox access concerns without confirmed broad data exposure, sustained adversary control, major fraud loss, regulated-data impact, or host compromise. Response requires log preservation, mailbox and transport-rule review, high-value mailbox scoping, identity-session review, administrator activity review, credential-risk assessment, limited forensic analysis, legal assessment, business-unit coordination, and executive reporting; estimated impact $1M to $7.5M.

High Impact Scenario

Confirmed or strongly suspected OWA-centered abuse affects executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, helpdesk mailboxes, shared operational mailboxes, service mailboxes, hybrid-administration identities, or Exchange administrative controls. Evidence may include unauthorized forwarding, mailbox-rule creation, delegate changes, mailbox permission changes, transport-rule manipulation, sensitive-message access, identity-session misuse, administrative expansion, unusual Exchange behavior, business email compromise, legal or regulated-data exposure, or host-level escalation. Response may require expanded forensics, mailbox reconstruction, transport and forwarding remediation, credential resets, session revocation, Exchange configuration review, executive communications assessment, fraud investigation, legal and regulatory review, insurance coordination where applicable, customer or partner communications readiness, and board-level incident governance; estimated impact $7.5M to $30M or higher.

S6A — Key Cost Drivers

· Number and criticality of affected Exchange systems, OWA-exposed assets, hybrid Exchange servers, and high-value mailboxes.

· Involvement of executive, finance, legal, security, helpdesk, shared, service, privileged, or hybrid-administration mailboxes.

· Evidence of suspicious OWA activity, unfamiliar sessions, mailbox-rule creation, forwarding changes, delegate updates, mailbox permission changes, transport-rule modification, message access, or mailbox search.

· Presence of sensitive communications, regulated data, privileged legal material, financial approvals, customer information, security alerts, credentials, operational secrets, or executive correspondence inside affected mailboxes.

· Potential for business email compromise, fraudulent payment redirection, unauthorized monitoring, confidential communications exposure, or manipulation of trusted business workflows.

· Breadth and governance quality of forwarding, delegation, mailbox permission, transport-rule, and Exchange administrative-change workflows.

· Completeness of mailbox audit records, administrator audit records, identity records, OWA access records, Exchange records, and supporting investigation evidence.

· Ability to distinguish approved OWA usage, helpdesk activity, mailbox delegation, transport-rule maintenance, migration activity, compliance workflows, hybrid administration, and incident-response actions from suspicious activity.

· Scope of required mailbox review, forwarding cleanup, delegate validation, permission review, transport-rule inspection, identity-session revocation, credential reset, and administrator activity investigation.

· Need for legal review, regulatory assessment, fraud investigation, executive communications assurance, cyber insurance coordination, business-unit notification, customer assurance, or board reporting.

Most Likely Scenario Justification

Moderate scenario is most likely when suspicious OWA-centered activity requires historical review, mailbox-control validation, identity-session analysis, high-value mailbox scoping, and administrative-change assessment, but available evidence does not confirm broad sensitive-data exposure, major fraud loss, sustained adversary control, enterprise-wide Exchange compromise, or host-level takeover. The estimate moves toward the lower end when evidence confirms narrow exposure, approved administrative context, no suspicious forwarding, no unauthorized delegation, no mailbox permission abuse, no transport-rule manipulation, no suspicious message access, and no identity escalation. The estimate moves toward the upper end when high-value mailboxes are involved, forwarding or delegation cannot be confidently explained, audit coverage is incomplete, identity sessions are suspicious, administrative activity is poorly documented, or sensitive communications exposure cannot be ruled out.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether suspicious OWA activity, mailbox-control abuse, forwarding, delegation, mailbox permission changes, transport-rule manipulation, suspicious message access, identity misuse, evidence gaps, or incomplete forensic scoping affected mailboxes containing regulated data, customer information, legal communications, financial records, security alerts, executive correspondence, contractual records, or business-critical operational data. CISA KEV inclusion strengthens the compliance and governance context because it confirms known exploitation and creates heightened remediation expectations, particularly for Federal Civilian Executive Branch agencies under BOD 22-01 and for regulated or risk-managed organizations that use KEV status to prioritize vulnerability remediation.

Risk Register Entry

Risk Title

Microsoft Exchange OWA XSS and Spoofing Communications-Integrity Risk

Risk Description

Adversaries may abuse Outlook Web Access rendering, spoofed interface context, authenticated session behavior, mailbox rules, forwarding controls, delegate access, mailbox permissions, transport rules, identity sessions, or Exchange administrative workflows to weaken the integrity of enterprise communications, enable unauthorized mailbox access, redirect sensitive messages, support business email compromise, conceal activity, expose regulated or privileged communications, or generate downstream fraud, operational, compliance, legal, and governance exposure. CISA KEV listing increases remediation urgency and governance significance because the vulnerability is recognized as actively exploited.

Likelihood

Medium to High.

Impact

Severe.

Risk Rating

Critical.

Annualized Risk Exposure

Estimated $1.5M to $15M or higher based on Exchange exposure, high-value mailbox count, OWA accessibility, patch and mitigation status, mailbox audit coverage, administrator audit coverage, identity visibility, forwarding and delegation governance, transport-rule control, sensitive communications scope, business email compromise potential, investigation burden, containment requirements, legal obligations, and regulatory exposure.

S7 — Risk Drivers

· OWA is a trusted business access path that can expose sensitive mailboxes, privileged communications, and Exchange control-plane workflows.

· XSS and spoofing activity can create business impact through user-interface trust abuse, session misuse, mailbox manipulation, or administrative activity without immediate host compromise.

· Mailbox rules, forwarding behavior, delegate access, mailbox permissions, and transport rules are high-value control-plane functions that require strong governance and auditability.

· High-value mailboxes increase business impact when they contain executive communications, financial approvals, legal material, security alerts, helpdesk messages, operational correspondence, or hybrid-administration context.

· Legitimate Exchange administration, helpdesk support, compliance workflows, mailbox delegation, migration activity, and hybrid management can resemble suspicious activity without strong account, source, timing, ticket, and baseline context.

· Incomplete mailbox audit, administrator audit, identity, OWA, or Exchange records can materially delay scoping and confidence.

· Short log-retention windows can prevent correlation between suspicious OWA activity and delayed mailbox-control changes or later identity misuse.

· Network-only visibility is insufficient because the core risk may be mailbox, session, identity, administrative, or communications-control oriented.

S8 — Bottom Line for Executives

Microsoft Exchange Server XSS and spoofing activity through OWA should be treated as a high-priority enterprise communications-integrity and mailbox-control risk. The key executive concern is not only whether Exchange is patched, but whether OWA access, mailbox rules, forwarding, delegation, permissions, transport controls, identity sessions, and Exchange administration can be trusted after suspicious activity. Risk reduction depends on patch validation, OWA exposure management, high-value mailbox prioritization, mailbox and administrator audit readiness, identity-session review, forwarding and delegation governance, transport-rule control, evidence preservation, and clear incident classification. Organizations should prioritize this report because OWA-centered abuse can create business email compromise exposure, sensitive communications risk, legal and compliance pressure, executive-trust concerns, and board-level governance requirements without always producing obvious malware or server compromise.

S9 — Board-Level Takeaway

Microsoft Exchange OWA XSS and spoofing abuse can turn a trusted enterprise communications platform into a control-plane and communications-integrity failure point. The board-level concern is that Exchange may appear available and stable while mailbox rules, forwarding, delegate access, permissions, transport rules, identity sessions, or administrative actions create unauthorized access, redirection, monitoring, or fraud-enablement risk. Leadership should require evidence that exposed Exchange systems are patched or mitigated, OWA access is understood, high-value mailboxes are prioritized, mailbox and administrator audit records are available, suspicious forwarding and delegation can be detected, identity sessions can be reviewed, Exchange administrative changes are governed, and suspicious activity can be classified with sufficient evidence. This report supports governance decisions around Exchange exposure, communications trust, mailbox-control security, executive-mailbox protection, evidence readiness, incident escalation, and enterprise confidence in Microsoft Exchange as a trusted business communications platform.

Figure 2

S10 — Threat Overview

Microsoft Exchange Server XSS and spoofing activity through Outlook Web Access refers to abuse of the trusted webmail interface, rendered content, authenticated session context, mailbox-control workflows, and Exchange administrative paths in a way that can weaken confidence in enterprise communications. The activity is not best understood as a conventional malware family, standalone network intrusion pattern, or automatic server-takeover event. It is a communications-integrity and mailbox-control risk centered on whether OWA access, mailbox behavior, identity sessions, administrative actions, and high-value communications can still be trusted after suspicious activity.

The core risk is that an attacker may attempt to use OWA-centered interaction, spoofed interface context, user trust abuse, or authenticated session behavior to influence mailbox activity, redirect messages, create or modify rules, change delegate access, alter mailbox permissions, manipulate transport behavior, or access sensitive communications. The most important business question is whether the organization can prove that Exchange-hosted communications, high-value mailboxes, and mailbox-control workflows remained trustworthy during and after suspicious OWA activity.

This activity is difficult to assess through single-event evidence because normal OWA usage, helpdesk action, mailbox delegation, Exchange administration, compliance workflows, migration activity, and hybrid-management operations can produce similar business artifacts. High-confidence assessment depends on correlation across OWA access, mailbox changes, administrator actions, identity sessions, high-value mailbox involvement, forwarding behavior, transport-rule activity, approved-change context, and evidence preservation.

Microsoft Exchange Server XSS and spoofing activity through OWA should therefore be treated as a communications-integrity and mailbox-control-plane risk. The response objective is not only to identify suspicious webmail activity, but to determine whether the organization can validate mailbox trust, administrative governance, high-value communications protection, and business-process integrity for affected Exchange environments.

S11 — Threat Classification and Type

Threat Type

Enterprise communications-integrity and mailbox-control-plane abuse risk.

Threat Sub-Type

Outlook Web Access XSS, spoofed interface context, authenticated session misuse, mailbox-rule abuse, forwarding manipulation, delegate and permission abuse, transport-rule misuse, and Exchange administrative-control abuse.

Operational Classification

Webmail-interface abuse, session-adjacent activity, mailbox-control-plane abuse, identity-adjacent activity, administrative-control-plane activity, and business-email-compromise-adjacent risk.

Primary Function

The primary function is to weaken the trustworthiness of Exchange-hosted communications by abusing OWA interaction, mailbox controls, forwarding paths, delegate relationships, mailbox permissions, transport rules, identity sessions, or administrative workflows. The activity may support unauthorized mailbox access, sensitive-message exposure, communications monitoring, message redirection, fraud enablement, concealment, business-process manipulation, or downstream legal, compliance, operational, and governance exposure.

S12 — Campaign or Activity Overview

Microsoft Exchange Server XSS and spoofing activity through OWA does not require a single fixed campaign pattern. The activity can appear as opportunistic webmail abuse, targeted high-value mailbox interaction, session misuse, business email compromise preparation, administrative-control-plane abuse, or a broader attempt to manipulate trusted communications. The most important activity pattern is not a single exploit string, payload, URI, message artifact, or tool name, but the relationship between suspicious OWA activity and surrounding mailbox, identity, administrative, and business context.

Relevant activity may begin with access to OWA, interaction with crafted or spoofed interface content, suspicious authenticated session behavior, unusual access to a high-value mailbox, mailbox-control changes, or administrative activity affecting Exchange configuration. In some cases, the activity may remain limited to mailbox access, rules, forwarding, delegation, permissions, or transport behavior. In other cases, it may escalate into administrative misuse, broader identity concern, unusual Exchange behavior, or confirmed host-level activity.

The strongest enterprise concern arises when suspicious OWA activity, unfamiliar session context, high-value mailbox access, forwarding changes, delegate updates, mailbox permission changes, transport-rule modification, administrator activity, or sensitive-message access appear together. The concern increases further when the affected mailbox belongs to an executive, finance function, legal team, security team, helpdesk function, shared operational group, service account, privileged user, or hybrid Exchange administrator.

This activity should be assessed through a behavior-led model. Static exploit indicators, isolated XSS-like strings, single request paths, unusual user agents, public proof-of-concept artifacts, or one-off OWA anomalies should not drive the primary risk judgment. The more durable question is whether OWA and Exchange control mechanisms were used in a way that falls outside approved identity, mailbox, administrative, business, and change-management context.

S13 — Targets and Exposure Surface

Microsoft Exchange Server XSS and spoofing activity through OWA is most relevant to on-premises Exchange environments where Outlook Web Access is internet-facing, high-value mailboxes are accessible through webmail, and mailbox-control or administrative workflows influence business communications. The exposure surface is not limited to one Exchange component. It spans OWA access, IIS and Exchange web paths, mailbox rules, forwarding configuration, delegate access, mailbox permissions, transport rules, administrative actions, identity sessions, hybrid Exchange workflows, and organizational change governance.

High-priority targets include mailboxes and Exchange workflows where unauthorized access or manipulation would create disproportionate business impact. This includes executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, helpdesk mailboxes, shared operational mailboxes, service mailboxes, privileged administrator mailboxes, compliance mailboxes, and hybrid-administration identities. These targets create elevated risk because misuse may lead to fraudulent communication, payment redirection, privileged-message exposure, legal-data exposure, security-alert suppression, operational misdirection, or concealment of attacker activity.

The exposure surface also includes Exchange administrators, helpdesk processes, mailbox delegation workflows, transport-rule governance, remote-access paths, reverse proxies, WAFs, identity-provider sessions, mailbox audit records, administrator audit records, and log-retention practices. Weakness in any of these areas can reduce confidence that OWA activity and mailbox-control changes remained authorized, traceable, and business-justified.

S14 — Sectors / Countries Affected

Sectors Affected

· Financial services, banking, insurance, payment-processing, accounting, and business-services organizations.

· Healthcare, life sciences, hospitals, clinics, medical research, and regulated care environments.

· Government, defense, public-sector, municipal, and public-administration organizations.

· Legal, consulting, professional-services, audit, advisory, and corporate-services firms.

· Technology, software development, managed services, cloud operations, engineering, and enterprise IT organizations.

· Energy, utilities, manufacturing, transportation, logistics, and critical infrastructure operators.

· Education, research institutions, universities, academic medical centers, and distributed campus environments.

· Retail, ecommerce, customer-support, franchise, and distributed workforce environments.

· Telecommunications, managed service providers, outsourcing providers, and organizations operating shared support functions.

· Organizations with executive mailboxes, finance workflows, legal communications, helpdesk mailboxes, shared operational mailboxes, service mailboxes, hybrid Exchange dependencies, or sensitive business communications hosted in Exchange.

· Organizations relying on Outlook Web Access, on-premises Exchange Server, Exchange hybrid administration, mailbox delegation, transport-rule workflows, and Exchange-hosted communications for business-critical operations.

Countries Affected

· Global.

· Exposure is not limited to a single country or region because Microsoft Exchange, Outlook Web Access, hybrid Exchange deployments, and business-critical mailbox workflows are used globally.

· Countries with large enterprise Exchange deployments, regulated industries, public-sector Exchange environments, financial institutions, legal and professional-services firms, managed service ecosystems, or high-value executive communications may face elevated operational exposure.

Overall Targeting Probability

Medium to High.

Microsoft Exchange Server XSS and spoofing activity through OWA becomes materially plausible where internet-facing OWA, high-value mailboxes, uncertain patch state, weak mailbox-control governance, incomplete audit visibility, broad delegation, permissive forwarding, or hybrid Exchange dependencies create an exploitable business surface. CISA KEV inclusion supports retaining the targeting probability at Medium to High because active exploitation has been confirmed, but it does not require raising the rating beyond that level without additional evidence of broader targeting, automated exploitation at scale, or confirmed compromise across affected environments. The risk is strongest for organizations that rely heavily on Exchange-hosted communications but cannot quickly prove that OWA activity, mailbox-control changes, identity sessions, and administrative actions are authorized, traceable, and business-justified.

Targeting Drivers

· Internet-facing Outlook Web Access on on-premises Microsoft Exchange Server.

· High-value mailboxes containing executive communications, financial approvals, legal material, security alerts, customer information, regulated data, operational secrets, or privileged administrative context.

· Finance, legal, executive, security, helpdesk, shared, service, and hybrid-administration mailboxes that can support fraud, monitoring, message redirection, concealment, or operational disruption.

· Weak governance over mailbox rules, forwarding, delegate access, mailbox permissions, transport rules, and administrative Exchange changes.

· Incomplete mailbox audit, administrator audit, identity-session, OWA access, or Exchange records.

· Poor linkage between administrative actions, helpdesk activity, change tickets, mailbox owners, business justification, and source context.

· Broad or poorly governed remote access, hybrid administration, service-account usage, shared mailbox administration, or delegated mailbox control.

· Limited ability to distinguish approved OWA usage, compliance workflows, migration work, helpdesk support, mailbox delegation, and Exchange administration from suspicious activity.

· Organizations where email is central to payment approval, legal communication, executive decision-making, customer support, security operations, or regulated business processes.

Most Likely Targets

· Executive mailboxes.

· Finance and payment-approval mailboxes.

· Legal and compliance mailboxes.

· Security operations and security-alert mailboxes.

· Helpdesk and IT support mailboxes.

· Shared operational mailboxes.

· Service mailboxes.

· Privileged administrator mailboxes.

· Hybrid Exchange administration identities.

· Mailboxes with external forwarding, broad delegation, sensitive communications, regulated data, customer information, privileged legal material, or business-critical approval workflows.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — OWA Exposure and Exploitation Opportunity

Microsoft Exchange Server XSS and spoofing activity through OWA begins with an exposed webmail or Exchange web-access condition that makes attacker interaction plausible. This may include internet-facing OWA, exposed Exchange web paths, user interaction with rendered content, or activity against Exchange web services. The report does not require a single assumed access method because the primary risk is abuse of trusted OWA and Exchange mailbox-control workflows after an access opportunity exists.

· ATT&CK mapping: Exploit Public-Facing Application T1190.

· Confidence: Conditional. OWA exposure and Exchange web access are relevant access conditions, but the specific access path must be validated per environment.

Stage 2 — Spoofed Interface Context or Authenticated Session Misuse

The next relevant stage is abuse of OWA-rendered content, spoofed interface context, authenticated session behavior, or user trust in the webmail experience. The activity may appear as legitimate webmail interaction unless it is correlated with suspicious user, source, timing, session, mailbox, or business context.

· ATT&CK mapping: Valid Accounts T1078.

· Confidence: Conditional to likely. Authenticated session or account-context abuse is central to this report, but it should not be treated as confirmed compromise without supporting mailbox, identity, administrative, or business-context evidence.

Stage 3 — Mailbox Access and Sensitive Communication Review

Once OWA access or session misuse exists, the actor may access messages, folders, archived mail, deleted items, search results, financial communications, legal correspondence, security alerts, or executive communications. The operational concern is whether access occurred outside the expected user, device, location, timing, role, mailbox, or business context.

· ATT&CK mapping: Email Collection T1114.

· Confidence: Conditional. Mailbox access becomes a stronger risk signal when tied to high-value mailboxes, suspicious sessions, unusual message access, mailbox search, or follow-on control-plane changes.

Stage 4 — Mailbox-Control or Administrative-Control Manipulation

OWA-centered abuse becomes more concerning when suspicious activity is followed by mailbox-rule creation, forwarding changes, delegate updates, mailbox permission changes, transport-rule modification, or administrative-control-plane changes. These actions can support monitoring, message redirection, concealment, business email compromise, or continued access to sensitive communications.

· ATT&CK mapping: Account Manipulation T1098.

· ATT&CK mapping: Email Forwarding Rule T1114.003.

· Confidence: Conditional to likely. Mailbox-control and administrative-control changes are strong indicators when paired with suspicious OWA activity, high-value mailbox involvement, identity concerns, administrator activity, or weak business justification.

Stage 5 — Concealment, Redirection, or Business-Process Abuse

Mailbox rules, forwarding behavior, delegate access, permissions, transport rules, or administrative changes may be used to hide messages, suppress alerts, redirect communications, copy messages externally, interfere with security notifications, or manipulate business workflows. This stage is especially concerning when it affects finance, legal, executive, security, helpdesk, shared, service, or hybrid-administration mailboxes.

· ATT&CK mapping: Email Hiding Rules T1564.008.

· ATT&CK mapping: Email Forwarding Rule T1114.003.

· Confidence: Conditional. Concealment and redirection should be treated as escalation signals when supported by mailbox, transport, administrative, identity, or business-process evidence.

Stage 6 — Data Exposure, Business Email Compromise, or External Communications Flow

If mailbox access, forwarding, redirect rules, transport changes, external delegation, suspicious recipients, or unusual outbound behavior creates access to sensitive communications outside approved business channels, the event moves from mailbox-control concern into data-exposure or business-email-compromise exposure. This stage should not be assumed without supporting evidence.

· ATT&CK mapping: Exfiltration Over Web Service T1567.

· ATT&CK mapping: Email Collection T1114.

Some activity may extend beyond OWA and mailbox-control abuse into Exchange management activity, PowerShell execution, suspicious process behavior, file activity, service modification, or abnormal Exchange server behavior. This stage is conditional and should not be treated as the default outcome because OWA-centered abuse can create material business impact without server takeover.

Relevant Signals

· Exchange management activity, PowerShell execution, suspicious process behavior, file creation, service modification, or scheduled-task activity following suspicious OWA-centered signals.

· Exchange application instability, IIS anomalies, application-pool recycle activity, service instability, or abnormal request failures near suspicious OWA activity.

· Exchange server outbound communication to rare, newly observed, unapproved, or high-risk destinations following suspicious OWA, mailbox, identity, or administrative activity.

· Independent endpoint, process, file, service, PowerShell, persistence, or network evidence supporting escalation beyond mailbox-control abuse.

Data Exposure, Fraud, and Communications-Assurance Impact

If mailbox access, forwarding, redirect rules, transport changes, external delegation, suspicious recipients, or unusual outbound behavior creates access to sensitive communications outside approved business channels, the event becomes a data-exposure, fraud, or communications-assurance risk. The final operational concern is whether Exchange-hosted communications, high-value mailboxes, mailbox-control workflows, identity sessions, and administrative actions remained trustworthy during suspicious OWA-centered activity.

Relevant Signals

· External forwarding, redirect rules, suspicious transport-rule routing, external delegate access, or mailbox permissions that create external access to business communications.

· Sensitive-message access, mailbox search, message export behavior, or repeated access to high-value communication threads.

· Fraud-adjacent activity involving finance approvals, payment workflows, vendor communications, executive instructions, customer correspondence, or legal communications.

· Legal, compliance, fraud, executive-communications, customer-communications, or operational exposure that cannot be confidently ruled out.

· Incomplete evidence during the key window for OWA activity, mailbox access, identity sessions, administrative actions, or Exchange control-plane changes.

S19 — Attack Chain Risk Amplification Summary

Microsoft Exchange Server XSS and spoofing activity through OWA becomes materially more severe when suspicious webmail interaction intersects with high-value mailboxes, mailbox-control changes, identity concerns, administrative activity, external communications flow, or incomplete evidence. The core risk is not simply that OWA is exposed or Exchange is affected. The risk is that trusted communications workflows may be used in a way that reduces confidence in mailbox integrity, executive communications, financial approval flows, legal correspondence, security notifications, and Exchange administration.

Primary Risk Amplifiers

· Suspicious OWA activity involves high-value mailboxes or privileged Exchange-related identities.

· OWA access occurs from unfamiliar source infrastructure, unusual geographies, unusual ASNs, unfamiliar devices, abnormal user agents, rare session paths, or unexpected time windows.

· Mailbox-rule creation, forwarding-rule creation, redirect behavior, delegate changes, mailbox permission changes, or transport-rule modification follows suspicious OWA activity.

· Mailbox-control changes create external exposure through forwarding, redirection, external delegation, suspicious mailbox permissions, or message-copy behavior.

· Administrative activity affects transport rules, mailbox permissions, connectors, accepted domains, remote domains, role assignments, organization settings, or hybrid Exchange configuration.

· Identity sessions show unfamiliar infrastructure, new device context, impossible travel, abnormal authentication sequence, risky sign-in behavior, or session reuse from rare infrastructure.

· High-value communications are accessed, searched, moved, deleted, hidden, suppressed, copied, redirected, or exposed outside normal business context.

· Helpdesk records, change tickets, mailbox-owner context, administrative approvals, source context, and business justification do not explain the activity.

· Evidence is incomplete because mailbox audit, administrator audit, identity, OWA, Exchange, endpoint, or network records are unavailable, inconsistent, or retained for too short a period.

· Host-level or Exchange server escalation indicators appear, including suspicious PowerShell, process behavior, file activity, service modification, application instability, or unusual Exchange egress.

Risk Interpretation

The risk should be escalated when OWA-centered activity moves from isolated webmail or session anomaly into correlated mailbox-control, identity, administrative, or business-process signals. Single events may justify review, but high-confidence risk emerges when multiple independent sources point to unauthorized mailbox access, suspicious forwarding, unexplained delegation, permission abuse, transport manipulation, sensitive-message exposure, or administrative misuse.

Operational Impact

The operational impact is highest when the organization cannot prove that Exchange-hosted communications remained trustworthy for high-value mailboxes. In those cases, response may require mailbox preservation, forwarding and rule review, delegate and permission validation, transport-rule inspection, identity-session review, credential reset, administrator activity review, Exchange configuration review, legal assessment, fraud review, customer or partner communications readiness, and executive assurance reporting.

S20 — Tactics, Techniques, and Procedures

Figure 3

OWA Exposure and Webmail Interaction

· Interact with internet-facing Outlook Web Access or Exchange web paths.

· Use OWA-rendered content, spoofed interface context, or user trust in webmail workflows to influence mailbox interaction.

· Access OWA from unfamiliar source infrastructure, unusual geographies, unusual ASNs, unfamiliar devices, abnormal user agents, or unexpected time windows.

· Focus interaction on mailboxes associated with high-value users, sensitive business functions, or Exchange administration.

Authenticated Session and Account-Context Abuse

· Use valid credentials, active sessions, compromised sessions, or trusted user context to make suspicious webmail activity appear legitimate.

· Reuse session context from unfamiliar infrastructure, new devices, unusual locations, or rare access paths.

· Blend mailbox activity into normal user behavior, helpdesk support, compliance workflows, migration activity, or hybrid Exchange administration.

· Use timing, source, device, or account context that complicates separation of legitimate and suspicious activity.

Mailbox Access and Sensitive Communication Review

· Access messages, folders, archived mail, deleted items, sensitive threads, search results, or high-value communication history.

· Search or review communications involving financial approvals, legal matters, executive decisions, customer information, security alerts, operational secrets, or privileged business context.

· Repeatedly access high-value folders, sensitive mailboxes, shared mailboxes, or delegated mailboxes.

· Use mailbox access to identify business workflows, approval chains, vendors, customers, legal matters, security operations, or administrative relationships.

Mailbox-Control Manipulation

· Create or modify mailbox rules that forward, redirect, delete, hide, mark as read, move, suppress, or reroute messages.

· Configure forwarding, redirect behavior, external recipients, external delegates, or suspicious mailbox permissions.

· Modify delegate access, FullAccess, SendAs, SendOnBehalf, or equivalent mailbox permissions outside approved workflows.

· Use mailbox-control changes to support monitoring, concealment, message redirection, business email compromise, or continued access.

Transport and Administrative-Control Abuse

· Create or modify transport rules that copy, blind-copy, redirect, delete, suppress, modify, or externally route messages.

· Modify mailbox permissions, connectors, accepted domains, remote domains, role assignments, organization settings, or hybrid Exchange configuration.

· Use Exchange administrative pathways, management hosts, service accounts, helpdesk accounts, or automation context to blend suspicious changes into expected operations.

· Perform administrative actions outside expected account, source, device, timing, change-ticket, role, or business context.

Concealment and Business-Process Manipulation

· Hide messages, suppress warnings, move security notifications, delete evidence, mark messages as read, or redirect sensitive communications.

· Manipulate finance, legal, executive, security, helpdesk, customer-support, or operational workflows through mailbox or transport behavior.

· Use forwarding, delegation, transport rules, or mailbox permissions to monitor communications without obvious host-level indicators.

· Create confusion around whether suspicious activity represents approved delegation, compliance work, helpdesk activity, migration activity, or unauthorized control.

Data Exposure and External Communications Flow

· Route messages to unfamiliar external recipients, suspicious domains, personal accounts, partner-like domains, or unapproved destinations.

· Access, search, copy, export, redirect, or expose sensitive communications outside approved business channels.

· Use mailbox and transport behavior to support business email compromise, payment redirection, vendor manipulation, customer communications abuse, or legal-data exposure.

· Pair suspicious mailbox-control behavior with unusual Exchange egress, external communication paths, or high-risk destinations where present.

Conditional Host-Level Escalation

· Use Exchange management activity, PowerShell, scripts, process execution, file activity, service modification, scheduled tasks, or abnormal Exchange behavior when activity escalates beyond OWA and mailbox-control abuse.

· Blend host-level activity into patching, maintenance, backup, monitoring, security tooling, troubleshooting, or incident-response workflows.

· Escalate from mailbox-control concern into host-compromise concern only when independent endpoint, process, file, service, PowerShell, persistence, or network evidence exists.

S20A — Adversary Tradecraft Summary

Core Tradecraft Characteristics

· Abuse of trusted OWA interaction, rendered webmail content, spoofed interface context, authenticated sessions, and user trust in Exchange communications.

· Use of mailbox and administrative control mechanisms as the primary opportunity for monitoring, redirection, concealment, or communications manipulation.

· Blending of suspicious activity with normal webmail use, helpdesk support, mailbox delegation, compliance workflows, migration activity, hybrid administration, and approved configuration changes.

· Targeting of high-value mailboxes and Exchange workflows that support executive decisions, financial approvals, legal communications, security operations, helpdesk activity, service functions, privileged administration, or hybrid Exchange management.

· Reliance on legitimate mailbox and administrative mechanisms rather than obvious malware, web-shell creation, command execution, or host takeover as the default activity model.

· Use of identity-session ambiguity, source-context uncertainty, forwarding governance gaps, delegation complexity, transport-rule complexity, and audit gaps to delay confident scoping.

· Downstream risk through business email compromise, sensitive communications exposure, fraud enablement, legal exposure, compliance pressure, customer or partner concern, operational disruption, or executive-trust loss.

Tradecraft Assessment

Microsoft Exchange Server XSS and spoofing activity through OWA should be assessed as a communications-integrity and mailbox-control assurance risk. The strongest cases are those where suspicious OWA-centered activity aligns with high-value mailboxes, unexplained forwarding, suspicious delegation, mailbox permission changes, transport-rule manipulation, identity concerns, administrative activity, sensitive-message access, or incomplete evidence. Static exploit indicators, isolated XSS-like strings, single request paths, unusual user agents, payload fragments, or one-off OWA anomalies should not drive the primary judgment without corroborating mailbox, identity, administrative, business, or escalation context.

S21 — Detection Strategy Overview

Detection Philosophy

CVE-2026-42897 should be detected as an Outlook Web Access-centered XSS and spoofing abuse scenario affecting on-premises Microsoft Exchange Server. The detection model should focus on user-interface trust abuse, OWA session manipulation, mailbox-control-plane changes, and suspicious authenticated activity rather than treating the vulnerability as an automatic host-compromise or remote-code-execution event.

· Detection should prioritize OWA-rendered content abuse, spoofed interface context, abnormal mailbox interaction, suspicious session behavior, and downstream mailbox-control-plane outcomes.

· Detection should treat XSS and spoofing activity as a deception and control-plane risk first.

· Detection should not assume malware deployment, web-shell creation, command execution, credential dumping, or server takeover unless corroborating telemetry supports that escalation.

· Detection should remain behavior-led because visible payloads, rendered content, user interaction paths, and OWA request patterns may vary.

· Detection should distinguish attempted exploitation, suspicious OWA interaction, probable mailbox-control-plane abuse, and confirmed post-exploitation.

· Detection should require correlation across OWA, IIS, Exchange, mailbox audit, admin audit, identity, endpoint, and network telemetry before assigning high-confidence compromise status.

Primary Detection Anchors

· OWA access from unfamiliar source IPs, geographies, ASNs, devices, browsers, user agents, session paths, or time windows.

· OWA activity involving privileged users, high-value mailboxes, shared mailboxes, service mailboxes, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, or hybrid-administration identities.

· OWA-rendered or message-driven activity followed by unusual mailbox access, mailbox search, message access, inbox manipulation, or suspicious mailbox-state changes.

· OWA session activity followed by mailbox-rule creation, forwarding-rule creation, delegate changes, mailbox permission changes, external recipient configuration, or transport-rule modification.

· OWA activity followed by unusual authentication behavior, unfamiliar session creation, session reuse from abnormal infrastructure, or access from a device or location inconsistent with baseline.

· OWA activity followed by Exchange administrative actions through ECP, Exchange Management Shell, PowerShell remoting, or administrative audit events.

· OWA activity followed by Exchange service instability, application errors, unusual IIS behavior, or abnormal application-pool recycle activity.

· OWA activity followed by suspicious Exchange server process, file, or outbound-network behavior only when those signals are present and time-correlated.

Detection Prioritization Model

· Prioritize OWA-centered events that show a suspicious session, rendered-content, mailbox, identity, or administrative outcome.

· Elevate activity involving privileged mailboxes, administrator identities, hybrid Exchange identities, executive users, finance users, legal users, security users, or shared operational mailboxes.

· Elevate OWA activity followed by mailbox-control-plane changes because XSS/spoofing abuse can produce meaningful business impact without immediate host-level malware.

· Elevate OWA activity followed by administrative-control-plane changes, especially where source context, account role, timing, command type, or change type differs from baseline.

· Elevate OWA activity followed by identity anomalies, including new session creation from unfamiliar infrastructure, unusual authentication sequence, impossible travel, new device context, or abnormal token/session behavior.

· Elevate OWA activity followed by suspicious Exchange instability, process execution, file creation, or outbound communication only as a correlated escalation path.

· Deprioritize isolated malformed-content indicators, isolated XSS-like strings, isolated unusual user agents, isolated OWA requests, isolated HTTP errors, and isolated mailbox changes unless they recur or correlate with other signals.

· Treat affected-version exposure as a risk amplifier, not as compromise evidence.

Correlation Strategy (Strict Enforcement)

· Require at least two independent signal families before escalating an event to probable exploitation.

· Require at least three signal families or clear unauthorized outcome evidence before escalating an event to confirmed compromise.

· Use OWA activity as the primary correlation anchor.

· Correlate OWA anomalies with mailbox audit events, admin audit events, identity-provider events, IIS records, Exchange application logs, EDR telemetry, PowerShell logs, DNS logs, proxy logs, firewall logs, and network egress records.

· Treat OWA anomaly plus mailbox-control change as a high-priority probable exploitation pattern.

· Treat OWA anomaly plus suspicious session or identity behavior as a high-priority probable exploitation pattern.

· Treat OWA anomaly plus administrative-control-plane change as a high-priority probable exploitation pattern.

· Treat OWA anomaly plus Exchange process, file, crash, or egress behavior as a host-compromise escalation pattern only when supported by endpoint or network telemetry.

· Align process, crash, IIS, and service-instability signals within short time windows.

· Align mailbox-rule, forwarding, delegate, mailbox-permission, transport-rule, and administrative-change signals within moderate time windows.

· Align delayed mailbox access, account misuse, persistence, staging, or exfiltration signals within extended time windows.

· Do not label activity as CVE-2026-42897-specific when the observed behavior only supports generic Exchange probing, credential misuse, mailbox compromise, or routine OWA authentication noise.

Telemetry Prioritization

· Highest priority telemetry should include OWA access records, Exchange IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider sign-in logs, Windows Security logs, EDR process telemetry, and PowerShell logs.

· Mailbox audit telemetry should be prioritized because OWA-centered XSS/spoofing abuse may produce mailbox-control-plane impact without immediate malware or server-side execution.

· Identity telemetry should be prioritized because attacker value may come from deceptive OWA interaction, session misuse, authenticated access, or follow-on mailbox control.

· Administrative audit telemetry should be prioritized because Exchange control-plane changes can materially increase impact even when host telemetry is quiet.

· Endpoint telemetry should be used to validate escalation into host compromise, including suspicious process ancestry, file creation, service changes, script execution, or abnormal Exchange server behavior.

· Network telemetry should be used to validate escalation into outbound communication, staging, command-and-control, data movement, or unusual Exchange server egress.

· Supporting telemetry should include message-tracking logs, transport logs, Exchange diagnostic logs, email security gateway telemetry, proxy logs, firewall logs, DNS logs, crash and fault telemetry, and Exchange health telemetry.

· Conditional telemetry may include packet metadata, decrypted HTTPS inspection, full message-body inspection, or rendering telemetry only where technically available, legally approved, and operationally reliable.

Detection Design Constraints

· Do not build detection around one exploit string, one payload, one URI, one public request pattern, one message artifact, one user agent, or one assumed attacker workflow.

· Do not assume every XSS-like artifact represents successful exploitation.

· Do not assume every spoofing indicator represents Exchange server compromise.

· Do not assume OWA activity alone is sufficient to prove CVE-2026-42897 exploitation.

· Do not assume command execution, web-shell deployment, malware execution, credential dumping, persistence, or data theft unless corroborating telemetry supports that escalation.

· Do not overfit to historic Exchange exploitation models where the current detection problem is OWA-centered XSS/spoofing and mail-control-plane abuse.

· Do not rely exclusively on decrypted HTTPS, full packet capture, or message-body inspection unless that telemetry is available and approved.

· Do not create rules that require fields unavailable across Exchange Server Subscription Edition, Exchange 2016, Exchange 2019, or organization-specific logging configurations.

· Do not expose private thresholds, internal scoring logic, customer-specific baselines, private allowlists, internal escalation procedures, or organization-specific SOC workflows in report-ready language.

Baseline and Deployment Requirements

· Baseline normal OWA access by user, mailbox type, source IP, geography, ASN, device, browser, user agent, authentication path, session timing, and request volume.

· Baseline normal mailbox-control-plane behavior, including inbox rules, forwarding rules, delegate access, mailbox permissions, shared-mailbox access, mailbox search, mailbox export, and message access patterns.

· Baseline normal Exchange administrative behavior by administrator, source device, source network, management interface, command type, change type, target object, and maintenance window.

· Baseline normal identity behavior for Exchange administrators, privileged users, shared-mailbox users, service accounts, hybrid identities, and high-value mailbox owners.

· Baseline normal Exchange server behavior, including IIS activity, Exchange service process trees, application-pool recycles, service restarts, PowerShell usage, scheduled tasks, file writes, and outbound destinations.

· Baseline normal Exchange error behavior so routine HTTP errors, application noise, maintenance activity, or expected service recycling does not create false-positive alerting.

· Deploy detection first against internet-facing on-premises Exchange systems and OWA-exposed assets.

· Expand deployment to hybrid Exchange servers, internal Exchange roles, mailbox servers, edge transport systems, management hosts, and identity-control-plane telemetry.

· Validate log retention before deployment because OWA-centered abuse investigations require correlation across web, mailbox, admin, identity, endpoint, and network records.

· Validate affected-version and update-state context separately from detection evidence so exposure management does not contaminate compromise classification.

Variant Resilience Requirements

· Detection must remain effective if the visible artifact changes from a crafted message to an OWA-rendered interface element, spoofed interface prompt, abnormal user-flow context, unusual session path, or mailbox-control-plane action.

· Detection must remain effective if attackers use valid sessions, compromised credentials, user interaction, or deceptive OWA interface context instead of obvious malware.

· Detection must remain effective if attackers avoid host-level execution and instead pursue inbox rules, forwarding, delegate access, transport-rule manipulation, mailbox search, or sensitive-message access.

· Detection must remain effective if attackers stage activity across multiple users, multiple mailboxes, multiple OWA sessions, multiple IP addresses, multiple user agents, or delayed follow-on actions.

· Detection must remain effective if attackers use legitimate Exchange administrative paths after initial access.

· Detection must remain effective if attackers limit activity to OWA, mailbox access, and mail-control-plane abuse without writing files, spawning processes, or creating persistence.

· Detection must remain effective if attackers blend activity into normal HTTPS traffic and avoid durable network signatures.

Operational Detection Model

· Classify activity as exposed-system probing when suspicious traffic reaches OWA or Exchange web paths without mailbox, identity, administrative, server, or network impact.

· Classify activity as suspicious OWA interaction when OWA session behavior, rendered-content behavior, user-interface context, or mailbox access deviates from baseline but lacks confirmed downstream impact.

· Classify activity as probable exploitation when suspicious OWA activity correlates with mailbox-control-plane changes, suspicious session behavior, identity anomalies, administrative actions, Exchange instability, suspicious process behavior, suspicious file activity, or unusual egress.

· Classify activity as confirmed mailbox-control-plane abuse when correlated evidence shows unauthorized mailbox access, unauthorized mailbox-rule changes, unauthorized forwarding, unauthorized delegate changes, unauthorized mailbox permission changes, suspicious message access, or unauthorized transport-rule changes.

· Classify activity as confirmed host compromise only when correlated evidence shows malicious process execution, suspicious file creation, persistence, credential-access behavior, staging, unauthorized service changes, or confirmed exfiltration behavior.

· SOC triage should first preserve OWA, IIS, Exchange application, mailbox audit, admin audit, identity, EDR, PowerShell, DNS, proxy, firewall, and network logs.

· SOC triage should then validate patch or mitigation state, exposed OWA/ECP posture, affected Exchange versions, suspicious mailboxes, mailbox rules, forwarding rules, delegate permissions, transport rules, active sessions, and administrator activity.

· SOC triage should include session revocation, credential reset, mailbox-rule review, administrator-account review, Exchange health validation, and egress review when correlated evidence supports escalation.

· Case documentation should explicitly state whether the evidence supports attempted exploitation, suspicious OWA interaction, probable exploitation, confirmed mailbox-control-plane abuse, confirmed host compromise, or unrelated Exchange noise.

Explicit Non-Deployment Guardrails

· Do not deploy rules that alert solely because an organization runs on-premises Exchange.

· Do not deploy rules that alert solely because OWA is internet-facing.

· Do not deploy rules that alert solely on one XSS-like string, one malformed parameter, one suspicious referrer, one unusual user agent, or one isolated OWA request.

· Do not deploy rules that equate spoofing indicators with Exchange server compromise.

· Do not deploy rules that equate OWA activity with confirmed exploitation without mailbox, identity, administrative, endpoint, or network correlation.

· Do not deploy rules that classify mailbox-rule changes as malicious without source, account, timing, recipient, mailbox type, target, or baseline context.

· Do not deploy rules that classify every Exchange application-pool recycle, HTTP error, service restart, or application exception as exploitation.

· Do not deploy rules that require full message-body inspection unless the organization has that telemetry and approval.

· Do not deploy rules that require decrypted OWA traffic unless the organization has that capability and approval.

· Do not deploy rules that mix exposure management with compromise detection.

· Do not deploy rules that reveal private thresholds, private scoring logic, private allowlists, internal escalation workflows, or customer-specific operational procedures.

S22 — Primary Detection Signals

Primary Detection Signals

· OWA access from unfamiliar source IPs, geographies, ASNs, devices, browsers, user agents, session paths, authentication contexts, or time windows.

· OWA activity involving privileged users, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, shared mailboxes, service mailboxes, helpdesk mailboxes, or hybrid-administration identities.

· OWA session behavior that deviates from baseline, including unusual request sequencing, abnormal session timing, unexpected mailbox interaction volume, unfamiliar device context, or activity inconsistent with the user’s normal access pattern.

· OWA-rendered or message-driven interaction followed by mailbox-rule creation, forwarding-rule creation, delegate modification, mailbox-permission change, external-recipient configuration, inbox manipulation, or transport-rule modification.

· OWA activity followed by suspicious mailbox access, unusual message access, mailbox search, sensitive-folder access, mailbox export behavior, or repeated interaction with high-value mail content.

· OWA activity followed by identity anomalies, including unfamiliar session creation, impossible travel, unusual authentication sequence, new device context, session reuse from rare infrastructure, or abnormal conditional-access outcome.

· OWA activity followed by Exchange administrative activity through ECP, Exchange Management Shell, PowerShell remoting, administrative audit events, or management actions inconsistent with the account’s baseline role.

· OWA activity followed by control-plane actions that create external exposure, including auto-forwarding, redirect rules, suspicious delegate access, unauthorized mailbox permissions, external transport behavior, or unexpected message-copy behavior.

· OWA activity followed by Exchange server instability, suspicious process behavior, suspicious file activity, or unusual outbound communication only when those signals are independently present and time-correlated.

· OWA-centered signal clusters affecting multiple users, multiple mailboxes, multiple source networks, multiple user agents, or multiple high-value roles within a short operational window.

Supporting Detection Signals

· IIS records showing unusual OWA or Exchange web access from unfamiliar infrastructure, rare ASNs, uncommon geographies, abnormal user agents, irregular request sequences, or access paths inconsistent with normal OWA use.

· Exchange application logs showing OWA-related application errors, request failures, session irregularities, rendering anomalies, unexpected service behavior, or abnormal activity near suspicious OWA sessions.

· Mailbox audit events showing unusual message reads, folder access, mailbox search, soft deletes, hard deletes, move operations, rule changes, forwarding changes, delegate actions, mailbox permission changes, or suspicious access to sensitive folders.

· Admin audit events showing unusual Exchange administrative changes, especially when performed by unexpected accounts, unfamiliar devices, rare source networks, unusual time windows, or management paths outside baseline.

· Identity-provider sign-in records showing unfamiliar infrastructure, new devices, abnormal authentication sequence, suspicious session reuse, impossible travel, atypical conditional-access results, or unusual access following OWA interaction.

· Windows Security logs showing abnormal logon behavior on Exchange servers, management hosts, jump hosts, or related administrative systems after suspicious OWA activity.

· EDR telemetry showing suspicious Exchange server process ancestry only when time-correlated with OWA, mailbox-control-plane, identity, or administrative activity.

· PowerShell logs showing unusual Exchange management commands, mailbox permission changes, transport-rule changes, forwarding configuration, mailbox export activity, role discovery, or administrative enumeration.

· DNS, proxy, firewall, or egress logs showing Exchange server communication to rare, newly observed, unapproved, or high-risk destinations after suspicious OWA or mailbox-control-plane activity.

· Email security gateway telemetry showing suspicious messages, rendered-content anomalies, spoofed context, abnormal HTML or script-like content, unusual message-delivery patterns, or targeted delivery to high-value OWA users.

Exploit Attempt and Instability Signals

· OWA requests with malformed parameters, unusual encoding, abnormal referrers, suspicious script-like content, unexpected request ordering, or request shapes inconsistent with normal OWA behavior.

· OWA activity targeting privileged mailboxes, shared mailboxes, service mailboxes, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, helpdesk mailboxes, or operational mailboxes.

· OWA access followed by Exchange application errors, IIS errors, abnormal response patterns, repeated request failures, or unusual session disruptions.

· OWA access followed by application-pool recycle events, Exchange service instability, worker-process faults, repeated Exchange health alerts, or maintenance-free service restarts.

· OWA activity followed by authentication failures, session retries, unfamiliar session creation, abnormal transition between unauthenticated and authenticated activity, or access from newly observed infrastructure.

· Suspicious OWA access followed by mailbox-control-plane activity from the same account, same source, nearby infrastructure, same device context, or a newly observed session context.

· Message-driven or rendered-content anomalies followed by unusual mailbox interaction, mailbox-rule activity, forwarding behavior, delegate changes, permission changes, or administrative action.

· Repeated XSS-like, spoofing-like, rendering, or interface-trust artifacts that become higher-value only when tied to OWA session anomalies, mailbox changes, identity anomalies, administrative outcomes, or server-side instability.

· Abnormal OWA activity occurring near Exchange instability, service restarts, application exceptions, or IIS anomalies outside maintenance windows.

· Similar OWA anomalies recurring across multiple users, mailboxes, source networks, user agents, or mailbox roles in a short period.

Outbound Communication Signals

· Exchange server outbound communication to rare, newly observed, unapproved, or high-risk destinations after suspicious OWA, identity, administrative, or mailbox-control-plane activity.

· Exchange server DNS lookups for unusual domains, newly registered domains, dynamic DNS services, suspicious cloud-hosted infrastructure, or destinations inconsistent with normal Exchange operations.

· Exchange server connections to destinations outside approved mail relay, update, monitoring, backup, security, administrative, or hybrid infrastructure.

· Exchange server outbound traffic volume that deviates from baseline after suspicious OWA or mailbox-control-plane activity.

· Exchange server outbound communication using unusual ports, protocols, timing, destination categories, or connection patterns.

· Exchange server communication to anonymization infrastructure, tunneling services, temporary hosting, paste services, file-sharing services, or unapproved cloud storage after suspicious OWA activity.

· Mailbox-control-plane changes that create external data flow, including forwarding rules, redirect rules, external delegate access, suspicious mailbox permissions, suspicious transport rules, or auto-forwarding to unfamiliar domains.

· Outbound email or message-routing behavior that deviates from normal mailbox, department, user, or organization patterns after suspicious OWA activity.

· External recipient additions, forwarding changes, redirect behavior, or transport-rule activity that occur after suspicious OWA activity and are inconsistent with business expectations.

· Unusual egress should be treated as an escalation signal, not a standalone CVE-specific indicator, unless correlated with OWA, mailbox, identity, administrative, or endpoint activity.

Persistence and Post-Exploitation Signals (Conditional)

· Mailbox-rule creation that forwards, redirects, deletes, hides, marks as read, moves, suppresses, or reroutes messages in a way that supports stealth, continued access, or data collection.

· Forwarding configuration to unfamiliar external recipients, personal email accounts, newly created domains, suspicious partner domains, or addresses unrelated to the user’s role.

· Delegate access changes that grant unfamiliar accounts access to sensitive mailboxes, shared mailboxes, executive mailboxes, legal mailboxes, finance mailboxes, security mailboxes, helpdesk mailboxes, or service mailboxes.

· Mailbox permission changes that grant FullAccess, SendAs, SendOnBehalf, or equivalent privileges outside approved administrative workflows.

· Transport-rule creation or modification that redirects, copies, blind-copies, deletes, suppresses, modifies, or externally routes messages in a suspicious manner.

· Inbox manipulation that hides messages, moves security notifications, suppresses warnings, deletes evidence, changes message visibility, or interferes with security, legal, finance, or administrative communications.

· Repeated access to sensitive folders, archived mail, deleted items, compliance-related folders, or messages containing credentials, financial data, legal data, security alerts, operational secrets, or privileged business context.

· Suspicious Exchange administrative changes following OWA activity, including changes to mailbox permissions, connectors, accepted domains, remote domains, transport rules, role assignments, or organization settings.

· Suspicious process execution, file creation, service modification, scheduled-task creation, script execution, credential-access behavior, or data staging only when endpoint telemetry confirms escalation beyond OWA and mailbox-control-plane abuse.

· Post-exploitation classification should require correlation across OWA activity, mailbox or administrative outcomes, and supporting identity, endpoint, or network telemetry.

Lateral Movement and Expansion Signals (Conditional)

· OWA activity followed by access to additional mailboxes outside the user’s normal scope.

· OWA activity followed by suspicious access to shared mailboxes, executive mailboxes, service mailboxes, finance mailboxes, legal mailboxes, security mailboxes, helpdesk mailboxes, privileged operational mailboxes, or delegated mailboxes.

· Mailbox permission or delegate access changes that expand access from one mailbox to additional users, groups, shared mailboxes, service mailboxes, or administrative mailboxes.

· Suspicious use of Exchange administrative interfaces to enumerate mailboxes, permissions, roles, connectors, transport rules, accepted domains, remote domains, organization configuration, or address-book data.

· Suspicious mailbox search or message discovery behavior across multiple users, folders, sensitive communication threads, business units, or privileged mailbox categories.

· Unusual access to address books, distribution lists, organizational contacts, internal routing information, mailbox metadata, or privileged communication patterns that could support targeting expansion.

· Identity anomalies showing the same source infrastructure, device context, session pattern, user agent, or authentication sequence across multiple Exchange accounts.

· PowerShell or administrative audit activity showing mailbox enumeration, permission discovery, role discovery, transport discovery, connector discovery, or configuration review after suspicious OWA activity.

· Exchange server host-level lateral movement signals only when endpoint telemetry confirms suspicious logons, remote execution, administrative-tool use, credential access, or movement from Exchange to another internal system.

· Lateral movement should not be inferred from OWA access alone; it requires mailbox, identity, administrative, endpoint, or network evidence showing expansion beyond the initial interaction.

Signal Usage Constraints

· Do not treat one OWA request, one unusual user agent, one malformed parameter, one XSS-like string, one suspicious referrer, one rendering artifact, or one isolated session irregularity as confirmed exploitation.

· Do not treat OWA exposure as detection evidence.

· Do not treat affected-version exposure as compromise evidence.

· Do not treat spoofing indicators as Exchange server compromise without mailbox, identity, administrative, endpoint, or network correlation.

· Do not treat mailbox-rule changes as malicious without source, account, recipient, timing, target mailbox, mailbox type, rule action, destination, and baseline context.

· Do not treat forwarding changes as malicious without validating whether they are approved, expected, temporary, legacy, user-initiated, administrator-initiated, or business-justified.

· Do not treat delegate or permission changes as malicious without validating administrative workflow, source context, request history, role alignment, and target mailbox sensitivity.

· Do not treat Exchange instability as exploitation without proximity to suspicious OWA, mailbox, identity, administrative, endpoint, or network behavior.

· Do not treat outbound Exchange server communication as malicious without destination reputation, baseline deviation, timing, protocol context, and correlation to suspicious OWA or mailbox activity.

· Do not treat endpoint process, file, or persistence behavior as part of the core model unless it is time-correlated with OWA-centered activity and independently supported by endpoint telemetry.

· Do not label activity as CVE-2026-42897-specific when the evidence only supports generic Exchange scanning, credential misuse, mailbox compromise, administrative error, maintenance activity, or routine OWA noise.

· Do not create detection rules that require unavailable telemetry such as decrypted HTTPS, full message-body inspection, packet capture, or rendering telemetry unless those sources are explicitly available and approved.

· Do not expose private thresholds, scoring logic, allowlists, customer-specific baselines, internal escalation procedures, or organization-specific SOC workflows in report-ready detection language.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

· EDR telemetry should be available on Exchange servers, Exchange management hosts, and administrative jump systems used to manage on-premises Exchange.

· Process creation telemetry should capture parent process, child process, command line, execution path, user context, integrity level, signer, hash, working directory, and network connection context where available.

· Exchange-related endpoint telemetry should baseline normal IIS worker-process behavior, Exchange service behavior, PowerShell activity, Exchange Management Shell activity, scheduled-task activity, service-control activity, and administrative-tool usage.

· Endpoint telemetry should identify suspicious process ancestry involving IIS, Exchange services, PowerShell, command shells, scripting engines, archive utilities, download tools, remote-access tools, administrative utilities, or credential-access tooling.

· Endpoint telemetry should support correlation between suspicious OWA activity and later host-level behavior, but host-level behavior should be treated as escalation evidence rather than the primary detection surface.

· Endpoint telemetry should capture suspicious file writes, script execution, service creation, scheduled-task creation, registry modification, credential-access behavior, and abnormal administrative-tool execution when present.

· Endpoint telemetry should support time-aligned correlation with OWA, IIS, mailbox audit, admin audit, identity, PowerShell, and network events.

· Endpoint telemetry should not be required to classify suspicious OWA interaction or mailbox-control-plane abuse, but it is required before classifying activity as confirmed host compromise.

Memory and Execution Telemetry

· Memory telemetry is useful for confirming advanced host-level compromise but should not be treated as mandatory for the core OWA-centered detection model.

· Memory telemetry should be prioritized when Exchange process behavior suggests code injection, abnormal module loading, suspicious in-memory execution, unexpected scripting activity, or process behavior inconsistent with baseline.

· Execution telemetry should capture command lines, script blocks, PowerShell module loads, PowerShell remoting activity, encoded commands, suspicious administrative commands, Exchange Management Shell usage, and unusual management-host execution.

· PowerShell logging should include script block logging, module logging, transcription where available, and operational logs from both Exchange servers and management hosts.

· Memory and execution telemetry should be used to validate escalation beyond OWA and mailbox-control-plane abuse.

· Memory telemetry should not be used as a dependency for detecting mailbox-rule creation, forwarding configuration, delegate changes, mailbox permission changes, transport-rule changes, message access, or session anomalies.

· Execution telemetry should be correlated with OWA, mailbox audit, admin audit, identity, endpoint, and network events before being attributed to this activity model.

· Lack of memory telemetry should be documented as a host-compromise validation gap, not as a failure of the OWA-centered detection strategy.

Crash and Fault Telemetry

· Exchange application logs should capture OWA-related application errors, rendering issues, request failures, exception patterns, service behavior, and abnormal activity near suspicious OWA sessions.

· IIS logs should capture response codes, request paths, source IPs, user agents, authenticated user context where available, request timing, request volume, and abnormal request sequences.

· Windows event logs should capture service restarts, application faults, worker-process failures, application-pool recycles, Exchange health events, and maintenance-free instability.

· Crash and fault telemetry should be correlated with suspicious OWA activity, mailbox-control-plane changes, identity anomalies, or administrative actions before being treated as exploitation-relevant.

· Application-pool recycle activity should be baselined against maintenance windows, expected service behavior, patch cycles, and known operational patterns.

· Exchange service instability should be treated as supporting evidence, not standalone proof of exploitation.

· Repeated OWA errors, request failures, application exceptions, or worker-process faults should be elevated only when they cluster around suspicious source infrastructure, high-value users, mailbox-control changes, identity anomalies, or administrative outcomes.

· Crash dumps, fault reports, and diagnostic traces should be preserved when host-level compromise or exploitation instability is suspected, but they should not be required for routine detection deployment.

File and Persistence Telemetry

· File telemetry should capture creation, modification, deletion, rename activity, unusual path access, suspicious script placement, and abnormal file writes on Exchange servers and management hosts.

· File telemetry should monitor Exchange web directories, IIS directories, ASP.NET temporary paths, Exchange installation paths, PowerShell script paths, scheduled-task paths, startup locations, service-related paths, administrator profile paths, and temporary staging locations.

· Persistence telemetry should capture scheduled-task creation, service creation, startup modification, registry run-key activity, WMI persistence, PowerShell profile modification, unauthorized tool staging, and suspicious configuration changes.

· File and persistence telemetry should be treated as escalation evidence only when correlated with OWA, mailbox-control-plane, identity, administrative, endpoint, or network signals.

· File telemetry should not be used to imply web-shell deployment, malware execution, or persistence unless suspicious artifacts are independently observed and time-correlated.

· Persistence telemetry should not be assumed for this report’s primary behavior model because OWA-centered XSS/spoofing may result in mailbox-control-plane abuse without host persistence.

· Security teams should preserve suspicious files, scripts, task definitions, service definitions, registry artifacts, relevant hashes, timestamps, signer metadata, owner context, and execution context when host-level escalation is suspected.

· File and persistence telemetry gaps should be documented as escalation-validation limitations, not as blockers for mailbox/session/control-plane detection.

Network and Outbound Communication Telemetry

· Network telemetry should capture Exchange server outbound connections, DNS lookups, proxy activity, firewall events, connection timing, destination IPs, destination domains, ports, protocols, byte counts, and destination categories where available.

· Network telemetry should baseline approved Exchange outbound destinations, including mail relay, hybrid Exchange, Microsoft services, update infrastructure, monitoring, backup, security, administrative, identity, and logging destinations.

· DNS telemetry should support detection of newly observed domains, rare domains, dynamic DNS services, suspicious cloud-hosted infrastructure, and destinations inconsistent with normal Exchange operations.

· Proxy and firewall telemetry should identify Exchange server communication to rare, high-risk, unapproved, anonymization, tunneling, temporary-hosting, paste, file-sharing, or unapproved cloud-storage destinations.

· Outbound communication should be treated as escalation evidence when it follows suspicious OWA, mailbox-control-plane, identity, administrative, endpoint, file, or process activity.

· Mailbox-control-plane telemetry should separately track external data-flow creation through forwarding, redirect rules, external delegate access, suspicious mailbox permissions, suspicious transport rules, or auto-forwarding to unfamiliar domains.

· Network telemetry should not be used as a standalone CVE-specific indicator unless correlated with OWA-centered or mailbox-control-plane behavior.

· Network telemetry gaps should be documented where encrypted traffic, NAT, proxy aggregation, load-balancer placement, missing DNS visibility, or incomplete egress logging limits investigation confidence.

Web and Application Telemetry (Conditional Availability)

· OWA access telemetry should capture user, mailbox, source IP, user agent, session path, request timing, authentication context, response behavior, endpoint path, and client context where available.

· IIS telemetry should capture Exchange virtual-directory access, response codes, method, URI stem, URI query where available, authenticated user context, user agent, referrer, bytes sent, bytes received, request duration, and source context.

· Exchange application telemetry should capture OWA errors, application exceptions, rendering issues, request failures, health events, abnormal session behavior, and unusual service behavior.

· Mailbox audit telemetry should capture message access, folder access, mailbox search, rule creation, rule modification, forwarding changes, delegate changes, permission changes, soft deletes, hard deletes, moves, and suspicious mailbox operations.

· Admin audit telemetry should capture administrative changes to mailbox permissions, transport rules, connectors, accepted domains, remote domains, organization settings, role assignments, Exchange configuration, and administrative role usage.

· Email security gateway telemetry should capture suspicious message delivery, abnormal HTML or script-like content, spoofed message context, targeted delivery to high-value users, and unusual message-rendering risk indicators.

· Rendering telemetry, decrypted HTTPS visibility, packet metadata, and full message-body inspection should be treated as conditional sources only when legally approved, technically available, and operationally reliable.

· Web and application telemetry should be normalized so OWA-centered activity can be joined with mailbox audit, admin audit, identity, endpoint, process, file, and network telemetry.

Telemetry Availability Requirements

· Minimum viable detection requires OWA or IIS access telemetry, mailbox audit telemetry, identity sign-in telemetry, and Exchange administrative audit telemetry.

· Strong detection requires correlation across OWA or IIS telemetry, mailbox audit logs, admin audit logs, identity-provider logs, Exchange application logs, and endpoint telemetry.

· High-confidence compromise classification requires independent corroboration from mailbox-control-plane, administrative, identity, endpoint, file, crash, process, PowerShell, or network telemetry.

· Confirmed host compromise classification requires endpoint, file, process, PowerShell, service, persistence, credential-access, staging, or network evidence beyond OWA activity.

· Confirmed mailbox-control-plane abuse requires mailbox audit, admin audit, forwarding, delegate, permission, rule, transport-rule, message-access, or mailbox-search evidence.

· Detection deployment should validate field availability before rule engineering, including source IP, user, mailbox, user agent, endpoint path, request timing, authentication context, rule action, forwarding destination, delegate target, permission type, administrative action, target object, and session context.

· Telemetry should be retained long enough to correlate immediate OWA activity with delayed mailbox-control-plane changes, later identity misuse, repeated mailbox access, and extended exfiltration or persistence behavior.

· Telemetry normalization should preserve timestamps, users, mailbox identities, source addresses, destination addresses, action names, target objects, session identifiers where available, administrative context, device context, and correlation identifiers.

Telemetry Limitations and Gaps

· OWA activity may appear as normal authenticated HTTPS traffic when content inspection, rendering telemetry, decrypted visibility, or session-level detail is unavailable.

· XSS/spoofing artifacts may not be visible in network telemetry if traffic is encrypted, if the payload is only observable after rendering, or if the observable behavior is limited to user-interface deception.

· Mailbox-control-plane abuse may occur without host-level malware, process execution, file creation, persistence, or unusual server egress.

· Endpoint telemetry may remain quiet when attacker value is achieved through mailbox rules, forwarding, delegate access, session misuse, message access, or administrative-control-plane changes.

· Mailbox audit gaps can materially reduce confidence in detecting mailbox-rule, forwarding, delegate, permission, message-access, search, deletion, and movement behavior.

· Admin audit gaps can materially reduce confidence in detecting unauthorized Exchange configuration, transport-rule, permission, connector, role, or organization-setting changes.

· Identity-provider gaps can limit confidence in distinguishing suspicious OWA activity from legitimate user behavior.

· IIS and OWA logging inconsistencies across Exchange versions, deployment architectures, retention policies, reverse-proxy configurations, and load-balancer placement can reduce signal fidelity.

· Proxy, NAT, load balancer, and security gateway placement can obscure original source IP, user agent, referrer, device context, and session context.

· Decrypted HTTPS inspection, packet capture, full message-body inspection, and rendering telemetry should not be assumed available.

· Affected-version exposure, OWA exposure, or patch state should support risk prioritization but should not be treated as compromise evidence.

· Lack of a single telemetry source should not invalidate the detection model, but it should lower confidence and require stronger correlation from available sources.

S24 — Detection Opportunities and Gaps

Figure 4

Detection Opportunities

· OWA-centered behavior provides the primary detection opportunity because the activity model depends on suspicious interaction with Outlook Web Access, rendered content, session context, mailbox access, or mailbox-control-plane outcomes.

· Mailbox audit telemetry provides high-value detection opportunities for mailbox-rule creation, forwarding-rule creation, delegate changes, mailbox permission changes, message access, folder access, mailbox search, move activity, delete activity, and suspicious access to sensitive folders.

· Admin audit telemetry provides high-value detection opportunities for Exchange administrative changes involving transport rules, mailbox permissions, connectors, accepted domains, remote domains, role assignments, organization settings, and administrative access paths.

· Identity telemetry provides high-value detection opportunities when suspicious OWA activity is followed by unfamiliar session creation, new device context, impossible travel, abnormal authentication sequence, unusual conditional-access outcome, or session reuse from rare infrastructure.

· IIS and Exchange application telemetry provide detection opportunities when suspicious OWA activity is associated with abnormal request patterns, application errors, response anomalies, rendering issues, service instability, or application-pool recycle behavior outside maintenance windows.

· Email security gateway telemetry provides supporting opportunities when targeted users receive suspicious messages, abnormal HTML or script-like content, spoofed message context, or delivery patterns associated with high-value mailbox targeting.

· Endpoint telemetry provides escalation-detection opportunities when OWA-centered activity is followed by suspicious process execution, file creation, PowerShell activity, service modification, scheduled-task creation, credential-access behavior, or abnormal Exchange server behavior.

· Network and egress telemetry provides escalation-detection opportunities when suspicious OWA or mailbox-control-plane activity is followed by Exchange server communication to rare, unapproved, newly observed, or high-risk destinations.

· Correlation across OWA, mailbox audit, admin audit, identity, Exchange application, endpoint, and network telemetry provides the strongest opportunity to distinguish suspicious interaction from probable exploitation and confirmed post-exploitation.

· High-value mailbox targeting provides an important prioritization opportunity because executive, finance, legal, security, shared, helpdesk, service, and hybrid-administration mailboxes are more likely to produce meaningful operational or business impact if abused.

Detection Gaps

· OWA activity may appear as normal authenticated HTTPS traffic when decrypted traffic visibility, rendering telemetry, full message-body inspection, or detailed session telemetry is unavailable.

· XSS and spoofing artifacts may be difficult to observe directly when the relevant behavior occurs during content rendering, user-interface deception, or authenticated OWA interaction.

· Mailbox-control-plane abuse may occur without malware, process execution, web-shell placement, file creation, persistence, or unusual server egress.

· Endpoint telemetry may remain quiet when attacker value is achieved through mailbox rules, forwarding, delegate access, transport-rule changes, session misuse, or message access.

· Mailbox audit gaps can reduce confidence in detecting mailbox-rule changes, forwarding configuration, delegate changes, permission changes, message access, mailbox search, movement, deletion, or sensitive-folder access.

· Admin audit gaps can reduce confidence in detecting unauthorized Exchange configuration changes, transport-rule changes, connector changes, role changes, permission changes, or organization-setting changes.

· Identity telemetry gaps can reduce confidence in separating suspicious OWA activity from legitimate user behavior, especially where source IP, device context, conditional-access result, or session identifier is incomplete.

· IIS and OWA logging inconsistencies across Exchange versions, reverse proxies, load balancers, retention policies, and deployment architectures can reduce source-context fidelity.

· Reverse proxy, NAT, load balancer, and security gateway placement can obscure original source IP, user agent, referrer, session context, request path, and authentication sequence.

· Affected-version exposure and OWA exposure identify risk posture but do not prove exploitation or compromise.

· Patch state can support prioritization, but it cannot replace behavioral evidence of suspicious OWA, mailbox, identity, administrative, endpoint, or network activity.

· Public vulnerability context may not provide enough durable payload-level detail to support safe static signature engineering, so the detection model must remain behavior-led and correlation-driven.

High-Value Detection Opportunities

· OWA activity followed by mailbox-rule creation, forwarding-rule creation, redirect behavior, delegate changes, mailbox permission changes, or transport-rule modification.

· OWA activity followed by access to executive, finance, legal, security, shared, service, helpdesk, or hybrid-administration mailboxes.

· OWA activity followed by unfamiliar session creation, new device context, impossible travel, unusual authentication sequence, or session reuse from rare infrastructure.

· OWA activity followed by Exchange administrative actions through ECP, Exchange Management Shell, PowerShell remoting, or administrative audit events.

· OWA activity followed by suspicious mailbox search, repeated sensitive-folder access, unusual message access, mailbox export behavior, or access to messages containing privileged business context.

· OWA activity followed by Exchange application errors, IIS anomalies, application-pool recycle activity, service instability, or worker-process faults outside maintenance windows.

· OWA activity followed by suspicious PowerShell activity, abnormal process ancestry, suspicious file writes, scheduled-task creation, service modification, or credential-access behavior.

· OWA activity followed by Exchange server outbound communication to rare, unapproved, newly observed, or high-risk destinations.

· Similar OWA, mailbox, identity, or administrative anomalies appearing across multiple users, mailboxes, source networks, user agents, or high-value roles within a short operational window.

· Mailbox-control-plane changes that create external data flow, including auto-forwarding, redirect rules, external delegate access, suspicious mailbox permissions, or suspicious transport-rule behavior.

Detection Engineering Gaps

· Detection logic that relies only on a single XSS-like string, malformed parameter, unusual referrer, suspicious user agent, or OWA request path is likely to be brittle and noisy.

· Detection logic that relies only on Exchange exposure, affected-version state, or internet-facing OWA posture confuses exposure management with compromise detection.

· Detection logic that assumes remote-code execution, web-shell deployment, malware execution, or persistence may miss mailbox-control-plane abuse where no host-level compromise occurs.

· Detection logic that requires decrypted HTTPS, full packet capture, full message-body inspection, or rendering telemetry may fail in environments where those sources are unavailable or not approved.

· Detection logic that does not incorporate mailbox audit telemetry may miss the most important control-plane outcomes for this activity model.

· Detection logic that does not incorporate identity telemetry may miss suspicious session reuse, unfamiliar device context, impossible travel, and abnormal authentication behavior following OWA interaction.

· Detection logic that does not incorporate admin audit telemetry may miss Exchange configuration changes, permission changes, transport-rule changes, and administrative expansion.

· Detection logic that does not account for baseline mailbox behavior may create false positives around legitimate forwarding, delegation, shared-mailbox access, transport-rule maintenance, or administrative support activity.

· Detection logic that does not separate suspicious interaction from confirmed host compromise may overstate incident severity and reduce analyst trust.

· Detection logic that hard-codes private thresholds, customer-specific baselines, private allowlists, or internal escalation procedures is not suitable for report-ready deployment language.

Operational Gaps

· Organizations without mailbox audit coverage may struggle to validate the most important downstream effects of OWA-centered XSS/spoofing abuse.

· Organizations without admin audit coverage may struggle to validate unauthorized Exchange control-plane changes.

· Organizations without identity-provider visibility may struggle to distinguish suspicious OWA sessions from legitimate user sessions.

· Organizations without reliable IIS or OWA logs may struggle to establish the initial suspicious interaction anchor.

· Organizations without endpoint telemetry on Exchange servers may struggle to validate escalation into host compromise.

· Organizations without PowerShell logging may struggle to identify suspicious Exchange Management Shell activity, administrative enumeration, permission changes, or transport-rule changes.

· Organizations without DNS, proxy, firewall, or egress telemetry may struggle to identify unusual Exchange server outbound communication or data-flow escalation.

· Organizations with short log-retention windows may miss delayed mailbox-control-plane changes, delayed identity misuse, repeated mailbox access, or staged exfiltration behavior.

· Organizations with reverse proxy or load-balancer architectures may need additional enrichment to recover original source IP, user agent, request path, authentication sequence, and session context.

· Organizations with legacy Exchange deployments may have inconsistent telemetry availability, field quality, and audit coverage that must be validated before detection deployment.

Compensating Detection Approaches

· Where decrypted traffic or rendering telemetry is unavailable, prioritize OWA session anomalies, mailbox audit outcomes, identity anomalies, admin audit events, and Exchange application behavior.

· Where mailbox audit telemetry is incomplete, use admin audit logs, transport-rule records, identity telemetry, user reports, message-tracking logs, and email security gateway telemetry to support partial reconstruction.

· Where admin audit telemetry is incomplete, use PowerShell logs, Windows Security logs, EDR telemetry, configuration-drift monitoring, change-management records, and Exchange management-host telemetry.

· Where identity telemetry is incomplete, use IIS source context, mailbox audit records, OWA session patterns, VPN logs, proxy records, endpoint telemetry, and device-management data where available.

· Where endpoint telemetry is incomplete, avoid classifying host compromise unless file, process, service, PowerShell, network, or forensic evidence independently supports that escalation.

· Where original source IP is obscured by proxy or load-balancer placement, use forwarded headers, proxy logs, WAF logs, gateway records, session identifiers, device context, and identity telemetry where available.

· Where network egress telemetry is incomplete, prioritize mailbox-created external data flows such as forwarding, redirect rules, external delegates, mailbox permissions, and transport rules.

· Where telemetry quality is uneven across Exchange versions or roles, deploy detections first against the most complete logging surfaces and document confidence limitations for weaker sources.

· Where false-positive risk is high, require OWA activity plus mailbox, identity, administrative, endpoint, or network correlation before escalation.

· Where visibility is limited, classify events as suspicious interaction or probable exploitation rather than confirmed compromise unless the evidence supports a higher classification.

Detection Confidence Model

· Low confidence should be assigned to isolated OWA anomalies, isolated XSS-like strings, isolated malformed parameters, isolated unusual user agents, isolated referrers, isolated HTTP errors, isolated rendering artifacts, or isolated Exchange instability.

· Moderate confidence should be assigned when suspicious OWA activity correlates with mailbox access anomalies, identity anomalies, administrative anomalies, or Exchange application anomalies.

· High confidence should be assigned when suspicious OWA activity correlates with mailbox-control-plane changes such as forwarding, mailbox-rule creation, delegate changes, permission changes, suspicious message access, or transport-rule modification.

· High confidence should also be assigned when suspicious OWA activity correlates with unusual administrative actions, suspicious session behavior, or repeated anomalies across high-value users or mailboxes.

· Confirmed mailbox-control-plane abuse should require evidence of unauthorized mailbox access, unauthorized forwarding, unauthorized mailbox-rule changes, unauthorized delegate changes, unauthorized permission changes, suspicious message access, or unauthorized transport-rule behavior.

· Confirmed host compromise should require endpoint, process, file, PowerShell, service, persistence, credential-access, staging, or network evidence beyond OWA activity.

· Confirmed exfiltration or data-flow abuse should require evidence of external forwarding, redirect rules, external delegate access, suspicious transport-rule routing, mailbox export, unusual outbound email behavior, or validated network data movement.

· Confidence should be downgraded when telemetry lacks source context, user context, mailbox context, target-object context, timing fidelity, session context, authentication context, or baseline comparison.

· Confidence should be upgraded when multiple independent signal families align within a defensible operational window.

· Confidence should not be upgraded solely because the environment is exposed, affected, unpatched, or running a vulnerable Exchange version.

Detection Gap Summary

· The most important detection gap is not the absence of a single exploit signature; it is the absence of correlated OWA, mailbox, identity, and administrative telemetry.

· The most important engineering risk is overfitting the detection model to payload artifacts instead of mailbox/session/control-plane outcomes.

· The most important operational risk is classifying OWA-centered XSS/spoofing activity as host compromise without evidence of host-level escalation.

· The most important visibility risk is missing mailbox-control-plane abuse because mailbox audit, admin audit, or identity telemetry is incomplete.

· The most important false-positive risk is treating normal OWA usage, expected delegation, approved forwarding, legitimate transport-rule maintenance, or routine Exchange instability as exploitation.

· The most resilient detection strategy is correlation-driven and uses OWA as the behavioral anchor, mailbox-control-plane outcomes as the primary impact signal, identity and administrative telemetry as validation layers, and endpoint or network telemetry as escalation evidence.

‍ ‍

S25 Ultra-Tuned Detection Engineering Rules

‍ ‍

NDR / Network Behavioral Analytics

‍ ‍

Detection Viability Assessment

‍ ‍

NDR / Network Behavioral Analytics has two rules for this EXP report.

‍ ‍

· NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior involving on-premises Exchange servers, OWA-exposed infrastructure, Exchange reverse proxies, WAF paths, Exchange server egress, DNS activity, source-to-Exchange access anomalies, and cloud-hosted security analytics correlation.

‍ ‍

· NDR / Network Behavioral Analytics is strongest where network-flow telemetry, firewall telemetry, proxy telemetry, DNS telemetry, WAF telemetry, asset inventory, OWA exposure mapping, approved-source baselines, Exchange egress baselines, and cloud or hybrid SIEM enrichment can be correlated.

‍ ‍

· NDR / Network Behavioral Analytics can identify suspicious sequencing between abnormal OWA access, rare or newly observed source infrastructure, high-value Exchange targeting, unusual Exchange server egress, and abnormal outbound communication patterns.

‍ ‍

· NDR / Network Behavioral Analytics is not a standalone source for confirming successful CVE-2026-42897 exploitation because encrypted HTTPS traffic, rendered-content behavior, mailbox-control-plane actions, and OWA user-interface abuse may not be directly visible in network telemetry.

‍ ‍

· NDR / Network Behavioral Analytics rules should be correlated with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, EDR telemetry, PowerShell logs, proxy logs, WAF logs, and change-management context before classifying activity as confirmed compromise.

‍ ‍

· Identify inbound HTTPS or proxy-observed traffic to OWA-exposed Exchange infrastructure from sources that are newly observed, rare for the environment, geographically unusual, ASN-unusual, associated with VPN egress, associated with hosting infrastructure, or inconsistent with approved user-access patterns.

‍ ‍

· Prioritize activity targeting OWA paths, Exchange web virtual directories, Exchange reverse proxies, WAF-fronted Exchange endpoints, or externally exposed Exchange access infrastructure.

‍ ‍

· Increase confidence when the same source, related source, ASN, VPN provider, hosting provider, or infrastructure cluster accesses multiple OWA-exposed assets or high-value Exchange paths within the same operational window.

‍ ‍

· Increase confidence when suspicious OWA access occurs near identity anomalies such as unfamiliar session creation, impossible travel, unusual device context, abnormal authentication sequence, suspicious conditional-access result, or session reuse from rare infrastructure.

‍ ‍

· Increase confidence when suspicious OWA access occurs near mailbox-control-plane activity such as mailbox-rule creation, forwarding-rule creation, delegate changes, mailbox permission changes, transport-rule changes, mailbox search, or unusual message access.

‍ ‍

· Increase confidence when suspicious OWA access occurs near Exchange application errors, IIS anomalies, application-pool recycle activity, service instability, or abnormal request failure patterns.

‍ ‍

· Increase confidence when suspicious OWA access is followed by Exchange server outbound communication to rare, newly observed, unapproved, or high-risk destinations.

‍ ‍

· Reduce severity for known corporate VPN ranges, approved remote-access paths, expected mobile-provider traffic, known managed-service access, approved security scanning, documented testing, and authorized maintenance windows.

‍ ‍

· Do not classify suspicious OWA access as confirmed exploitation without corroborating mailbox, identity, administrative, endpoint, application, or network escalation evidence.

‍ ‍

· Do not treat affected-version exposure, internet-facing OWA posture, or source novelty as compromise evidence by itself.

‍ ‍

Required Telemetry

‍ ‍

· Network-flow telemetry.

‍ ‍

· Firewall logs.

‍ ‍

· Proxy logs.

‍ ‍

· WAF logs where available.

‍ ‍

· DNS telemetry where available.

‍ ‍

· NDR session metadata.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where preserved.

‍ ‍

· Destination IP.

‍ ‍

· Destination hostname.

‍ ‍

· Destination port.

‍ ‍

· Protocol.

‍ ‍

· Timestamp.

‍ ‍

· Session duration.

‍ ‍

· Connection count.

‍ ‍

· Directionality.

‍ ‍

· User agent where available.

‍ ‍

· Referrer where available.

‍ ‍

· TLS SNI where available.

‍ ‍

· HTTP host where available.

‍ ‍

· Reverse-proxy forwarded source context where available.

‍ ‍

· Load-balancer source context where available.

‍ ‍

· Asset identity for on-premises Exchange servers.

‍ ‍

· Asset identity for OWA-exposed Exchange infrastructure.

‍ ‍

· Asset identity for Exchange reverse proxies, WAFs, and load balancers.

‍ ‍

· Approved OWA access baselines.

‍ ‍

· Approved corporate VPN and remote-access source ranges.

‍ ‍

· Approved managed-service and security-scanning sources.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· OWA/IIS log correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· Mailbox audit and admin audit correlation where available.

‍ ‍

· Exchange application and EDR correlation where available.

‍ ‍

· Maintenance-window, testing, and change-management context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange endpoints, Exchange reverse proxies, WAF-fronted Exchange endpoints, load balancers, and Exchange management infrastructure.

‍ ‍

· Validate the organization’s OWA exposure paths before production deployment.

‍ ‍

· Validate whether NDR visibility is positioned before or after reverse proxies, WAFs, NAT, load balancers, and VPN concentrators.

‍ ‍

· Preserve original source context using proxy headers, WAF records, gateway logs, load-balancer logs, firewall records, and identity telemetry where available.

‍ ‍

· Build baselines for normal OWA source geographies, ASNs, VPN paths, corporate remote-access paths, mobile-provider usage, device patterns, session volumes, and access timing.

‍ ‍

· Add enrichment for source geography, ASN, cloud provider, hosting provider, VPN provider, first-seen timestamp, destination asset role, and Exchange exposure status.

‍ ‍

· Correlate suspicious OWA source activity with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, endpoint telemetry, and Exchange egress telemetry.

‍ ‍

· Use shorter correlation windows for source-to-OWA access followed by identity anomalies or Exchange application instability.

‍ ‍

· Use moderate correlation windows for source-to-OWA access followed by mailbox-rule, forwarding, delegate, permission, transport-rule, or mailbox-search activity.

‍ ‍

· Use longer correlation windows for delayed mailbox access, repeated source reuse, staged egress, or repeated activity across multiple high-value mailboxes.

‍ ‍

· Tune severity based on mailbox sensitivity, source novelty, source reputation, infrastructure type, access pattern, affected asset role, and correlated downstream behavior.

‍ ‍

· Avoid broad suppression for cloud, VPN, mobile-provider, or hosting infrastructure because attacker and legitimate remote-access paths may overlap.

‍ ‍

· Use change-management, testing records, approved scanner lists, and managed-service context as triage evidence before classifying activity as suspicious or probable exploitation.

‍ ‍

· Validate all environment variables, asset groups, and enrichment fields before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to abnormal access against OWA-exposed Exchange infrastructure rather than static CVE strings or exploit payloads.

‍ ‍

· The rule remains useful if XSS/spoofing delivery changes but the attacker still interacts with OWA, Exchange web paths, reverse proxies, or exposed Exchange access infrastructure.

‍ ‍

· The score is supported by the durability of source novelty, source reputation, Exchange asset targeting, OWA exposure context, timing, and correlation with mailbox, identity, administrative, application, endpoint, or egress signals.

‍ ‍

· The score is constrained by encrypted HTTPS visibility, reverse-proxy source masking, legitimate VPN use, mobile-provider variability, managed-service access, source-attribution uncertainty, and the inability of NDR alone to observe mailbox-control-plane outcomes.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on NDR sensor placement, network-flow fidelity, Exchange asset tagging, OWA exposure mapping, original-source preservation, approved-source baselines, and maintenance-window context.

‍ ‍

· Operational confidence is reduced where reverse proxies, NAT, WAFs, load balancers, VPN concentrators, or cloud access brokers obscure original source context.

‍ ‍

· Operational confidence is reduced where normal OWA access includes broad VPN, cloud, mobile-provider, managed-service, or geographically distributed user activity.

‍ ‍

· Full-telemetry confidence improves when NDR events are enriched with OWA/IIS logs, mailbox audit logs, admin audit logs, identity-provider records, Exchange application logs, EDR telemetry, proxy logs, WAF logs, and change-management records.

‍ ‍

· Even under full telemetry conditions, this rule should support escalation and investigation rather than standalone confirmation of successful exploitation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA access behavior, not successful exploitation by itself.

‍ ‍

· Encrypted HTTPS traffic may prevent direct payload inspection or rendered-content analysis.

‍ ‍

· Reverse proxies, NAT, WAFs, VPN concentrators, load balancers, and cloud access layers may obscure original source context.

‍ ‍

· Legitimate VPN use, mobile access, managed-service support, security testing, and distributed workforce patterns may overlap with suspicious source behavior.

‍ ‍

· The rule requires accurate Exchange asset inventory, OWA exposure mapping, approved-source baselines, and proxy/WAF context to remain reliable.

‍ ‍

· Confirmation requires correlation with OWA/IIS events, mailbox audit events, admin audit events, identity anomalies, Exchange application anomalies, endpoint escalation, or suspicious egress.

‍ ‍

Detection Query Pattern

‍ ‍

NDR behavioral query pattern requiring platform syntax validation, Exchange asset tagging, OWA exposure validation, reverse-proxy mapping, original-source preservation validation, source-enrichment validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify outbound communication from on-premises Exchange servers to destinations that are rare, newly observed, unapproved, high-risk, inconsistent with Exchange baseline behavior, or outside approved mail relay, update, hybrid, monitoring, backup, security, administrative, identity, and logging destinations.

‍ ‍

· Prioritize outbound communication that occurs after suspicious OWA access, rare source access, OWA/IIS anomalies, Exchange application errors, mailbox-control-plane changes, identity anomalies, or administrative-control-plane changes.

‍ ‍

· Prioritize DNS lookups or outbound sessions involving newly observed domains, dynamic DNS, suspicious cloud-hosted infrastructure, anonymization services, tunneling services, temporary hosting, paste services, file-sharing services, or unapproved cloud storage.

‍ ‍

· Increase confidence when egress occurs from an Exchange server that recently received suspicious OWA traffic from a rare or newly observed source.

‍ ‍

· Increase confidence when egress occurs near mailbox-rule creation, forwarding-rule creation, delegate changes, mailbox permission changes, mailbox search, transport-rule changes, or unusual message access.

‍ ‍

· Increase confidence when egress occurs near suspicious endpoint behavior, including abnormal Exchange process ancestry, PowerShell execution, file creation, service modification, scheduled-task creation, or credential-access behavior.

‍ ‍

· Increase confidence when outbound traffic volume, timing, destination category, protocol, or byte count deviates from established Exchange server baseline.

‍ ‍

· Reduce severity for approved Microsoft services, approved hybrid Exchange destinations, approved mail relay infrastructure, approved security tooling, approved monitoring, approved backup destinations, approved identity services, approved logging destinations, and documented maintenance or incident-response activity.

‍ ‍

· Do not classify Exchange egress as confirmed exploitation or exfiltration without corroborating OWA, mailbox, administrative, identity, endpoint, or data-flow evidence.

‍ ‍

· Do not use destination reputation alone as confirmation because newly compromised, newly created, or shared cloud infrastructure may produce incomplete or misleading reputation signals.

‍ ‍

Required Telemetry

‍ ‍

· Network-flow telemetry.

‍ ‍

· Firewall logs.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs where available.

‍ ‍

· WAF logs where available.

‍ ‍

· NDR session metadata.

‍ ‍

· Source IP.

‍ ‍

· Source asset identity.

‍ ‍

· Destination IP.

‍ ‍

· Destination domain.

‍ ‍

· Destination port.

‍ ‍

· Protocol.

‍ ‍

· Timestamp.

‍ ‍

· Session duration.

‍ ‍

· Byte count.

‍ ‍

· Connection count.

‍ ‍

· Directionality.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· TLS SNI where available.

‍ ‍

· HTTP host where available.

‍ ‍

· Exchange server asset inventory.

‍ ‍

· Exchange role and exposure context.

‍ ‍

· Approved Exchange egress baselines.

‍ ‍

· Approved mail relay destinations.

‍ ‍

· Approved Microsoft service destinations.

‍ ‍

· Approved hybrid Exchange destinations.

‍ ‍

· Approved monitoring, backup, identity, administrative, security, and logging destinations.

‍ ‍

· GeoIP, ASN, cloud-provider, hosting-provider, VPN-provider, domain-age, and first-seen enrichment.

‍ ‍

· OWA/IIS correlation where available.

‍ ‍

· Mailbox audit and admin audit correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· EDR and PowerShell correlation where available.

‍ ‍

· File and process telemetry correlation where available.

‍ ‍

· Change-management, maintenance, and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange endpoints, Exchange reverse proxies, hybrid Exchange infrastructure, and Exchange management systems.

‍ ‍

· Build approved egress baselines for Exchange servers, including mail relay, Microsoft services, hybrid Exchange, monitoring, backup, security, administrative, identity, update, and logging destinations.

‍ ‍

· Validate normal Exchange outbound behavior before enabling high-severity alerting.

‍ ‍

· Add enrichment for destination reputation, domain age, first-seen timestamp, destination category, ASN, cloud provider, hosting provider, VPN provider, and sanctioned-service status.

‍ ‍

· Correlate suspicious Exchange egress with recent OWA access, rare source activity, OWA/IIS anomalies, mailbox audit events, admin audit events, identity anomalies, Exchange application logs, EDR events, PowerShell activity, and file or process telemetry where available.

‍ ‍

· Use shorter correlation windows for OWA access followed by immediate Exchange egress or DNS activity.

‍ ‍

· Use moderate correlation windows for OWA access followed by mailbox-control-plane changes and later Exchange egress.

‍ ‍

· Use longer correlation windows for delayed staging, repeated destination contact, mailbox-created external data flow, or recurring access to the same suspicious destination.

‍ ‍

· Tune severity based on asset criticality, mailbox sensitivity, source novelty, destination risk, destination novelty, data volume, protocol, timing, and correlated telemetry.

‍ ‍

· Avoid broad suppression for cloud providers, content-delivery networks, Microsoft-adjacent services, and common hosting providers without validation because attacker infrastructure may use common infrastructure categories.

‍ ‍

· Use maintenance, backup, monitoring, hybrid, incident-response, and change-management records as triage evidence before classifying outbound activity as suspicious or confirmed escalation.

‍ ‍

· Validate all environment variables, asset groups, approved-destination lists, and enrichment fields before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious Exchange server egress following OWA-centered activity rather than static exploit payloads or CVE-string indicators.

‍ ‍

· The rule remains useful if the XSS/spoofing delivery path changes but the activity still produces abnormal Exchange egress, external data flow, suspicious DNS behavior, or outbound staging.

‍ ‍

· The score is supported by the durability of Exchange asset identity, egress baseline deviation, destination novelty, destination reputation, timing, and correlation with OWA, mailbox, identity, administrative, endpoint, application, or file signals.

‍ ‍

· The score is constrained by legitimate Exchange egress complexity, hybrid Exchange traffic, Microsoft service dependencies, backup and monitoring traffic, security tooling, destination-reputation uncertainty, and environments with incomplete DNS or proxy visibility.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on network-flow coverage, Exchange asset tagging, egress-baseline quality, DNS visibility, proxy visibility, firewall fidelity, and approved-destination inventories.

‍ ‍

· Operational confidence is reduced where Exchange servers routinely communicate with broad cloud services, hybrid infrastructure, third-party relays, security tools, backup platforms, or managed-service destinations.

‍ ‍

· Full-telemetry confidence improves when suspicious egress is correlated with OWA/IIS records, mailbox audit events, admin audit events, identity-provider records, EDR telemetry, PowerShell logs, file telemetry, and change-management context.

‍ ‍

· Under full telemetry conditions, this rule can provide strong escalation evidence, but confirmed exploitation still requires corroborating OWA, mailbox, identity, administrative, endpoint, or data-flow evidence.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious Exchange egress after OWA-centered activity, not successful exploitation by itself.

‍ ‍

· Legitimate Exchange operations may include outbound traffic to Microsoft services, hybrid connectors, security platforms, monitoring tools, backup systems, mail relays, identity services, and logging destinations.

‍ ‍

· Missing DNS, proxy, firewall, or NDR visibility may reduce confidence in destination classification and data-flow analysis.

‍ ‍

· Destination reputation may be incomplete or misleading for newly created, compromised, or shared cloud-hosted infrastructure.

‍ ‍

· Encrypted traffic may limit content visibility and prevent confirmation of command-and-control or exfiltration content.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox-control-plane activity, identity anomalies, administrative changes, endpoint behavior, file evidence, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

NDR behavioral query pattern requiring platform syntax validation, Exchange asset tagging, approved-egress validation, destination-enrichment validation, OWA-to-egress sequencing validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

NetworkEvent AS EgressEvent
WHERE EgressEvent.SourceAsset IN ASSET_GROUP(
"On-Prem Exchange Servers",
"OWA Exposed Exchange Servers",
"Hybrid Exchange Servers"
)
AND EgressEvent.Direction = "Outbound"
AND EgressEvent.DestinationIP NOT IN ASSET_GROUP(
"Approved Exchange Mail Relay Destinations",
"Approved Microsoft Service Destinations",
"Approved Hybrid Exchange Destinations",
"Approved Monitoring Destinations",
"Approved Backup Destinations",
"Approved Security Tool Destinations",
"Approved Identity Service Destinations",
"Approved Administrative Destinations",
"Approved Logging Destinations"
)
AND (
EgressEvent.DestinationFirstSeen WITHIN ENV_NEW_DESTINATION_WINDOW
OR EgressEvent.DestinationDomainAge <= ENV_NEW_DOMAIN_AGE_WINDOW
OR EgressEvent.DestinationReputation IN ANY (
    "high_risk",
    "suspicious",
    "rare",
    "newly_observed",
    "unknown"
)
OR EgressEvent.DestinationCategory IN ANY (
    "anonymization",
    "tunneling",
    "temporary_hosting",
    "paste_service",
    "file_sharing",
    "unapproved_cloud_storage",
    "unknown_external"
)
OR EgressEvent.ByteCount >= ENV_EXCHANGE_EGRESS_VOLUME_THRESHOLD
OR EgressEvent.Protocol NOT IN ENV_APPROVED_EXCHANGE_EGRESS_PROTOCOLS
)
AND EVENT_NEAR WITHIN ENV_EXCHANGE_EGRESS_CORRELATION_WINDOW (
NetworkEvent AS OWAEvent
WHERE OWAEvent.DestinationAsset IN ASSET_GROUP(
    "OWA Exposed Exchange Endpoints",
    "Exchange Reverse Proxies",
    "WAF Fronted Exchange Endpoints"
)
AND OWAEvent.DestinationService IN ANY (
    "HTTPS",
    "OWA",
    "Exchange Web"
)
AND (
    OWAEvent.SourceFirstSeen WITHIN ENV_NEW_SOURCE_WINDOW
    OR OWAEvent.SourceGeo NOT IN ENV_APPROVED_OWA_ACCESS_GEOS
    OR OWAEvent.SourceASN NOT IN ENV_APPROVED_OWA_ACCESS_ASNS
    OR OWAEvent.SourceProviderType IN ANY (
      "cloud_hosting",
      "vpn_provider",
      "hosting_provider",
      "unknown_external"
    )
)
OR MailboxAuditEvent.EventType IN ANY (
    "Mailbox Rule Created",
    "Forwarding Rule Created",
    "Delegate Modified",
    "Mailbox Permission Changed",
    "Mailbox Search",
    "Unusual Message Access"
)
OR AdminAuditEvent.EventType IN ANY (
    "Transport Rule Modified",
    "Mailbox Permission Modified",
    "Connector Modified",
    "Exchange Organization Setting Modified"
)
OR IdentityEvent.EventType IN ANY (
    "Unfamiliar Session Created",
    "Impossible Travel",
    "New Device Context",
    "Abnormal Authentication Sequence"
)
OR EndpointEvent.EventType IN ANY (
    "Suspicious Exchange Process Ancestry",
    "Suspicious PowerShell Execution",
    "Suspicious File Creation",
    "Service Modified",
    "Scheduled Task Created",
    "Credential Access Behavior"
)
)
AND NOT ChangeContext IN ANY (
"approved_exchange_maintenance",
"approved_hybrid_exchange_operation",
"approved_backup_activity",
"approved_monitoring_activity",
"approved_security_tool_activity",
"approved_incident_response_activity"
)

‍ ‍

SentinelOne

‍ ‍

Detection Viability Assessment

‍ ‍

SentinelOne has three rules for this EXP report.

‍ ‍

· SentinelOne is viable for detecting endpoint and XDR escalation behavior on on-premises Exchange servers, Exchange management hosts, administrative jump systems, and hybrid Exchange infrastructure.

‍ ‍

· SentinelOne is strongest where Exchange server agents, process telemetry, command-line telemetry, PowerShell visibility, file telemetry, service telemetry, scheduled-task telemetry, registry telemetry, network connection telemetry, identity context, and cloud-managed XDR correlation are available.

‍ ‍

· SentinelOne can identify suspicious sequencing between OWA-centered activity, Exchange or IIS process anomalies, PowerShell execution, mailbox-control-plane administration, file activity, service modification, scheduled-task creation, credential-access behavior, and abnormal Exchange server egress.

‍ ‍

· SentinelOne is not a standalone source for confirming successful CVE-2026-42897 exploitation because OWA-rendered XSS/spoofing activity, mailbox-rule changes, forwarding behavior, delegate changes, permission changes, and transport-rule abuse may occur without host-level execution.

‍ ‍

· SentinelOne detections should be correlated with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, proxy logs, WAF logs, DNS logs, firewall logs, NDR telemetry, and change-management context before classifying activity as confirmed compromise.

‍ ‍

· Identify Exchange or IIS-related parent processes spawning suspicious child processes, including command shells, PowerShell, script interpreters, archive utilities, download utilities, remote-access tools, reconnaissance commands, credential-access tools, or unexpected administrative utilities.

‍ ‍

· Prioritize process ancestry involving IIS worker processes, Exchange services, Exchange application pools, Exchange transport services, Exchange management processes, Exchange service accounts, or web-facing Exchange roles.

‍ ‍

· Increase confidence when suspicious process execution occurs near OWA/IIS anomalies, suspicious OWA access, rare source infrastructure, Exchange application errors, application-pool recycle activity, or Exchange service instability.

‍ ‍

· Increase confidence when suspicious process execution occurs near mailbox-rule creation, forwarding-rule creation, delegate modification, mailbox-permission changes, mailbox search, transport-rule modification, or unusual message access.

‍ ‍

· Increase confidence when suspicious process execution occurs near identity anomalies such as unfamiliar session creation, unusual authentication sequence, impossible travel, new device context, suspicious conditional-access result, or session reuse from rare infrastructure.

‍ ‍

· Increase confidence when suspicious process execution is followed by file creation, service modification, scheduled-task creation, credential-access behavior, suspicious outbound communication, or tool staging.

‍ ‍

· Reduce severity for approved Exchange maintenance, approved backup activity, approved security tooling, approved monitoring tools, approved administrative scripts, approved patching workflows, approved migration activity, and documented incident-response activity.

‍ ‍

· Do not classify suspicious process ancestry as confirmed exploitation unless it is correlated with OWA-centered, mailbox-control-plane, identity, administrative, application, or network evidence.

‍ ‍

· Do not treat normal Exchange Management Shell activity as malicious without command context, source context, account context, target context, change-management context, and baseline deviation.

‍ ‍

· Do not classify mailbox-control-plane abuse as host compromise unless endpoint telemetry independently supports host-level escalation.

‍ ‍

Required Telemetry

‍ ‍

· SentinelOne endpoint telemetry.

‍ ‍

· Process creation telemetry.

‍ ‍

· Parent process name.

‍ ‍

· Parent process path.

‍ ‍

· Child process name.

‍ ‍

· Child process path.

‍ ‍

· Command line.

‍ ‍

· Working directory.

‍ ‍

· User context.

‍ ‍

· Service account context.

‍ ‍

· Process hash.

‍ ‍

· Signer metadata.

‍ ‍

· Process start time.

‍ ‍

· Process network connections.

‍ ‍

· File creation and modification events.

‍ ‍

· Script execution telemetry.

‍ ‍

· PowerShell command-line telemetry.

‍ ‍

· PowerShell script block telemetry where available.

‍ ‍

· Agent coverage on Exchange servers.

‍ ‍

· Agent coverage on Exchange management hosts.

‍ ‍

· Agent coverage on administrative jump systems.

‍ ‍

· Exchange server asset tags.

‍ ‍

· OWA-exposed Exchange server tags.

‍ ‍

· Exchange role context.

‍ ‍

· Approved administrative-tool baselines.

‍ ‍

· Approved Exchange maintenance and patching windows.

‍ ‍

· OWA/IIS log correlation where available.

‍ ‍

· Exchange application log correlation where available.

‍ ‍

· Mailbox audit and admin audit correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· DNS, proxy, firewall, NDR, and egress correlation where available.

‍ ‍

· Change-management and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange servers, Exchange management hosts, administrative jump systems, and hybrid Exchange infrastructure.

‍ ‍

· Validate normal Exchange process trees before production deployment.

‍ ‍

· Baseline IIS worker process behavior, Exchange service behavior, Exchange Management Shell usage, PowerShell execution, maintenance scripts, backup tooling, monitoring agents, security tooling, and administrative troubleshooting utilities.

‍ ‍

· Identify suspicious parent-child relationships involving IIS worker processes, Exchange services, PowerShell, command shells, scripting engines, download utilities, archive utilities, remote-access tools, reconnaissance utilities, and credential-access tools.

‍ ‍

· Correlate suspicious process ancestry with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, DNS logs, proxy logs, firewall logs, NDR telemetry, and network egress telemetry.

‍ ‍

· Use shorter correlation windows for OWA activity followed by process execution, file creation, service instability, or outbound communication.

‍ ‍

· Use moderate correlation windows for OWA activity followed by mailbox-control-plane changes and later endpoint behavior.

‍ ‍

· Use longer correlation windows for delayed tool staging, recurring process anomalies, repeated outbound communication, or repeated access to high-value mailboxes.

‍ ‍

· Tune severity based on parent process, child process, command line, user context, asset role, mailbox sensitivity, timing, execution path, signer status, and correlated telemetry.

‍ ‍

· Avoid broad suppression for PowerShell or administrative tools because legitimate administrators and attackers may use the same utilities.

‍ ‍

· Use change-management, maintenance windows, approved administrative scripts, approved security tools, approved backup activity, and documented incident-response activity as triage evidence before classifying the event as suspicious or confirmed escalation.

‍ ‍

· Validate all SentinelOne Deep Visibility fields, asset tags, exclusions, correlation windows, and enrichment sources before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious Exchange or IIS process ancestry rather than static CVE strings, exploit payloads, or scanner output.

‍ ‍

· The rule remains useful if the OWA XSS/spoofing delivery path changes but the activity results in host-level execution, scripting activity, tool staging, or administrative-utility abuse.

‍ ‍

· The score is supported by the durability of process ancestry, command-line behavior, asset identity, user context, execution path, timing, and correlation with OWA, mailbox, identity, administrative, application, or egress signals.

‍ ‍

· The score is constrained by the fact that OWA-centered XSS/spoofing and mailbox-control-plane abuse may not produce host-level execution.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on SentinelOne agent coverage, process-command-line fidelity, Exchange asset tagging, PowerShell visibility, administrative baselines, and change-management context.

‍ ‍

· Operational confidence is reduced where Exchange administrators routinely use PowerShell, scripts, backup tools, monitoring tools, troubleshooting utilities, or incident-response tooling from Exchange systems.

‍ ‍

· Full-telemetry confidence improves when SentinelOne events are enriched with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, DNS logs, proxy logs, firewall logs, and NDR telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence, but confirmed exploitation still requires OWA-centered, mailbox-control-plane, identity, administrative, or network corroboration.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious host-level execution on Exchange systems, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing abuse may occur without process execution, malware, web-shell deployment, or host compromise.

‍ ‍

· Legitimate Exchange administration may involve PowerShell, Exchange Management Shell, scripts, service-control utilities, backup tooling, monitoring tools, troubleshooting commands, and incident-response utilities.

‍ ‍

· Missing command-line visibility, incomplete agent coverage, weak Exchange asset tagging, or incomplete administrative baselines can reduce detection reliability.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox-control-plane activity, identity anomalies, administrative changes, Exchange application anomalies, suspicious file activity, or unusual egress.

‍ ‍

Detection Query Pattern

‍ ‍

SentinelOne XDR behavioral query pattern requiring platform syntax validation, Exchange asset tagging, process-baseline validation, PowerShell visibility validation, OWA-correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify PowerShell, Exchange Management Shell, or Exchange administrative activity on Exchange servers or management hosts involving mailbox rules, forwarding, delegate access, mailbox permissions, transport rules, mailbox search, mailbox export, connector changes, role assignment changes, or organization setting changes.

‍ ‍

· Prioritize commands executed by unexpected accounts, from unfamiliar hosts, outside approved maintenance windows, or from systems not normally used for Exchange administration.

‍ ‍

· Increase confidence when management activity follows suspicious OWA access, OWA session anomalies, Exchange application errors, mailbox-control-plane events, admin audit events, or identity anomalies.

‍ ‍

· Increase confidence when commands target high-value mailboxes, shared mailboxes, service mailboxes, privileged mailboxes, executive users, finance users, legal users, security users, helpdesk mailboxes, or hybrid-administration objects.

‍ ‍

· Increase confidence when commands create external data flow, including forwarding, redirect rules, external delegate access, suspicious mailbox permissions, transport-rule copying, blind-copying, or external routing.

‍ ‍

· Increase confidence when PowerShell activity includes encoded commands, remote execution, script downloads, unusual module loads, suspicious command chaining, execution from unusual paths, or activity by an account outside the approved Exchange administration baseline.

‍ ‍

· Reduce severity for approved Exchange administrators, approved automation, documented mailbox delegation, approved transport-rule maintenance, approved compliance workflows, approved migration activity, approved helpdesk activity, and documented incident-response activity.

‍ ‍

· Do not classify PowerShell or Exchange management activity as malicious without account, source, target, timing, command, baseline, and change-management context.

‍ ‍

· Do not treat mailbox-control-plane changes as host compromise unless endpoint telemetry independently supports host-level escalation.

‍ ‍

· Do not treat authorized administrative commands as malicious solely because they involve forwarding, delegate access, permissions, or transport rules.

‍ ‍

Required Telemetry

‍ ‍

· SentinelOne endpoint telemetry.

‍ ‍

· Process creation telemetry.

‍ ‍

· PowerShell process telemetry.

‍ ‍

· Command line.

‍ ‍

· Script block telemetry where available.

‍ ‍

· Module logging where available.

‍ ‍

· PowerShell remoting telemetry where available.

‍ ‍

· Parent process name.

‍ ‍

· Child process name.

‍ ‍

· User context.

‍ ‍

· Source host.

‍ ‍

· Target mailbox where available.

‍ ‍

· Target object where available.

‍ ‍

· Command name.

‍ ‍

· Command parameters.

‍ ‍

· Execution path.

‍ ‍

· Working directory.

‍ ‍

· Process hash.

‍ ‍

· Signer metadata.

‍ ‍

· Exchange server asset tags.

‍ ‍

· Exchange management host tags.

‍ ‍

· Approved Exchange administrator baseline.

‍ ‍

· Approved automation baseline.

‍ ‍

· Approved Exchange maintenance windows.

‍ ‍

· Mailbox audit correlation where available.

‍ ‍

· Admin audit correlation where available.

‍ ‍

· OWA/IIS correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· Exchange application log correlation where available.

‍ ‍

· DNS, proxy, firewall, NDR, and egress correlation where available.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for Exchange servers, Exchange management hosts, approved administrative jump systems, and hybrid Exchange systems.

‍ ‍

· Build identity groups for approved Exchange administrators, service accounts, automation accounts, migration accounts, managed-service accounts, compliance accounts, helpdesk accounts, and emergency-access accounts.

‍ ‍

· Baseline normal Exchange Management Shell usage, PowerShell remoting, mailbox administration, transport-rule management, connector management, hybrid-management activity, compliance workflows, migration workflows, and helpdesk workflows.

‍ ‍

· Monitor Exchange-related PowerShell commands that modify mailbox rules, forwarding, delegates, permissions, transport rules, connectors, role assignments, organization settings, and mailbox access.

‍ ‍

· Correlate suspicious PowerShell or management activity with OWA/IIS logs, mailbox audit logs, admin audit logs, identity-provider records, Exchange application logs, EDR telemetry, and network telemetry.

‍ ‍

· Use shorter correlation windows for suspicious OWA activity followed by administrative command execution.

‍ ‍

· Use moderate correlation windows for suspicious OWA activity followed by mailbox-control-plane changes or transport-rule modification.

‍ ‍

· Use longer correlation windows for delayed mailbox export, recurring mailbox access, staged forwarding, repeated permission modification, or slow administrative expansion.

‍ ‍

· Tune severity based on account privilege, source host, command type, target mailbox sensitivity, external data-flow creation, timing, and correlated telemetry.

‍ ‍

· Avoid broad suppression for PowerShell, Exchange Management Shell, or administrative accounts because attacker activity may use legitimate management paths.

‍ ‍

· Use change-management, approved delegation records, compliance workflows, migration records, helpdesk tickets, approved automation records, and incident-response records as triage evidence before classifying activity as suspicious or probable exploitation.

‍ ‍

· Validate all SentinelOne fields, script visibility, PowerShell logging levels, asset groups, identity groups, and correlation sources before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious Exchange PowerShell and management activity tied to mailbox-control-plane abuse rather than exploit strings or payload artifacts.

‍ ‍

· The rule remains useful if the OWA XSS/spoofing path changes but the attacker uses legitimate Exchange administrative mechanisms to modify mailbox, forwarding, permission, delegate, connector, or transport behavior.

‍ ‍

· The score is supported by the durability of command behavior, user context, management-host context, target-object context, external data-flow creation, and correlation with OWA, mailbox, identity, administrative, and endpoint telemetry.

‍ ‍

· The score is constrained by legitimate administrative overlap, automation workflows, migration activity, compliance operations, helpdesk activity, and environments where PowerShell visibility is incomplete.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on SentinelOne process visibility, PowerShell command-line fidelity, script logging, Exchange management-host coverage, administrator baselines, identity context, and change-management context.

‍ ‍

· Operational confidence is reduced where Exchange administration is highly script-driven, automation-heavy, compliance-heavy, or performed from multiple management paths.

‍ ‍

· Full-telemetry confidence improves when SentinelOne telemetry is correlated with mailbox audit logs, admin audit logs, OWA/IIS records, identity-provider records, Exchange application logs, NDR telemetry, and network egress telemetry.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious mail-control-plane administration, but confirmed exploitation still requires OWA-centered, mailbox, identity, administrative, or endpoint corroboration.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious Exchange management activity, not successful exploitation by itself.

‍ ‍

· Legitimate administrators, automation accounts, compliance workflows, migration tasks, helpdesk operations, and incident-response workflows may perform similar mailbox or transport-rule changes.

‍ ‍

· OWA-centered XSS/spoofing abuse may result in mailbox-control-plane changes that are visible in mailbox or admin audit logs but not in SentinelOne telemetry.

‍ ‍

· Incomplete PowerShell logging, missing command-line capture, weak identity context, or missing management-host coverage may reduce reliability.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, Exchange application anomalies, or endpoint escalation evidence.

‍ ‍

Detection Query Pattern

‍ ‍

SentinelOne XDR behavioral query pattern requiring platform syntax validation, Exchange management-host tagging, PowerShell visibility validation, administrator-baseline validation, mailbox-control-plane correlation validation, OWA-correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

· Identify suspicious file creation, script placement, unusual binary creation, archive creation, staging activity, service modification, scheduled-task creation, registry run-key activity, WMI persistence, PowerShell profile modification, or credential-access behavior on Exchange servers.

‍ ‍

· Prioritize activity in Exchange web paths, IIS paths, ASP.NET temporary paths, Exchange installation directories, administrator profiles, temporary directories, startup paths, scheduled-task paths, service executable paths, or unusual writable locations.

‍ ‍

· Increase confidence when file or persistence activity occurs after suspicious OWA access, Exchange application anomalies, OWA/IIS request anomalies, mailbox-control-plane changes, identity anomalies, suspicious Exchange management activity, or unusual Exchange egress.

‍ ‍

· Increase confidence when file or persistence activity is associated with suspicious process ancestry, encoded PowerShell, script downloads, archive utilities, credential-access tools, remote-access tools, or abnormal outbound communication.

‍ ‍

· Increase confidence when new files are unsigned, rarely seen, newly created, executed shortly after creation, externally sourced, located in unusual directories, or associated with suspicious command lines.

‍ ‍

· Increase confidence when service or task changes use suspicious paths, unfamiliar accounts, hidden execution, script interpreters, encoded commands, external network locations, or unusual execution timing.

‍ ‍

· Reduce severity for approved Exchange updates, approved patching, approved backup operations, approved monitoring tools, approved security tooling, approved maintenance scripts, approved administrative troubleshooting, and documented incident-response activity.

‍ ‍

· Do not classify suspicious file or persistence activity as part of this report’s activity model unless it is time-correlated with OWA-centered, mailbox-control-plane, identity, administrative, application, or network evidence.

‍ ‍

· Do not assume host compromise from mailbox-control-plane abuse alone.

‍ ‍

Required Telemetry

‍ ‍

· SentinelOne endpoint telemetry.

‍ ‍

· File creation telemetry.

‍ ‍

· File modification telemetry.

‍ ‍

· File deletion telemetry where available.

‍ ‍

· Process creation telemetry.

‍ ‍

· Command-line telemetry.

‍ ‍

· Script execution telemetry.

‍ ‍

· Service creation and modification telemetry.

‍ ‍

· Scheduled-task telemetry.

‍ ‍

· Registry modification telemetry.

‍ ‍

· WMI event telemetry where available.

‍ ‍

· Process hash.

‍ ‍

· File hash.

‍ ‍

· Signer metadata.

‍ ‍

· File path.

‍ ‍

· Parent process.

‍ ‍

· User context.

‍ ‍

· Execution timestamp.

‍ ‍

· Network connection context.

‍ ‍

· Exchange server asset tags.

‍ ‍

· OWA-exposed Exchange server tags.

‍ ‍

· Exchange role context.

‍ ‍

· Approved file-path baselines.

‍ ‍

· Approved service and scheduled-task baselines.

‍ ‍

· Approved patching and maintenance windows.

‍ ‍

· OWA/IIS correlation where available.

‍ ‍

· Exchange application log correlation where available.

‍ ‍

· Mailbox audit and admin audit correlation where available.

‍ ‍

· Identity-provider correlation where available.

‍ ‍

· DNS, proxy, firewall, NDR, and egress correlation where available.

‍ ‍

· Change-management and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange servers, hybrid Exchange servers, Exchange management hosts, and administrative jump systems.

‍ ‍

· Baseline expected Exchange file paths, IIS paths, ASP.NET temporary paths, Exchange installation paths, script paths, service paths, scheduled tasks, startup paths, security-tool paths, backup-tool paths, monitoring-tool paths, and administrative troubleshooting paths.

‍ ‍

· Monitor suspicious file creation, service modification, scheduled-task creation, registry run-key modification, WMI persistence, PowerShell profile modification, script staging, unusual binary execution, and credential-access behavior on Exchange systems.

‍ ‍

· Correlate suspicious file or persistence activity with OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, process telemetry, PowerShell logs, and network egress telemetry.

‍ ‍

· Use shorter correlation windows for suspicious OWA activity followed by immediate file creation, script execution, service modification, or scheduled-task creation.

‍ ‍

· Use moderate correlation windows for OWA activity followed by mailbox-control-plane changes and later host-level escalation.

‍ ‍

· Use longer correlation windows for delayed staging, repeated tool execution, recurring persistence behavior, or repeated outbound communication.

‍ ‍

· Tune severity based on file path, file reputation, signer status, hash prevalence, process ancestry, user context, asset role, timing, and correlated telemetry.

‍ ‍

· Avoid broad suppression for temporary directories, Microsoft-signed binaries, administrative utilities, or security-tool activity without validation because attacker tradecraft may blend with legitimate paths and tools.

‍ ‍

· Use patching records, maintenance records, backup schedules, monitoring records, security-tool context, administrative troubleshooting records, and incident-response tickets as triage evidence before classifying activity as suspicious or confirmed host compromise.

‍ ‍

· Validate all SentinelOne fields, file-path coverage, service telemetry, scheduled-task telemetry, registry telemetry, asset tags, and correlation windows before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious file, service, persistence, credential-access, and staging behavior on Exchange servers after OWA-centered signals.

‍ ‍

· The rule remains useful if the initial OWA XSS/spoofing delivery path changes but the activity escalates into host-level staging, persistence, tool deployment, credential-access behavior, or unusual data preparation.

‍ ‍

· The score is supported by the durability of file paths, service changes, task creation, signer metadata, process ancestry, hash prevalence, asset identity, timing, and correlation with OWA, mailbox, identity, administrative, application, or network signals.

‍ ‍

· The score is constrained by the fact that the core OWA/mail-control-plane behavior may not produce file or persistence artifacts.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on SentinelOne file telemetry, process telemetry, service telemetry, scheduled-task telemetry, registry telemetry, asset tagging, baseline quality, and change-management context.

‍ ‍

· Operational confidence is reduced where Exchange patching, backup tools, monitoring tools, security tools, administrative troubleshooting, or incident-response scripts create frequent file and service changes.

‍ ‍

· Full-telemetry confidence improves when suspicious file or persistence activity is correlated with OWA/IIS records, Exchange application logs, mailbox audit events, admin audit events, identity-provider records, PowerShell logs, and network egress telemetry.

‍ ‍

· Under full telemetry conditions, this rule can provide strong host-compromise escalation evidence, but confirmed exploitation still requires supporting OWA-centered, mailbox, identity, administrative, or application evidence.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious host-level escalation behavior, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing abuse may produce mailbox-control-plane impact without file creation, service modification, scheduled-task creation, registry persistence, or malware.

‍ ‍

· Legitimate patching, backup activity, monitoring tools, security tools, troubleshooting scripts, and incident response may overlap with suspicious file or persistence patterns.

‍ ‍

· Missing file telemetry, service telemetry, scheduled-task telemetry, registry telemetry, or weak asset tagging can reduce detection reliability.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox-control-plane activity, identity anomalies, administrative changes, Exchange application anomalies, process evidence, or unusual egress.

‍ ‍

Detection Query Pattern

‍ ‍

SentinelOne XDR escalation query pattern requiring platform syntax validation, Exchange asset tagging, file-path baseline validation, persistence-telemetry validation, OWA-correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

‍ ‍

EndpointEvent
WHERE AgentAsset IN ASSET_GROUP(
"On-Prem Exchange Servers",
"OWA Exposed Exchange Servers",
"Hybrid Exchange Servers",
"Exchange Management Hosts"
)
AND EventType IN ANY (
"File Created",
"File Modified",
"Process Creation",
"Service Created",
"Service Modified",
"Scheduled Task Created",
"Registry Modified",
"WMI Persistence",
"Script Execution"
)
AND (
FilePath CONTAINS_ANY (
    "\\inetpub\\wwwroot\\",
    "\\Exchange Server\\",
    "\\FrontEnd\\HttpProxy\\",
  "\\ClientAccess\\",
    "\\aspnet_client\\",
    "\\Windows\\Temp\\",
    "\\ProgramData\\",
    "\\Users\\Public\\",
    "\\AppData\\Local\\Temp\\",
    "\\Tasks\\",
    "\\System32\\Tasks\\"
)
OR CommandLine CONTAINS_ANY (
    "EncodedCommand",
    "FromBase64String",
    "DownloadString",
    "Invoke-WebRequest",
    "certutil",
    "bitsadmin",
    "schtasks",
    "sc create",
    "reg add",
    "New-Service",
    "Start-BitsTransfer",
    "Add-MpPreference",
    "procdump",
    "rclone"
)
OR ServicePath NOT IN ENV_APPROVED_EXCHANGE_SERVICE_PATHS
OR ScheduledTaskPath NOT IN ENV_APPROVED_EXCHANGE_TASK_PATHS
OR FileSigner NOT IN ENV_APPROVED_EXCHANGE_SIGNERS
OR FileReputation IN ANY (
    "rare",
    "newly_observed",
    "unknown",
    "suspicious",
    "malicious"
)
)
AND EVENT_NEAR WITHIN ENV_EXCHANGE_HOST_ESCALATION_WINDOW (
NetworkEvent.EventType IN ANY (
    "Suspicious OWA Access",
    "Rare Source Access To OWA",
    "OWA Access From Newly Observed Source"
)
OR ExchangeAppEvent.EventType IN ANY (
    "OWA Application Error",
    "IIS Request Anomaly",
    "Application Pool Recycle",
    "Exchange Service Instability"
)
OR MailboxAuditEvent.EventType IN ANY (
    "Mailbox Rule Created",
    "Forwarding Rule Created",
    "Delegate Modified",
    "Mailbox Permission Changed",
    "Mailbox Search",
    "Unusual Message Access"
)
OR AdminAuditEvent.EventType IN ANY (
    "Transport Rule Modified",
    "Mailbox Permission Modified",
    "Connector Modified",
    "Exchange Organization Setting Modified"
)
OR IdentityEvent.EventType IN ANY (
    "Unfamiliar Session Created",
    "Impossible Travel",
    "New Device Context",
    "Abnormal Authentication Sequence"
)
)
AND NOT ChangeContext IN ANY (
"approved_exchange_maintenance",
"approved_exchange_patching",
"approved_backup_activity",
"approved_monitoring_activity",
"approved_security_tool_activity",
"approved_administrative_troubleshooting",
"approved_incident_response_activity"
)

‍ ‍

Splunk

‍ ‍

Detection Viability Assessment

‍ ‍

Splunk has three rules for this EXP report.

‍ ‍

· Splunk is highly viable for this EXP report because the activity model requires correlation across OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, endpoint telemetry, DNS, proxy, firewall, WAF, NDR, and change-management context.

‍ ‍

· Splunk is strongest where on-premises Exchange telemetry, Microsoft identity telemetry, endpoint/XDR data, network telemetry, proxy records, WAF records, mailbox audit logs, and admin audit logs are normalized into consistent fields with reliable timestamps, user identity, mailbox identity, source context, and asset identity.

‍ ‍

· Splunk can identify suspicious sequencing between OWA-centered activity, mailbox-control-plane changes, identity anomalies, administrative-control-plane changes, Exchange application instability, endpoint escalation, and Exchange server egress.

‍ ‍

· Splunk is well suited for cloud or hybrid security analytics because many organizations forward on-premises Exchange, identity, endpoint, audit, proxy, and network telemetry into centralized Splunk environments.

‍ ‍

· Splunk rules should remain behavior-led and correlation-driven rather than relying on CVE strings, static payloads, single request paths, single user agents, or exploit-specific indicators.

‍ ‍

· Splunk detections should not classify successful CVE-2026-42897 exploitation unless OWA-centered activity is corroborated by mailbox, identity, administrative, endpoint, application, or network evidence.

‍ ‍

· Identify OWA or Exchange web activity from sources that are newly observed, rare for the user, rare for the organization, geographically unusual, ASN-unusual, associated with VPN or hosting infrastructure, or inconsistent with approved user-access patterns.

‍ ‍

· Correlate suspicious OWA activity with mailbox audit events involving inbox-rule creation, inbox-rule modification, forwarding behavior, delegate changes, mailbox permission changes, mailbox search, unusual message access, folder access, mailbox export behavior, move activity, or delete activity.

‍ ‍

· Correlate suspicious OWA activity with admin audit events involving transport-rule creation, transport-rule modification, mailbox permission changes, connector changes, organization-setting changes, role assignments, or Exchange administrative actions.

‍ ‍

· Increase confidence when the mailbox target is privileged, executive, finance, legal, security, shared, service, helpdesk, or hybrid-administration related.

‍ ‍

· Increase confidence when mailbox-control-plane changes create external exposure through forwarding, redirect behavior, external delegates, mailbox permissions, transport-rule copying, blind-copying, or external routing.

‍ ‍

· Increase confidence when the same user, mailbox, source IP, device context, session identifier, or related infrastructure appears across OWA, mailbox audit, admin audit, and identity events.

‍ ‍

· Increase confidence when mailbox-control-plane activity occurs outside the user’s normal working hours, normal device pattern, normal location pattern, normal mailbox behavior, or normal administrative role.

‍ ‍

· Reduce severity for approved mailbox delegation, approved forwarding, approved transport-rule maintenance, approved compliance workflows, approved helpdesk activity, approved migration activity, approved automation, and documented change tickets.

‍ ‍

· Do not classify mailbox-rule, forwarding, delegate, or permission activity as malicious without source, account, mailbox, target, timing, action, destination, baseline, and change-management context.

‍ ‍

· Do not classify this activity as host compromise unless endpoint, file, process, service, persistence, or network evidence independently supports escalation.

‍ ‍

· Do not treat a vulnerable or exposed Exchange version as compromise evidence without behavioral correlation.

‍ ‍

Required Telemetry

‍ ‍

· Splunk-indexed OWA access logs.

‍ ‍

· Splunk-indexed IIS logs.

‍ ‍

· Exchange mailbox audit logs.

‍ ‍

· Exchange admin audit logs.

‍ ‍

· Exchange application logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Proxy logs where available.

‍ ‍

· WAF logs where available.

‍ ‍

· Endpoint telemetry where available.

‍ ‍

· DNS and network telemetry where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· User.

‍ ‍

· Normalized user identity.

‍ ‍

· Mailbox identity.

‍ ‍

· Target mailbox.

‍ ‍

· Target object.

‍ ‍

· Action name.

‍ ‍

· Rule name.

‍ ‍

· Forwarding destination.

‍ ‍

· Delegate target.

‍ ‍

· Permission type.

‍ ‍

· Transport-rule action.

‍ ‍

· User agent.

‍ ‍

· Request path.

‍ ‍

· Authentication context.

‍ ‍

· Session identifier where available.

‍ ‍

· Device context where available.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· Exchange server asset tags.

‍ ‍

· OWA exposure tags.

‍ ‍

· High-value mailbox tags.

‍ ‍

· Approved mailbox delegation records.

‍ ‍

· Approved forwarding records.

‍ ‍

· Approved transport-rule maintenance records.

‍ ‍

· Approved automation records.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, mailbox audit, admin audit, identity, proxy, WAF, endpoint, and network events into consistent user, mailbox, source, destination, action, object, timestamp, and session fields.

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange endpoints, Exchange reverse proxies, WAF-fronted Exchange paths, hybrid Exchange servers, and Exchange management hosts.

‍ ‍

· Build identity and mailbox groups for privileged users, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, shared mailboxes, service mailboxes, helpdesk mailboxes, hybrid-administration identities, and Exchange administrators.

‍ ‍

· Build baselines for normal OWA access patterns, mailbox-rule activity, forwarding behavior, delegate changes, mailbox permissions, transport-rule activity, mailbox search behavior, and high-value mailbox access.

‍ ‍

· Correlate suspicious OWA source activity with mailbox audit and admin audit events using user, mailbox, source IP, original client IP, session context, device context, and time-window alignment.

‍ ‍

· Prefer transaction, stats, tstats, or accelerated data-model correlation where available instead of broad join-heavy searches in high-volume environments.

‍ ‍

· Use shorter correlation windows for OWA activity followed by immediate mailbox-rule, forwarding, delegate, permission, or message-access events.

‍ ‍

· Use moderate correlation windows for OWA activity followed by transport-rule changes, administrative actions, or repeated mailbox access.

‍ ‍

· Use longer correlation windows for delayed forwarding, repeated sensitive-folder access, staged mailbox searches, mailbox export behavior, or recurring activity across high-value mailboxes.

‍ ‍

· Tune severity based on source novelty, mailbox sensitivity, action type, external data-flow creation, administrator involvement, destination risk, timing, and corroborating identity or endpoint telemetry.

‍ ‍

· Use change-management records, approved delegation records, helpdesk tickets, compliance workflows, migration records, automation records, and business justification as triage evidence before classifying the event as probable exploitation.

‍ ‍

· Validate Splunk sourcetypes, field extractions, CIM mappings, data-model acceleration, lookups, macros, asset tags, identity tags, time zones, and correlation windows before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to the most important activity model for this report: suspicious OWA activity followed by mailbox/session/control-plane changes.

‍ ‍

· The rule remains useful if exploit delivery changes because the downstream mailbox-control-plane outcomes remain durable and operationally meaningful.

‍ ‍

· The score is supported by the durability of OWA access context, mailbox audit actions, admin audit actions, identity context, mailbox sensitivity, destination context, and time-window correlation.

‍ ‍

· The score is constrained by mailbox audit gaps, admin audit gaps, weak source preservation, inconsistent session identifiers, legitimate delegation, approved forwarding, automation activity, and helpdesk or compliance workflows that may overlap with suspicious activity.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, mailbox audit logs, admin audit logs, identity-provider logs, source-context preservation, Splunk field normalization, asset tagging, mailbox-sensitivity enrichment, and change-management context.

‍ ‍

· Operational confidence is reduced where mailbox audit logging is incomplete, admin audit logging is inconsistent, reverse proxies obscure source context, or business-approved forwarding and delegation are poorly documented.

‍ ‍

· Full-telemetry confidence improves when Splunk correlates OWA/IIS activity with mailbox audit, admin audit, identity, endpoint, proxy, WAF, DNS, firewall, NDR, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of probable mailbox-control-plane abuse, but confirmed exploitation still requires corroborating context and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA-to-mailbox-control-plane sequencing, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing artifacts may not be visible if content inspection, message-body inspection, rendering telemetry, or decrypted traffic visibility is unavailable.

‍ ‍

· Legitimate delegation, forwarding, helpdesk activity, compliance workflows, automation, migration work, and transport-rule maintenance may overlap with suspicious mailbox-control-plane behavior.

‍ ‍

· Missing mailbox audit logs, admin audit logs, identity context, original source IP, session identifiers, or change-management records can reduce confidence.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, endpoint telemetry, Exchange application anomalies, network evidence, or validated unauthorized control-plane outcome.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk SPL correlation pattern requiring platform syntax validation, sourcetype validation, field normalization, CIM mapping validation, lookup validation, mailbox-audit validation, admin-audit validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

· Identify suspicious OWA access from unusual source infrastructure, rare geographies, unusual ASNs, new devices, unfamiliar user agents, or access paths inconsistent with baseline.

‍ ‍

· Correlate suspicious OWA access with identity anomalies such as unfamiliar session creation, impossible travel, new device context, abnormal authentication sequence, risky sign-in, suspicious conditional-access result, or session reuse from rare infrastructure.

‍ ‍

· Correlate suspicious OWA access with administrative events involving ECP, Exchange Management Shell, PowerShell remoting, mailbox permissions, transport rules, connectors, accepted domains, remote domains, organization settings, role assignments, or hybrid configuration.

‍ ‍

· Increase confidence when identity or administrative anomalies involve privileged users, Exchange administrators, service accounts, helpdesk accounts, hybrid-administration identities, or accounts with mailbox-control authority.

‍ ‍

· Increase confidence when administrative activity occurs from a host, source IP, device, geography, ASN, or time window inconsistent with the account’s normal administrative baseline.

‍ ‍

· Increase confidence when administrative activity targets high-value mailboxes, transport configuration, external routing, connector configuration, accepted domains, remote domains, mailbox permissions, or hybrid objects.

‍ ‍

· Increase confidence when OWA activity, identity anomalies, and administrative changes align within a defensible operational window.

‍ ‍

· Reduce severity for approved administrative activity, approved helpdesk workflows, approved migration activity, approved transport-rule maintenance, approved hybrid-management activity, approved emergency access, approved automation, and documented incident-response work.

‍ ‍

· Do not classify identity anomalies as exploitation without OWA, mailbox, administrative, endpoint, application, or network correlation.

‍ ‍

· Do not classify administrative changes as malicious without account, source, target, command, timing, role, baseline, and change-management context.

‍ ‍

· Do not treat privileged-account use as malicious solely because the account is sensitive.

‍ ‍

Required Telemetry

‍ ‍

· Splunk-indexed OWA access logs.

‍ ‍

· Splunk-indexed IIS logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Risky sign-in telemetry where available.

‍ ‍

· Exchange admin audit logs.

‍ ‍

· Exchange mailbox audit logs.

‍ ‍

· Exchange application logs.

‍ ‍

· PowerShell logs where available.

‍ ‍

· ECP administrative records where available.

‍ ‍

· Endpoint telemetry where available.

‍ ‍

· Proxy and WAF logs where available.

‍ ‍

· DNS, firewall, NDR, and egress telemetry where available.

‍ ‍

· User.

‍ ‍

· Normalized account identity.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· Device identifier where available.

‍ ‍

· User agent.

‍ ‍

· Authentication result.

‍ ‍

· Authentication method.

‍ ‍

· Conditional-access result.

‍ ‍

· Session identifier where available.

‍ ‍

· Administrative action.

‍ ‍

· Command name.

‍ ‍

· Target object.

‍ ‍

· Target mailbox.

‍ ‍

· Source host.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· Approved Exchange administrator groups.

‍ ‍

· Approved helpdesk groups.

‍ ‍

· Approved service accounts.

‍ ‍

· Approved hybrid-administration accounts.

‍ ‍

· Approved administrative source hosts.

‍ ‍

· Approved emergency-access records.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, identity-provider, conditional-access, admin audit, mailbox audit, PowerShell, proxy, WAF, endpoint, and network events into consistent user, source, device, action, target, timestamp, and session fields.

‍ ‍

· Build identity groups for Exchange administrators, hybrid administrators, service accounts, helpdesk accounts, automation accounts, compliance accounts, and emergency-access accounts.

‍ ‍

· Build asset groups for OWA-exposed Exchange endpoints, Exchange reverse proxies, WAF-fronted Exchange endpoints, Exchange management hosts, administrative jump systems, and hybrid Exchange infrastructure.

‍ ‍

· Baseline normal OWA access, administrative source networks, administrative hosts, privileged-account sign-in patterns, device context, user-agent patterns, and management windows.

‍ ‍

· Correlate suspicious OWA activity with identity anomalies and administrative-control-plane changes using user, source IP, original client IP, device identifier, session identifier, target object, and timing.

‍ ‍

· Prefer append-plus-stats, transaction, tstats, or accelerated data-model approaches over broad appendcols or unconstrained joins in production environments.

‍ ‍

· Use shorter correlation windows for OWA access followed by unfamiliar session creation, risky sign-in, impossible travel, or abnormal authentication sequence.

‍ ‍

· Use moderate correlation windows for OWA access followed by administrative mailbox, transport, connector, role, organization-setting, or hybrid-configuration changes.

‍ ‍

· Use longer correlation windows for delayed administrative expansion, repeated access from rare infrastructure, or recurring changes across high-value mailboxes and Exchange objects.

‍ ‍

· Tune severity based on account privilege, action type, target sensitivity, source novelty, device novelty, authentication anomaly, administrative baseline deviation, and correlated mailbox or endpoint evidence.

‍ ‍

· Avoid broad suppression for administrators, service accounts, helpdesk accounts, or hybrid accounts because attacker activity may use legitimate privileged identities.

‍ ‍

· Use change-management records, approved emergency access, helpdesk tickets, migration records, hybrid-management records, automation records, and incident-response records as triage evidence before classifying activity as probable exploitation.

‍ ‍

· Validate Splunk sourcetypes, field extractions, identity mappings, admin audit onboarding, macro logic, lookups, time synchronization, and correlation windows before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to OWA activity followed by identity or administrative-control-plane anomalies rather than exploit strings or static payloads.

‍ ‍

· The rule remains useful if the initial XSS/spoofing artifact changes but the activity still produces suspicious session behavior, identity misuse, or administrative changes.

‍ ‍

· The score is supported by the durability of identity anomalies, administrative actions, source context, device context, privileged-account behavior, target-object sensitivity, and time-aligned OWA context.

‍ ‍

· The score is constrained by legitimate administrator activity, helpdesk operations, emergency access, automation, hybrid-management workflows, incomplete identity telemetry, and inconsistent session correlation.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, identity-provider telemetry, admin audit logs, PowerShell visibility, user and device normalization, privileged-account baselines, and change-management context.

‍ ‍

· Operational confidence is reduced where identity telemetry lacks source context, devices are unmanaged, administrators use broad VPN paths, or administrative changes are poorly documented.

‍ ‍

· Full-telemetry confidence improves when Splunk correlates OWA/IIS records with identity, admin audit, mailbox audit, endpoint, proxy, WAF, DNS, firewall, NDR, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious OWA-linked identity or administrative-control-plane abuse, but confirmed exploitation still requires corroborating evidence and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA-linked identity and administrative behavior, not successful exploitation by itself.

‍ ‍

· Legitimate Exchange administrators, helpdesk users, service accounts, automation accounts, emergency-access accounts, and hybrid-management workflows may produce similar administrative patterns.

‍ ‍

· Identity-provider telemetry may not fully capture session-level context, original client IP, device context, or OWA-specific behavior.

‍ ‍

· Missing admin audit logs, weak source preservation, incomplete device identity, inconsistent field normalization, or poor change-management records can reduce confidence.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, endpoint evidence, Exchange application anomalies, or network evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk SPL correlation pattern requiring platform syntax validation, identity sourcetype validation, admin-audit validation, field normalization, lookup validation, macro validation, source-context validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

· Identify suspicious OWA access to on-premises Exchange infrastructure from rare, newly observed, high-risk, geographically unusual, ASN-unusual, hosting, VPN, or otherwise abnormal source infrastructure.

‍ ‍

· Correlate suspicious OWA access with Exchange application errors, IIS anomalies, application-pool recycle activity, worker-process faults, service instability, or abnormal request failure patterns.

‍ ‍

· Correlate suspicious OWA access with endpoint events involving suspicious Exchange or IIS process ancestry, PowerShell execution, file creation, service modification, scheduled-task creation, registry modification, credential-access behavior, or tool staging.

‍ ‍

· Correlate suspicious OWA access with Exchange server outbound communication to rare, newly observed, unapproved, high-risk, anonymization, tunneling, paste, file-sharing, temporary-hosting, or unapproved cloud-storage destinations.

‍ ‍

· Increase confidence when OWA activity, application instability, endpoint behavior, and unusual egress align within a defensible operational window.

‍ ‍

· Increase confidence when the Exchange server supports high-value mailboxes, is OWA-exposed, participates in hybrid Exchange operations, or recently showed mailbox-control-plane or identity anomalies.

‍ ‍

· Increase confidence when suspicious endpoint activity includes encoded PowerShell, script downloads, unusual child processes, newly created files, unsigned files, service changes, scheduled tasks, or credential-access indicators.

‍ ‍

· Reduce severity for approved Exchange maintenance, approved patching, approved backup activity, approved security tooling, approved monitoring activity, approved administrative troubleshooting, approved automation, and documented incident-response activity.

‍ ‍

· Do not classify Exchange instability as exploitation without OWA, identity, mailbox, administrative, endpoint, or network correlation.

‍ ‍

· Do not classify unusual egress as exfiltration without data-flow, destination, volume, protocol, timing, and supporting investigative evidence.

‍ ‍

· Do not classify endpoint escalation as CVE-specific unless it is time-correlated with OWA-centered activity and supporting Exchange telemetry.

‍ ‍

Required Telemetry

‍ ‍

· Splunk-indexed OWA access logs.

‍ ‍

· Splunk-indexed IIS logs.

‍ ‍

· Exchange application logs.

‍ ‍

· Windows event logs.

‍ ‍

· Endpoint telemetry.

‍ ‍

· PowerShell logs.

‍ ‍

· File telemetry where available.

‍ ‍

· Service and scheduled-task telemetry where available.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs.

‍ ‍

· Firewall logs.

‍ ‍

· NDR telemetry.

‍ ‍

· WAF logs where available.

‍ ‍

· Mailbox audit logs where available.

‍ ‍

· Admin audit logs where available.

‍ ‍

· Identity-provider logs where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· Destination asset.

‍ ‍

· Exchange server asset identity.

‍ ‍

· Exchange role.

‍ ‍

· Event timestamp.

‍ ‍

· Process name.

‍ ‍

· Parent process name.

‍ ‍

· Command line.

‍ ‍

· File path.

‍ ‍

· File hash.

‍ ‍

· Signer metadata.

‍ ‍

· Service name.

‍ ‍

· Scheduled task name.

‍ ‍

· Destination IP.

‍ ‍

· Destination domain.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Byte count.

‍ ‍

· Protocol.

‍ ‍

· User context.

‍ ‍

· Asset tags.

‍ ‍

· OWA exposure tags.

‍ ‍

· Approved Exchange egress baselines.

‍ ‍

· Approved maintenance and patching records.

‍ ‍

· Change-management and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, Exchange application, Windows, endpoint, PowerShell, DNS, proxy, firewall, NDR, WAF, mailbox audit, admin audit, and identity events into consistent asset, user, source, destination, action, process, file, timestamp, and session fields.

‍ ‍

· Build asset groups for OWA-exposed Exchange servers, on-premises Exchange servers, hybrid Exchange servers, Exchange reverse proxies, WAF-fronted Exchange endpoints, and Exchange management hosts.

‍ ‍

· Build approved baselines for Exchange egress, Exchange application-pool behavior, service restarts, maintenance windows, PowerShell usage, administrative troubleshooting, backup activity, monitoring tools, security tooling, and automation.

‍ ‍

· Correlate suspicious OWA activity with Exchange application instability, endpoint execution behavior, file activity, service activity, scheduled-task activity, PowerShell activity, and unusual Exchange server egress.

‍ ‍

· Prefer stats, transaction, tstats, accelerated data models, or bounded append workflows over unconstrained joins in high-volume Splunk environments.

‍ ‍

· Use shorter correlation windows for OWA access followed by application errors, process execution, PowerShell execution, DNS lookups, or immediate outbound communication.

‍ ‍

· Use moderate correlation windows for OWA activity followed by file creation, service modification, scheduled-task creation, registry modification, or repeated egress.

‍ ‍

· Use longer correlation windows for delayed staging, repeated tool execution, recurring outbound communication, or slow data-flow escalation.

‍ ‍

· Tune severity based on source novelty, asset criticality, Exchange role, mailbox sensitivity, process behavior, command-line content, destination novelty, destination reputation, byte count, protocol, and correlated mailbox or identity evidence.

‍ ‍

· Avoid broad suppression for Microsoft services, cloud providers, security tools, monitoring tools, backup platforms, automation platforms, or administrative utilities without validation because attacker behavior may blend with legitimate infrastructure and tooling.

‍ ‍

· Use maintenance records, patching records, backup schedules, monitoring records, security-tool context, administrative troubleshooting records, automation records, and incident-response tickets as triage evidence before classifying activity as confirmed host compromise or exfiltration.

‍ ‍

· Validate Splunk sourcetypes, field extractions, CIM mappings, endpoint indexes, egress lookups, asset tags, correlation macros, environment variables, and time synchronization before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to OWA activity followed by endpoint, application, or egress escalation rather than CVE strings or static exploit indicators.

‍ ‍

· The rule remains useful if the OWA XSS/spoofing path changes but the activity produces host-level behavior, Exchange instability, PowerShell execution, file activity, or unusual outbound communication.

‍ ‍

· The score is supported by the durability of Exchange asset identity, OWA context, application instability, process behavior, command-line behavior, egress deviation, destination novelty, and timing correlation.

‍ ‍

· The score is constrained by legitimate Exchange maintenance, patching, backup, monitoring, automation, incident-response activity, security tooling, encrypted egress, and environments where endpoint or network visibility is incomplete.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, Exchange application logs, endpoint telemetry, PowerShell visibility, network egress logs, DNS logs, asset tagging, egress baselines, and maintenance context.

‍ ‍

· Operational confidence is reduced where Exchange systems have frequent patching, backup activity, monitoring activity, automation, administrative troubleshooting, or broad outbound dependencies.

‍ ‍

· Full-telemetry confidence improves when Splunk correlates OWA/IIS records with Exchange application, endpoint, PowerShell, DNS, proxy, firewall, NDR, mailbox audit, admin audit, identity, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence, but confirmed exploitation or exfiltration still requires corroborating evidence and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects escalation patterns after suspicious OWA activity, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing abuse may produce mailbox-control-plane impact without endpoint execution, service instability, file creation, or unusual egress.

‍ ‍

· Legitimate patching, backup, monitoring, administrative troubleshooting, automation, security tooling, and incident-response activity may overlap with suspicious escalation patterns.

‍ ‍

· Missing endpoint telemetry, incomplete PowerShell logs, weak egress visibility, inconsistent Exchange application logs, incomplete asset tags, or weak time synchronization can reduce reliability.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, endpoint evidence, Exchange application anomalies, mailbox-control-plane evidence, identity anomalies, administrative changes, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

Splunk SPL escalation pattern requiring platform syntax validation, sourcetype validation, field normalization, CIM mapping validation, endpoint-source validation, Exchange application-log validation, egress-baseline validation, lookup validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

index=ENV_EXCHANGE_WEB_INDEX sourcetype IN (
"ms:iis:default",
"exchange:iis",
"exchange:owa",
"proxy:exchange",
"waf:exchange"
)
(uri_path="/owa*" OR uri_path="/ecp*" OR uri_path="/Microsoft-Server-ActiveSync*" OR uri_path="/EWS*" OR uri_path="/mapi*" OR uri_path="/autodiscover*")
dest IN (
`exchange_owa_exposed_assets`,
`exchange_reverse_proxy_assets`,
`exchange_waf_fronted_assets`
)
(
first_seen_src_within(src, ENV_NEW_SOURCE_WINDOW)
OR NOT geo IN (`approved_owa_access_geos`)
OR NOT src_asn IN (`approved_owa_access_asns`)
OR src_provider_type IN ("cloud_hosting","vpn_provider","hosting_provider","unknown_external")
OR src_reputation IN ("high_risk","suspicious","newly_observed")
)
| eval owa_time=_time
| eval normalized_src=coalesce(original_client_ip, x_forwarded_for, src)
| eval exchange_asset=dest
| fields owa_time normalized_src exchange_asset uri_path http_user_agent src_asn geo src_provider_type src_reputation
| append [
    search index=ENV_EXCHANGE_APP_INDEX sourcetype IN (
      "exchange:application",
      "windows:eventlog:application",
      "iis:application"
    )
    event_type IN (
      "OWA Application Error",
      "IIS Request Anomaly",
      "Application Pool Recycle",
      "Exchange Service Instability",
      "Worker Process Fault",
      "Repeated Request Failure"
    )
    | eval app_time=_time
    | eval exchange_asset=coalesce(dest, host)
    | fields app_time exchange_asset event_type error_code service_name
]
| append [
    search index=ENV_ENDPOINT_INDEX sourcetype IN (
      "sentinelone:deep_visibility",
      "edr:process",
      "windows:sysmon",
      "windows:eventlog:security"
    )
    event_type IN (
      "Process Creation",
      "File Created",
      "Service Created",
      "Service Modified",
      "Scheduled Task Created",
      "Registry Modified",
      "PowerShell Execution",
      "Credential Access Behavior"
    )
    (
      parent_process IN (
        "w3wp.exe",
        "MSExchangeTransport.exe",
        "Microsoft.Exchange.ServiceHost.exe",
        "inetinfo.exe"
      )
      OR process_name IN (
        "powershell.exe",
        "pwsh.exe",
        "cmd.exe",
        "rundll32.exe",
        "regsvr32.exe",
        "mshta.exe",
        "certutil.exe",
        "bitsadmin.exe",
        "schtasks.exe",
        "sc.exe"
      )
    )
    | eval endpoint_time=_time
    | eval exchange_asset=coalesce(dest, host)
    | fields endpoint_time exchange_asset event_type parent_process process_name command_line file_path file_hash user
]
| append [
    search index=ENV_NETWORK_INDEX sourcetype IN (
      "dns",
      "proxy",
      "firewall",
      "ndr:flow"
    )
    direction="outbound"
    src IN (`on_prem_exchange_servers`)
    (
      dest_reputation IN ("high_risk","suspicious","rare","newly_observed","unknown")
      OR dest_category IN ("anonymization","tunneling","temporary_hosting","paste_service","file_sharing","unapproved_cloud_storage","unknown_external")
      OR bytes_out >= ENV_EXCHANGE_EGRESS_VOLUME_THRESHOLD
    )
    NOT dest IN (`approved_exchange_egress_destinations`)
    | eval egress_time=_time
    | eval exchange_asset=src
    | fields egress_time exchange_asset dest dest_domain dest_reputation dest_category bytes_out protocol
]
| stats
    values(owa_time) AS owa_times
    values(normalized_src) AS owa_sources
    values(uri_path) AS uri_paths
    values(http_user_agent) AS user_agents
    values(src_provider_type) AS source_provider_types
    values(src_reputation) AS source_reputations
    values(app_time) AS app_times
    values(endpoint_time) AS endpoint_times
    values(egress_time) AS egress_times
    values(event_type) AS event_types
    values(error_code) AS error_codes
    values(service_name) AS service_names
    values(parent_process) AS parent_processes
    values(process_name) AS process_names
    values(command_line) AS command_lines
    values(file_path) AS file_paths
    values(file_hash) AS file_hashes
    values(user) AS users
    values(dest_domain) AS dest_domains
    values(dest_reputation) AS dest_reputations
    values(dest_category) AS dest_categories
    values(bytes_out) AS bytes_out_values
    values(protocol) AS protocols
    BY exchange_asset
| where mvcount(owa_times) > 0 AND (mvcount(app_times) > 0 OR mvcount(endpoint_times) > 0 OR mvcount(egress_times) > 0)
| eval app_delta=MIN_TIME_DELTA(owa_times, app_times)
| eval endpoint_delta=MIN_TIME_DELTA(owa_times, endpoint_times)
| eval egress_delta=MIN_TIME_DELTA(owa_times, egress_times)
| where (
    (isnotnull(app_delta) AND app_delta <= ENV_OWA_APP_CORRELATION_WINDOW)
    OR (isnotnull(endpoint_delta) AND endpoint_delta <= ENV_OWA_ENDPOINT_CORRELATION_WINDOW)
    OR (isnotnull(egress_delta) AND egress_delta <= ENV_OWA_EGRESS_CORRELATION_WINDOW)
)
| lookup approved_exchange_operations exchange_asset event_type AS event_types process_name AS process_names dest_domain AS dest_domains OUTPUT operation_status
| where isnull(operation_status) OR operation_status!="approved"
| eval risk_reason=mvappend(
    if(mvcount(app_times)>0,"exchange_application_instability",null()),
    if(mvcount(endpoint_times)>0,"endpoint_escalation_signal",null()),
    if(mvcount(egress_times)>0,"unusual_exchange_egress",null()),
    if(mvfind(source_provider_types,"cloud_hosting|vpn_provider|hosting_provider|unknown_external")>=0,"rare_source_infrastructure",null())
)
| where mvcount(risk_reason) >= ENV_MIN_ESCALATION_REASON_COUNT
| table exchange_asset owa_times app_times endpoint_times egress_times app_delta endpoint_delta egress_delta owa_sources uri_paths event_types parent_processes process_names command_lines file_paths dest_domains dest_reputations dest_categories bytes_out_values risk_reason

‍ ‍

Elastic

‍ ‍

Detection Viability Assessment

‍ ‍

Elastic has three rules for this EXP report.

‍ ‍

· Elastic is highly viable for this EXP report where on-premises Exchange, OWA/IIS, mailbox audit, admin audit, identity, endpoint, DNS, proxy, firewall, WAF, and network telemetry are ingested into Elastic Security or Elastic SIEM.

‍ ‍

· Elastic is strongest where ECS field mapping, endpoint agent coverage, Exchange asset tagging, OWA exposure mapping, mailbox identity normalization, ingest-pipeline enrichment, and cloud or hybrid analytics correlation are available.

‍ ‍

· Elastic can identify suspicious sequencing between OWA-centered activity, mailbox-control-plane changes, identity anomalies, administrative-control-plane actions, endpoint escalation, Exchange instability, and unusual Exchange server egress.

‍ ‍

· Elastic is well suited for cloud or hybrid deployment models because many organizations centralize on-premises Exchange and security telemetry into Elastic-managed or Elastic-hosted analytics environments.

‍ ‍

· Elastic rules should remain behavior-led and correlation-driven rather than relying on CVE strings, static payloads, single request paths, single user agents, or exploit-specific indicators.

‍ ‍

· Elastic detections should not classify successful CVE-2026-42897 exploitation unless OWA-centered activity is corroborated by mailbox, identity, administrative, endpoint, application, or network evidence.

‍ ‍

· Identify OWA or Exchange web activity from sources that are newly observed, rare for the user, rare for the organization, geographically unusual, ASN-unusual, associated with VPN or hosting infrastructure, or inconsistent with approved user-access patterns.

‍ ‍

· Correlate suspicious OWA activity with mailbox audit events involving inbox-rule creation, inbox-rule modification, forwarding behavior, delegate changes, mailbox permission changes, mailbox search, unusual message access, folder access, mailbox export behavior, move activity, or delete activity.

‍ ‍

· Correlate suspicious OWA activity with admin audit events involving transport-rule creation, transport-rule modification, mailbox permission changes, connector changes, organization-setting changes, role assignments, or Exchange administrative actions.

‍ ‍

· Increase confidence when the mailbox target is privileged, executive, finance, legal, security, shared, service, helpdesk, or hybrid-administration related.

‍ ‍

· Increase confidence when mailbox-control-plane changes create external exposure through forwarding, redirect behavior, external delegates, mailbox permissions, transport-rule copying, blind-copying, or external routing.

‍ ‍

· Increase confidence when the same user, mailbox, source IP, device context, session identifier, or related infrastructure appears across OWA, mailbox audit, admin audit, and identity events.

‍ ‍

· Increase confidence when mailbox-control-plane activity occurs outside the user’s normal working hours, normal device pattern, normal location pattern, normal mailbox behavior, or normal administrative role.

‍ ‍

· Reduce severity for approved mailbox delegation, approved forwarding, approved transport-rule maintenance, approved compliance workflows, approved helpdesk activity, approved migration activity, approved automation, and documented change tickets.

‍ ‍

· Do not classify mailbox-rule, forwarding, delegate, or permission activity as malicious without source, account, mailbox, target, timing, action, destination, baseline, and change-management context.

‍ ‍

· Do not classify this activity as host compromise unless endpoint, file, process, service, persistence, or network evidence independently supports escalation.

‍ ‍

· Do not treat a vulnerable or exposed Exchange version as compromise evidence without behavioral correlation.

‍ ‍

Required Telemetry

‍ ‍

· Elastic-ingested OWA access logs.

‍ ‍

· Elastic-ingested IIS logs.

‍ ‍

· Exchange mailbox audit logs.

‍ ‍

· Exchange admin audit logs.

‍ ‍

· Exchange application logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Proxy logs where available.

‍ ‍

· WAF logs where available.

‍ ‍

· Elastic Defend or endpoint telemetry where available.

‍ ‍

· DNS and network telemetry where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· User.

‍ ‍

· Normalized user identity.

‍ ‍

· Mailbox identity.

‍ ‍

· Target mailbox.

‍ ‍

· Target object.

‍ ‍

· Action name.

‍ ‍

· Rule name.

‍ ‍

· Forwarding destination.

‍ ‍

· Delegate target.

‍ ‍

· Permission type.

‍ ‍

· Transport-rule action.

‍ ‍

· User agent.

‍ ‍

· Request path.

‍ ‍

· Authentication context.

‍ ‍

· Session identifier where available.

‍ ‍

· Device context where available.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· Exchange server asset tags.

‍ ‍

· OWA exposure tags.

‍ ‍

· High-value mailbox tags.

‍ ‍

· Approved mailbox delegation records.

‍ ‍

· Approved forwarding records.

‍ ‍

· Approved transport-rule maintenance records.

‍ ‍

· Approved automation records.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, mailbox audit, admin audit, identity, proxy, WAF, endpoint, and network events into ECS-aligned fields for user, mailbox, source, destination, action, object, timestamp, and session context.

‍ ‍

· Build asset groups for on-premises Exchange servers, OWA-exposed Exchange endpoints, Exchange reverse proxies, WAF-fronted Exchange paths, hybrid Exchange servers, and Exchange management hosts.

‍ ‍

· Build identity and mailbox groups for privileged users, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, shared mailboxes, service mailboxes, helpdesk mailboxes, hybrid-administration identities, and Exchange administrators.

‍ ‍

· Build baselines for normal OWA access patterns, mailbox-rule activity, forwarding behavior, delegate changes, mailbox permissions, transport-rule activity, mailbox search behavior, and high-value mailbox access.

‍ ‍

· Correlate suspicious OWA source activity with mailbox audit and admin audit events using user, mailbox, source IP, original client IP, session context, device context, and time-window alignment.

‍ ‍

· Use Elastic timeline, EQL sequence logic, threshold rules, event correlation, risk scoring, entity analytics, and exception lists where available.

‍ ‍

· Use shorter correlation windows for OWA activity followed by immediate mailbox-rule, forwarding, delegate, permission, or message-access events.

‍ ‍

· Use moderate correlation windows for OWA activity followed by transport-rule changes, administrative actions, or repeated mailbox access.

‍ ‍

· Use longer correlation windows for delayed forwarding, repeated sensitive-folder access, staged mailbox searches, mailbox export behavior, or recurring activity across high-value mailboxes.

‍ ‍

· Tune severity based on source novelty, mailbox sensitivity, action type, external data-flow creation, administrator involvement, destination risk, timing, and corroborating identity or endpoint telemetry.

‍ ‍

· Use change-management records, approved delegation records, helpdesk tickets, compliance workflows, migration records, automation records, and business justification as triage evidence before classifying the event as probable exploitation.

‍ ‍

· Validate Elastic index patterns, ECS mappings, ingest pipelines, enrichment fields, detection exceptions, event categories, asset tags, identity tags, time zones, and correlation windows before production deployment.

‍ ‍

· Validate that sequence logic uses fields consistently mapped across Exchange web logs and mailbox or admin audit logs before production deployment.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

9.0 / 10

‍ ‍

· The rule is behaviorally anchored to the most important activity model for this report: suspicious OWA activity followed by mailbox/session/control-plane changes.

‍ ‍

· The rule remains useful if exploit delivery changes because the downstream mailbox-control-plane outcomes remain durable and operationally meaningful.

‍ ‍

· The score is supported by the durability of OWA access context, mailbox audit actions, admin audit actions, identity context, mailbox sensitivity, destination context, and time-window correlation.

‍ ‍

· The score is constrained by mailbox audit gaps, admin audit gaps, weak source preservation, inconsistent session identifiers, legitimate delegation, approved forwarding, automation activity, and helpdesk or compliance workflows that may overlap with suspicious activity.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

8.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, mailbox audit logs, admin audit logs, identity-provider logs, source-context preservation, ECS field mapping, asset tagging, mailbox-sensitivity enrichment, and change-management context.

‍ ‍

· Operational confidence is reduced where mailbox audit logging is incomplete, admin audit logging is inconsistent, reverse proxies obscure source context, or business-approved forwarding and delegation are poorly documented.

‍ ‍

· Full-telemetry confidence improves when Elastic correlates OWA/IIS activity with mailbox audit, admin audit, identity, endpoint, proxy, WAF, DNS, firewall, NDR, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of probable mailbox-control-plane abuse, but confirmed exploitation still requires corroborating context and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA-to-mailbox-control-plane sequencing, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing artifacts may not be visible if content inspection, message-body inspection, rendering telemetry, or decrypted traffic visibility is unavailable.

‍ ‍

· Legitimate delegation, forwarding, helpdesk activity, compliance workflows, automation, migration work, and transport-rule maintenance may overlap with suspicious mailbox-control-plane behavior.

‍ ‍

· Missing mailbox audit logs, admin audit logs, identity context, original source IP, session identifiers, ECS mappings, or change-management records can reduce confidence.

‍ ‍

· EQL sequence reliability depends on consistent user, mailbox, source, and host mapping across web and audit data sources.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, endpoint telemetry, Exchange application anomalies, network evidence, or validated unauthorized control-plane outcome.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL correlation pattern requiring platform syntax validation, index-pattern validation, ECS field mapping validation, mailbox-audit validation, admin-audit validation, enrichment validation, exception-list validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

· Identify suspicious OWA access from unusual source infrastructure, rare geographies, unusual ASNs, new devices, unfamiliar user agents, or access paths inconsistent with baseline.

‍ ‍

· Correlate suspicious OWA access with identity anomalies such as unfamiliar session creation, impossible travel, new device context, abnormal authentication sequence, risky sign-in, suspicious conditional-access result, or session reuse from rare infrastructure.

‍ ‍

· Correlate suspicious OWA access with administrative events involving ECP, Exchange Management Shell, PowerShell remoting, mailbox permissions, transport rules, connectors, accepted domains, remote domains, organization settings, role assignments, or hybrid configuration.

‍ ‍

· Increase confidence when identity or administrative anomalies involve privileged users, Exchange administrators, service accounts, helpdesk accounts, hybrid-administration identities, or accounts with mailbox-control authority.

‍ ‍

· Increase confidence when administrative activity occurs from a host, source IP, device, geography, ASN, or time window inconsistent with the account’s normal administrative baseline.

‍ ‍

· Increase confidence when administrative activity targets high-value mailboxes, transport configuration, external routing, connector configuration, accepted domains, remote domains, mailbox permissions, or hybrid objects.

‍ ‍

· Increase confidence when OWA activity, identity anomalies, and administrative changes align within a defensible operational window.

‍ ‍

· Reduce severity for approved administrative activity, approved helpdesk workflows, approved migration activity, approved transport-rule maintenance, approved hybrid-management activity, approved emergency access, approved automation, and documented incident-response work.

‍ ‍

· Do not classify identity anomalies as exploitation without OWA, mailbox, administrative, endpoint, application, or network correlation.

‍ ‍

· Do not classify administrative changes as malicious without account, source, target, command, timing, role, baseline, and change-management context.

‍ ‍

· Do not treat privileged-account use as malicious solely because the account is sensitive.

‍ ‍

Required Telemetry

‍ ‍

· Elastic-ingested OWA access logs.

‍ ‍

· Elastic-ingested IIS logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Risky sign-in telemetry where available.

‍ ‍

· Exchange admin audit logs.

‍ ‍

· Exchange mailbox audit logs.

‍ ‍

· Exchange application logs.

‍ ‍

· PowerShell logs where available.

‍ ‍

· ECP administrative records where available.

‍ ‍

· Elastic Defend or endpoint telemetry where available.

‍ ‍

· Proxy and WAF logs where available.

‍ ‍

· DNS, firewall, NDR, and egress telemetry where available.

‍ ‍

· User.

‍ ‍

· Normalized account identity.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· Device identifier where available.

‍ ‍

· User agent.

‍ ‍

· Authentication result.

‍ ‍

· Authentication method.

‍ ‍

· Conditional-access result.

‍ ‍

· Session identifier where available.

‍ ‍

· Administrative action.

‍ ‍

· Command name.

‍ ‍

· Target object.

‍ ‍

· Target mailbox.

‍ ‍

· Source host.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· Approved Exchange administrator groups.

‍ ‍

· Approved helpdesk groups.

‍ ‍

· Approved service accounts.

‍ ‍

· Approved hybrid-administration accounts.

‍ ‍

· Approved administrative source hosts.

‍ ‍

· Approved emergency-access records.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, identity-provider, conditional-access, admin audit, mailbox audit, PowerShell, proxy, WAF, endpoint, and network events into ECS-aligned fields for user, source, device, action, target, timestamp, and session context.

‍ ‍

· Build identity groups for Exchange administrators, hybrid administrators, service accounts, helpdesk accounts, automation accounts, compliance accounts, and emergency-access accounts.

‍ ‍

· Build asset groups for OWA-exposed Exchange endpoints, Exchange reverse proxies, WAF-fronted Exchange endpoints, Exchange management hosts, administrative jump systems, and hybrid Exchange infrastructure.

‍ ‍

· Baseline normal OWA access, administrative source networks, administrative hosts, privileged-account sign-in patterns, device context, user-agent patterns, and management windows.

‍ ‍

· Correlate suspicious OWA activity with identity anomalies and administrative-control-plane changes using user, source IP, original client IP, device identifier, session identifier, target object, and timing.

‍ ‍

· Use Elastic EQL sequence logic, threshold rules, entity risk scoring, exception lists, event correlation, and investigation timelines where available.

‍ ‍

· Use shorter correlation windows for OWA access followed by unfamiliar session creation, risky sign-in, impossible travel, or abnormal authentication sequence.

‍ ‍

· Use moderate correlation windows for OWA access followed by administrative mailbox, transport, connector, role, organization-setting, or hybrid-configuration changes.

‍ ‍

· Use longer correlation windows for delayed administrative expansion, repeated access from rare infrastructure, or recurring changes across high-value mailboxes and Exchange objects.

‍ ‍

· Tune severity based on account privilege, action type, target sensitivity, source novelty, device novelty, authentication anomaly, administrative baseline deviation, and correlated mailbox or endpoint evidence.

‍ ‍

· Avoid broad suppression for administrators, service accounts, helpdesk accounts, or hybrid accounts because attacker activity may use legitimate privileged identities.

‍ ‍

· Use change-management records, approved emergency access, helpdesk tickets, migration records, hybrid-management records, automation records, and incident-response records as triage evidence before classifying activity as probable exploitation.

‍ ‍

· Validate Elastic index patterns, ECS mappings, identity mappings, admin audit onboarding, ingest pipelines, enrichment quality, exception lists, time synchronization, and correlation windows before production deployment.

‍ ‍

· Validate whether identity events and OWA events can be correlated by the same normalized user, original source, device, or session context before enabling high-severity alerting.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to OWA activity followed by identity or administrative-control-plane anomalies rather than exploit strings or static payloads.

‍ ‍

· The rule remains useful if the initial XSS/spoofing artifact changes but the activity still produces suspicious session behavior, identity misuse, or administrative changes.

‍ ‍

· The score is supported by the durability of identity anomalies, administrative actions, source context, device context, privileged-account behavior, target-object sensitivity, and time-aligned OWA context.

‍ ‍

· The score is constrained by legitimate administrator activity, helpdesk operations, emergency access, automation, hybrid-management workflows, incomplete identity telemetry, and inconsistent session correlation.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, identity-provider telemetry, admin audit logs, PowerShell visibility, user and device normalization, privileged-account baselines, ECS mappings, and change-management context.

‍ ‍

· Operational confidence is reduced where identity telemetry lacks source context, devices are unmanaged, administrators use broad VPN paths, or administrative changes are poorly documented.

‍ ‍

· Full-telemetry confidence improves when Elastic correlates OWA/IIS records with identity, admin audit, mailbox audit, endpoint, proxy, WAF, DNS, firewall, NDR, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of suspicious OWA-linked identity or administrative-control-plane abuse, but confirmed exploitation still requires corroborating evidence and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA-linked identity and administrative behavior, not successful exploitation by itself.

‍ ‍

· Legitimate Exchange administrators, helpdesk users, service accounts, automation accounts, emergency-access accounts, and hybrid-management workflows may produce similar administrative patterns.

‍ ‍

· Identity-provider telemetry may not fully capture session-level context, original client IP, device context, or OWA-specific behavior.

‍ ‍

· Missing admin audit logs, weak source preservation, incomplete device identity, inconsistent ECS mapping, or poor change-management records can reduce confidence.

‍ ‍

· EQL sequence reliability depends on consistent user, device, source, and session mapping across OWA, identity, and admin audit data sources.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, endpoint evidence, Exchange application anomalies, or network evidence.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL correlation pattern requiring platform syntax validation, index-pattern validation, identity mapping validation, admin-audit validation, ECS field mapping validation, enrichment validation, exception-list validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

· Identify suspicious OWA access to on-premises Exchange infrastructure from rare, newly observed, high-risk, geographically unusual, ASN-unusual, hosting, VPN, or otherwise abnormal source infrastructure.

‍ ‍

· Correlate suspicious OWA access with Exchange application errors, IIS anomalies, application-pool recycle activity, worker-process faults, service instability, or abnormal request failure patterns.

‍ ‍

· Correlate suspicious OWA access with endpoint events involving suspicious Exchange or IIS process ancestry, PowerShell execution, file creation, service modification, scheduled-task creation, registry modification, credential-access behavior, or tool staging.

‍ ‍

· Correlate suspicious OWA access with Exchange server outbound communication to rare, newly observed, unapproved, high-risk, anonymization, tunneling, paste, file-sharing, temporary-hosting, or unapproved cloud-storage destinations.

‍ ‍

· Increase confidence when OWA activity, application instability, endpoint behavior, and unusual egress align within a defensible operational window.

‍ ‍

· Increase confidence when the Exchange server supports high-value mailboxes, is OWA-exposed, participates in hybrid Exchange operations, or recently showed mailbox-control-plane or identity anomalies.

‍ ‍

· Increase confidence when suspicious endpoint activity includes encoded PowerShell, script downloads, unusual child processes, newly created files, unsigned files, service changes, scheduled tasks, or credential-access indicators.

‍ ‍

· Reduce severity for approved Exchange maintenance, approved patching, approved backup activity, approved security tooling, approved monitoring activity, approved administrative troubleshooting, approved automation, and documented incident-response activity.

‍ ‍

· Do not classify Exchange instability as exploitation without OWA, identity, mailbox, administrative, endpoint, or network correlation.

‍ ‍

· Do not classify unusual egress as exfiltration without data-flow, destination, volume, protocol, timing, and supporting investigative evidence.

‍ ‍

· Do not classify endpoint escalation as CVE-specific unless it is time-correlated with OWA-centered activity and supporting Exchange telemetry.

‍ ‍

Required Telemetry

‍ ‍

· Elastic-ingested OWA access logs.

‍ ‍

· Elastic-ingested IIS logs.

‍ ‍

· Exchange application logs.

‍ ‍

· Windows event logs.

‍ ‍

· Elastic Defend or endpoint telemetry.

‍ ‍

· PowerShell logs.

‍ ‍

· File telemetry where available.

‍ ‍

· Service and scheduled-task telemetry where available.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs.

‍ ‍

· Firewall logs.

‍ ‍

· NDR telemetry.

‍ ‍

· WAF logs where available.

‍ ‍

· Mailbox audit logs where available.

‍ ‍

· Admin audit logs where available.

‍ ‍

· Identity-provider logs where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· Destination asset.

‍ ‍

· Exchange server asset identity.

‍ ‍

· Exchange role.

‍ ‍

· Event timestamp.

‍ ‍

· Process name.

‍ ‍

· Parent process name.

‍ ‍

· Command line.

‍ ‍

· File path.

‍ ‍

· File hash.

‍ ‍

· Signer metadata.

‍ ‍

· Service name.

‍ ‍

· Scheduled task name.

‍ ‍

· Destination IP.

‍ ‍

· Destination domain.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Byte count.

‍ ‍

· Protocol.

‍ ‍

· User context.

‍ ‍

· Asset tags.

‍ ‍

· OWA exposure tags.

‍ ‍

· Approved Exchange egress baselines.

‍ ‍

· Approved maintenance and patching records.

‍ ‍

· Change-management and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Normalize OWA/IIS, Exchange application, Windows, endpoint, PowerShell, DNS, proxy, firewall, NDR, WAF, mailbox audit, admin audit, and identity events into ECS-aligned fields for asset, user, source, destination, action, process, file, timestamp, and session context.

‍ ‍

· Build asset groups for OWA-exposed Exchange servers, on-premises Exchange servers, hybrid Exchange servers, Exchange reverse proxies, WAF-fronted Exchange endpoints, and Exchange management hosts.

‍ ‍

· Build approved baselines for Exchange egress, Exchange application-pool behavior, service restarts, maintenance windows, PowerShell usage, administrative troubleshooting, backup activity, monitoring tools, security tooling, and automation.

‍ ‍

· Correlate suspicious OWA activity with Exchange application instability, endpoint execution behavior, file activity, service activity, scheduled-task activity, PowerShell activity, and unusual Exchange server egress.

‍ ‍

· Use Elastic EQL sequence logic, threshold rules, KQL filters, event correlation, host risk scoring, exception lists, and investigation timelines where available.

‍ ‍

· Use shorter correlation windows for OWA access followed by application errors, process execution, PowerShell execution, DNS lookups, or immediate outbound communication.

‍ ‍

· Use moderate correlation windows for OWA activity followed by file creation, service modification, scheduled-task creation, registry modification, or repeated egress.

‍ ‍

· Use longer correlation windows for delayed staging, repeated tool execution, recurring outbound communication, or slow data-flow escalation.

‍ ‍

· Tune severity based on source novelty, asset criticality, Exchange role, mailbox sensitivity, process behavior, command-line content, destination novelty, destination reputation, byte count, protocol, and correlated mailbox or identity evidence.

‍ ‍

· Avoid broad suppression for Microsoft services, cloud providers, security tools, monitoring tools, backup platforms, automation platforms, or administrative utilities without validation because attacker behavior may blend with legitimate infrastructure and tooling.

‍ ‍

· Use maintenance records, patching records, backup schedules, monitoring records, security-tool context, administrative troubleshooting records, automation records, and incident-response tickets as triage evidence before classifying activity as confirmed host compromise or exfiltration.

‍ ‍

· Validate Elastic index patterns, ECS mappings, ingest pipelines, endpoint integration fields, egress enrichment, asset tags, detection exceptions, environment variables, and time synchronization before production deployment.

‍ ‍

· Validate that host identifiers are consistently mapped across OWA, Exchange application, endpoint, and network telemetry before enabling high-severity escalation alerting.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to OWA activity followed by endpoint, application, or egress escalation rather than CVE strings or static exploit indicators.

‍ ‍

· The rule remains useful if the OWA XSS/spoofing path changes but the activity produces host-level behavior, Exchange instability, PowerShell execution, file activity, or unusual outbound communication.

‍ ‍

· The score is supported by the durability of Exchange asset identity, OWA context, application instability, process behavior, command-line behavior, egress deviation, destination novelty, and timing correlation.

‍ ‍

· The score is constrained by legitimate Exchange maintenance, patching, backup, monitoring, automation, incident-response activity, security tooling, encrypted egress, and environments where endpoint or network visibility is incomplete.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, Exchange application logs, endpoint telemetry, PowerShell visibility, network egress logs, DNS logs, asset tagging, ECS mappings, egress baselines, and maintenance context.

‍ ‍

· Operational confidence is reduced where Exchange systems have frequent patching, backup activity, monitoring activity, automation, administrative troubleshooting, or broad outbound dependencies.

‍ ‍

· Full-telemetry confidence improves when Elastic correlates OWA/IIS records with Exchange application, endpoint, PowerShell, DNS, proxy, firewall, NDR, mailbox audit, admin audit, identity, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong escalation evidence, but confirmed exploitation or exfiltration still requires corroborating evidence and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects escalation patterns after suspicious OWA activity, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing abuse may produce mailbox-control-plane impact without endpoint execution, service instability, file creation, or unusual egress.

‍ ‍

· Legitimate patching, backup, monitoring, administrative troubleshooting, automation, security tooling, and incident-response activity may overlap with suspicious escalation patterns.

‍ ‍

· Missing endpoint telemetry, incomplete PowerShell logs, weak egress visibility, inconsistent Exchange application logs, incomplete asset tags, weak ECS mapping, or weak time synchronization can reduce reliability.

‍ ‍

· EQL sequence reliability depends on consistent host, source, and event-action mapping across OWA, application, endpoint, and network data sources.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, endpoint evidence, Exchange application anomalies, mailbox-control-plane evidence, identity anomalies, administrative changes, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

Elastic EQL escalation pattern requiring platform syntax validation, index-pattern validation, ECS field mapping validation, endpoint-source validation, Exchange application-log validation, egress-baseline validation, enrichment validation, exception-list validation, time-window validation, and environment-specific tuning before production deployment.

‍ ‍

sequence by host.name with maxspan=ENV_OWA_ESCALATION_CORRELATION_WINDOW
[any where
    event.dataset in (
      "iis.access",
      "exchange.owa",
      "proxy.exchange",
      "waf.exchange"
    )
    and url.path : (
      "/owa*",
      "/ecp*",
      "/Microsoft-Server-ActiveSync*",
      "/EWS*",
      "/mapi*",
      "/autodiscover*"
    )
    and destination.domain in (
      "ENV_EXCHANGE_OWA_EXPOSED_ASSETS",
      "ENV_EXCHANGE_REVERSE_PROXY_ASSETS",
      "ENV_EXCHANGE_WAF_FRONTED_ASSETS"
    )
    and (
      source.first_seen_status in (
        "new",
        "rare",
        "newly_observed"
      )
      or not source.geo.country_iso_code in ENV_APPROVED_OWA_ACCESS_GEOS
      or not source.as.organization.name in ENV_APPROVED_OWA_ACCESS_ASNS
      or source.provider_type in (
        "cloud_hosting",
        "vpn_provider",
        "hosting_provider",
        "unknown_external"
      )
      or source.reputation in (
        "high_risk",
        "suspicious",
        "newly_observed"
      )
    )
]
[any where
    (
      event.dataset in (
        "exchange.application",
        "windows.application",
        "iis.application"
      )
      and event.action in (
        "OWA Application Error",
        "IIS Request Anomaly",
        "Application Pool Recycle",
        "Exchange Service Instability",
        "Worker Process Fault",
        "Repeated Request Failure"
      )
    )
    or (
      event.category in (
        "process",
        "file",
        "registry",
        "network"
      )
      and host.name in ENV_ON_PREM_EXCHANGE_SERVERS
      and (
        process.parent.name in (
          "w3wp.exe",
          "MSExchangeTransport.exe",
          "Microsoft.Exchange.ServiceHost.exe",
          "inetinfo.exe"
        )
        or process.name in (
          "powershell.exe",
          "pwsh.exe",
          "cmd.exe",
          "rundll32.exe",
          "regsvr32.exe",
          "mshta.exe",
          "certutil.exe",
          "bitsadmin.exe",
          "schtasks.exe",
          "sc.exe"
        )
        or file.path in ENV_SUSPICIOUS_EXCHANGE_FILE_PATHS
        or event.action in (
          "Service Created",
          "Service Modified",
          "Scheduled Task Created",
          "Registry Modified",
          "Credential Access Behavior"
        )
      )
    )
    or (
      event.category == "network"
      and source.domain in ENV_ON_PREM_EXCHANGE_SERVERS
      and network.direction == "outbound"
      and (
        destination.reputation in (
          "high_risk",
          "suspicious",
          "rare",
          "newly_observed",
          "unknown"
        )
        or destination.category in (
          "anonymization",
          "tunneling",
          "temporary_hosting",
          "paste_service",
          "file_sharing",
          "unapproved_cloud_storage",
          "unknown_external"
        )
        or network.bytes >= ENV_EXCHANGE_EGRESS_VOLUME_THRESHOLD
      )
      and not destination.domain in ENV_APPROVED_EXCHANGE_EGRESS_DESTINATIONS
    )
    and not change.context in (
      "approved_exchange_maintenance",
      "approved_exchange_patching",
      "approved_backup_activity",
      "approved_monitoring_activity",
      "approved_security_tool_activity",
      "approved_administrative_troubleshooting",
      "approved_automation_activity",
      "approved_incident_response_activity"
    )
]

‍ ‍

QRadar

‍ ‍

Detection Viability Assessment

‍ ‍

QRadar has two rules for this EXP report.

‍ ‍

· QRadar is viable for this EXP report where OWA/IIS logs, Exchange application logs, mailbox audit logs, admin audit logs, identity-provider records, endpoint telemetry, DNS, proxy, firewall, WAF, and network-flow telemetry are normalized into QRadar.

‍ ‍

· QRadar is strongest where DSM parsing, custom event properties, reference sets, asset profiles, identity enrichment, source-context preservation, offense correlation rules, and cloud or hybrid SIEM enrichment are mature.

‍ ‍

· QRadar can identify suspicious sequencing between OWA-centered activity, mailbox-control-plane changes, identity anomalies, administrative-control-plane activity, Exchange instability, endpoint escalation, and Exchange server egress.

‍ ‍

· QRadar is suitable for enterprise, managed, cloud-hosted, or hybrid SIEM deployments where on-premises Exchange telemetry is forwarded into centralized analytics.

‍ ‍

· QRadar rules should remain behavior-led and correlation-driven rather than relying on CVE strings, static payloads, single request paths, single user agents, or exploit-specific indicators.

‍ ‍

· QRadar detections should not classify successful CVE-2026-42897 exploitation unless OWA-centered activity is corroborated by mailbox, identity, administrative, endpoint, application, or network evidence.

‍ ‍

· QRadar content should be validated against local DSM mappings, custom properties, reference sets, building blocks, asset models, time synchronization, event-source coverage, and offense-rule behavior before production deployment.

‍ ‍

Rule

‍ ‍

OWA-Centered Activity Followed by Mailbox-Control-Plane or Administrative Changes

‍ ‍

Rule Format

‍ ‍

QRadar correlation rule suitable for OWA/IIS, Exchange mailbox audit, Exchange admin audit, identity, proxy, WAF, asset-profile, reference-set, building-block, and change-management correlation after DSM validation, custom-property validation, Exchange source onboarding, mailbox-audit validation, admin-audit validation, reference-set validation, and environment-specific tuning.

‍ ‍

Detection Purpose

‍ ‍

· Detect suspicious OWA-centered activity followed by mailbox-control-plane or administrative changes.

‍ ‍

· Identify possible OWA XSS/spoofing abuse where attacker value is achieved through mailbox/session/control-plane manipulation rather than host-level compromise.

‍ ‍

· Prioritize mailbox-rule creation, forwarding-rule creation, delegate modification, mailbox-permission changes, suspicious message access, mailbox search, mailbox export behavior, folder activity, transport-rule modification, and Exchange administrative actions.

‍ ‍

· Prioritize activity involving privileged users, executive mailboxes, finance mailboxes, legal mailboxes, security mailboxes, shared mailboxes, service mailboxes, helpdesk mailboxes, and hybrid-administration identities.

‍ ‍

· Support investigation of OWA-centered mail-control-plane abuse without requiring decrypted HTTPS, full message-body inspection, packet capture, rendered-content telemetry, or static exploit indicators.

‍ ‍

· This rule does not prove successful exploitation without supporting OWA/IIS, mailbox audit, admin audit, identity, endpoint, Exchange application, network, or change-management evidence.

‍ ‍

Detection Logic

‍ ‍

· Identify OWA or Exchange web activity from sources that are newly observed, rare for the user, rare for the organization, geographically unusual, ASN-unusual, associated with VPN or hosting infrastructure, or inconsistent with approved user-access patterns.

‍ ‍

· Correlate suspicious OWA activity with mailbox audit events involving inbox-rule creation, inbox-rule modification, forwarding behavior, delegate changes, mailbox permission changes, mailbox search, unusual message access, folder access, mailbox export behavior, move activity, or delete activity.

‍ ‍

· Correlate suspicious OWA activity with admin audit events involving transport-rule creation, transport-rule modification, mailbox permission changes, connector changes, organization-setting changes, role assignments, or Exchange administrative actions.

‍ ‍

· Increase confidence when the mailbox target is privileged, executive, finance, legal, security, shared, service, helpdesk, or hybrid-administration related.

‍ ‍

· Increase confidence when mailbox-control-plane changes create external exposure through forwarding, redirect behavior, external delegates, mailbox permissions, transport-rule copying, blind-copying, or external routing.

‍ ‍

· Increase confidence when the same user, mailbox, source IP, device context, session identifier, destination asset, or related infrastructure appears across OWA, mailbox audit, admin audit, and identity events.

‍ ‍

· Increase confidence when mailbox-control-plane activity occurs outside the user’s normal working hours, normal device pattern, normal location pattern, normal mailbox behavior, or normal administrative role.

‍ ‍

· Increase confidence when QRadar creates an offense from multiple related events across OWA, mailbox audit, admin audit, identity, and asset context.

‍ ‍

· Reduce severity for approved mailbox delegation, approved forwarding, approved transport-rule maintenance, approved compliance workflows, approved helpdesk activity, approved migration activity, approved automation, approved hybrid-management activity, and documented change tickets.

‍ ‍

· Do not classify mailbox-rule, forwarding, delegate, permission, or administrative activity as malicious without source, account, mailbox, target, timing, action, destination, baseline, and change-management context.

‍ ‍

· Do not classify this activity as host compromise unless endpoint, file, process, service, persistence, or network evidence independently supports escalation.

‍ ‍

· Do not treat a vulnerable or exposed Exchange version as compromise evidence without behavioral correlation.

‍ ‍

· Do not allow QRadar offense creation alone to imply confirmed exploitation; offense status should trigger triage, not final classification.

‍ ‍

Required Telemetry

‍ ‍

· QRadar-normalized OWA access logs.

‍ ‍

· QRadar-normalized IIS logs.

‍ ‍

· Exchange mailbox audit logs.

‍ ‍

· Exchange admin audit logs.

‍ ‍

· Exchange application logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Proxy logs where available.

‍ ‍

· WAF logs where available.

‍ ‍

· Endpoint telemetry where available.

‍ ‍

· DNS and network-flow telemetry where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· User.

‍ ‍

· Normalized user identity.

‍ ‍

· Mailbox identity.

‍ ‍

· Target mailbox.

‍ ‍

· Target object.

‍ ‍

· Action name.

‍ ‍

· Rule name.

‍ ‍

· Forwarding destination.

‍ ‍

· Delegate target.

‍ ‍

· Permission type.

‍ ‍

· Transport-rule action.

‍ ‍

· User agent.

‍ ‍

· Request path.

‍ ‍

· Authentication context.

‍ ‍

· Session identifier where available.

‍ ‍

· Device context where available.

‍ ‍

· GeoIP, ASN, VPN-provider, cloud-provider, hosting-provider, and first-seen enrichment.

‍ ‍

· Exchange server asset profiles.

‍ ‍

· OWA exposure reference sets.

‍ ‍

· High-value mailbox reference sets.

‍ ‍

· Approved mailbox delegation reference sets.

‍ ‍

· Approved forwarding reference sets.

‍ ‍

· Approved transport-rule maintenance reference sets.

‍ ‍

· Approved automation reference sets.

‍ ‍

· Approved hybrid-management reference sets.

‍ ‍

· Change-management and ticketing context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Validate DSM parsing for OWA/IIS, Exchange mailbox audit, Exchange admin audit, identity-provider, proxy, WAF, endpoint, DNS, and network-flow sources.

‍ ‍

· Create or validate custom event properties for user, normalized user, mailbox, target mailbox, source IP, original client IP, user agent, request path, action, target object, forwarding destination, delegate target, permission type, transport-rule action, session identifier, device context, and change context.

‍ ‍

· Build QRadar reference sets for OWA-exposed Exchange assets, Exchange reverse proxies, WAF-fronted Exchange paths, hybrid Exchange servers, Exchange management hosts, high-value mailboxes, privileged users, helpdesk mailboxes, service mailboxes, and hybrid-administration identities.

‍ ‍

· Build reference sets for approved mailbox delegation, approved forwarding, approved transport-rule maintenance, approved automation, approved helpdesk workflows, approved migration activity, approved hybrid-management activity, and approved emergency access.

‍ ‍

· Build baselines for normal OWA access patterns, mailbox-rule activity, forwarding behavior, delegate changes, mailbox permissions, transport-rule activity, mailbox search behavior, high-value mailbox access, and Exchange administrative actions.

‍ ‍

· Correlate suspicious OWA source activity with mailbox audit and admin audit events using normalized user, mailbox, source IP, original client IP, destination asset, session context, device context, and time-window alignment.

‍ ‍

· Use QRadar building blocks for suspicious OWA source activity, high-value mailbox targeting, mailbox-control-plane change, administrative-control-plane change, identity anomaly, approved-change suppression, and change-management suppression.

‍ ‍

· Use shorter correlation windows for OWA activity followed by immediate mailbox-rule, forwarding, delegate, permission, or message-access events.

‍ ‍

· Use moderate correlation windows for OWA activity followed by transport-rule changes, administrative actions, repeated mailbox access, or suspicious mailbox search.

‍ ‍

· Use longer correlation windows for delayed forwarding, repeated sensitive-folder access, staged mailbox searches, mailbox export behavior, or recurring activity across high-value mailboxes.

‍ ‍

· Tune offense magnitude based on source novelty, mailbox sensitivity, action type, external data-flow creation, administrator involvement, destination risk, timing, related events, and corroborating identity or endpoint telemetry.

‍ ‍

· Use change-management records, approved delegation records, helpdesk tickets, compliance workflows, migration records, automation records, hybrid-management records, and business justification as triage evidence before classifying the offense as probable exploitation.

‍ ‍

· Validate QRadar DSM mappings, custom properties, reference sets, building blocks, rule responses, asset profiles, time zones, offense indexing, offense grouping, and correlation windows before production deployment.

‍ ‍

· Validate that custom properties are extracted consistently across Exchange web, mailbox audit, admin audit, and identity sources before assigning high offense magnitude.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.5 / 10

‍ ‍

· The rule is behaviorally anchored to suspicious OWA activity followed by mailbox/session/control-plane or administrative changes.

‍ ‍

· The rule remains useful if exploit delivery changes because the downstream mailbox-control-plane and administrative outcomes remain durable and operationally meaningful.

‍ ‍

· The score is supported by the durability of OWA access context, mailbox audit actions, admin audit actions, identity context, mailbox sensitivity, destination context, reference-set enrichment, and time-window correlation.

‍ ‍

· The score is constrained by mailbox audit gaps, admin audit gaps, weak source preservation, DSM parsing gaps, inconsistent custom properties, legitimate delegation, approved forwarding, automation activity, and helpdesk or compliance workflows that may overlap with suspicious activity.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.5 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

9.0 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, mailbox audit logs, admin audit logs, identity-provider logs, source-context preservation, QRadar DSM parsing, custom-property fidelity, reference-set quality, asset profiles, and change-management context.

‍ ‍

· Operational confidence is reduced where mailbox audit logging is incomplete, admin audit logging is inconsistent, reverse proxies obscure source context, custom-property extraction is incomplete, or business-approved forwarding and delegation are poorly documented.

‍ ‍

· Full-telemetry confidence improves when QRadar correlates OWA/IIS activity with mailbox audit, admin audit, identity, endpoint, proxy, WAF, DNS, firewall, flow, NDR, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides strong evidence of probable mailbox-control-plane abuse, but confirmed exploitation still requires corroborating context and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects suspicious OWA-to-mailbox-control-plane or administrative sequencing, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing artifacts may not be visible if content inspection, message-body inspection, rendering telemetry, or decrypted traffic visibility is unavailable.

‍ ‍

· Legitimate delegation, forwarding, helpdesk activity, compliance workflows, automation, migration work, hybrid-management activity, and transport-rule maintenance may overlap with suspicious mailbox-control-plane behavior.

‍ ‍

· Missing mailbox audit logs, admin audit logs, identity context, original source IP, session identifiers, custom properties, or change-management records can reduce confidence.

‍ ‍

· QRadar reliability depends on accurate DSM parsing, custom-property extraction, reference-set maintenance, building-block quality, asset model accuracy, and time synchronization across event sources.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, mailbox audit events, admin audit events, identity anomalies, endpoint telemetry, Exchange application anomalies, network evidence, or validated unauthorized control-plane outcome.

‍ ‍

Detection Query Pattern

‍ ‍

QRadar AQL correlation pattern requiring platform syntax validation, DSM validation, custom-property validation, reference-set validation, mailbox-audit validation, admin-audit validation, time-window validation, offense-grouping validation, and environment-specific tuning before production deployment.

‍ ‍

· Identify suspicious OWA access to on-premises Exchange infrastructure from rare, newly observed, high-risk, geographically unusual, ASN-unusual, hosting, VPN, or otherwise abnormal source infrastructure.

‍ ‍

· Correlate suspicious OWA access with identity anomalies such as unfamiliar session creation, impossible travel, new device context, abnormal authentication sequence, risky sign-in, suspicious conditional-access result, or session reuse from rare infrastructure.

‍ ‍

· Correlate suspicious OWA access with Exchange application errors, IIS anomalies, application-pool recycle activity, worker-process faults, service instability, or abnormal request failure patterns.

‍ ‍

· Correlate suspicious OWA access with endpoint events involving suspicious Exchange or IIS process ancestry, PowerShell execution, file creation, service modification, scheduled-task creation, registry modification, credential-access behavior, or tool staging.

‍ ‍

· Correlate suspicious OWA access with Exchange server outbound communication to rare, newly observed, unapproved, high-risk, anonymization, tunneling, paste, file-sharing, temporary-hosting, or unapproved cloud-storage destinations.

‍ ‍

· Increase confidence when OWA activity, identity anomalies, application instability, endpoint behavior, and unusual egress align within a defensible operational window.

‍ ‍

· Increase confidence when the Exchange server supports high-value mailboxes, is OWA-exposed, participates in hybrid Exchange operations, or recently showed mailbox-control-plane or administrative anomalies.

‍ ‍

· Increase confidence when suspicious endpoint activity includes encoded PowerShell, script downloads, unusual child processes, newly created files, unsigned files, service changes, scheduled tasks, or credential-access indicators.

‍ ‍

· Reduce severity for approved Exchange maintenance, approved patching, approved backup activity, approved security tooling, approved monitoring activity, approved administrative troubleshooting, approved automation, approved hybrid-management activity, approved emergency access, and documented incident-response activity.

‍ ‍

· Do not classify Exchange instability as exploitation without OWA, identity, mailbox, administrative, endpoint, or network correlation.

‍ ‍

· Do not classify unusual egress as exfiltration without data-flow, destination, volume, protocol, timing, and supporting investigative evidence.

‍ ‍

· Do not classify endpoint escalation as CVE-specific unless it is time-correlated with OWA-centered activity and supporting Exchange telemetry.

‍ ‍

· Do not allow one endpoint, identity, application, or egress signal to drive confirmed compromise classification without supporting signal-family correlation.

‍ ‍

Required Telemetry

‍ ‍

· QRadar-normalized OWA access logs.

‍ ‍

· QRadar-normalized IIS logs.

‍ ‍

· Identity-provider sign-in logs.

‍ ‍

· Conditional-access logs where available.

‍ ‍

· Risky sign-in telemetry where available.

‍ ‍

· Exchange application logs.

‍ ‍

· Windows event logs.

‍ ‍

· Endpoint telemetry.

‍ ‍

· PowerShell logs.

‍ ‍

· File telemetry where available.

‍ ‍

· Service and scheduled-task telemetry where available.

‍ ‍

· DNS logs.

‍ ‍

· Proxy logs.

‍ ‍

· Firewall logs.

‍ ‍

· Network-flow telemetry.

‍ ‍

· WAF logs where available.

‍ ‍

· Mailbox audit logs where available.

‍ ‍

· Admin audit logs where available.

‍ ‍

· Source IP.

‍ ‍

· Original client IP where available.

‍ ‍

· Destination asset.

‍ ‍

· Exchange server asset identity.

‍ ‍

· Exchange role.

‍ ‍

· Event timestamp.

‍ ‍

· Identity event type.

‍ ‍

· Authentication result.

‍ ‍

· Device context.

‍ ‍

· Process name.

‍ ‍

· Parent process name.

‍ ‍

· Command line.

‍ ‍

· File path.

‍ ‍

· File hash.

‍ ‍

· Signer metadata.

‍ ‍

· Service name.

‍ ‍

· Scheduled task name.

‍ ‍

· Destination IP.

‍ ‍

· Destination domain.

‍ ‍

· Destination reputation.

‍ ‍

· Destination category.

‍ ‍

· Byte count.

‍ ‍

· Protocol.

‍ ‍

· User context.

‍ ‍

· QRadar asset profiles.

‍ ‍

· OWA exposure reference sets.

‍ ‍

· Approved Exchange egress reference sets.

‍ ‍

· Approved maintenance and patching records.

‍ ‍

· Approved hybrid-management records.

‍ ‍

· Change-management and incident-response context.

‍ ‍

Engineering Implementation Instructions

‍ ‍

· Validate DSM parsing for OWA/IIS, identity-provider, Exchange application, Windows, endpoint, PowerShell, DNS, proxy, firewall, flow, WAF, mailbox audit, and admin audit sources.

‍ ‍

· Create or validate custom event properties for user, source IP, original client IP, destination asset, request path, identity event type, authentication result, device context, process name, parent process name, command line, file path, service name, scheduled task name, destination domain, destination category, byte count, protocol, and change context.

‍ ‍

· Build asset profiles and reference sets for OWA-exposed Exchange servers, on-premises Exchange servers, hybrid Exchange servers, Exchange reverse proxies, WAF-fronted Exchange endpoints, Exchange management hosts, approved egress destinations, approved management hosts, and high-value Exchange assets.

‍ ‍

· Build approved baselines for Exchange egress, Exchange application-pool behavior, service restarts, maintenance windows, PowerShell usage, administrative troubleshooting, backup activity, monitoring tools, security tooling, automation, and hybrid-management activity.

‍ ‍

· Use QRadar building blocks for suspicious OWA source activity, identity anomaly, Exchange application instability, endpoint escalation, suspicious PowerShell activity, unusual Exchange egress, approved-operation suppression, and approved-change suppression.

‍ ‍

· Correlate suspicious OWA activity with identity anomalies, Exchange application instability, endpoint execution behavior, file activity, service activity, scheduled-task activity, PowerShell activity, and unusual Exchange server egress.

‍ ‍

· Use shorter correlation windows for OWA access followed by identity anomalies, application errors, process execution, PowerShell execution, DNS lookups, or immediate outbound communication.

‍ ‍

· Use moderate correlation windows for OWA activity followed by file creation, service modification, scheduled-task creation, registry modification, repeated egress, or repeated identity anomalies.

‍ ‍

· Use longer correlation windows for delayed staging, repeated tool execution, recurring outbound communication, delayed identity misuse, or slow data-flow escalation.

‍ ‍

· Tune offense magnitude based on source novelty, asset criticality, Exchange role, mailbox sensitivity, identity anomaly type, process behavior, command-line content, destination novelty, destination reputation, byte count, protocol, and correlated mailbox or administrative evidence.

‍ ‍

· Avoid broad suppression for Microsoft services, cloud providers, security tools, monitoring tools, backup platforms, automation platforms, hybrid-management workflows, or administrative utilities without validation because attacker behavior may blend with legitimate infrastructure and tooling.

‍ ‍

· Use maintenance records, patching records, backup schedules, monitoring records, security-tool context, administrative troubleshooting records, automation records, emergency-access records, hybrid-management records, and incident-response tickets as triage evidence before classifying activity as confirmed host compromise or exfiltration.

‍ ‍

· Validate QRadar DSM mappings, custom properties, reference sets, asset profiles, building blocks, offense rules, rule responses, time zones, offense grouping, and correlation windows before production deployment.

‍ ‍

· Validate that QRadar offense grouping does not merge unrelated OWA, endpoint, identity, or egress activity from shared proxies, NAT gateways, or load-balanced Exchange infrastructure.

‍ ‍

DRI Assessment

‍ ‍

DRI

‍ ‍

8.0 / 10

‍ ‍

· The rule is behaviorally anchored to OWA activity followed by identity, endpoint, application, or egress escalation rather than CVE strings or static exploit indicators.

‍ ‍

· The rule remains useful if the OWA XSS/spoofing path changes but the activity produces identity misuse, host-level behavior, Exchange instability, PowerShell execution, file activity, or unusual outbound communication.

‍ ‍

· The score is supported by the durability of Exchange asset identity, OWA context, identity anomaly context, application instability, process behavior, command-line behavior, egress deviation, destination novelty, and timing correlation.

‍ ‍

· The score is constrained by legitimate Exchange maintenance, patching, backup, monitoring, automation, emergency access, incident-response activity, security tooling, encrypted egress, DSM parsing quality, and environments where endpoint or network visibility is incomplete.

‍ ‍

TCR Assessment

‍ ‍

Operational TCR

‍ ‍

7.0 / 10

‍ ‍

Full-Telemetry TCR

‍ ‍

8.5 / 10

‍ ‍

· Operational confidence depends on reliable OWA/IIS logs, identity-provider telemetry, Exchange application logs, endpoint telemetry, PowerShell visibility, network egress logs, DNS logs, asset profiles, reference sets, DSM parsing, custom-property fidelity, and maintenance context.

‍ ‍

· Operational confidence is reduced where Exchange systems have frequent patching, backup activity, monitoring activity, automation, administrative troubleshooting, emergency access, hybrid-management activity, or broad outbound dependencies.

‍ ‍

· Full-telemetry confidence improves when QRadar correlates OWA/IIS records with identity, Exchange application, endpoint, PowerShell, DNS, proxy, firewall, flow, mailbox audit, admin audit, and change-management records.

‍ ‍

· Under full telemetry conditions, this rule provides useful escalation evidence, but confirmed exploitation or exfiltration still requires corroborating evidence and analyst validation.

‍ ‍

Limitations

‍ ‍

· This rule detects escalation patterns after suspicious OWA activity, not successful exploitation by itself.

‍ ‍

· OWA-centered XSS/spoofing abuse may produce mailbox-control-plane impact without endpoint execution, service instability, file creation, or unusual egress.

‍ ‍

· Legitimate patching, backup, monitoring, administrative troubleshooting, automation, emergency access, hybrid-management activity, security tooling, and incident-response activity may overlap with suspicious escalation patterns.

‍ ‍

· Missing endpoint telemetry, incomplete PowerShell logs, weak egress visibility, inconsistent Exchange application logs, incomplete asset profiles, weak custom properties, or weak time synchronization can reduce reliability.

‍ ‍

· QRadar reliability depends on accurate DSM parsing, custom-property extraction, reference-set maintenance, building-block quality, asset model accuracy, offense grouping, and correlation-window tuning.

‍ ‍

· Confirmation requires correlation with OWA/IIS activity, endpoint evidence, Exchange application anomalies, mailbox-control-plane evidence, identity anomalies, administrative changes, or validated data movement.

‍ ‍

Detection Query Pattern

‍ ‍

QRadar AQL escalation pattern requiring platform syntax validation, DSM validation, custom-property validation, endpoint-source validation, Exchange application-log validation, egress-baseline validation, reference-set validation, time-window validation, offense-grouping validation, and environment-specific tuning before production deployment.

‍ ‍

SELECT
owa."destinationip" AS exchange_asset,
owa."sourceip" AS source_ip,
owa."originalclientip" AS original_client_ip,
owa."username" AS user,
owa."url" AS request_path,
escalation."eventname" AS escalation_event,
escalation."processname" AS process_name,
escalation."parentprocessname" AS parent_process_name,
escalation."commandline" AS command_line,
escalation."destinationdomain" AS destination_domain,
escalation."destinationreputation" AS destination_reputation,
escalation."destinationcategory" AS destination_category,
escalation."bytesout" AS bytes_out,
MIN(owa.starttime) AS first_owa_time,
MIN(escalation.starttime) AS first_escalation_time
FROM events AS owa
JOIN events AS escalation
ON owa."destinationip" = escalation."sourceassetip"
WHERE
owa."logsource" IN (
    'Exchange OWA',
    'IIS Exchange',
    'Exchange Reverse Proxy',
    'Exchange WAF'
)
AND (
    owa."url" ILIKE '/owa%'
    OR owa."url" ILIKE '/ecp%'
    OR owa."url" ILIKE '/Microsoft-Server-ActiveSync%'
    OR owa."url" ILIKE '/EWS%'
    OR owa."url" ILIKE '/mapi%'
    OR owa."url" ILIKE '/autodiscover%'
)
AND owa."destinationip" IN REFERENCESET('OWA Exposed Exchange Assets')
AND (
    owa."sourceip" IN REFERENCESET('Newly Observed Sources')
    OR owa."sourcegeo" NOT IN REFERENCESET('Approved OWA Access Geographies')
    OR owa."sourceasn" NOT IN REFERENCESET('Approved OWA Access ASNs')
    OR owa."sourceprovidertype" IN (
      'cloud_hosting',
      'vpn_provider',
      'hosting_provider',
      'unknown_external'
    )
    OR owa."sourcereputation" IN (
      'high_risk',
      'suspicious',
      'newly_observed'
    )
)
AND escalation."logsource" IN (
    'Exchange Application',
    'Windows Event Log',
    'Endpoint Detection',
    'PowerShell',
    'DNS',
    'Proxy',
    'Firewall',
    'Network Flow'
)
AND (
    escalation."eventname" IN (
      'OWA Application Error',
      'IIS Request Anomaly',
      'Application Pool Recycle',
      'Exchange Service Instability',
      'Worker Process Fault',
      'Process Creation',
      'File Created',
      'Service Created',
      'Service Modified',
      'Scheduled Task Created',
      'Registry Modified',
      'PowerShell Execution',
      'Credential Access Behavior'
    )
    OR escalation."destinationreputation" IN (
      'high_risk',
      'suspicious',
      'rare',
      'newly_observed',
      'unknown'
    )
    OR escalation."destinationcategory" IN (
      'anonymization',
      'tunneling',
      'temporary_hosting',
      'paste_service',
      'file_sharing',
      'unapproved_cloud_storage',
      'unknown_external'
    )
    OR escalation."bytesout" >= ENV_EXCHANGE_EGRESS_VOLUME_THRESHOLD
)
AND escalation."changecontext" NOT IN (
    'approved_exchange_maintenance',
    'approved_exchange_patching',
    'approved_backup_activity',
    'approved_monitoring_activity',
    'approved_security_tool_activity',
    'approved_administrative_troubleshooting',
    'approved_automation_activity',
    'approved_hybrid_management',
    'approved_emergency_access',
    'approved_incident_response_activity'
)
AND ABS(escalation.starttime - owa.starttime) <= ENV_OWA_ESCALATION_CORRELATION_WINDOW
GROUP BY
exchange_asset,
source_ip,
original_client_ip,
user,
request_path,
escalation_event,
process_name,
parent_process_name,
command_line,
destination_domain,
destination_reputation,
destination_category,
bytes_out
HAVING
(
    escalation_event IS NOT NULL
    OR destination_reputation IN (
      'high_risk',
      'suspicious',
      'rare',
      'newly_observed'
    )
    OR bytes_out >= ENV_EXCHANGE_EGRESS_VOLUME_THRESHOLD
)

SIGMA

Detection Viability Assessment

SIGMA has three rules for this EXP report.

· SIGMA is viable as portable detection logic for endpoint, Windows, IIS, Exchange, PowerShell, service-control, scheduled-task, registry, and file-event patterns associated with OWA-centered Exchange abuse.

· SIGMA is strongest where rules are translated into a SIEM or XDR backend that can correlate SIGMA hits with OWA/IIS logs, Exchange mailbox audit logs, Exchange admin audit logs, identity telemetry, endpoint telemetry, DNS, proxy, firewall, WAF, NDR, and change-management records.

· SIGMA can express durable behavioral patterns involving suspicious Exchange or IIS process ancestry, Exchange PowerShell activity, management command behavior, file activity, service changes, scheduled tasks, and persistence-like behavior.

· SIGMA is useful as a portable rule layer, but it should not be treated as the complete analytic layer for this report because OWA XSS/spoofing and mailbox/session/control-plane abuse require cross-source correlation.

· SIGMA detections should remain behavior-led and should not rely on CVE strings, static exploit payloads, single request paths, single user agents, or one public exploit pattern.

· SIGMA detections should not classify successful CVE-2026-42897 exploitation unless the translated SIEM rule correlates OWA-centered activity with mailbox, identity, administrative, endpoint, application, or network evidence.

· SIGMA content should be validated against the target backend, field mappings, log source availability, pipeline transformations, normalization quality, false-positive handling, and correlation support before production deployment.

· SIGMA rules should be treated as translated detection primitives that support the S25 model, not as standalone proof of OWA XSS/spoofing exploitation.

Rule

Suspicious Exchange or IIS Process Ancestry After OWA-Centered Activity

Rule Format

SIGMA behavioral rule suitable for Windows process creation, Sysmon, EDR, PowerShell, and Exchange server telemetry after log-source validation, backend translation validation, Exchange asset tagging, process-baseline validation, approved-administration validation, and environment-specific tuning.

Detection Purpose

· Detect suspicious process execution on Exchange servers where IIS, Exchange services, or Exchange-related worker processes spawn command shells, scripting engines, administrative utilities, download tools, archive tools, remote-access tools, reconnaissance utilities, or credential-access tooling.

· Identify possible host-level escalation following OWA-centered XSS/spoofing activity, suspicious OWA access, Exchange application anomalies, identity anomalies, administrative-control-plane changes, or mailbox-control-plane abuse.

· Prioritize suspicious process behavior on Exchange servers that host OWA, support high-value mailboxes, participate in hybrid Exchange operations, or show recent suspicious OWA/IIS activity.

· Support portable detection of endpoint escalation without assuming every suspicious OWA event results in command execution, malware deployment, web-shell placement, or host compromise.

· This rule does not prove successful exploitation without supporting OWA/IIS, mailbox audit, admin audit, identity, Exchange application, endpoint, or network evidence.