[EXP] SharePoint Server RCE and IIS Worker Process Post-Exploitation Detection Coverage

Jul 2

Report Type: EXP
Threat Category: SharePoint Server RCE and IIS Worker Process Post-Exploitation
Assessment Date: July 02, 2026
Primary Impact Domain: Enterprise Collaboration Infrastructure Trust
Secondary Impact Domains: Application Server Integrity, Service-Account Trust, Credential Exposure, Internal Expansion, Conditional Cloud-Control-Plane Exposure
Affected Asset Class: On-Premises Microsoft SharePoint Server and IIS-Hosted SharePoint Infrastructure
Threat Objective Classification: Server-Side Execution, File Staging, Webshell-Like Access, Credential or Machine-Key Exposure, Outbound Communication, Internal Expansion

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 02, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍ SharePoint Server RCE and IIS worker process post-exploitation create material enterprise risk when attackers can convert exposed or vulnerable SharePoint infrastructure into server-side execution, file staging, credential access, outbound communication, internal expansion, or downstream cloud-control-plane exposure. The report is driven by the operational reality that successful SharePoint exploitation may not preserve a stable exploit string, request artifact, payload marker, or webshell name, making behavior-led detection more reliable than CVE-only or request-path-only alerting. The primary concern is whether SharePoint or IIS service context produced abnormal execution, suspicious file creation, rare outbound communication, service-account misuse, or internal movement before remediation closed the visible exposure. Executive action is required to validate SharePoint Server inventory, exposure state, patch status, IIS and SharePoint log retention, endpoint process visibility, file and webroot telemetry, outbound communication baselines, service-account behavior, and detection coverage for request-to-execution, worker-process child execution, file staging, internal expansion, and conditional downstream cloud activity.

Executive Risk Translation

This threat shifts business risk from isolated SharePoint vulnerability exposure to loss of trust in enterprise collaboration infrastructure, Windows application-server integrity, privileged service-account behavior, and downstream identity-dependent systems. The core executive issue is not only whether SharePoint Server was vulnerable or patched, but whether an exposed SharePoint or IIS-hosted SharePoint system was used to execute commands, stage files, alter web-accessible content, access credentials, communicate externally, or move internally before remediation. If compromise occurred, response may expand into SharePoint server isolation, webroot and application-directory review, application pool identity review, credential rotation, service-account containment, database and file-share access review, outbound traffic analysis, lateral-movement scoping, cloud identity review, legal assessment, executive incident governance, and business assurance for affected collaboration services. This creates operational, financial, regulatory, reputational, and customer-trust exposure beyond the initially vulnerable SharePoint service.

S3 — Why This Matters Now

· SharePoint Server remains a high-value enterprise collaboration platform connected to documents, workflows, internal portals, service accounts, databases, identity systems, file shares, and business-critical content.

· SharePoint RCE risk should be treated as an application-server compromise issue, not only as a vulnerability-management or patch-status issue.

· Successful exploitation can produce suspicious execution from w3wp.exe, SharePoint application pool identities, SharePoint service accounts, or IIS worker process context.

· Post-exploitation behavior may involve command interpreters, scripting engines, download utilities, archive tools, reconnaissance commands, webshell-like file placement, outbound communication, credential access, and internal expansion.

· Exploit attempts may not leave stable request strings, payload markers, serialized object artifacts, or CVE-specific indicators in standard logs.

· Authenticated exploitation remains relevant because valid credentials, compromised sessions, low-privilege users, VPN access, reverse proxies, stolen cookies, or trusted internal access paths can precede abnormal server-side behavior.

· Patch validation does not prove that exposed SharePoint systems were uncompromised before remediation.

· Historical compromise review is required when exposed or high-value SharePoint servers had suspicious request activity, IIS faults, worker process instability, file staging, outbound communication, or abnormal service-account behavior before remediation.

· Detection must prioritize behavior-chain convergence across SharePoint request activity, endpoint process lineage, file telemetry, network telemetry, identity context, and conditional cloud-control-plane activity.

· Organizations without reliable SharePoint server inventory, IIS log mapping, endpoint telemetry, file telemetry, service-account baselines, destination baselines, and SIEM correlation face elevated risk of delayed detection and incomplete scoping.

S4 — Key Judgments

· SharePoint Server RCE and IIS worker process post-exploitation create high-priority enterprise infrastructure risk because successful server-side execution can affect collaboration data, application-server integrity, service-account trust, downstream authentication, and internal movement paths.

· The primary business risk is attacker use of SharePoint or IIS service context to execute commands, stage files, deploy webshell-like artifacts, access credentials, communicate externally, or expand into internal systems.

· The strongest enterprise risk signal is SharePoint or IIS request activity followed by suspicious worker process execution, suspicious file creation, rare outbound communication, application instability, service-account misuse, or internal expansion from the same server.

· Vulnerable or exposed SharePoint systems should drive patch prioritization and retrospective hunting, but exposure state, version status, scan activity, or request anomalies alone should not be treated as confirmed compromise.

· Endpoint process telemetry is central because suspicious child process execution from w3wp.exe, owstimer.exe, SharePoint service context, or application-pool identities provides high-confidence evidence of abnormal server-side behavior.

· File telemetry is central because new or modified ASPX, DLL, EXE, script, archive, temporary, configuration, or staging artifacts in SharePoint, IIS, webroot, layout, upload, temporary, or application-adjacent paths can indicate payload staging or webshell-like persistence.

· Network telemetry materially improves detection when SharePoint servers initiate rare outbound communication, direct internet egress, suspicious DNS activity, abnormal transfer behavior, or internal connections inconsistent with approved SharePoint dependencies.

· Identity telemetry is required to determine whether SharePoint application pool identities, service accounts, administrators, or authenticated users behaved outside established baselines.

· SIEM correlation provides the strongest end-to-end behavior-chain visibility when SharePoint request telemetry, endpoint execution, file activity, network activity, asset inventory, identity context, and approved-workflow suppressions share normalized host, user, process, and time fields.

· NDR coverage is strongest for rare outbound communication and internal expansion from SharePoint infrastructure, but network telemetry alone should not be treated as exploit confirmation.

· AWS, Azure, and Google Cloud coverage should be treated as conditional downstream correlation only when identity, source, session, device, service-account, role, project, subscription, account, organization, or incident-case lineage connects cloud activity to SharePoint compromise context.

· Executive risk reduction depends on patch validation, exposed asset identification, historical compromise review, endpoint and file telemetry validation, service-account review, outbound communication review, internal movement scoping, and validated detection coverage across endpoint, SIEM, NDR, portable-rule, and conditional cloud-correlation layers.

S5 — Executive Risk Summary

Business Risk

SharePoint Server compromise can create severe operational, regulatory, customer-trust, and reputational risk when attackers gain server-side execution on infrastructure that supports enterprise collaboration, document storage, workflow processing, internal portals, business applications, identity-connected services, and downstream data access. Risk increases when affected SharePoint systems are internet-facing, partner-facing, extranet-connected, hybrid-connected, highly privileged, poorly segmented, or tied to sensitive business units, regulated content, executive workflows, legal repositories, financial data, engineering data, customer data, or identity-dependent automation.

Technical Cause

The risk is driven by SharePoint Server RCE and IIS worker process post-exploitation conditions where abnormal request handling, authenticated access, application faults, or vulnerable server-side paths may lead to execution from SharePoint or IIS service context. The enterprise detection model should focus on w3wp.exe and SharePoint service-context child process execution, suspicious command lines, SharePoint webroot and application-path file staging, rare outbound communication, internal expansion, service-account behavior, and downstream cloud-control-plane activity only when linked to SharePoint compromise context.

Threat Posture

The threat posture is elevated because successful exploitation can convert a collaboration application server into an execution foothold, staging point, credential-access path, internal movement bridge, webshell location, outbound callback source, or downstream cloud identity pivot. The risk is amplified when SharePoint servers have broad access to databases, file shares, domain services, backup systems, administrative hosts, identity infrastructure, or cloud-linked administrator accounts.

Executive Decision Requirement

Executives must require immediate validation of SharePoint Server exposure, patch status, asset ownership, log retention, endpoint coverage, process-lineage visibility, file telemetry, outbound destination baselines, service-account baselines, and internal communication baselines. Response leadership should also confirm that patched or remediated systems receive retrospective compromise review when they were exposed before remediation or show suspicious request, execution, file, network, identity, crash, or application-fault evidence.

S6 — Executive Cost Summary

[EXP] SharePoint Server RCE and IIS Worker Process Post-Exploitation Detection Coverage creates financial exposure based on the number of exposed SharePoint servers, whether server-side execution occurred before remediation, whether SharePoint or IIS service context staged files or executed commands, whether credentials or service accounts were exposed, whether collaboration content or web-accessible files were modified, whether outbound communication or internal expansion occurred, whether downstream cloud activity can be linked to SharePoint compromise context, telemetry completeness, and how broadly affected SharePoint services support regulated, executive, customer, legal, financial, operational, or mission-critical business workflows.

Low Impact Scenario

Rapid assessment confirms affected SharePoint servers were patched or isolated quickly, IIS and SharePoint logs are preserved, no suspicious w3wp.exe or SharePoint service-context child process execution is observed, no suspicious SharePoint webroot or application-path file staging is identified, no rare outbound communication or internal expansion is linked to the servers, no service-account misuse is observed, and no downstream cloud-control-plane activity is tied to SharePoint compromise context. Response still requires emergency patch validation, exposed asset scoping, endpoint and file-system hunting, log preservation, service-account review, outbound destination review, and executive tracking because exposed SharePoint infrastructure can create high-consequence business risk; estimated impact $2M to $10M.

Moderate Impact Scenario

Suspicious SharePoint or IIS request activity, worker process instability, suspicious child process execution, limited file staging, abnormal service-account behavior, rare outbound communication, or constrained internal access is identified on one or more SharePoint servers, but investigation indicates limited blast radius and no confirmed broad data exposure, sustained persistence, large-scale credential compromise, or material downstream cloud-control-plane impact. Response requires server containment or controlled isolation, retrospective log review, endpoint forensics, webroot and SharePoint directory inspection, credential rotation for affected accounts, service-account review, database and file-share access review, outbound traffic analysis, detection tuning, SOC surge support, legal assessment, business-owner coordination, and executive incident governance; estimated impact $20M to $90M.

High Impact Scenario

Confirmed or strongly suspected SharePoint server compromise affects internet-facing, partner-facing, extranet, hybrid, high-value, or business-critical SharePoint infrastructure, with evidence of server-side execution, webshell-like artifact placement, credential access, service-account misuse, collaboration content exposure, database or file-share access, internal expansion, security-tool tampering, outbound staging, incomplete historical telemetry, or downstream AWS, Azure, or Google Cloud activity linked to SharePoint compromise context. Response may require broad server isolation, SharePoint farm integrity review, webroot and application-directory forensics, credential rotation at scale, database and file-share scoping, backup and recovery validation, segmentation changes, legal and regulatory review, cyber insurance engagement, customer or workforce communications, executive incident governance, and board-level oversight; estimated impact $125M to $500M or higher.

S6A — Key Cost Drivers

· Number of exposed on-premises SharePoint Server and IIS-hosted SharePoint systems.

· Whether affected SharePoint systems were internet-facing, partner-facing, extranet-connected, VPN-accessible, reverse-proxy-accessible, hybrid-connected, or internally reachable from broad user populations.

· Whether patch validation occurred before or after suspicious SharePoint request activity, application faults, worker process instability, suspicious process execution, file staging, or outbound communication.

· Whether w3wp.exe, owstimer.exe, SharePoint application pool identities, service accounts, or IIS worker process context launched command interpreters, scripting engines, download utilities, archive tools, reconnaissance commands, or living-off-the-land binaries.

· Whether suspicious files were created or modified in SharePoint webroot, IIS application, layout, upload, temporary, staging, or application-adjacent directories.

· Whether suspicious ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, archive, temporary, configuration, or XML artifacts were present.

· Whether suspicious file activity was followed by outbound communication, repeated access to new web-accessible artifacts, credential access, archive creation, or internal expansion.

· Whether SharePoint servers initiated rare outbound connections, direct internet egress, suspicious DNS lookups, file-sharing access, paste-site access, dynamic DNS communication, newly observed destinations, abnormal ports, or unusual transfer volumes.

· Whether SharePoint servers initiated abnormal SMB, LDAP, Kerberos, NTLM, WinRM, WMI, RPC, RDP, MSSQL, administrative-share, file-server, database-server, backup-system, management-server, or domain-controller activity.

· Whether service accounts, application pool identities, administrator accounts, compromised users, or privileged identities authenticated from SharePoint servers outside approved workflows.

· Whether downstream AWS, Azure, or Google Cloud activity can be linked to SharePoint compromise context through identity, source IP, device, session, role, service account, project, subscription, account, organization, or incident-case lineage.

· Whether affected SharePoint servers host or provide access to regulated data, customer data, legal repositories, financial records, executive files, source-code-related content, engineering data, sensitive contracts, operational procedures, or high-value collaboration workspaces.

· Availability and retention of IIS logs, SharePoint application logs, ULS data, reverse proxy logs, WAF logs, load-balancer logs, endpoint process telemetry, file telemetry, DNS logs, proxy logs, firewall logs, NDR data, identity telemetry, cloud audit logs, and incident-case context.

· Ability to normalize backend host identity, source user, source IP, request path, process lineage, file path, service account, destination, cloud identity, and event time across SIEM, EDR, NDR, identity, and cloud platforms.

· Need for credential rotation across SharePoint service accounts, application pool identities, local administrators, domain administrators, database users, automation accounts, API keys, cloud roles, federated identities, and privileged users.

· Need for SharePoint farm integrity review, webroot inspection, database access review, file-share scoping, backup validation, application pool configuration review, and downstream authentication review.

· Need for legal review, regulatory assessment, customer or workforce assurance, cyber insurance reporting, executive communications, and board-level incident oversight.

· Degree to which incomplete telemetry forces broader containment, server rebuilds, SharePoint farm recovery, credential reset at scale, cloud-access review, or extended historical compromise assessment.

S6B — Compliance and Risk Context

Figure 1

Compliance Exposure Indicator

Moderate to High depending on whether SharePoint compromise involved unauthorized server-side execution, collaboration content exposure, regulated-data access, credential compromise, service-account misuse, database access, file-share access, webshell-like artifacts, outbound communication, internal expansion, downstream cloud activity, customer-impact uncertainty, workforce data exposure, or incomplete forensic scoping.

Risk Register Entry

Risk Title

SharePoint Server RCE and IIS Worker Process Post-Exploitation Enterprise Infrastructure Compromise

Risk Description

Adversaries may exploit exposed or vulnerable SharePoint Server infrastructure to obtain server-side execution, launch commands from IIS or SharePoint service context, stage files in SharePoint or IIS-accessible directories, access credentials, modify application content, initiate rare outbound communication, move internally, misuse service accounts, or expand into downstream cloud-control-plane activity when identity or session lineage connects SharePoint compromise context to cloud resources.

Likelihood

High.

Impact

Severe.

Risk Rating

Critical.

Annualized Risk Exposure

Estimated $30M to $140M or higher based on SharePoint server exposure, asset criticality, patch latency, collaboration-data sensitivity, service-account privilege, endpoint visibility, file telemetry completeness, IIS and SharePoint log retention, outbound network visibility, internal movement evidence, downstream cloud linkage, regulatory obligations, containment complexity, and executive assurance requirements.

S7 — Risk Drivers

· SharePoint Server is commonly tied to enterprise collaboration, document storage, workflows, internal portals, business applications, identity-connected services, databases, file shares, and privileged administrative operations.

· SharePoint Server RCE can create direct application-server compromise risk when attackers convert exposed or authenticated access paths into server-side execution.

· IIS worker process lineage creates high-confidence risk when w3wp.exe, owstimer.exe, SharePoint service context, application-pool identities, or service accounts launch suspicious child processes.

· Suspicious child process execution can include command shells, PowerShell, Windows Script Host, MSHTA, Rundll32, Regsvr32, Certutil, Bitsadmin, Curl, Wget, archive tools, reconnaissance commands, and living-off-the-land binaries.

· Suspicious file staging in SharePoint or IIS paths can indicate webshell placement, payload staging, tool placement, archive creation, script staging, persistence preparation, or content tampering.

· Web request anomalies may not preserve full exploit bodies, serialized payloads, authentication token details, request bodies, or backend execution context in standard logs.

· Authenticated exploitation or post-authentication abuse can blend into normal SharePoint access unless user context, source device, source network, session timing, request sequence, and downstream server behavior are correlated.

· Patch status alone does not prove that exposed SharePoint servers were uncompromised before remediation.

· Absence of known webshell names, malware hashes, static IOCs, or CVE-specific request strings does not prove absence of compromise.

· Endpoint telemetry gaps can obscure short-lived processes, in-memory execution, deleted artifacts, parent-child process lineage, and command-line content.

· File telemetry gaps can obscure short-lived webshells, temporary staging files, renamed files, hidden files, permission changes, and artifacts created and deleted before collection.

· IIS, SharePoint, proxy, WAF, or load-balancer mapping gaps can prevent teams from tying suspicious requests to backend SharePoint servers.

· Network visibility gaps can obscure rare outbound destinations, direct internet egress, abnormal transfer behavior, internal expansion, and post-exploitation infrastructure contact.

· Service-account and application-pool identity baseline gaps can prevent teams from distinguishing legitimate SharePoint processing from malicious post-exploitation behavior.

· Cloud identity lineage gaps can prevent teams from determining whether AWS, Azure, or Google Cloud activity is related to SharePoint compromise context.

· Legitimate patching, backup operations, monitoring tools, search indexing, deployment workflows, SharePoint customization, vulnerability scanning, and administrative scripts can resemble malicious behavior without approved-workflow baselines.

· Over-reliance on CVE strings, public proof-of-concept artifacts, scanner names, known malicious IPs, request paths, user-agent strings, filenames, or webshell names can miss evolved exploitation and post-exploitation tradecraft.

S8 — Bottom Line for Executives

[EXP] SharePoint Server RCE and IIS Worker Process Post-Exploitation Detection Coverage should be treated as a high-priority enterprise infrastructure trust issue because SharePoint compromise can affect more than the vulnerable application endpoint. The key executive concern is whether exposed or vulnerable SharePoint systems allowed attackers to execute commands, stage files, misuse service accounts, access sensitive collaboration content, communicate externally, move internally, or pivot into downstream cloud-control-plane activity before remediation. Risk reduction depends on patch confirmation, exposed asset scoping, historical compromise review, preserved IIS and SharePoint logs, endpoint process visibility, SharePoint directory and webroot inspection, outbound communication review, service-account validation, internal expansion scoping, and validated detection coverage across endpoint, SIEM, NDR, portable-rule, and conditional cloud-correlation layers. Organizations should prioritize this report as a collaboration-platform compromise and enterprise blast-radius issue because successful exploitation can create operational disruption, credential exposure, regulatory uncertainty, customer or workforce trust loss, and board-level incident governance requirements.

S9 — Board-Level Takeaway

SharePoint Server RCE and IIS worker process post-exploitation turn a collaboration platform vulnerability into a potential enterprise infrastructure compromise risk. The board-level concern is whether attackers used SharePoint or IIS service context to execute commands, stage files, access credentials, alter web-accessible content, communicate externally, move internally, or reach downstream cloud resources tied to privileged identity lineage. Leadership should require evidence that exposed SharePoint assets were identified, patch status was validated, logs were preserved, endpoint and file telemetry were reviewed, service-account activity was investigated, outbound and internal communication were scoped, and downstream cloud-control-plane activity was assessed when identity, source, session, device, or incident-case linkage exists. This report supports governance decisions around SharePoint infrastructure risk, collaboration-data trust, privileged service-account containment, telemetry readiness, historical compromise review, credential rotation, cloud identity assurance, incident response scope, and executive oversight of enterprise application-server compromise.

S10 — Threat Overview

[EXP] SharePoint Server RCE and IIS Worker Process Post-Exploitation Detection Coverage centers on attacker abuse of exposed, vulnerable, or compromised on-premises SharePoint Server infrastructure to obtain server-side execution, stage files, misuse service context, initiate outbound communication, or expand into internal systems. The strategic risk is not limited to a single exploit string, request path, payload marker, webshell name, or CVE-specific artifact because SharePoint exploitation and post-exploitation behavior can vary by authentication context, endpoint, payload structure, staging method, tooling choice, and follow-on objective.

The threat is significant because SharePoint Server often sits at the intersection of enterprise collaboration, document storage, workflow processing, internal portals, databases, service accounts, application pools, authentication paths, and downstream business systems. If attackers convert SharePoint or IIS service context into command execution, file staging, outbound communication, or internal expansion, the organization may face business disruption, collaboration-data exposure, service-account compromise, lateral movement scoping, cloud identity review, legal assessment, regulatory review, and executive incident governance.

This report treats SharePoint RCE and IIS worker process post-exploitation as a behavior-led infrastructure compromise risk. Detection and response should focus on abnormal SharePoint request activity followed by suspicious w3wp.exe or SharePoint service-context execution, suspicious file creation in SharePoint or IIS paths, rare outbound communication, internal expansion, service-account misuse, and downstream cloud-control-plane activity only when identity or incident lineage ties the cloud activity to SharePoint compromise context.

The operational risk is highest where SharePoint servers are internet-facing, partner-facing, extranet-connected, VPN-accessible, reverse-proxy-accessible, hybrid-connected, highly privileged, poorly segmented, or linked to sensitive collaboration content, databases, file shares, administrative hosts, identity infrastructure, backup systems, or cloud-connected administrator accounts. Patch validation is necessary, but it is not sufficient when exposed systems may have been reachable before remediation or when suspicious execution, file, network, identity, or application-fault evidence exists.

S11 — Threat Classification and Type

Threat Type

· Exploitation-enabled SharePoint Server compromise.

· IIS worker process post-exploitation.

· Enterprise collaboration infrastructure compromise.

· Application-server execution and service-context abuse.

Threat Sub-Type

· SharePoint Server RCE exploitation.

· Request-to-execution behavior.

· IIS worker process child process execution.

· Webroot or application-path file staging.

· Service-account misuse and internal expansion.

· Conditional downstream cloud-control-plane correlation.

Operational Classification

· Exposure-driven application-server compromise risk requiring patch validation, asset scoping, historical compromise review, and telemetry preservation.

· Post-exploitation behavior risk involving command execution, script execution, file staging, outbound communication, persistence preparation, internal expansion, and service-account misuse.

· Behavior-led detection problem where endpoint, web, file, network, identity, SIEM, NDR, and cloud audit telemetry must be correlated before high-confidence compromise assessment.

· Infrastructure trust issue affecting SharePoint farms, IIS-hosted SharePoint servers, collaboration services, application pool identities, service accounts, databases, file shares, and downstream identity-dependent systems.

Primary Function

· Convert exposed or vulnerable SharePoint Server infrastructure into server-side execution.

· Use SharePoint or IIS service context to launch command interpreters, scripting engines, download utilities, archive tools, reconnaissance commands, or living-off-the-land binaries.

· Stage suspicious files in SharePoint webroot, IIS application, layout, upload, temporary, staging, or writable application directories.

· Establish or support post-exploitation activity through webshell-like artifacts, outbound communication, internal movement, or service-account abuse.

· Expand impact from one SharePoint server into collaboration-data exposure, database access, file-share access, identity risk, internal infrastructure exposure, or downstream cloud-control-plane review when linkage exists.

S12 — Campaign or Activity Overview

Figure 2

SharePoint Server RCE and IIS worker process post-exploitation activity model showing exposed SharePoint access, abnormal request handling, worker process execution, suspicious file staging, outbound communication, internal expansion, and downstream containment validation.

This report assesses SharePoint Server RCE and IIS worker process post-exploitation as a durable behavior class rather than a single exploit string, scanner pattern, actor campaign, webshell name, payload artifact, or IOC set. The activity pattern involves adversaries attempting to use vulnerable SharePoint application behavior, exposed SharePoint endpoints, authenticated access paths, IIS worker process context, SharePoint application pool identities, or service-account context as a starting point for server-side execution and post-exploitation activity.

· The activity is best understood as an enterprise application-server compromise threat rather than a routine vulnerability-management issue, isolated web request anomaly, or scan-only exposure finding.

· Adversaries may target internet-facing SharePoint Server deployments, partner-facing portals, extranet SharePoint sites, VPN-accessible SharePoint services, reverse-proxy-accessible SharePoint systems, hybrid-connected environments, and internally reachable high-value SharePoint servers.

· The behavior may involve abnormal SharePoint request patterns, authenticated access anomalies, HTTP 500-series responses, worker process instability, application pool recycling, suspicious child process execution, suspicious file creation, rare outbound communication, service-account authentication, or internal movement.

· The activity may remain limited to scanning, malformed requests, blocked exploit attempts, failed authentication, application faults, or request anomalies, or it may progress into command execution, script execution, webshell-like placement, payload staging, outbound communication, persistence preparation, internal expansion, or downstream cloud identity review.

· The activity becomes highest risk when affected SharePoint systems support regulated content, executive workflows, legal records, customer data, financial records, engineering content, sensitive operational procedures, database access, file-share dependencies, identity infrastructure, backup systems, or cloud-linked administrator accounts.

Actor names, CVE identifiers, exploit references, proof-of-concept details, request paths, public scanner infrastructure, known IP addresses, user agents, filenames, or webshell names may increase urgency, but they should enrich the report rather than replace local behavior-led evidence of request-to-execution behavior, suspicious file staging, outbound communication, service-account misuse, or internal expansion.

S13 — Targets and Exposure Surface

The exposure surface includes on-premises SharePoint Server infrastructure, IIS-hosted SharePoint application servers, SharePoint web applications, application pools, service accounts, webroot and layout paths, upload paths, temporary directories, databases, file shares, authentication paths, reverse proxies, VPN-accessible paths, partner-facing sites, extranet portals, hybrid identity dependencies, and the telemetry needed to determine whether activity remained an attempt or became compromise.

· Internet-facing SharePoint Server deployments, partner-facing SharePoint sites, extranet portals, reverse-proxy-accessible SharePoint services, VPN-accessible SharePoint systems, and high-value internally reachable SharePoint servers.

· IIS worker processes, SharePoint application pools, SharePoint timer services, SharePoint service accounts, application pool identities, web applications, site collections, workflow paths, layout paths, service endpoints, upload paths, and administrative endpoints.

· SharePoint webroot paths, IIS application paths, layout directories, upload directories, temporary directories, staging directories, writable application paths, configuration files, scripts, DLLs, ASPX files, archives, and web-accessible artifacts.

· SharePoint content databases, configuration databases, service application databases, file shares, backup repositories, search components, workflow dependencies, identity infrastructure, domain controllers, database servers, management servers, and administrative hosts.

· Endpoint process activity involving w3wp.exe, owstimer.exe, command interpreters, scripting engines, download utilities, archive tools, reconnaissance commands, living-off-the-land binaries, and administrative utilities launched from SharePoint or IIS service context.

· Outbound DNS, proxy, firewall, EDR network, NDR, and flow telemetry involving rare destinations, newly observed infrastructure, direct internet egress, suspicious cloud storage, dynamic DNS, file-sharing services, paste sites, tunneling infrastructure, abnormal ports, unusual transfer volume, or low-reputation destinations.

· Identity and authentication telemetry involving SharePoint users, administrators, service accounts, application pool identities, privileged accounts, source IPs, source devices, geographies, ASNs, authentication paths, session patterns, and downstream authentication from SharePoint servers.

· Conditional AWS, Azure, and Google Cloud audit telemetry where identity, source, session, device, service account, project, subscription, account, organization, role, or incident-case lineage connects cloud activity to SharePoint compromise context.

· IIS logs, SharePoint application logs, ULS data, reverse proxy logs, WAF logs, load-balancer logs, endpoint telemetry, file telemetry, process telemetry, DNS logs, proxy logs, firewall logs, NDR data, identity logs, cloud audit logs, vulnerability context, asset inventory, and incident-response case context.

Environments with incomplete SharePoint asset inventory, weak IIS log mapping, limited endpoint visibility, missing command-line telemetry, incomplete file telemetry, missing SharePoint application logs, weak service-account baselines, incomplete outbound destination baselines, limited east-west network visibility, inconsistent identity normalization, or unclear ownership across SharePoint, Windows, SOC, vulnerability-management, identity, and cloud teams face elevated detection and scoping risk.

S14 — Sectors / Countries Affected

Sectors Affected

· Government and public sector organizations using SharePoint for portals, internal collaboration, records, workflows, or citizen-facing services.

· Defense industrial base and contractors using SharePoint for controlled collaboration, engineering documentation, supplier coordination, or program records.

· Financial services organizations using SharePoint for internal collaboration, regulated documents, customer-support workflows, legal records, audit evidence, or operational procedures.

· Healthcare and life sciences organizations using SharePoint for policies, research coordination, regulated documents, workforce collaboration, or patient-adjacent business processes.

· Energy, utilities, and critical infrastructure organizations using SharePoint for operational documentation, compliance workflows, vendor coordination, and internal procedures.

· Manufacturing and industrial organizations using SharePoint for engineering content, supplier collaboration, quality documentation, and operational procedures.

· Technology and software organizations using SharePoint for internal documentation, project coordination, customer-support content, and business operations.

· Education and research institutions using SharePoint for departmental collaboration, grant documentation, research administration, student services, and internal portals.

· Legal, consulting, and professional services organizations using SharePoint for client documents, matter files, project workspaces, and regulated business records.

· Retail, logistics, transportation, and hospitality organizations using SharePoint for operational documentation, workforce collaboration, vendor management, and business-continuity workflows.

· Any organization operating on-premises SharePoint Server, IIS-hosted SharePoint infrastructure, partner-facing SharePoint portals, extranet SharePoint deployments, hybrid-connected SharePoint services, or high-value internal SharePoint farms.

Countries Affected

· Global.

· Exposure is not limited to a single country or region because on-premises SharePoint Server is broadly deployed across enterprise, government, education, healthcare, financial, technology, industrial, and managed-service environments.

· Countries with large enterprise, government, defense, critical-infrastructure, financial-services, healthcare, education, or managed-service footprints may face elevated operational exposure when on-premises SharePoint infrastructure remains externally reachable or poorly segmented.

Overall Targeting Probability

High

Targeting probability is high because exposed SharePoint Server infrastructure provides immediate enterprise value after compromise and can support server-side execution, collaboration-data access, outbound communication, internal expansion, and downstream identity risk.

Targeting Drivers

· Publicly reachable or partner-facing SharePoint Server deployments.

· High-value enterprise collaboration and document repositories.

· SharePoint access to databases, file shares, service accounts, workflows, internal portals, and administrative dependencies.

· Potential to convert IIS worker process context into command execution or file staging.

· Potential to deploy webshell-like artifacts or temporary staging files in web-accessible paths.

· Potential to misuse SharePoint application pool identities or service accounts.

· Potential to reach internal systems through SMB, LDAP, Kerberos, NTLM, WinRM, WMI, RPC, RDP, MSSQL, or administrative-share activity.

· Potential to initiate rare outbound communication, payload retrieval, command-and-control-like traffic, or file-transfer activity.

· Delayed patching or incomplete patch validation across complex SharePoint farms.

· Incomplete IIS, SharePoint, endpoint, file, network, identity, or cloud telemetry.

· Difficulty distinguishing legitimate SharePoint administration, patching, backup, monitoring, indexing, workflow processing, and deployment activity from post-exploitation behavior.

· Post-remediation uncertainty when systems were exposed before patch validation or containment.

Most Likely Targets

· Internet-facing on-premises SharePoint Server deployments.

· Partner-facing or extranet SharePoint portals.

· VPN-accessible or reverse-proxy-accessible SharePoint systems.

· Hybrid-connected SharePoint environments with identity or cloud dependencies.

· SharePoint servers supporting regulated data, executive workflows, legal records, financial records, customer data, engineering content, or operational procedures.

· SharePoint servers with broad access to databases, file shares, backup systems, management servers, identity infrastructure, or administrative hosts.

· SharePoint farms with overprivileged service accounts, weak segmentation, incomplete monitoring, or broad outbound egress.

· Organizations with delayed patch validation, incomplete historical compromise review, weak IIS log retention, limited endpoint process visibility, missing file telemetry, weak outbound baselines, or inconsistent service-account baselines.

S17 — MITRE ATT&CK Chain Flow Mapping

MITRE ATT&CK chain flow showing SharePoint exposure discovery, public-facing application exploitation, IIS worker process execution, file staging, outbound communication, and internal discovery or expansion only where supported by observed or strongly inferable behavior.

Stage 1 — Exposure Discovery and Target Selection

Mapped Techniques

· T1071 — Application Layer Protocol

· T1105 — Ingress Tool Transfer

Stage 6 — Internal Discovery and Expansion

Attackers may use the SharePoint server as an internal foothold to enumerate the host, domain, users, groups, network, services, databases, file shares, or connected systems, and may attempt abnormal internal service access from the SharePoint server. This stage should be included only when internal communication, authentication, process, or identity telemetry supports behavior beyond normal SharePoint workflows.

Mapped Techniques

· T1087 — Account Discovery

· T1083 — File and Directory Discovery

· T1018 — Remote System Discovery

· T1021 — Remote Services

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Stage 1 — Exposure Discovery and SharePoint Target Selection

Attackers identify exposed or reachable SharePoint Server infrastructure through internet-facing services, partner-facing portals, extranet access paths, VPN-accessible systems, reverse-proxy paths, or high-value internal application surfaces. Targeting may focus on SharePoint web applications, administrative paths, layout paths, service endpoints, upload paths, workflow paths, API-style paths, or other reachable SharePoint functionality. At this stage, observed activity may include scanning, repeated endpoint access, unusual request patterns, uncommon user agents, abnormal request duration, HTTP 500-series responses, or repeated access to rare SharePoint paths.

This stage should be treated as exposure-prioritization or exploit-attempt activity unless stronger evidence shows host-side execution, file creation, outbound communication, service-account misuse, internal expansion, or downstream authentication activity.

· SharePoint servers initiating SMB, LDAP, Kerberos, NTLM, WinRM, WMI, RPC, RDP, MSSQL, administrative-share, database-server, file-server, backup-system, management-server, or domain-controller activity outside expected application workflows.

· net.exe, nltest.exe, whoami.exe, ipconfig.exe, systeminfo.exe, tasklist.exe, quser.exe, nslookup.exe, wmic.exe, PowerShell remoting, remote-service, or discovery-oriented activity from SharePoint or IIS service context.

· Authentication attempts from SharePoint servers to multiple internal systems within a short time window.

· SharePoint service accounts authenticating to systems they do not normally administer or contact.

· Internal fan-out, abnormal protocol use, sensitive destination access, or failed-then-successful authentication sequences following suspicious SharePoint execution, file staging, or outbound communication.

S19 — Attack Chain Risk Amplification Summary

The attack chain begins as a SharePoint exposure and exploitation problem but can escalate into an enterprise infrastructure compromise event when request activity produces server-side execution, file staging, outbound communication, service-account misuse, or internal expansion. The greatest amplification occurs when the affected SharePoint server supports sensitive collaboration content, regulated documents, executive workflows, legal records, financial data, customer data, databases, file shares, identity infrastructure, backup systems, or cloud-linked administrator accounts.

Risk amplification is driven by the concentration of trust in SharePoint infrastructure. SharePoint Server often connects users, documents, workflows, databases, service accounts, IIS application pools, authentication paths, file shares, and business-critical collaboration spaces. If attackers obtain execution from SharePoint or IIS service context, the compromise can shift from an application vulnerability event into a broader operational, identity, data-access, and governance problem.

Risk increases materially when attackers move beyond request anomalies into observable host-side behavior. The most important escalation signals are SharePoint request activity followed by suspicious w3wp.exe or SharePoint service-context execution, suspicious file creation in SharePoint or IIS paths, rare outbound communication, abnormal service-account authentication, internal fan-out, or access to sensitive downstream systems. These signals distinguish scanning and exploit attempts from probable compromise.

Patch validation reduces future exposure but does not close historical risk. SharePoint systems that were exposed before remediation require retrospective review because attackers may have executed commands, staged files, created web-accessible artifacts, communicated externally, abused service accounts, or attempted internal expansion before patching was completed. The absence of later exploitation attempts should not be treated as proof that earlier compromise did not occur.

The most severe risk scenario occurs when telemetry is incomplete and SharePoint ownership or dependency mapping is weak. Missing IIS logs, incomplete SharePoint application logs, limited endpoint process visibility, missing file telemetry, poor outbound network visibility, weak service-account baselines, incomplete cloud identity linkage, and inconsistent host normalization can force broader containment, longer investigation, wider credential review, and lower confidence in impact scoping. In those conditions, uncertainty itself becomes a cost and governance driver.

S20 — Tactics, Techniques, and Procedures

Figure 3

Exposure Targeting and Exploit Attempt Activity

· Attackers target exposed or reachable SharePoint Server infrastructure through internet-facing, partner-facing, extranet, VPN-accessible, reverse-proxy-accessible, or high-value internal access paths.

· Observable procedures may include scanning, repeated endpoint access, rare URI access, suspicious user agents, abnormal POST or PUT activity, unusual request duration, malformed requests, backend faults, or HTTP 500-series responses.

· Exposure and request anomalies should remain classified as exploit-attempt activity unless correlated with host-side execution, file activity, outbound communication, service-account misuse, or internal expansion.

Request-to-Execution Transition

· Attackers may convert SharePoint request handling into server-side execution from IIS worker process or SharePoint service context.

· Observable procedures may include w3wp.exe, owstimer.exe, SharePoint application pool identities, or SharePoint service accounts launching command shells, scripting engines, download utilities, archive tools, reconnaissance commands, or living-off-the-land binaries.

· Execution from SharePoint or IIS context is strongest when it follows suspicious request activity, authenticated access anomalies, worker process instability, application faults, or unexpected service-account behavior.

File Staging and Web-Accessible Artifact Placement

· Attackers may create or modify files in SharePoint webroot, IIS application, layout, upload, temporary, staging, writable application, or application-adjacent directories.

· Observable procedures may include ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, archive, temporary, configuration, XML, or webshell-like artifact placement.

· File staging should be evaluated against approved patching, deployment, customization, backup, monitoring, indexing, migration, and administrative workflows.

Outbound Communication and Tool Transfer

· Attackers may use compromised SharePoint servers to retrieve tools, contact attacker-controlled infrastructure, initiate command-and-control-like traffic, or transfer staged content.

· Observable procedures may include DNS queries, HTTP or HTTPS connections, raw TCP activity, PowerShell web requests, Certutil downloads, BITS transfers, Curl or Wget activity, suspicious user agents, direct egress, rare destination ports, abnormal bytes out, or access to newly observed destinations.

· Outbound activity should be treated as highest risk when it follows SharePoint-origin execution, file staging, application instability, service-account misuse, or internal expansion.

Service-Account Misuse and Internal Expansion

· Attackers may use the SharePoint server as an internal foothold to enumerate hosts, users, groups, services, domains, file shares, databases, or connected systems.

· Observable procedures may include discovery commands, SMB, LDAP, Kerberos, NTLM, WinRM, WMI, RPC, RDP, MSSQL, administrative-share access, database-server access, file-server access, backup-system access, management-server access, or domain-controller communication outside expected workflows.

· Internal expansion should increase severity only when telemetry supports behavior beyond normal SharePoint dependencies, search crawling, workflow processing, database connectivity, backup activity, monitoring, patching, or approved administration.

Cloud-Control-Plane Review Conditions

· Attackers may create downstream cloud risk only when identity, source IP, device, session, service account, role, project, subscription, account, organization, or incident-case lineage connects cloud activity to SharePoint compromise context.

· Observable procedures may include suspicious AWS, Azure, or Google Cloud administrative activity, access-key activity, role assumption, service-principal activity, storage access, secret access, logging modification, security-control modification, or privileged resource access when linked to SharePoint-side compromise evidence.

· Cloud activity should not be treated as SharePoint exploitation evidence by itself and should remain conditional unless strong lineage exists.

Evasion and Blending Behavior

· Attackers may blend with legitimate SharePoint administration by using normal-looking access paths, delayed execution, low-volume file changes, common Windows utilities, service-account context, approved-looking source paths, or maintenance-adjacent timing.

· Attackers may avoid durable artifacts by using transient execution, in-memory activity, temporary files, deleted staging files, living-off-the-land tools, or renamed artifacts.

· Detection should remain behavior-led because exploit strings, public proof-of-concept details, request paths, user agents, source infrastructure, filenames, webshell names, and payload content can change quickly.

S20A — Adversary Tradecraft Summary

The tradecraft associated with [EXP] SharePoint Server RCE and IIS Worker Process Post-Exploitation Detection Coverage is best understood as application-server compromise and service-context abuse rather than a malware-first intrusion model. The initial access opportunity comes from exposed or vulnerable SharePoint Server infrastructure, but the durable risk comes from attacker use of IIS worker process context, SharePoint service accounts, application pool identities, writable application paths, and outbound or internal connectivity after server-side execution occurs.

The strongest tradecraft pattern is request-to-execution conversion. Suspicious SharePoint access becomes materially more significant when followed by w3wp.exe or SharePoint service-context child process execution, suspicious file creation in SharePoint or IIS-accessible paths, rare outbound communication, abnormal service-account authentication, or internal expansion. These behaviors establish the difference between scanning, suspected exploitation, probable compromise, and compromise requiring containment review.

Attackers may rely on legitimate Windows and SharePoint-adjacent behavior to reduce detection clarity. SharePoint administration, patching, backup activity, monitoring, search indexing, workflow processing, deployment operations, customization, vulnerability scanning, and service-account activity can resemble post-exploitation behavior without strong baselines. This creates an operational detection challenge because defenders must distinguish authorized SharePoint operations from attacker-driven execution, staging, outbound communication, and internal access.

The most important defensive implication is that static indicators are not sufficient. CVE strings, public exploit details, scanner names, request paths, user-agent strings, known malicious IP addresses, file names, or webshell names may support triage, but they should not define the detection model. The durable detection model must correlate SharePoint request activity, IIS behavior, endpoint process lineage, file activity, outbound communication, service-account behavior, internal communication, and conditional cloud-control-plane activity.

No single named threat actor, intrusion set, or malware family is required for this report’s detection model. Where ransomware deployment, webshell activity, malware delivery, credential theft, or other abuse is confirmed in a specific environment, it should be documented using the confirmed family, artifact, infrastructure cluster, or abuse pattern. If no identifier is confirmed, reporting should describe the activity as unidentified SharePoint post-exploitation activity, unidentified webshell-like artifact placement, or unidentified outbound infrastructure contact rather than assigning unsupported attribution.

The highest-risk tradecraft outcome is internal expansion from trusted collaboration infrastructure. In enterprise environments, one compromised SharePoint server can create downstream exposure across databases, file shares, service accounts, identity systems, backup systems, administrative hosts, and cloud-linked identities. This makes SharePoint asset inventory, IIS log retention, endpoint process visibility, file telemetry, service-account baselines, outbound network monitoring, internal communication baselines, and historical compromise review essential to reliable scoping.

S21 — Detection Strategy Overview

Detection Philosophy

Detection for SharePoint Server RCE and IIS worker process post-exploitation must prioritize behavior that follows successful or attempted server-side code execution rather than relying on exploit-string matching, CVE-specific payload signatures, or single web request indicators. The strongest detection model is built around SharePoint application context, IIS worker process lineage, abnormal child process creation, suspicious command execution, unexpected file creation, outbound communication, and post-exploitation activity originating from SharePoint or IIS service accounts.

Primary Detection Anchors

· SharePoint and IIS worker process activity involving w3wp.exe spawning command interpreters, scripting engines, LOLBins, archive utilities, download utilities, credential-access tooling, or reconnaissance commands.

· SharePoint application pool identities initiating behavior that is inconsistent with normal SharePoint content processing, indexing, workflow execution, timer jobs, or administrative maintenance.

· Web-accessible SharePoint directories receiving newly written ASPX, DLL, script, archive, executable, configuration, or temporary staging artifacts.

· SharePoint request activity followed by process execution, file creation, service instability, outbound network connections, or authentication activity from the same host.

· Repeated access to sensitive SharePoint paths, administrative endpoints, upload paths, workflow paths, layout paths, or service endpoints followed by abnormal server-side execution.

· Authenticated SharePoint activity that precedes unusual server behavior, especially when the source account, IP address, device, geography, user agent, session pattern, or access path is inconsistent with normal use.

Detection Prioritization Model

· Highest priority should be assigned to SharePoint or IIS worker process lineage that produces command execution, encoded PowerShell, script execution, binary staging, credential-access tooling, webshell-like file writes, or outbound communication.

· Medium priority should be assigned to abnormal SharePoint request sequences that correlate with application faults, HTTP 500-series errors, unusual upload behavior, suspicious user agents, rare endpoint access, or repeated attempts against sensitive paths.

· Lower priority should be assigned to standalone web request anomalies unless they correlate with host, file, process, identity, or network telemetry.

· CVE-specific detections should be treated as supporting logic only because SharePoint RCE exploitation may vary by payload, authentication context, endpoint, serialization pathway, and post-exploitation objective.

Correlation Strategy (Strict Enforcement)

· Do not alert on SharePoint request anomalies alone unless the request pattern is confirmed by high-confidence exploit artifacts or active exploitation intelligence.

· Correlate web telemetry with endpoint telemetry whenever available, especially process execution, file creation, script execution, module loads, crash events, outbound connections, and service-account activity.

· Correlate authenticated SharePoint access with abnormal server behavior when the user context, source network, authentication path, or session sequence is unusual for the environment.

· Require a bounded time window between SharePoint request activity and downstream execution behavior to reduce false positives from normal administrative activity, patching, indexing, workflow processing, and backup operations.

· Treat process execution from SharePoint or IIS worker process lineage as a stronger anchor than request path matching because successful exploitation may not preserve a stable request artifact across variants.

Telemetry Prioritization

· Endpoint process telemetry should be prioritized first because post-exploitation activity from w3wp.exe, SharePoint application pools, or related service accounts provides the clearest evidence of server-side code execution.

· File creation telemetry should be prioritized when it captures new ASPX, DLL, script, executable, archive, temporary, or web-accessible artifacts in SharePoint, IIS, webroot, temporary, or application directories.

· Web and application logs should be prioritized when they include authenticated user context, source IP, URI path, HTTP method, status code, user agent, referrer, request timing, and backend server mapping.

· Network telemetry should be prioritized when SharePoint servers initiate rare outbound connections, direct internet egress, command-and-control-like traffic, file downloads, or connections inconsistent with known Microsoft, backup, monitoring, update, proxy, or integration destinations.

· Identity telemetry should be prioritized when SharePoint access or server-origin authentication activity involves unusual accounts, service accounts, privileged accounts, newly elevated users, impossible travel, unfamiliar devices, or abnormal authentication sequences.

Detection Design Constraints

· Detection logic must not assume every SharePoint RCE attempt is unauthenticated because authenticated SharePoint RCE paths may require valid user context before server-side execution occurs.

· Detection logic must not assume that deserialization activity will expose a stable request string, payload marker, endpoint name, or serialized object artifact in standard logs.

· Detection logic must not treat all w3wp.exe child process activity as malicious without accounting for local administrative scripts, backup agents, monitoring tools, antivirus activity, SharePoint maintenance jobs, search indexing, and sanctioned automation.

· Detection logic must not classify outbound traffic from SharePoint servers as malicious solely because it is external; the destination must be rare, newly observed, suspicious, unapproved, or correlated with host execution or file activity.

· Detection logic must avoid CVE-only matching and must remain resilient across authenticated RCE, deserialization abuse, webshell deployment, staged execution, and follow-on intrusion workflows.

Baseline and Deployment Requirements

· Organizations must baseline normal SharePoint application pool identities, IIS worker process behavior, scheduled maintenance activity, patching windows, backup operations, search crawling, workflow execution, service accounts, and administrative automation.

· Organizations must identify internet-facing, partner-facing, extranet, hybrid, and internally reachable SharePoint deployments before applying alert severity.

· Organizations must map SharePoint servers to IIS logs, endpoint telemetry, EDR process data, webroot directories, application pool identities, authentication logs, proxy logs, DNS logs, firewall logs, and vulnerability-management data.

· Organizations must maintain allowlists for approved administrative tools, known script paths, sanctioned automation accounts, monitoring agents, backup agents, update services, and approved outbound destinations.

· Organizations must distinguish SharePoint Online exposure from on-premises SharePoint Server exposure because this detection model applies to server-side enterprise infrastructure where IIS, endpoint, file, and application telemetry can be collected.

Variant Resilience Requirements

· Detection should remain effective when attackers change the request path, serialized payload structure, user agent, staging directory, command interpreter, script engine, webshell name, payload extension, or outbound infrastructure.

· Detection should emphasize execution lineage, account context, file-system impact, suspicious command semantics, outbound behavior, and post-exploitation sequencing rather than fixed IOCs.

· Detection should account for attackers using valid credentials, low-privilege SharePoint accounts, compromised internal accounts, stolen cookies, VPN access, reverse proxies, or trusted source networks.

· Detection should support both quick exploit-to-command execution and slower staged operations where web access, file writes, process execution, and outbound communication occur across separate time windows.

· Detection should support ransomware, extortion, credential theft, persistence, reconnaissance, and lateral-movement follow-on behavior without requiring a ransomware payload to be present.

Operational Detection Model

· The operational model should begin with SharePoint exposure validation, move to abnormal request and authentication review, then pivot quickly into endpoint process lineage, file writes, outbound communication, service-account behavior, and post-exploitation expansion.

· SOC triage should prioritize alerts where SharePoint or IIS worker process activity directly produces command execution, suspicious file writes, encoded or downloaded payload activity, credential-access commands, outbound connections, or lateral movement.

· Vulnerability-management teams should use KEV status, patch state, exposure state, authentication requirements, asset criticality, and internet reachability to prioritize containment and remediation.

· Detection engineering teams should build correlation rules that connect SharePoint request telemetry to endpoint and network outcomes rather than isolated single-signal alerts.

· Incident response teams should treat confirmed SharePoint-origin execution as potential server compromise requiring host isolation, credential review, webroot inspection, application pool identity review, outbound traffic analysis, and downstream authentication review.

Explicit Non-Deployment Guardrails

· Do not deploy request-path-only detection as a high-severity alert without endpoint, file, network, crash, or identity corroboration.

· Do not deploy CVE-name-only detection as a substitute for behavior-based SharePoint exploitation coverage.

· Do not deploy w3wp.exe child-process detection without environment-specific allowlists for sanctioned maintenance, backup, monitoring, update, and administrative workflows.

· Do not assume that a patched SharePoint server is clean if suspicious process execution, file writes, webshell artifacts, or outbound communication occurred before remediation.

· Do not treat absence of webshell artifacts as absence of compromise because attackers may execute commands in memory, use temporary staging paths, delete artifacts, or rely on living-off-the-land tooling.

· Do not promote rules to production alerting until SharePoint asset inventory, IIS log mapping, endpoint telemetry, service-account baselines, known administrative workflows, and false-positive suppressions have been validated.

S22 — Primary Detection Signals

Primary Detection Signals

· SharePoint or IIS worker process lineage where w3wp.exe spawns cmd.exe, powershell.exe, pwsh.exe, cscript.exe, wscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe, curl.exe, wget.exe, whoami.exe, net.exe, nltest.exe, ipconfig.exe, systeminfo.exe, tasklist.exe, quser.exe, ping.exe, nslookup.exe, tar.exe, 7z.exe, rar.exe, or other tools inconsistent with normal SharePoint processing.

· SharePoint application pool identities executing commands, creating processes, accessing unusual directories, writing executable content, initiating network connections, or authenticating to downstream systems outside established operational baselines.

· Newly created ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, ZIP, 7Z, RAR, TMP, CONFIG, or similarly suspicious artifacts in SharePoint webroot, IIS application, temporary, upload, layout, or writable application directories.

· Web-accessible files created or modified shortly after abnormal SharePoint request activity, authenticated access anomalies, application faults, upload behavior, or repeated access to sensitive SharePoint paths.

· Encoded, compressed, downloaded, decoded, staged, reflected, or obfuscated command execution originating from SharePoint or IIS service context.

· SharePoint server outbound connections to rare destinations, newly observed infrastructure, direct internet egress paths, file-sharing services, paste sites, tunneling infrastructure, suspicious cloud storage, dynamic DNS, or destinations not normally contacted by SharePoint servers.

· SharePoint server activity where web telemetry, endpoint telemetry, file telemetry, network telemetry, and identity telemetry converge within a bounded time window.

Supporting Detection Signals

· Repeated HTTP POST, upload, workflow, layout, service, administrative, or API-style requests against SharePoint endpoints followed by HTTP 500-series responses, backend faults, unusual response sizes, or rapid retry behavior.

· Authenticated SharePoint access from unusual source IPs, geographies, ASNs, VPN paths, proxy paths, unmanaged devices, unfamiliar user agents, atypical access times, or accounts with no normal SharePoint administration pattern.

· SharePoint access followed by unexpected local reconnaissance, host enumeration, domain enumeration, credential access, service discovery, network discovery, or file staging activity.

· IIS logs showing rare URI paths, abnormal parameter length, unusual request methods, uncommon user agents, repeated failed attempts followed by success, or request sequences inconsistent with normal user interaction.

· Windows event logs, EDR telemetry, or application logs showing SharePoint service instability, application pool recycling, unexpected worker process crashes, unhandled exceptions, or repeated faults near suspicious requests.

· File writes to directories where SharePoint should normally read content but not receive ad hoc executable, script, webshell, archive, or staging artifacts.

· Temporary file creation, rapid file deletion, renamed file extensions, suspicious alternate extensions, hidden files, or short-lived artifacts associated with SharePoint execution context.

Exploit Attempt and Instability Signals

· Unusual SharePoint request bursts targeting administrative, layout, upload, workflow, service, or application endpoints, especially when followed by service errors, worker process instability, or endpoint execution.

· Authenticated request activity that produces abnormal backend behavior, including repeated exceptions, serialization-related errors, application faults, high CPU spikes, application pool recycling, or unusual event-log entries.

· Sequences where a source account or source IP performs SharePoint interaction immediately before suspicious process creation, file write, outbound connection, or service-account authentication from the SharePoint server.

· Multiple failed or malformed SharePoint requests followed by a successful request pattern from the same account, source IP, session, device, or user agent.

· Web requests involving suspicious content length, uncommon methods, rare endpoints, compressed content, unusual referrers, or abnormal request timing when correlated with host-side execution or file activity.

· SharePoint server instability that aligns with external, partner, VPN, reverse-proxy, or authenticated user access patterns rather than scheduled maintenance, patching, backup, indexing, or administrative operations.

Outbound Communication Signals

· SharePoint servers initiating outbound connections shortly after suspicious request handling, abnormal process creation, file staging, service instability, or web-accessible artifact creation.

· IIS or SharePoint service context initiating DNS lookups, HTTP requests, HTTPS connections, raw TCP connections, or file-transfer activity to destinations not seen in the prior baseline period.

· Direct outbound communication from SharePoint servers that normally rely on proxies, update services, management services, backup destinations, or known Microsoft endpoints.

· Outbound connections involving suspicious user agents, command-line download utilities, PowerShell web requests, certificate utility downloads, BITS transfers, cloud storage access, anonymous file-sharing services, paste services, dynamic DNS, newly registered domains, or infrastructure with low reputation.

· Large outbound transfers, repeated beacon-like connections, abnormal TLS patterns, rare destination ports, unexpected geographic destinations, or egress activity inconsistent with SharePoint’s normal business function.

· Network activity that occurs under the same time window as SharePoint-origin process execution, file creation, script execution, credential discovery, or archive creation.

Persistence and Post-Exploitation Signals (Conditional)

· Webshell-like ASPX, script, DLL, handler, configuration, or executable artifacts placed in SharePoint-accessible or IIS-served directories.

· New or modified scheduled tasks, services, startup entries, registry run keys, WMI event subscriptions, local accounts, group memberships, or administrative shares on SharePoint servers.

· SharePoint application pool identities, service accounts, or compromised user accounts performing activity inconsistent with their normal role, including domain discovery, privileged group enumeration, credential dumping attempts, or access to administrative shares.

· Creation of compressed archives, staged directories, credential files, dump files, script bundles, or temporary packaging artifacts on SharePoint servers.

· Attempts to disable logging, delete files, clear event logs, stop security services, modify web configuration, change application pool settings, or tamper with endpoint protection.

· Repeated access to the same web-accessible artifact from external or internal sources after suspicious file creation.

Lateral Movement and Expansion Signals (Conditional)

· SharePoint servers initiating SMB, WinRM, WMI, RDP, LDAP, Kerberos, NTLM, RPC, MSSQL, or remote-service activity to systems they do not normally administer or contact.

· SharePoint service accounts authenticating to domain controllers, file servers, database servers, backup systems, management servers, developer systems, or administrative hosts outside expected application workflows.

· Use of net.exe, nltest.exe, dsquery.exe, whoami.exe, ipconfig.exe, netstat.exe, quser.exe, wmic.exe, PowerShell remoting, remote service creation, or credential-validation commands from SharePoint server context.

· Authentication attempts from SharePoint servers to multiple internal systems within a short time window, especially when paired with failed logons, privileged-account use, or unusual NTLM/Kerberos patterns.

· SharePoint server access to sensitive file shares, backup repositories, database servers, identity infrastructure, or administrative systems following suspicious web, process, file, or outbound activity.

· Internal scanning, host discovery, port probing, DNS enumeration, or service discovery originating from SharePoint servers.

Signal Usage Constraints

· Do not treat SharePoint web request anomalies as sufficient compromise evidence without endpoint, file, network, crash, identity, or application-log corroboration.

· Do not treat authenticated access as benign solely because credentials were valid; authenticated SharePoint RCE paths remain relevant when paired with abnormal server behavior.

· Do not treat w3wp.exe child process creation as malicious without validating local administrative workflows, backup operations, monitoring tools, patching activity, indexing, antivirus activity, and sanctioned SharePoint automation.

· Do not treat outbound traffic from SharePoint servers as malicious unless the destination, timing, process context, volume, reputation, or correlation pattern is abnormal.

· Do not assume webshell deployment is required for successful exploitation because attackers may use transient execution, memory-resident activity, temporary files, deleted artifacts, or living-off-the-land tooling.

· Do not promote any single signal to high-severity alerting until it is correlated with at least one stronger execution, file, identity, crash, network, or post-exploitation signal.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

· Process creation telemetry from SharePoint and IIS servers must capture parent process, child process, command line, executable path, working directory, user context, logon session, integrity level, process hash, process start time, and host identity.

· EDR or Windows event telemetry must support lineage analysis for w3wp.exe, SharePoint application pool identities, IIS worker processes, SharePoint timer services, service-hosted processes, scripting engines, command interpreters, and living-off-the-land binaries.

· Telemetry must capture command-line arguments for PowerShell, command shell, Windows Script Host, MSHTA, Rundll32, Regsvr32, Certutil, Bitsadmin, Curl, Wget, archive utilities, reconnaissance tools, and administrative utilities.

· Endpoint telemetry must distinguish sanctioned administrative execution from SharePoint-origin execution by correlating process lineage, user context, service account, host role, command semantics, and execution timing.

· Process telemetry must preserve enough detail to determine whether execution originated from SharePoint service context, IIS worker process context, scheduled maintenance, backup tooling, monitoring agents, update services, or manual administration.

Memory and Execution Telemetry

· Memory and execution telemetry should capture suspicious script execution, reflective loading, encoded command execution, .NET assembly loading, unmanaged code execution, and in-memory payload behavior associated with SharePoint or IIS service context.

· EDR telemetry should identify suspicious module loads, unmanaged code invocation, script engine abuse, LOLBin execution, AMSI-related events, suspicious PowerShell behavior, and unusual .NET runtime activity from SharePoint-hosted processes.

· PowerShell telemetry should include Script Block Logging, Module Logging, transcription where operationally appropriate, command invocation details, encoded command content where available, and PowerShell host process lineage.

· Execution telemetry should support identification of short-lived processes, transient staging behavior, in-memory execution, rapid process chains, deleted artifacts, and command execution that does not leave stable file-system evidence.

· Memory-focused telemetry should be treated as supporting context unless it can be correlated to SharePoint process lineage, suspicious command execution, file staging, outbound communication, or identity activity.

Crash and Fault Telemetry

· Windows event logs, IIS logs, SharePoint Unified Logging Service data, application logs, and EDR telemetry should capture worker process crashes, application pool recycling, unhandled exceptions, serialization-related errors, abnormal service restarts, and backend faults.

· Crash and fault telemetry should include host identity, service name, application pool name, exception context where available, faulting process, faulting module, timestamp, request correlation fields where available, and affected SharePoint component.

· Telemetry should support correlation between abnormal SharePoint requests, authenticated access patterns, HTTP 500-series responses, service instability, worker process crashes, and post-crash execution behavior.

· Application instability should be baselined against patching, maintenance, backup, indexing, search crawling, workflow execution, service restarts, and normal operational error patterns.

· Crash and fault telemetry must not be treated as exploitation evidence by itself; it becomes meaningful when aligned with abnormal request activity, authenticated access anomalies, process execution, file writes, or outbound communication.

File and Persistence Telemetry

· File telemetry from SharePoint and IIS servers must capture file creation, modification, deletion, rename, permission changes, owner changes, hash, path, extension, signer information where available, process lineage, user context, and timestamp.

· Monitoring must cover SharePoint webroot paths, IIS application directories, writable SharePoint directories, upload paths, layout-related paths, temporary directories, staging directories, service-account-accessible directories, and administrative script locations.

· File telemetry must identify newly created or modified ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, ZIP, 7Z, RAR, TMP, CONFIG, XML, and similarly suspicious artifacts in web-accessible or application-adjacent paths.

· Persistence telemetry must capture scheduled task creation, service creation, startup entry changes, registry run key changes, WMI event subscription changes, local user creation, group membership changes, application configuration changes, and application pool configuration changes.

· File and persistence telemetry must be correlated with SharePoint request activity, process execution, service-account behavior, administrative maintenance windows, patching activity, backup activity, and known deployment workflows before alert promotion.

Network and Outbound Communication Telemetry

· Network telemetry must capture outbound connections from SharePoint and IIS servers, including source host, source process where available, source account where available, destination IP, destination domain, destination port, protocol, timestamp, bytes transferred, TLS metadata, proxy path, DNS query, and firewall action.

· DNS, proxy, firewall, NDR, EDR network, and cloud egress telemetry should identify rare destinations, newly observed destinations, direct internet egress, suspicious hosting, dynamic DNS, anonymous file-sharing services, paste services, tunneling infrastructure, cloud storage, and destinations inconsistent with normal SharePoint activity.

· Telemetry must distinguish approved Microsoft services, update endpoints, backup infrastructure, monitoring services, enterprise integrations, proxy infrastructure, and known business destinations from unusual outbound communication.

· Outbound telemetry should support correlation between SharePoint-origin process execution, download utility usage, script-based web requests, file staging, archive creation, credential access, and external communication.

· Network telemetry must not claim exploit confirmation by itself; it must be interpreted as supporting evidence unless tied to suspicious SharePoint request activity, endpoint execution, file artifacts, identity anomalies, or post-exploitation behavior.

Web and Application Telemetry (Conditional Availability)

· IIS logs should capture timestamp, host, site name, source IP, authenticated user where available, URI stem, URI query where retained, HTTP method, status code, substatus, Win32 status, response size, user agent, referrer, server IP, and request duration.

· SharePoint application logs should capture service faults, workflow errors, application exceptions, authentication context where available, administrative actions, upload behavior, and backend component errors.

· Reverse proxy, WAF, load balancer, and web gateway telemetry should capture original client IP, forwarded headers, authenticated session context where available, user agent, request path, response code, request size, response size, TLS metadata, and routing destination.

· Web telemetry should support correlation between authenticated access, unusual request paths, repeated POST activity, upload behavior, sensitive endpoint access, application instability, backend errors, and host-side execution.

· Web and application telemetry may be unavailable, incomplete, truncated, normalized, privacy-limited, or insufficiently detailed; it should not be the only required detection source for high-confidence compromise assessment.

Telemetry Availability Requirements

· Production detection requires mapped SharePoint asset inventory, IIS log sources, endpoint telemetry, service-account context, application pool identity mapping, host role tags, known maintenance windows, proxy or firewall visibility, and baseline outbound destinations.

· Detection engineering must validate local field names, log source names, index names, sourcetypes, data models, EDR schemas, network telemetry fields, identity mappings, and retention windows before enabling alert-mode rules.

· SharePoint servers must be tagged separately from generic Windows servers so correlation logic can prioritize application-server behavior and suppress irrelevant endpoint noise.

· Baselines must include approved administrative tools, backup agents, monitoring agents, antivirus activity, update processes, deployment workflows, patching windows, search indexing, workflow execution, service restarts, and known integration traffic.

· Telemetry retention must be long enough to support delayed discovery, retroactive KEV-driven hunting, webshell review, service-account investigation, outbound destination analysis, and downstream lateral-movement review.

Telemetry Limitations and Gaps

· Standard IIS logs may not capture full exploit payloads, serialized object content, request bodies, authentication token details, or backend execution context.

· SharePoint application logs may be noisy, incomplete, or difficult to correlate without server role mapping, request tracing, ULS configuration, and administrator knowledge of normal SharePoint operations.

· Endpoint telemetry may miss short-lived processes, memory-resident execution, deleted artifacts, child process lineage, or command-line content if EDR visibility, logging policy, or sensor health is incomplete.

· Network telemetry may lack process attribution, user attribution, TLS content, original client IP, or proxy-normalized destination detail.

· Authenticated exploitation may blend into normal user activity unless identity context, source device, source network, session timing, request sequence, and downstream server behavior are correlated.

· Absence of webshell artifacts, known IOCs, crash events, or outbound traffic does not prove absence of compromise because attackers may use valid credentials, transient execution, deleted staging files, internal-only activity, or living-off-the-land tooling.

S24 — Detection Opportunities and Gaps

Figure 4

High-Value Detection Opportunities

· Detect SharePoint or IIS worker process lineage where w3wp.exe launches command interpreters, scripting engines, LOLBins, archive utilities, reconnaissance commands, download utilities, or execution patterns inconsistent with normal SharePoint operations

· Detect SharePoint application pool identities performing process execution, file writes, outbound communication, administrative enumeration, credential-access behavior, or downstream authentication outside known operational baselines

· Detect suspicious file creation or modification in SharePoint webroot, IIS application, upload, layout, temporary, staging, or writable application directories

· Detect abnormal SharePoint request activity followed by process execution, file creation, service instability, outbound communication, credential access, or lateral movement from the same server

· Detect authenticated SharePoint access patterns that appear normal at the credential layer but produce abnormal server-side behavior

· Detect rare outbound communication from SharePoint servers following suspicious request handling, command execution, file staging, archive creation, or service instability

· Detect post-exploitation behaviors from SharePoint servers, including webshell-like artifact placement, local reconnaissance, domain enumeration, archive creation, credential-access attempts, logging tampering, and lateral-movement preparation

Primary Correlation Opportunities

· Correlate IIS and SharePoint request telemetry with endpoint process telemetry to identify request-to-execution chains

· Correlate authenticated SharePoint access with service-account activity, application pool execution context, abnormal process lineage, and unusual server behavior

· Correlate SharePoint request bursts, HTTP 500-series responses, application faults, worker process crashes, or application pool recycling with suspicious execution or file activity

· Correlate newly created web-accessible artifacts with prior SharePoint request activity, upload behavior, service instability, or process execution from IIS context

· Correlate SharePoint-origin command execution with outbound DNS, proxy, firewall, EDR network, or NDR telemetry

· Correlate SharePoint server authentication to domain controllers, file servers, database servers, backup systems, management systems, or administrative hosts with prior suspicious host-side execution

· Correlate SharePoint server exposure, patch state, KEV relevance, internet reachability, and asset criticality with detection priority and SOC response urgency

Endpoint Detection Opportunities

· Monitor w3wp.exe and SharePoint-related service processes for suspicious child process creation

· Monitor PowerShell, command shell, Windows Script Host, MSHTA, Rundll32, Regsvr32, Certutil, Bitsadmin, Curl, Wget, archive utilities, and reconnaissance commands launched from SharePoint or IIS service context

· Monitor encoded command execution, script-based downloads, certificate utility downloads, BITS transfers, archive creation, rapid staging, and obfuscated command lines

· Monitor suspicious process execution by SharePoint application pool identities, service accounts, or compromised user contexts

· Monitor endpoint protection tampering, log clearing, service manipulation, application pool changes, scheduled task creation, service creation, registry persistence, and WMI persistence on SharePoint servers

· Monitor short-lived execution chains, rapid process spawning, deleted artifacts, and transient staging behavior that may indicate command execution without durable malware deployment

File and Web Artifact Detection Opportunities

· Monitor creation or modification of ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, ZIP, 7Z, RAR, TMP, CONFIG, XML, and similarly suspicious artifacts in SharePoint or IIS-accessible directories

· Monitor new files in web-accessible paths that are created by SharePoint service accounts, IIS worker processes, unexpected users, or administrative accounts outside approved maintenance windows

· Monitor renamed extensions, double extensions, short-lived artifacts, temporary payload staging, hidden files, unusual permissions, and suspicious owner changes

· Monitor SharePoint and IIS configuration changes, handler changes, application pool changes, web configuration modifications, and unexpected executable mappings

· Monitor repeated access to newly created web-accessible files, especially when access follows suspicious request activity or originates from unfamiliar internal or external sources

· Monitor file staging that precedes outbound communication, archive creation, credential-access behavior, or downstream authentication attempts

Network and Identity Detection Opportunities

· Monitor SharePoint servers for rare outbound destinations, newly observed domains, direct internet egress, dynamic DNS, suspicious hosting, anonymous file-sharing services, paste services, tunneling infrastructure, and cloud storage destinations outside normal business use

· Monitor outbound traffic from SharePoint servers when the initiating process, timing, destination, port, protocol, user agent, or volume is inconsistent with baseline behavior

· Monitor SharePoint service accounts and application pool identities for abnormal authentication to domain controllers, file servers, database servers, backup systems, administrative hosts, and management platforms

· Monitor failed and successful authentication sequences from SharePoint servers to multiple internal systems within short time windows

· Monitor NTLM, Kerberos, SMB, WinRM, WMI, LDAP, RPC, RDP, MSSQL, and remote service activity originating from SharePoint servers outside expected application workflows

· Monitor privileged-account interaction with SharePoint servers when paired with abnormal process execution, file writes, outbound communication, or service instability

Detection Gaps

· Standard IIS logs may not capture request bodies, serialized payloads, exploit-specific object content, backend execution context, or full authentication-token detail

· SharePoint application logs may be noisy, incomplete, inconsistently configured, or difficult to correlate without application-role mapping and operational knowledge

· Authenticated exploitation may appear as valid SharePoint use unless identity, device, source network, request sequence, and downstream server behavior are correlated

· Endpoint telemetry may miss short-lived execution, command-line details, process lineage, in-memory execution, deleted artifacts, or sensor-blind activity

· Network telemetry may not provide process attribution, user attribution, decrypted payload visibility, original client IP, proxy-normalized destination detail, or reliable command-and-control confirmation

· Webshell detection may fail when attackers use memory-resident execution, transient files, renamed artifacts, deleted staging files, or living-off-the-land execution without durable payloads

· Single-signal detections may produce excessive false positives in environments with heavy SharePoint administration, complex workflows, custom solutions, backup agents, monitoring tools, and frequent maintenance activity

Engineering Gaps

· Many environments lack complete SharePoint asset inventory, server role tags, application pool identity mapping, IIS log onboarding, SharePoint ULS onboarding, EDR coverage, or proxy and firewall correlation

· Local field names, index names, sourcetypes, EDR schemas, network telemetry mappings, and identity normalization may vary significantly across SIEM and EDR deployments

· SharePoint-specific baselines may not exist for normal application pool behavior, scheduled jobs, search indexing, workflow execution, administrative scripts, patching windows, backup activity, and approved integrations

· Alert logic may fail if it assumes all SharePoint exploitation is unauthenticated, externally sourced, webshell-based, malware-based, or tied to a stable request artifact

· Detection logic may over-alert when legitimate maintenance tools, monitoring agents, backup processes, administrative scripts, or deployment workflows are not properly allowlisted

· Cloud, identity, and endpoint telemetry may not share consistent host, account, session, process, or destination identifiers without normalization and enrichment

Operational Gaps

· SOC teams may investigate SharePoint alerts as generic Windows server activity instead of treating SharePoint servers as high-value application infrastructure with downstream identity, file, database, and collaboration dependencies

· Vulnerability-management teams may close remediation work after patching without checking for pre-patch compromise, webshell artifacts, service-account misuse, file staging, outbound communication, or lateral movement

· Incident response teams may under-scope compromise when they do not review SharePoint webroots, IIS application paths, application pool identities, service accounts, authentication logs, proxy logs, and downstream server access

· Organizations may lack clear ownership across SharePoint administrators, Windows server teams, identity teams, SOC analysts, vulnerability-management teams, and incident responders

· Environments with hybrid, extranet, partner-facing, or legacy SharePoint deployments may have unclear exposure boundaries and inconsistent telemetry collection

· Retention gaps may prevent retroactive hunting after KEV updates, delayed exploitation reporting, or discovery of older suspicious SharePoint activity

Prioritized Gap Closure Actions

· Establish a complete inventory of on-premises SharePoint servers, IIS roles, application pools, internet-facing paths, partner-facing paths, hybrid connectors, service accounts, and critical business dependencies

· Onboard IIS logs, SharePoint application logs, endpoint process telemetry, file telemetry, identity telemetry, DNS telemetry, proxy telemetry, firewall telemetry, and EDR network telemetry into a common investigation workflow

· Baseline normal SharePoint application pool execution, administrative scripts, search indexing, workflow processing, backup operations, monitoring activity, patching windows, outbound destinations, and service-account authentication

· Build correlation logic that joins SharePoint request behavior with endpoint execution, file activity, crash and fault telemetry, outbound communication, and identity activity

· Validate allowlists for approved administrative tools, monitoring agents, backup agents, update services, deployment tools, known service accounts, known SharePoint integrations, and approved outbound destinations

· Conduct retroactive hunts after KEV or active exploitation updates using SharePoint request telemetry, w3wp.exe process lineage, suspicious file writes, outbound destinations, service-account activity, and lateral-movement indicators

· Treat confirmed SharePoint-origin execution as a compromise-level investigation trigger requiring host containment review, credential review, webroot inspection, outbound traffic analysis, and downstream authentication review

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Rule

SharePoint Server Rare Outbound Communication After Application-Layer Anomaly

Rule Format

NDR / Network Behavioral Analytics backend-correlation pattern

Detection Purpose

Detect suspicious outbound communication from SharePoint servers that occurs shortly after abnormal SharePoint or IIS request handling, service instability, suspicious web activity, or application-layer anomaly patterns

Detection Logic

This rule identifies SharePoint servers that show abnormal web or application-layer activity followed by rare outbound communication. The detection is designed to find post-exploitation network behavior from SharePoint Server infrastructure without claiming exploit confirmation from network telemetry alone. High-confidence conditions require a SharePoint server role match, abnormal SharePoint or IIS activity, rare outbound destination behavior, and a bounded timing relationship between the application-layer anomaly and outbound communication.

Required Telemetry

NDR or network behavioral analytics telemetry with source host, destination IP, destination domain, destination port, protocol, timestamp, bytes transferred, TLS metadata where available, DNS context where available, and flow direction

· SharePoint server asset inventory or host role tags

· IIS, proxy, WAF, reverse proxy, or application-layer telemetry where available

· DNS telemetry for destination rarity and domain context

· Proxy or firewall telemetry for destination category, action, and egress path where available

· Approved destination baselines for SharePoint servers

· Known Microsoft, update, monitoring, backup, and business integration destination baselines

· Optional SIEM or EDR enrichment for process context, service-account context, file activity, or host-side execution

Engineering Implementation Instructions

Scope the source population to confirmed on-premises SharePoint Server and IIS-hosted SharePoint infrastructure

· Build a SharePoint server role inventory before enabling alert-mode logic

· Maintain approved destination baselines for Microsoft services, update infrastructure, backup infrastructure, monitoring platforms, proxy infrastructure, security tooling, enterprise integrations, and known business destinations

· Treat IIS, proxy, WAF, reverse-proxy, and application telemetry as enrichment where available

· Require destination rarity, newly observed destination status, suspicious destination category, direct egress, abnormal port usage, or abnormal transfer behavior before alert promotion

· Suppress known administrative windows, backup operations, vulnerability scanning, patching activity, search indexing, monitoring activity, and sanctioned integration traffic

· Do not claim SharePoint exploitation from network telemetry alone

· Promote to alert mode only when network behavior is correlated with application-layer anomaly, server role mapping, and environment-specific destination baselines

DRI Assessment

This rule has strong detection value when the environment has reliable SharePoint asset tagging, destination rarity logic, DNS or proxy enrichment, and application-layer anomaly telemetry. It is resilient against changes in exploit payload and webshell naming because it focuses on suspicious egress after abnormal SharePoint activity. Its main weakness is that NDR telemetry cannot confirm server-side code execution unless endpoint or SIEM enrichment is available.

DRI

8.2

TCR Assessment

Operational coverage is moderate to strong where SharePoint servers are tagged and outbound destination baselines exist. Full-telemetry coverage improves when IIS, proxy, DNS, firewall, EDR, and SIEM enrichment can correlate request anomalies with host-side execution and outbound behavior.

Operational TCR

7.6

Full-Telemetry TCR

8.7

Limitations

Cannot confirm SharePoint exploitation without endpoint, IIS, SharePoint, SIEM, or EDR corroboration

· May miss internal-only post-exploitation activity without outbound egress

· May generate false positives during patching, backup operations, monitoring activity, vulnerability scanning, or sanctioned integrations

· Requires reliable SharePoint server inventory and destination baselines

· May not identify the initiating process unless enriched by EDR, firewall, proxy, or SIEM telemetry

· Encrypted traffic may limit payload visibility

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support server-role baselining, destination rarity, DNS / proxy / firewall enrichment, application-layer anomaly context, and sequence logic. Endpoint and SIEM fields should be treated as enrichment where available.

LET SHAREPOINT_SERVERS =

ENV_ON_PREM_SHAREPOINT_SERVERS

OR ENV_IIS_HOSTED_SHAREPOINT_SERVERS

OR ENV_SHAREPOINT_APP_SERVER_ROLE_TAGS

LET APPROVED_SHAREPOINT_DESTINATIONS =

ENV_MICROSOFT_SERVICE_DESTINATIONS

OR ENV_SHAREPOINT_APPROVED_UPDATE_DESTINATIONS

OR ENV_SHAREPOINT_APPROVED_BACKUP_DESTINATIONS

OR ENV_SHAREPOINT_APPROVED_MONITORING_DESTINATIONS

OR ENV_SHAREPOINT_APPROVED_SECURITY_TOOL_DESTINATIONS

OR ENV_SHAREPOINT_APPROVED_INTEGRATION_DESTINATIONS

OR ENV_ENTERPRISE_PROXY_DESTINATIONS

LET sharepoint_application_anomaly =

application_or_web_events

WHERE source_host IN SHAREPOINT_SERVERS

AND (

http_status IN ("500", "502", "503")

OR application_fault = true

OR worker_process_crash = true

OR application_pool_recycle = true

OR request_path IN ENV_RARE_SHAREPOINT_PATHS

OR request_method IN ("POST", "PUT")

OR upload_activity = true

OR request_count > ENV_SHAREPOINT_REQUEST_BURST_BASELINE

OR request_duration > ENV_SHAREPOINT_REQUEST_DURATION_BASELINE

OR user_agent NOT IN ENV_SHAREPOINT_APPROVED_USER_AGENTS

OR authenticated_user NOT IN ENV_SHAREPOINT_USER_BASELINE

)

LET rare_sharepoint_outbound =

network_flow_events

WHERE source_host IN SHAREPOINT_SERVERS

AND flow_direction = "outbound"

AND (

destination_domain NOT IN APPROVED_SHAREPOINT_DESTINATIONS

OR destination_ip NOT IN APPROVED_SHAREPOINT_DESTINATIONS

OR destination_first_seen_status IN ("new", "rare")

OR destination_category IN ("dynamic_dns", "file_sharing", "paste_site", "newly_registered_domain", "unknown", "suspicious_hosting", "tunnel", "anonymizer")

OR destination_reputation IN ("low", "suspicious", "malicious", "unknown")

OR destination_port NOT IN ENV_SHAREPOINT_APPROVED_EGRESS_PORTS

OR egress_path = "direct_internet"

OR bytes_out > ENV_SHAREPOINT_SERVER_OUTBOUND_BASELINE

OR dns_query NOT IN ENV_SHAREPOINT_DNS_BASELINE

)

SEQUENCE sharepoint_application_anomaly THEN rare_sharepoint_outbound

WHERE same_source_host = true

WITHIN ENV_SHAREPOINT_ANOMALY_TO_OUTBOUND_WINDOW

OUTPUT

source_host,

source_ip,

host_role,

application_pool,

authenticated_user,

request_path,

request_method,

http_status,

application_fault,

worker_process_crash,

destination_ip,

destination_domain,

destination_port,

protocol,

destination_category,

destination_reputation,

destination_first_seen_status,

egress_path,

bytes_out,

dns_query,

time_delta

Rule

SharePoint Server Post-Exploitation Internal Expansion from Network Behavior

Rule Format

NDR / Network Behavioral Analytics backend-correlation pattern

Detection Purpose

Detect SharePoint servers initiating abnormal internal authentication, discovery, remote-service, database, file-share, or management-plane communication that may indicate post-exploitation expansion after SharePoint Server compromise

Detection Logic

This rule identifies SharePoint servers that begin communicating with internal systems in ways inconsistent with normal SharePoint application behavior. It focuses on lateral-movement and expansion signals such as SMB, LDAP, Kerberos, NTLM, WinRM, WMI, RPC, RDP, MSSQL, administrative shares, domain-controller access, file-server access, database-server access, backup-system access, and management-server access. The strongest detections require abnormal internal destination selection, abnormal protocol use, destination role sensitivity, authentication anomalies, and recent SharePoint-side application or network anomaly context.

Required Telemetry

NDR or network behavioral analytics telemetry with internal source, destination, protocol, port, timing, bytes, and session metadata

· SharePoint server asset inventory or host role tags

· Internal asset role inventory for domain controllers, file servers, database servers, backup systems, management servers, administrative hosts, and high-value infrastructure

· Authentication telemetry or identity enrichment where available

· DNS telemetry for internal destination resolution

· Approved internal communication baselines for SharePoint servers

· Optional SIEM, EDR, or Windows event enrichment for process, user, service-account, or authentication context

Engineering Implementation Instructions

Scope the source population to confirmed on-premises SharePoint Server and IIS-hosted SharePoint infrastructure

· Build approved internal communication baselines for SharePoint-to-database, SharePoint-to-domain-controller, SharePoint-to-file-share, backup, monitoring, management, and integration flows

· Require abnormal destination role, abnormal protocol use, abnormal fan-out, authentication failure and success patterns, or rare internal service access before alert promotion

· Treat domain-controller, backup-system, management-server, administrative-host, and sensitive file-server communication as higher-priority destinations

· Suppress known SharePoint database dependencies, approved service-account workflows, scheduled jobs, monitoring flows, backup flows, vulnerability scanning, and maintenance windows

· Treat internal expansion signals as post-exploitation indicators only when paired with abnormal SharePoint server behavior or rare internal movement

· Do not use this rule to claim exploit confirmation without host, web, identity, or file corroboration

DRI Assessment

This rule has strong value for detecting post-exploitation expansion when SharePoint servers are well baselined and internal asset roles are mapped. It is resilient against web exploit variation because it focuses on downstream behavior after compromise. Its main limitation is that complex SharePoint deployments may legitimately communicate with many internal systems, so asset role mapping and approved-flow baselines are mandatory.

DRI

8.0

TCR Assessment

Operational coverage is moderate where NDR has internal east-west visibility and SharePoint server baselines exist. Full-telemetry coverage improves when identity logs, Windows events, EDR telemetry, and asset criticality enrich the internal movement pattern.

Operational TCR

7.4

Full-Telemetry TCR

8.5

Limitations

May over-alert in complex SharePoint environments with broad internal integrations

· Requires internal asset role mapping and approved communication baselines

· May miss post-exploitation activity that remains local to the SharePoint server

· May miss activity tunneled through approved management paths or compromised administrative tooling

· Cannot identify the initiating process without EDR, firewall, proxy, or SIEM enrichment

· Cannot confirm exploitation without SharePoint, endpoint, file, identity, or application-layer corroboration

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support east-west traffic visibility, internal asset role mapping, source baselining, authentication enrichment, and sequence logic. Endpoint, Windows event, and SIEM fields should be treated as enrichment where available.

LET SHAREPOINT_SERVERS =

ENV_ON_PREM_SHAREPOINT_SERVERS

OR ENV_IIS_HOSTED_SHAREPOINT_SERVERS

OR ENV_SHAREPOINT_APP_SERVER_ROLE_TAGS

LET SENSITIVE_INTERNAL_DESTINATIONS =

ENV_DOMAIN_CONTROLLERS

OR ENV_FILE_SERVERS

OR ENV_DATABASE_SERVERS

OR ENV_BACKUP_SYSTEMS

OR ENV_MANAGEMENT_SERVERS

OR ENV_ADMINISTRATIVE_HOSTS

OR ENV_IDENTITY_INFRASTRUCTURE

OR ENV_HIGH_VALUE_INTERNAL_SERVERS

LET APPROVED_SHAREPOINT_INTERNAL_FLOWS =

ENV_SHAREPOINT_APPROVED_DATABASE_FLOWS

OR ENV_SHAREPOINT_APPROVED_DOMAIN_CONTROLLER_FLOWS

OR ENV_SHAREPOINT_APPROVED_FILE_SHARE_FLOWS

OR ENV_SHAREPOINT_APPROVED_BACKUP_FLOWS

OR ENV_SHAREPOINT_APPROVED_MONITORING_FLOWS

OR ENV_SHAREPOINT_APPROVED_MANAGEMENT_FLOWS

OR ENV_SHAREPOINT_APPROVED_INTEGRATION_FLOWS

LET prior_sharepoint_anomaly =

application_or_network_events

WHERE source_host IN SHAREPOINT_SERVERS

AND (

application_fault = true

OR worker_process_crash = true

OR rare_outbound_destination = true

OR suspicious_file_transfer = true

OR request_path IN ENV_RARE_SHAREPOINT_PATHS

OR request_count > ENV_SHAREPOINT_REQUEST_BURST_BASELINE

OR outbound_bytes > ENV_SHAREPOINT_SERVER_OUTBOUND_BASELINE

OR destination_first_seen_status IN ("new", "rare")

)

LET abnormal_internal_expansion =

network_flow_events

WHERE source_host IN SHAREPOINT_SERVERS

AND destination_host IN SENSITIVE_INTERNAL_DESTINATIONS

AND (

protocol IN ("SMB", "LDAP", "KERBEROS", "NTLM", "RPC", "RDP", "WINRM", "WMI", "MSSQL")

OR destination_port IN (88, 135, 139, 389, 445, 464, 593, 636, 1433, 3389, 5985, 5986)

OR source_destination_protocol_tuple NOT IN APPROVED_SHAREPOINT_INTERNAL_FLOWS

OR destination_role NOT IN ENV_SHAREPOINT_BASELINE_DESTINATION_ROLES

OR internal_connection_count > ENV_SHAREPOINT_INTERNAL_CONNECTION_BASELINE

OR unique_internal_destination_count > ENV_SHAREPOINT_INTERNAL_FANOUT_BASELINE

OR authentication_result_sequence IN ("multiple_failures_then_success", "unusual_success", "privileged_success")

OR service_account NOT IN ENV_SHAREPOINT_APPROVED_SERVICE_ACCOUNTS

)

SEQUENCE prior_sharepoint_anomaly THEN abnormal_internal_expansion

WHERE same_source_host = true

WITHIN ENV_SHAREPOINT_ANOMALY_TO_INTERNAL_EXPANSION_WINDOW

OUTPUT

source_host,

source_ip,

host_role,

destination_host,

destination_ip,

destination_role,

destination_port,

protocol,

service_account,

authentication_result_sequence,

internal_connection_count,

unique_internal_destination_count,

approved_flow_status,

source_destination_protocol_tuple,

prior_anomaly_type,

prior_request_path,

prior_destination_first_seen_status,

time_delta

SentinelOne

Rule

SharePoint IIS Worker Process Suspicious Child Process Execution

Rule Format

SentinelOne Deep Visibility / STAR-style endpoint detection pattern

Detection Purpose

Detect suspicious command execution, scripting, download activity, reconnaissance, or living-off-the-land behavior launched from SharePoint or IIS worker process context

Detection Logic

This rule identifies SharePoint and IIS worker process lineage where w3wp.exe, SharePoint application pool identities, or SharePoint-related service context launches command interpreters, scripting engines, download utilities, archive tools, reconnaissance commands, or living-off-the-land binaries. The detection is designed to identify server-side execution and post-exploitation behavior without relying on a specific CVE, exploit string, webshell name, or payload artifact.

Required Telemetry

SentinelOne process telemetry with endpoint name, endpoint tags, parent process, child process, command line, process path, user context, process hash, and event time

· Endpoint tags identifying on-premises SharePoint servers, IIS-hosted SharePoint servers, SharePoint application servers, and high-value collaboration infrastructure

· Process lineage visibility for w3wp.exe, SharePoint application pools, SharePoint timer services, IIS worker processes, command interpreters, scripting engines, and living-off-the-land binaries

· Command-line visibility for PowerShell, command shell, Windows Script Host, MSHTA, Rundll32, Regsvr32, Certutil, Bitsadmin, Curl, Wget, archive utilities, and reconnaissance tools

· Local allowlists for approved SharePoint maintenance scripts, backup agents, monitoring tools, update workflows, administrative automation, and sanctioned deployment activity

Engineering Implementation Instructions

Validate tenant-specific SentinelOne event types, field names, process fields, command-line fields, endpoint-tag syntax, and STAR rule compatibility before production deployment

· Scope the rule to confirmed SharePoint and IIS-hosted SharePoint servers using endpoint tags or asset-group logic

· Require SharePoint or IIS parent-process context before alert promotion

· Suppress approved SharePoint administration, backup, monitoring, patching, indexing, deployment, and maintenance workflows

· Treat encoded commands, download utilities, script interpreters, archive creation, reconnaissance commands, and LOLBin execution from w3wp.exe lineage as high-priority signals

· Do not treat all w3wp.exe child process activity as malicious without local baseline validation

· Promote to alert mode only after validating local SharePoint process baselines, allowlisted tools, service-account behavior, and command-line field availability

DRI Assessment

This rule has strong detection value because SharePoint or IIS worker process lineage producing suspicious child processes is a high-confidence post-exploitation signal. It is resilient against exploit variation because it focuses on execution behavior rather than exploit strings or CVE-specific artifacts. Its main weakness is that some environments may have legitimate SharePoint automation, administrative scripts, backup agents, or monitoring tools that create child processes from service context.

DRI

8.7

TCR Assessment

Operational coverage is strong where SentinelOne captures parent-child process lineage, command lines, endpoint tags, and process user context. Full-telemetry coverage improves when the rule is enriched with IIS logs, SharePoint application logs, identity telemetry, file telemetry, and network telemetry in the SIEM or XDR workflow.

Operational TCR

8.1

Full-Telemetry TCR

9.0

Limitations

Requires reliable endpoint tagging for SharePoint and IIS-hosted SharePoint servers

· May over-alert if approved administrative scripts, monitoring agents, backup tools, or maintenance workflows are not allowlisted

· May miss in-memory activity that does not create observable child processes

· May miss activity if command-line collection or parent-process lineage is incomplete

· Does not prove initial exploit path without IIS, SharePoint, web, identity, or application-layer corroboration

· Tenant-specific SentinelOne syntax and event names must be validated before deployment

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports process, command-line, parent-process, endpoint-tag, and user-context correlation. IIS, SharePoint, identity, and network correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET SHAREPOINT_ENDPOINTS =

EndpointTags CONTAINS ANY (

"ENV_ON_PREM_SHAREPOINT_SERVERS",

"ENV_IIS_HOSTED_SHAREPOINT_SERVERS",

"ENV_SHAREPOINT_APP_SERVERS",

"ENV_HIGH_VALUE_COLLABORATION_SERVERS"

)

LET SHAREPOINT_PARENT_CONTEXT =

ParentProcessName IN ("w3wp.exe", "owstimer.exe", "svchost.exe")

OR ParentProcessPath CONTAINS ANY (

"\\inetpub\\",

"\\Microsoft Office Servers\\",

"\\Web Server Extensions\\",

"\\SharePoint\\"

)

OR UserName IN ENV_SHAREPOINT_APP_POOL_IDENTITIES

OR UserName IN ENV_SHAREPOINT_SERVICE_ACCOUNTS

LET SUSPICIOUS_CHILD_PROCESS =

ProcessName IN (

"cmd.exe",

"powershell.exe",

"pwsh.exe",

"cscript.exe",

"wscript.exe",

"mshta.exe",

"rundll32.exe",

"regsvr32.exe",

"certutil.exe",

"bitsadmin.exe",

"curl.exe",

"wget.exe",

"whoami.exe",

"net.exe",

"nltest.exe",

"ipconfig.exe",

"systeminfo.exe",

"tasklist.exe",

"quser.exe",

"ping.exe",

"nslookup.exe",

"tar.exe",

"7z.exe",

"rar.exe"

)

OR CommandLine CONTAINS ANY (

"-enc",

"-encodedcommand",

"downloadstring",

"invoke-webrequest",

"invoke-expression",

"frombase64string",

"certutil",

"bitsadmin",

"curl",

"wget",

"iwr",

"iex",

"whoami",

"nltest",

"net group",

"net user",

"systeminfo",

"tasklist",

"quser"

)

FROM ProcessEvents

WHERE EndpointName IN SHAREPOINT_ENDPOINTS

AND SHAREPOINT_PARENT_CONTEXT = true

AND SUSPICIOUS_CHILD_PROCESS = true

AND ProcessName NOT IN ENV_SHAREPOINT_APPROVED_CHILD_PROCESSES

AND CommandLine NOT IN ENV_SHAREPOINT_APPROVED_ADMIN_COMMAND_LINES

AND UserName NOT IN ENV_SHAREPOINT_APPROVED_ADMIN_OR_SERVICE_USERS

AND EventTime NOT IN ENV_SHAREPOINT_APPROVED_MAINTENANCE_WINDOWS

OUTPUT

EndpointName,

EndpointTags,

UserName,

ParentProcessName,

ParentProcessPath,

ProcessName,

ProcessPath,

CommandLine,

ProcessHash,

EventTime

Rule

SharePoint Webroot Suspicious File Staging from Service Context

Rule Format

SentinelOne Deep Visibility / STAR-style endpoint detection pattern

Detection Purpose

Detect suspicious file creation, modification, staging, or web-accessible artifact placement in SharePoint and IIS directories from SharePoint service context

Detection Logic

This rule identifies suspicious file activity in SharePoint, IIS, webroot, upload, layout, temporary, staging, and application-adjacent directories. It focuses on newly created or modified ASPX, DLL, EXE, PS1, JS, VBS, BAT, CMD, archive, temporary, configuration, and script artifacts that may indicate webshell placement, payload staging, command execution preparation, or post-exploitation tooling. The rule does not require a known webshell name or malware sample.

Required Telemetry

SentinelOne file telemetry with endpoint name, endpoint tags, file path, file name, file extension, file hash, file size, event type, process name, parent process name, command line, user context, and event time

· Endpoint tags identifying SharePoint servers and IIS-hosted SharePoint infrastructure

· File-event visibility for SharePoint webroot paths, IIS application paths, upload paths, layout paths, temporary directories, staging directories, and writable application directories

· Process telemetry linking file activity to w3wp.exe, SharePoint service accounts, application pool identities, administrative tools, script interpreters, or suspicious child processes

· Local allowlists for approved deployment tools, patching workflows, backup agents, monitoring agents, administrative scripts, and sanctioned SharePoint customization activity

Engineering Implementation Instructions

Validate tenant-specific SentinelOne file event names, file path fields, process fields, endpoint-tag syntax, and STAR compatibility before production deployment

· Scope the rule to confirmed SharePoint and IIS-hosted SharePoint servers

· Monitor web-accessible and application-adjacent directories where executable, script, archive, or configuration artifacts should not appear unexpectedly

· Require suspicious extension, suspicious path, unexpected process context, unexpected user context, short-lived artifact behavior, or post-creation access correlation before alert promotion

· Suppress approved patching, deployment, backup, monitoring, indexing, and SharePoint customization workflows

· Treat file creation by SharePoint service context in web-accessible paths as high priority when paired with suspicious process execution or outbound communication

· Do not assume every new file in SharePoint directories is malicious without validating deployment, patching, customization, and maintenance activity

DRI Assessment

This rule has strong detection value because suspicious file creation in SharePoint or IIS-accessible paths is a durable post-exploitation indicator across webshell deployment, payload staging, and tool placement behaviors. It is resilient against specific webshell names because it focuses on file path, extension, process context, user context, and timing. Its main weakness is that legitimate SharePoint customization, patching, and deployment workflows may create similar artifacts.

DRI

8.4

TCR Assessment

Operational coverage is strong where SentinelOne captures file events, process context, endpoint tags, and user context. Full-telemetry coverage improves when file activity is correlated with IIS logs, SharePoint application logs, process lineage, outbound communication, identity telemetry, and repeated access to newly created artifacts.

Operational TCR

7.9

Full-Telemetry TCR

8.8

Limitations

May over-alert during SharePoint patching, customization, deployment, backup, monitoring, or maintenance workflows

· Requires reliable file-event visibility for SharePoint and IIS directories

· May miss memory-resident execution that does not create durable file artifacts

· May miss artifacts that are created and deleted before telemetry collection

· Does not prove initial exploit path without web, process, identity, network, or application-log corroboration

· Tenant-specific SentinelOne path fields, file-event names, and command-line fields must be validated before deployment

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports file, process, command-line, endpoint-tag, and user-context correlation. IIS access, SharePoint application, identity, and network correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET SHAREPOINT_ENDPOINTS =

EndpointTags CONTAINS ANY (

"ENV_ON_PREM_SHAREPOINT_SERVERS",

"ENV_IIS_HOSTED_SHAREPOINT_SERVERS",

"ENV_SHAREPOINT_APP_SERVERS",

"ENV_HIGH_VALUE_COLLABORATION_SERVERS"

)

LET SHAREPOINT_SENSITIVE_PATHS =

FilePath CONTAINS ANY (

"\\inetpub\\wwwroot\\",

"\\inetpub\\temp\\",

"\\Microsoft Shared\\Web Server Extensions\\",

"\\Microsoft Office Servers\\",

"\\SharePoint\\",

"\\TEMPLATE\\LAYOUTS\\",

"\\TEMPLATE\\CONTROLTEMPLATES\\",

"\\_layouts\\",

"\\_vti_bin\\",

"\\App_Data\\",

"\\Temp\\"

)

LET SUSPICIOUS_SHAREPOINT_FILE_ACTIVITY =

FileExtension IN (

".aspx",

".ashx",

".asmx",

".dll",

".exe",

".ps1",

".js",

".vbs",

".bat",

".cmd",

".zip",

".7z",

".rar",

".tmp",

".config",

".xml"

)

OR FileName MATCHES ENV_SHAREPOINT_SUSPICIOUS_FILE_NAME_PATTERNS

OR FilePath NOT IN ENV_SHAREPOINT_APPROVED_DEPLOYMENT_PATHS

OR FileSize > ENV_SHAREPOINT_FILE_SIZE_BASELINE

OR FileHash NOT IN ENV_SHAREPOINT_APPROVED_FILE_HASHES

LET SUSPICIOUS_FILE_PROCESS_CONTEXT =

ProcessName IN (

"w3wp.exe",

"cmd.exe",

"powershell.exe",

"pwsh.exe",

"cscript.exe",

"wscript.exe",

"mshta.exe",

"rundll32.exe",

"regsvr32.exe",

"certutil.exe",

"bitsadmin.exe"

)

OR ParentProcessName IN (

"w3wp.exe",

"cmd.exe",

"powershell.exe",

"pwsh.exe",

"cscript.exe",

"wscript.exe",

"mshta.exe"

)

OR UserName IN ENV_SHAREPOINT_APP_POOL_IDENTITIES

OR UserName IN ENV_SHAREPOINT_SERVICE_ACCOUNTS

FROM FileEvents OR ProcessEvents

WHERE EndpointName IN SHAREPOINT_ENDPOINTS

AND SHAREPOINT_SENSITIVE_PATHS = true

AND SUSPICIOUS_SHAREPOINT_FILE_ACTIVITY = true

AND SUSPICIOUS_FILE_PROCESS_CONTEXT = true

AND ProcessName NOT IN ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_BACKUP_TOOLS

AND UserName NOT IN ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_ADMIN_USERS

AND EventTime NOT IN ENV_SHAREPOINT_APPROVED_PATCHING_OR_DEPLOYMENT_WINDOWS

OUTPUT

EndpointName,

EndpointTags,

UserName,

FilePath,

FileName,

FileExtension,

FileSize,

FileHash,

EventType,

ProcessName,

ParentProcessName,

CommandLine,

EventTime

Splunk

Rule

SharePoint Request-to-Worker-Process Execution Correlation

Rule Format

Splunk SPL backend-correlation pattern

Detection Purpose

Detect SharePoint request activity followed by suspicious IIS worker process or SharePoint service-context command execution on the same SharePoint server

Detection Logic

This rule correlates abnormal SharePoint or IIS request activity with suspicious process execution from SharePoint or IIS service context. It is designed to identify request-to-execution behavior associated with SharePoint Server RCE and IIS worker process post-exploitation without relying on a specific CVE, exploit string, request payload, webshell name, or malware artifact. High-confidence detections require SharePoint server asset context, abnormal request activity, suspicious process lineage, and a bounded timing relationship between the request anomaly and host-side execution.

Required Telemetry

Splunk ingestion of IIS, SharePoint, reverse proxy, WAF, or web gateway telemetry with host, URI, method, status, user, source IP, user agent, request duration, and event time

· Splunk ingestion of Windows process telemetry, EDR process telemetry, Sysmon process creation, or endpoint data model process events

· SharePoint server asset lookup with host, server role, application pool, exposure state, and criticality where available

· Approved SharePoint request-path, user-agent, administrative, maintenance, and service-account lookups

· Approved child-process, command-line, administrative-tool, monitoring-tool, backup-tool, and deployment-tool lookups

· Optional vulnerability, KEV, patch-state, identity, DNS, proxy, and firewall enrichment for triage and prioritization

Engineering Implementation Instructions

Abstract customer-specific indexes, sourcetypes, data models, field names, and summary indexes behind macros

· Normalize host, user, source IP, URI, method, status, user agent, process name, parent process name, command line, process path, and event time before correlation

· Use SharePoint server asset lookups to scope detection to confirmed on-premises SharePoint and IIS-hosted SharePoint infrastructure

· Require suspicious process execution from SharePoint or IIS context before alert promotion

· Suppress approved SharePoint administration, patching, backup, monitoring, indexing, deployment, and maintenance workflows

· Avoid broad raw joins, unbounded subsearches, repeated mvexpand, and high-cardinality correlation over raw indexes

· Promote to alert mode only after validating local indexes, sourcetypes, CIM mapping, macros, lookups, baselines, retention, and query performance

DRI Assessment

This rule has strong detection value because it correlates application-layer SharePoint activity with endpoint execution from IIS or SharePoint service context. It is resilient against exploit variation because it does not depend on a specific payload or CVE string. Its primary weakness is that environments with incomplete IIS logging, incomplete process telemetry, inconsistent host normalization, or heavy SharePoint administrative automation may reduce confidence or increase false positives.

DRI

8.8

TCR Assessment

Operational coverage is strong when Splunk receives IIS or proxy telemetry and process telemetry for SharePoint servers. Full-telemetry coverage improves when SharePoint application logs, identity events, DNS, proxy, firewall, vulnerability context, and asset criticality enrich the request-to-execution chain.

Operational TCR

8.2

Full-Telemetry TCR

9.1

Limitations

Requires reliable host normalization across web, endpoint, and asset data

· May miss exploitation if IIS or proxy telemetry is unavailable, incomplete, or not mapped to backend SharePoint hosts

· May miss host-side execution if EDR, Sysmon, Windows event, or process telemetry is incomplete

· May over-alert without allowlists for approved maintenance, backup, monitoring, deployment, indexing, and administrative workflows

· Does not prove the initial exploit path without supporting SharePoint, identity, application, or vulnerability context

· Requires local macro, lookup, field, and performance validation before production alerting

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support IIS, SharePoint, reverse proxy, WAF, Windows process, EDR, Sysmon, asset-inventory, and identity correlation. Customer-specific indexes, sourcetypes, field names, summary indexes, and accelerated data sources should be abstracted behind macros and lookups.

`sharepoint_web_or_application_events`

| eval normalized_host=coalesce(dest, host, ComputerName, server_name, backend_host)

| eval normalized_user=coalesce(user, cs_username, authenticated_user, AccountName, userPrincipalName)

| eval normalized_src_ip=coalesce(src_ip, c_ip, client_ip, SourceIpAddress, x_forwarded_for)

| eval normalized_uri=coalesce(uri, uri_path, cs_uri_stem, request_path, url_path)

| eval normalized_method=coalesce(method, cs_method, http_method)

| eval normalized_status=coalesce(status, sc_status, http_status)

| eval normalized_user_agent=coalesce(user_agent, cs_user_agent, UserAgent)

| eval normalized_request_duration=coalesce(time_taken, request_duration, duration)

| eval web_time=_time

| lookup ENV_SHAREPOINT_SERVERS normalized_host OUTPUT sharepoint_server_match host_role exposure_state asset_criticality

| lookup ENV_SHAREPOINT_RARE_OR_SENSITIVE_PATHS normalized_uri OUTPUT sensitive_path_match

| lookup ENV_SHAREPOINT_APPROVED_USER_AGENTS normalized_user_agent OUTPUT approved_user_agent

| lookup ENV_SHAREPOINT_APPROVED_USERS normalized_user OUTPUT approved_sharepoint_user

| where sharepoint_server_match="true"

| where normalized_status IN ("500", "502", "503")

OR sensitive_path_match="true"

OR normalized_method IN ("POST", "PUT")

OR normalized_request_duration > ENV_SHAREPOINT_REQUEST_DURATION_BASELINE

OR approved_user_agent!="true"

OR approved_sharepoint_user!="true"

| eval event_kind="sharepoint_request_anomaly"

| eval candidate_time=web_time

| eval carry_web_time=if(event_kind="sharepoint_request_anomaly", candidate_time, null())

| eval carry_uri=if(event_kind="sharepoint_request_anomaly", normalized_uri, null())

| eval carry_method=if(event_kind="sharepoint_request_anomaly", normalized_method, null())

| eval carry_status=if(event_kind="sharepoint_request_anomaly", normalized_status, null())

| eval carry_src_ip=if(event_kind="sharepoint_request_anomaly", normalized_src_ip, null())

| eval carry_user=if(event_kind="sharepoint_request_anomaly", normalized_user, null())

| eval carry_user_agent=if(event_kind="sharepoint_request_anomaly", normalized_user_agent, null())

| fields normalized_host host_role exposure_state asset_criticality event_kind candidate_time carry_web_time carry_uri carry_method carry_status carry_src_ip carry_user carry_user_agent

| append [

`sharepoint_process_events`

| eval normalized_host=coalesce(dest, host, ComputerName, endpoint, EndpointName)

| eval normalized_user=coalesce(user, UserName, AccountName, SubjectUserName, process_user)

| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, parent_image, ParentImage))

| eval normalized_process=lower(coalesce(process_name, ProcessName, process, process_image, Image))

| eval normalized_process_path=coalesce(process_path, ProcessPath, Image, process_image)

| eval normalized_command_line=coalesce(command_line, CommandLine, process_command_line, ProcessCommandLine)

| eval process_time=_time

| lookup ENV_SHAREPOINT_SERVERS normalized_host OUTPUT sharepoint_server_match host_role exposure_state asset_criticality

| lookup ENV_SHAREPOINT_APP_POOL_IDENTITIES normalized_user OUTPUT app_pool_identity_match

| lookup ENV_SHAREPOINT_APPROVED_CHILD_PROCESSES normalized_process OUTPUT approved_child_process

| lookup ENV_SHAREPOINT_APPROVED_ADMIN_COMMAND_LINES normalized_command_line OUTPUT approved_admin_command

| lookup ENV_SHAREPOINT_APPROVED_ADMIN_OR_SERVICE_USERS normalized_user OUTPUT approved_admin_user

| where sharepoint_server_match="true"

| where normalized_parent_process IN ("w3wp.exe", "owstimer.exe")

OR app_pool_identity_match="true"

| where normalized_process IN ("cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "wget.exe", "whoami.exe", "net.exe", "nltest.exe", "ipconfig.exe", "systeminfo.exe", "tasklist.exe", "quser.exe", "ping.exe", "nslookup.exe", "tar.exe", "7z.exe", "rar.exe")

| where approved_child_process!="true"

| where approved_admin_command!="true"

| where approved_admin_user!="true"

| eval event_kind="sharepoint_process_execution_candidate"

| eval candidate_time=process_time

| fields normalized_host host_role exposure_state asset_criticality event_kind candidate_time normalized_user normalized_parent_process normalized_process normalized_process_path normalized_command_line

]

| sort 0 normalized_host candidate_time

| filldown carry_web_time carry_uri carry_method carry_status carry_src_ip carry_user carry_user_agent by normalized_host

| where event_kind="sharepoint_process_execution_candidate"

| where isnotnull(carry_web_time)

| where candidate_time >= carry_web_time

| where candidate_time <= carry_web_time + ENV_SHAREPOINT_REQUEST_TO_EXECUTION_WINDOW_SECONDS

| table carry_web_time candidate_time normalized_host host_role exposure_state asset_criticality carry_src_ip carry_user carry_user_agent carry_uri carry_method carry_status normalized_user normalized_parent_process normalized_process normalized_process_path normalized_command_line

Rule

SharePoint Webroot File Staging and Outbound Communication Correlation

Rule Format

Splunk SPL backend-correlation pattern

Detection Purpose

Detect suspicious file creation or modification in SharePoint or IIS paths followed by outbound communication from the same SharePoint server

Detection Logic

This rule correlates suspicious file creation, file modification, staging, or web-accessible artifact placement in SharePoint and IIS paths with outbound DNS, proxy, firewall, EDR network, or NDR telemetry. It is designed to detect webshell placement, payload staging, tool staging, archive creation, or post-exploitation file activity followed by external communication. High-confidence detections require SharePoint server asset context, suspicious file activity, abnormal process or user context, rare outbound destination behavior, and a bounded timing relationship.

Required Telemetry

Splunk ingestion of Windows file telemetry, Sysmon file events, EDR file telemetry, or endpoint data model file events

· Splunk ingestion of DNS, proxy, firewall, EDR network, NDR, or network telemetry with destination, port, protocol, action, category, reputation, bytes, and event time where available

· SharePoint server asset lookup with host role, exposure state, and criticality

· Approved SharePoint file-path, deployment-path, file-hash, file-extension, process, user, maintenance-window, and destination lookups

· Optional IIS, SharePoint application, identity, vulnerability, and patch-state context for triage and prioritization

Engineering Implementation Instructions

Abstract customer-specific file, network, DNS, proxy, firewall, EDR, and NDR sources behind macros

· Normalize host, user, file path, file name, file extension, file hash, process name, command line, destination, protocol, port, and event time before correlation

· Scope detection to confirmed SharePoint and IIS-hosted SharePoint servers

· Require suspicious file activity in SharePoint or IIS paths before evaluating outbound communication as high-confidence

· Suppress approved patching, deployment, customization, backup, monitoring, indexing, and administrative workflows

· Suppress approved Microsoft, update, backup, monitoring, enterprise proxy, security-tool, and business integration destinations

· Promote to alert mode only after validating local path mappings, destination baselines, file-event schemas, network-field mappings, and query performance

DRI Assessment

This rule has strong detection value because suspicious file staging followed by outbound communication is a durable post-exploitation pattern across webshell, loader, staging, and tool-deployment workflows. It is resilient against payload-name changes because it focuses on path, extension, process context, destination rarity, and sequence. Its main weakness is that legitimate deployment, patching, backup, or customization workflows may produce file changes and network activity if baselines are incomplete.

DRI

8.6

TCR Assessment

Operational coverage is strong where Splunk receives file telemetry and network telemetry for SharePoint servers. Full-telemetry coverage improves when IIS logs, SharePoint application logs, process lineage, identity context, DNS, proxy, firewall, EDR, and asset-criticality data enrich the chain.

Operational TCR

8.0

Full-Telemetry TCR

9.0

Limitations

Requires reliable file telemetry from SharePoint and IIS paths

· Requires reliable destination baselines for SharePoint servers

· May miss memory-only execution that does not create durable file artifacts

· May miss activity where outbound communication is internal-only or uses approved egress paths

· May over-alert during patching, deployment, backup, customization, monitoring, or maintenance workflows

· Requires local macro, lookup, field, and performance validation before production alerting

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support file, process, DNS, proxy, firewall, EDR network, NDR, SharePoint asset, and destination-baseline correlation. Customer-specific indexes, sourcetypes, field names, summary indexes, and accelerated data sources should be abstracted behind macros and lookups.

`sharepoint_file_events`

| eval normalized_host=coalesce(dest, host, ComputerName, endpoint, EndpointName)

| eval normalized_user=coalesce(user, UserName, AccountName, SubjectUserName, process_user)

| eval normalized_file_path=coalesce(file_path, FilePath, TargetFilename, file_name, ObjectName)

| eval normalized_file_name=coalesce(file_name, FileName, TargetFilename)

| eval normalized_file_hash=coalesce(file_hash, FileHash, sha256, SHA256, md5, MD5)

| eval normalized_process=lower(coalesce(process_name, ProcessName, process, Image))

| eval normalized_parent_process=lower(coalesce(parent_process_name, ParentProcessName, parent_process, ParentImage))

| eval normalized_command_line=coalesce(command_line, CommandLine, process_command_line, ProcessCommandLine)

| eval normalized_file_extension=lower(replace(normalized_file_name, "^.*(\\.[^.]+)$", "\\1"))

| eval file_time=_time

| lookup ENV_SHAREPOINT_SERVERS normalized_host OUTPUT sharepoint_server_match host_role exposure_state asset_criticality

| lookup ENV_SHAREPOINT_SENSITIVE_PATHS normalized_file_path OUTPUT sensitive_path_match

| lookup ENV_SHAREPOINT_APPROVED_DEPLOYMENT_PATHS normalized_file_path OUTPUT approved_deployment_path

| lookup ENV_SHAREPOINT_APPROVED_FILE_HASHES normalized_file_hash OUTPUT approved_file_hash

| lookup ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_BACKUP_TOOLS normalized_process OUTPUT approved_file_process

| lookup ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_ADMIN_USERS normalized_user OUTPUT approved_file_user

| where sharepoint_server_match="true"

| where sensitive_path_match="true"

| where normalized_file_extension IN (".aspx", ".ashx", ".asmx", ".dll", ".exe", ".ps1", ".js", ".vbs", ".bat", ".cmd", ".zip", ".7z", ".rar", ".tmp", ".config", ".xml")

OR match(lower(normalized_file_name), ENV_SHAREPOINT_SUSPICIOUS_FILE_NAME_REGEX)

OR approved_deployment_path!="true"

OR approved_file_hash!="true"

| where approved_file_process!="true"

| where approved_file_user!="true"

| eval event_kind="sharepoint_file_staging_candidate"

| eval candidate_time=file_time

| eval carry_file_time=if(event_kind="sharepoint_file_staging_candidate", candidate_time, null())

| eval carry_file_path=if(event_kind="sharepoint_file_staging_candidate", normalized_file_path, null())

| eval carry_file_name=if(event_kind="sharepoint_file_staging_candidate", normalized_file_name, null())

| eval carry_file_hash=if(event_kind="sharepoint_file_staging_candidate", normalized_file_hash, null())

| eval carry_file_process=if(event_kind="sharepoint_file_staging_candidate", normalized_process, null())

| eval carry_file_user=if(event_kind="sharepoint_file_staging_candidate", normalized_user, null())

| fields normalized_host host_role exposure_state asset_criticality event_kind candidate_time carry_file_time carry_file_path carry_file_name carry_file_hash carry_file_process carry_file_user

| append [

`sharepoint_network_events`

| eval normalized_host=coalesce(src_host, host, ComputerName, endpoint, EndpointName)

| eval normalized_dest_ip=coalesce(dest_ip, destination_ip, DestinationIp, d_ip)

| eval normalized_dest_domain=coalesce(dest_domain, url_domain, query, dns_query, DestinationHostname)

| eval normalized_dest_port=coalesce(dest_port, destination_port, d_port)

| eval normalized_protocol=coalesce(protocol, transport, app, app_protocol)

| eval normalized_action=coalesce(action, verdict, firewall_action, proxy_action)

| eval normalized_bytes_out=coalesce(bytes_out, bytes, sent_bytes, bytes_sent)

| eval normalized_dest_category=coalesce(dest_category, category, url_category, destination_category)

| eval normalized_dest_reputation=coalesce(dest_reputation, reputation, threat_score, risk)

| eval network_time=_time

| lookup ENV_SHAREPOINT_SERVERS normalized_host OUTPUT sharepoint_server_match host_role exposure_state asset_criticality

| lookup ENV_SHAREPOINT_APPROVED_DESTINATIONS normalized_dest_domain normalized_dest_ip OUTPUT approved_destination

| lookup ENV_SHAREPOINT_DNS_BASELINE normalized_host normalized_dest_domain OUTPUT baseline_dns_match

| lookup ENV_SHAREPOINT_APPROVED_EGRESS_PORTS normalized_dest_port OUTPUT approved_egress_port

| where sharepoint_server_match="true"

| where approved_destination!="true"

OR baseline_dns_match!="true"

OR approved_egress_port!="true"

OR normalized_dest_category IN ("dynamic_dns", "file_sharing", "paste_site", "newly_registered_domain", "unknown", "suspicious_hosting", "tunnel", "anonymizer")

OR normalized_dest_reputation IN ("low", "suspicious", "malicious", "unknown")

OR normalized_bytes_out > ENV_SHAREPOINT_SERVER_OUTBOUND_BASELINE

| eval event_kind="sharepoint_outbound_candidate"

| eval candidate_time=network_time

| fields normalized_host host_role exposure_state asset_criticality event_kind candidate_time normalized_dest_ip normalized_dest_domain normalized_dest_port normalized_protocol normalized_action normalized_bytes_out normalized_dest_category normalized_dest_reputation

]

| sort 0 normalized_host candidate_time

| filldown carry_file_time carry_file_path carry_file_name carry_file_hash carry_file_process carry_file_user by normalized_host

| where event_kind="sharepoint_outbound_candidate"

| where isnotnull(carry_file_time)

| where candidate_time >= carry_file_time

| where candidate_time <= carry_file_time + ENV_SHAREPOINT_FILE_TO_OUTBOUND_WINDOW_SECONDS

| table carry_file_time candidate_time normalized_host host_role exposure_state asset_criticality carry_file_user carry_file_process carry_file_path carry_file_name carry_file_hash normalized_dest_ip normalized_dest_domain normalized_dest_port normalized_protocol normalized_action normalized_bytes_out normalized_dest_category normalized_dest_reputation

Elastic

Rule

SharePoint Request-to-Worker-Process Execution Sequence

Rule Format

Elastic EQL / KQL backend-correlation pattern

Detection Purpose

Detect abnormal SharePoint or IIS request activity followed by suspicious worker-process, service-context, or SharePoint application-pool execution on the same SharePoint server

Detection Logic

This rule correlates abnormal SharePoint or IIS web activity with suspicious process execution from SharePoint or IIS service context. It is designed to detect request-to-execution behavior associated with SharePoint Server RCE and IIS worker process post-exploitation without relying on a specific CVE, exploit string, webshell name, or payload artifact. High-confidence detections require SharePoint server role mapping, web or application anomaly context, suspicious process lineage, and a bounded timing relationship.

Required Telemetry

Elastic data streams or indices containing IIS, SharePoint, reverse proxy, WAF, load balancer, or web gateway telemetry

· Elastic Endpoint, Windows event, Sysmon, EDR, or ECS-mapped process telemetry from SharePoint servers

· ECS or locally mapped fields for host identity, host role, user, source IP, URL path, HTTP method, HTTP status, user agent, process name, parent process name, command line, process path, and event time

· Enrichment fields or value lists identifying on-premises SharePoint servers, IIS-hosted SharePoint servers, SharePoint application servers, application pool identities, approved users, approved user agents, approved child processes, and approved administrative command lines

· Exception lists for approved maintenance, backup, monitoring, indexing, patching, deployment, and administrative workflows

· Optional identity, vulnerability, KEV, DNS, proxy, firewall, and asset-criticality enrichment for triage

Engineering Implementation Instructions

Map customer-specific Elastic index names, data streams, ECS fields, local fields, transforms, enrichment policies, value lists, and exception lists before deployment

· Scope detections to confirmed SharePoint and IIS-hosted SharePoint servers through host role tags, asset enrichment, or value lists

· Use EQL sequence logic only where the required web/application and process events share a reliable host identifier

· Require suspicious SharePoint or IIS process lineage before alert promotion

· Suppress approved administrative workflows, backup tools, monitoring agents, patching activity, deployment workflows, indexing activity, and maintenance windows

· Do not treat request anomalies alone as proof of exploitation

· Promote to alert mode only after validating ECS mappings, local enriched fields, exception logic, event timing, index performance, and alert volume

DRI Assessment

This rule has strong detection value when Elastic receives both web or application telemetry and endpoint process telemetry for SharePoint servers. It is resilient against exploit variation because it correlates abnormal request handling with downstream execution behavior instead of matching CVE-specific payloads. Its main weakness is that incomplete ECS mapping, missing backend host attribution, or weak SharePoint role tagging can reduce correlation accuracy.

DRI

8.6

TCR Assessment

Operational coverage is strong where SharePoint web/application logs and endpoint process telemetry are present and mapped to consistent host identifiers. Full-telemetry coverage improves when identity, DNS, proxy, firewall, vulnerability, and asset-criticality enrichment are available.

Operational TCR

8.0

Full-Telemetry TCR

8.9

Limitations

Requires reliable host identity normalization across web, application, endpoint, and asset data

· May miss exploitation when web telemetry does not map to backend SharePoint hosts

· May miss host-side execution when endpoint or process telemetry is incomplete

· May over-alert without exception lists for approved administration, deployment, backup, monitoring, patching, indexing, and maintenance workflows

· Does not prove initial exploit path without SharePoint, IIS, identity, application, or vulnerability corroboration

· Customer-specific Elastic schema, ECS mappings, data streams, and exception lists must be validated before deployment

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support IIS, SharePoint, reverse proxy, WAF, endpoint process, Windows event, EDR, asset-inventory, and identity correlation. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by host.id with maxspan=ENV_SHAREPOINT_REQUEST_TO_EXECUTION_WINDOW

[ any where

event.dataset : ENV_SHAREPOINT_WEB_OR_APPLICATION_DATASET_PATTERN and

host.role : ("sharepoint_server", "iis_hosted_sharepoint", "sharepoint_app_server") and

sharepoint.server.in_scope == true and

exception.sharepoint_web_activity.match != true and

(

http.response.status_code in (500, 502, 503) or

url.path in ENV_SHAREPOINT_RARE_OR_SENSITIVE_PATHS or

http.request.method in ("POST", "PUT") or

event.duration > ENV_SHAREPOINT_REQUEST_DURATION_BASELINE or

user_agent.original not in ENV_SHAREPOINT_APPROVED_USER_AGENTS or

user.name not in ENV_SHAREPOINT_APPROVED_USERS or

sharepoint.application_fault == true or

sharepoint.worker_process_crash == true or

sharepoint.application_pool_recycle == true

)

]

[ process where

event.dataset : ENV_SHAREPOINT_PROCESS_EVENT_DATASET_PATTERN and

host.role : ("sharepoint_server", "iis_hosted_sharepoint", "sharepoint_app_server") and

sharepoint.server.in_scope == true and

exception.sharepoint_process_execution.match != true and

(

process.parent.name in ("w3wp.exe", "owstimer.exe") or

user.name in ENV_SHAREPOINT_APP_POOL_IDENTITIES or

user.name in ENV_SHAREPOINT_SERVICE_ACCOUNTS

) and

(

process.name in ("cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "wget.exe", "whoami.exe", "net.exe", "nltest.exe", "ipconfig.exe", "systeminfo.exe", "tasklist.exe", "quser.exe", "ping.exe", "nslookup.exe", "tar.exe", "7z.exe", "rar.exe") or

) and

process.name not in ENV_SHAREPOINT_APPROVED_CHILD_PROCESSES and

process.command_line not in ENV_SHAREPOINT_APPROVED_ADMIN_COMMAND_LINES and

user.name not in ENV_SHAREPOINT_APPROVED_ADMIN_OR_SERVICE_USERS

]

Rule

SharePoint Webroot File Staging Followed by Rare Outbound Communication

Rule Format

Elastic EQL / KQL backend-correlation pattern

Detection Purpose

Detect suspicious file creation or modification in SharePoint or IIS paths followed by rare outbound communication from the same SharePoint server

Detection Logic

This rule correlates suspicious file activity in SharePoint or IIS-accessible paths with rare outbound network communication from the same server. It is designed to detect webshell placement, payload staging, tool staging, archive creation, or post-exploitation file activity followed by external communication. The detection focuses on suspicious path, extension, process context, user context, destination rarity, and bounded sequence timing.

Required Telemetry

Elastic data streams or indices containing file telemetry from Elastic Endpoint, Sysmon, Windows events, EDR, or ECS-mapped file events

· Elastic data streams or indices containing DNS, proxy, firewall, EDR network, NDR, or ECS-mapped network telemetry

· ECS or locally mapped fields for host identity, file path, file name, file extension, file hash, file size, process name, parent process name, command line, user, destination IP, destination domain, destination port, protocol, destination category, destination reputation, bytes out, and event time

· Enrichment fields or value lists identifying SharePoint servers, sensitive SharePoint paths, approved deployment paths, approved file hashes, approved deployment tools, approved administrative users, approved destinations, approved egress ports, and baseline DNS destinations

· Exception lists for approved patching, deployment, customization, backup, monitoring, indexing, and maintenance windows

· Optional IIS, SharePoint application, identity, vulnerability, patch-state, and asset-criticality enrichment for triage

Engineering Implementation Instructions

Map customer-specific file, process, DNS, proxy, firewall, EDR network, NDR, ECS, and local enriched fields before deployment

· Scope detection to confirmed SharePoint and IIS-hosted SharePoint servers through host role tags, asset enrichment, or value lists

· Monitor SharePoint webroot, IIS application, layout, upload, temporary, staging, and writable application directories

· Require suspicious file path, suspicious extension, unexpected process context, unexpected user context, unapproved hash, or post-creation access pattern before treating file activity as a candidate

· Require outbound destination rarity, suspicious category, low reputation, abnormal egress port, baseline mismatch, or abnormal transfer volume before alert promotion

· Suppress approved patching, deployment, customization, backup, monitoring, indexing, maintenance, Microsoft, update, proxy, security-tool, and business integration activity

· Promote to alert mode only after validating ECS mappings, path baselines, destination baselines, exception lists, sequence timing, and query performance

DRI Assessment

This rule has strong detection value because suspicious file staging followed by rare outbound communication is a durable post-exploitation behavior across webshell placement, payload staging, tool deployment, and outbound callback workflows. It is resilient against file-name and infrastructure changes because it emphasizes path, extension, process context, destination rarity, and sequence. Its main weakness is that legitimate deployment or patching workflows may resemble the behavior when exceptions and baselines are incomplete.

DRI

8.5

TCR Assessment

Operational coverage is strong where Elastic receives file and network telemetry from SharePoint servers with reliable host correlation. Full-telemetry coverage improves when IIS logs, SharePoint application logs, process lineage, identity telemetry, DNS, proxy, firewall, vulnerability, and asset-criticality enrichment are available.

Operational TCR

7.9

Full-Telemetry TCR

8.8

Limitations

Requires reliable file telemetry from SharePoint and IIS paths

· Requires reliable network telemetry and destination baselines for SharePoint servers

· May miss memory-only execution that does not create durable file artifacts

· May miss activity where outbound communication remains internal or uses approved egress paths

· May over-alert during patching, deployment, customization, backup, monitoring, indexing, or maintenance workflows

· Customer-specific Elastic schema, ECS mappings, transforms, and exception lists must be validated before deployment

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support file, process, DNS, proxy, firewall, EDR network, NDR, SharePoint asset, and destination-baseline correlation. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by host.id with maxspan=ENV_SHAREPOINT_FILE_TO_OUTBOUND_WINDOW

[ file where

event.dataset : ENV_SHAREPOINT_FILE_EVENT_DATASET_PATTERN and

host.role : ("sharepoint_server", "iis_hosted_sharepoint", "sharepoint_app_server") and

sharepoint.server.in_scope == true and

exception.sharepoint_file_activity.match != true and

(

file.path : ENV_SHAREPOINT_SENSITIVE_PATH_PATTERNS or

file.path in ENV_SHAREPOINT_SENSITIVE_PATHS

) and

(

file.extension in ("aspx", "ashx", "asmx", "dll", "exe", "ps1", "js", "vbs", "bat", "cmd", "zip", "7z", "rar", "tmp", "config", "xml") or

file.name regex~ ENV_SHAREPOINT_SUSPICIOUS_FILE_NAME_REGEX or

file.path not in ENV_SHAREPOINT_APPROVED_DEPLOYMENT_PATHS or

file.hash.sha256 not in ENV_SHAREPOINT_APPROVED_FILE_HASHES or

file.size > ENV_SHAREPOINT_FILE_SIZE_BASELINE

) and

(

process.name in ("w3wp.exe", "cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe") or

process.parent.name in ("w3wp.exe", "cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "mshta.exe") or

user.name in ENV_SHAREPOINT_APP_POOL_IDENTITIES or

user.name in ENV_SHAREPOINT_SERVICE_ACCOUNTS

) and

process.name not in ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_BACKUP_TOOLS and

user.name not in ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_ADMIN_USERS

]

[ network where

event.dataset : ENV_SHAREPOINT_NETWORK_EVENT_DATASET_PATTERN and

host.role : ("sharepoint_server", "iis_hosted_sharepoint", "sharepoint_app_server") and

sharepoint.server.in_scope == true and

exception.sharepoint_network_activity.match != true and

(

destination.domain not in ENV_SHAREPOINT_APPROVED_DESTINATIONS or

destination.ip not in ENV_SHAREPOINT_APPROVED_DESTINATIONS or

destination.port not in ENV_SHAREPOINT_APPROVED_EGRESS_PORTS or

dns.question.name not in ENV_SHAREPOINT_DNS_BASELINE or

destination.category in ("dynamic_dns", "file_sharing", "paste_site", "newly_registered_domain", "unknown", "suspicious_hosting", "tunnel", "anonymizer") or

destination.reputation in ("low", "suspicious", "malicious", "unknown") or

network.bytes > ENV_SHAREPOINT_SERVER_OUTBOUND_BASELINE

)

]

QRadar

Rule

SharePoint Request-to-Worker-Process Execution Offense Correlation

Rule Format

QRadar CRE offense-correlation pseudologic

Detection Purpose

Detect abnormal SharePoint or IIS request activity followed by suspicious process execution from SharePoint, IIS worker process, or SharePoint service-account context on the same server

Detection Logic

This rule correlates SharePoint or IIS web and application activity with suspicious Windows process, EDR, Sysmon, or endpoint execution events from the same SharePoint server. It is designed to detect request-to-execution behavior associated with SharePoint Server RCE and IIS worker process post-exploitation without relying on a specific CVE, exploit string, request payload, webshell name, or malware artifact. High-confidence detections require SharePoint server scoping, abnormal request or application activity, suspicious process lineage, approved-workflow suppression, and a bounded timing relationship between the web anomaly and host-side execution.

Required Telemetry

QRadar events from IIS, SharePoint, reverse proxy, WAF, load balancer, or web gateway telemetry

· QRadar events from Windows Security, Sysmon, EDR, or endpoint telemetry that capture process creation and command-line execution

· DSM-parsed or custom properties for host, backend host, source IP, user, URI, HTTP method, HTTP status, user agent, request duration, application fault, worker process crash, application pool recycle, process name, parent process name, command line, process path, user context, and event time

· Reference sets for SharePoint servers, IIS-hosted SharePoint servers, rare or sensitive SharePoint paths, approved SharePoint users, approved user agents, approved child processes, approved command lines, approved service accounts, approved administrative users, and active investigation suppressions

· Reference maps for SharePoint server roles, exposure state, asset criticality, approved maintenance windows, approved administrative contexts, and approved user-to-server relationships

· Optional vulnerability, KEV, patch-state, identity, DNS, proxy, and firewall enrichment for prioritization and triage

Engineering Implementation Instructions

Map all DSM fields, custom properties, reference sets, reference maps, building blocks, offense rules, and time windows to the target QRadar environment before deployment

· Build QRadar building blocks for confirmed SharePoint servers, abnormal SharePoint request activity, SharePoint service-account context, suspicious child process execution, and approved-workflow suppression

· Use CRE correlation for offense generation and reserve AQL for supporting hunts or validation unless local performance has been tested

· Require same-host or equivalent normalized backend-host lineage between the web anomaly and process execution candidate

· Suppress approved patching, backup, monitoring, indexing, deployment, maintenance, vulnerability scanning, and sanctioned administrative workflows

· Do not generate a high-severity offense from web request anomalies alone

· Promote to production only after validating DSM parsing, custom properties, reference data, event volume, offense grouping, false-positive suppressions, and SOC triage workflow

DRI Assessment

This rule has strong detection value because it correlates SharePoint web or application anomalies with suspicious server-side execution from the same host. It is resilient against exploit variation because it focuses on behavior rather than CVE-specific strings or payload artifacts. Its main weakness is that QRadar effectiveness depends heavily on DSM parsing quality, custom-property accuracy, host normalization, and reference-set maintenance.

DRI

8.5

TCR Assessment

Operational coverage is strong when QRadar receives both SharePoint web/application telemetry and endpoint process telemetry with reliable host correlation. Full-telemetry coverage improves when identity, proxy, firewall, DNS, vulnerability, patch-state, and asset-criticality context enrich the offense.

Operational TCR

7.9

Full-Telemetry TCR

8.8

Limitations

Requires reliable backend-host normalization between web telemetry and endpoint telemetry

· May miss exploitation when IIS, SharePoint, reverse proxy, or WAF events are unavailable or not mapped to the SharePoint server

· May miss host-side execution when Windows, Sysmon, EDR, or endpoint telemetry is incomplete

· May over-alert without approved-workflow reference sets for maintenance, patching, backup, monitoring, indexing, deployment, and administration

· Does not prove the initial exploit path without supporting SharePoint, IIS, identity, application, or vulnerability context

· Requires local DSM parsing, custom-property, reference-set, reference-map, building-block, and offense-rule validation before deployment

Detection Query Pattern

Use this pattern as implementation-ready QRadar correlation pseudologic and map all custom properties, reference sets, reference maps, DSM fields, building blocks, offense rules, and time windows to the target QRadar environment before deployment.

WHEN events are detected for the same normalized SharePoint server, same backend host, same destination host, same asset ID, same application pool context, or equivalent normalized host lineage

WITHIN ENV_SHAREPOINT_REQUEST_TO_EXECUTION_WINDOW

AND SharePoint_Server is contained in reference set ENV_SHAREPOINT_SERVERS

AND SharePoint_Request_Anomaly_Time occurs before SharePoint_Process_Execution_Time

AND SharePoint_Process_Execution_Time occurs within ENV_SHAREPOINT_REQUEST_TO_EXECUTION_WINDOW after SharePoint_Request_Anomaly_Time

AND (

HTTP_Status is contained in reference set ENV_SHAREPOINT_SERVER_ERROR_STATUS_CODES

OR URI_Path is contained in reference set ENV_SHAREPOINT_RARE_OR_SENSITIVE_PATHS

OR HTTP_Method is contained in reference set ENV_SHAREPOINT_HIGH_RISK_METHODS

OR Request_Duration is greater than ENV_SHAREPOINT_REQUEST_DURATION_BASELINE

OR User_Agent is not contained in reference set ENV_SHAREPOINT_APPROVED_USER_AGENTS

OR Authenticated_User is not contained in reference set ENV_SHAREPOINT_APPROVED_USERS

OR SharePoint_Application_Fault equals true

OR Worker_Process_Crash equals true

OR Application_Pool_Recycle equals true

)

AND (

Parent_Process_Name equals w3wp.exe

OR Parent_Process_Name equals owstimer.exe

OR Process_User is contained in reference set ENV_SHAREPOINT_APP_POOL_IDENTITIES

OR Process_User is contained in reference set ENV_SHAREPOINT_SERVICE_ACCOUNTS

)

AND (

Process_Name is contained in reference set ENV_SHAREPOINT_SUSPICIOUS_CHILD_PROCESSES

OR Command_Line matches any pattern in reference set ENV_SHAREPOINT_SUSPICIOUS_COMMAND_LINE_PATTERNS

OR Process_Path matches any pattern in reference set ENV_SHAREPOINT_SUSPICIOUS_PROCESS_PATH_PATTERNS

)

AND NOT (

Process_Name is contained in reference set ENV_SHAREPOINT_APPROVED_CHILD_PROCESSES

AND Command_Line matches any pattern in reference set ENV_SHAREPOINT_APPROVED_ADMIN_COMMAND_LINES

AND Process_User is contained in reference set ENV_SHAREPOINT_APPROVED_ADMIN_OR_SERVICE_USERS

AND SharePoint_Server is contained in reference map ENV_SHAREPOINT_APPROVED_ADMIN_CONTEXTS for Process_User

)

AND NOT (

SharePoint_Server is contained in reference set ENV_SHAREPOINT_PATCHING_OR_MAINTENANCE_TARGETS

AND Event_Time is contained in reference map ENV_SHAREPOINT_APPROVED_MAINTENANCE_WINDOWS for SharePoint_Server

AND Process_Name is contained in reference set ENV_SHAREPOINT_APPROVED_MAINTENANCE_PROCESSES

)

AND NOT (

SharePoint_Server is contained in reference set ENV_SHAREPOINT_BACKUP_OR_MONITORING_TARGETS

AND Process_Name is contained in reference set ENV_SHAREPOINT_APPROVED_BACKUP_OR_MONITORING_PROCESSES

AND Process_User is contained in reference set ENV_SHAREPOINT_APPROVED_BACKUP_OR_MONITORING_USERS

)

AND SharePoint_Server is not contained in reference set ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

THEN generate offense with context:

SharePoint_Server,

Host_Role,

Exposure_State,

Asset_Criticality,

SharePoint_Request_Anomaly_Time,

SharePoint_Process_Execution_Time,

Source_IP,

Authenticated_User,

User_Agent,

URI_Path,

HTTP_Method,

HTTP_Status,

Request_Duration,

SharePoint_Application_Fault,

Worker_Process_Crash,

Application_Pool_Recycle,

Process_User,

Parent_Process_Name,

Process_Name,

Process_Path,

Command_Line,

Process_Hash,

Offense_Grouping_Key,

Time_Delta

Rule

SharePoint Webroot File Staging and Rare Outbound Offense Correlation

Rule Format

QRadar CRE offense-correlation pseudologic

Detection Purpose

Detect suspicious file creation or modification in SharePoint or IIS paths followed by rare outbound communication from the same SharePoint server

Detection Logic

This rule correlates suspicious file activity in SharePoint or IIS-accessible directories with rare outbound DNS, proxy, firewall, EDR network, NDR, or flow telemetry from the same SharePoint server. It is designed to identify webshell placement, payload staging, tool staging, archive creation, or post-exploitation file activity followed by external communication. High-confidence detections require SharePoint server scoping, suspicious file path or extension, suspicious process or user context, rare destination behavior, approved-workflow suppression, and bounded timing between file activity and outbound communication.

Required Telemetry

QRadar events from Windows file telemetry, Sysmon file events, EDR file telemetry, or endpoint file-monitoring sources

· QRadar events from DNS, proxy, firewall, EDR network, NDR, NetFlow, or network telemetry

· DSM-parsed or custom properties for host, file path, file name, file extension, file hash, file size, process name, parent process name, command line, user context, destination IP, destination domain, destination port, protocol, destination category, destination reputation, bytes out, and event time

· Reference sets for SharePoint servers, sensitive SharePoint paths, suspicious file extensions, suspicious file-name patterns, approved deployment paths, approved file hashes, approved deployment users, approved deployment tools, approved destinations, approved egress ports, baseline DNS destinations, and active investigation suppressions

· Reference maps for SharePoint server roles, exposure state, asset criticality, approved deployment windows, approved source-to-destination relationships, approved DNS baselines, and approved user-to-server deployment contexts

· Optional IIS, SharePoint application, process lineage, identity, vulnerability, patch-state, and asset-criticality enrichment for triage

Engineering Implementation Instructions

Map file, network, DNS, proxy, firewall, EDR, NDR, and flow DSM fields to normalized QRadar custom properties before deployment

· Build QRadar building blocks for SharePoint server scoping, sensitive SharePoint file paths, suspicious file activity, rare outbound communication, approved deployment activity, and approved destination suppression

· Require same-host or equivalent normalized host lineage between suspicious file activity and outbound communication

· Suppress approved patching, deployment, customization, backup, monitoring, indexing, maintenance, Microsoft, update, proxy, security-tool, and business integration activity

· Use reference maps for approved source-to-destination relationships rather than comparing a destination host to a generic flow list

· Reserve AQL for supporting hunts and performance validation unless local QRadar deployment supports the required correlation at scale

· Promote to production only after validating DSM parsing, custom properties, reference data, event volume, offense grouping, false-positive suppressions, and SOC triage workflow

DRI Assessment

This rule has strong detection value because suspicious file staging followed by rare outbound communication is a durable post-exploitation behavior across webshell placement, payload staging, and tool deployment workflows. It is resilient against file-name and infrastructure changes because it emphasizes path, extension, process context, user context, destination rarity, and sequence. Its main weakness is that legitimate SharePoint deployment, patching, backup, or customization activity may resemble the behavior when reference data is incomplete.

DRI

8.4

TCR Assessment

Operational coverage is strong when QRadar receives file telemetry and network telemetry from SharePoint servers with reliable host correlation. Full-telemetry coverage improves when IIS logs, SharePoint application logs, process telemetry, identity events, DNS, proxy, firewall, vulnerability context, and asset-criticality enrichment are available.

Operational TCR

7.8

Full-Telemetry TCR

8.7

Limitations

Requires reliable file telemetry from SharePoint and IIS paths

· Requires reliable network telemetry and destination baselines for SharePoint servers

· May miss memory-only execution that does not create durable file artifacts

· May miss activity where outbound communication remains internal or uses approved egress paths

· May over-alert during patching, deployment, customization, backup, monitoring, indexing, or maintenance workflows

· Requires local DSM parsing, custom-property, reference-set, reference-map, building-block, and offense-rule validation before deployment

Detection Query Pattern

WHEN events are detected for the same normalized SharePoint server, same backend host, same destination host, same asset ID, or equivalent normalized host lineage

WITHIN ENV_SHAREPOINT_FILE_TO_OUTBOUND_WINDOW

AND SharePoint_Server is contained in reference set ENV_SHAREPOINT_SERVERS

AND SharePoint_File_Activity_Time occurs before SharePoint_Outbound_Communication_Time

AND SharePoint_Outbound_Communication_Time occurs within ENV_SHAREPOINT_FILE_TO_OUTBOUND_WINDOW after SharePoint_File_Activity_Time

AND (

File_Path matches any pattern in reference set ENV_SHAREPOINT_SENSITIVE_PATH_PATTERNS

OR File_Path is contained in reference set ENV_SHAREPOINT_SENSITIVE_PATHS

)

AND (

File_Extension is contained in reference set ENV_SHAREPOINT_SUSPICIOUS_FILE_EXTENSIONS

OR File_Name matches any pattern in reference set ENV_SHAREPOINT_SUSPICIOUS_FILE_NAME_PATTERNS

OR File_Path is not contained in reference set ENV_SHAREPOINT_APPROVED_DEPLOYMENT_PATHS

OR File_Hash is not contained in reference set ENV_SHAREPOINT_APPROVED_FILE_HASHES

OR File_Size is greater than ENV_SHAREPOINT_FILE_SIZE_BASELINE

)

AND (

Process_Name is contained in reference set ENV_SHAREPOINT_FILE_STAGING_PROCESSES

OR Parent_Process_Name is contained in reference set ENV_SHAREPOINT_FILE_STAGING_PARENT_PROCESSES

OR Process_User is contained in reference set ENV_SHAREPOINT_APP_POOL_IDENTITIES

OR Process_User is contained in reference set ENV_SHAREPOINT_SERVICE_ACCOUNTS

)

AND (

Destination_Domain is not contained in reference set ENV_SHAREPOINT_APPROVED_DESTINATIONS

OR Destination_IP is not contained in reference set ENV_SHAREPOINT_APPROVED_DESTINATIONS

OR Destination_Port is not contained in reference set ENV_SHAREPOINT_APPROVED_EGRESS_PORTS

OR DNS_Query is not contained in reference map ENV_SHAREPOINT_DNS_BASELINE for SharePoint_Server

OR Destination_Category is contained in reference set ENV_SHAREPOINT_SUSPICIOUS_DESTINATION_CATEGORIES

OR Destination_Reputation is contained in reference set ENV_SUSPICIOUS_OR_LOW_REPUTATION_DESTINATIONS

OR Bytes_Out is greater than ENV_SHAREPOINT_SERVER_OUTBOUND_BASELINE

OR Source_Destination_Protocol_Tuple is not contained in reference map ENV_SHAREPOINT_APPROVED_SOURCE_DESTINATION_PROTOCOL_TUPLES for SharePoint_Server

)

AND NOT (

SharePoint_Server is contained in reference set ENV_SHAREPOINT_PATCHING_OR_DEPLOYMENT_TARGETS

AND Event_Time is contained in reference map ENV_SHAREPOINT_APPROVED_PATCHING_OR_DEPLOYMENT_WINDOWS for SharePoint_Server

AND Process_Name is contained in reference set ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_BACKUP_TOOLS

AND Process_User is contained in reference set ENV_SHAREPOINT_APPROVED_DEPLOYMENT_OR_ADMIN_USERS

)

AND NOT (

SharePoint_Server is contained in reference set ENV_SHAREPOINT_BACKUP_OR_MONITORING_TARGETS

AND Destination_Domain is contained in reference set ENV_SHAREPOINT_APPROVED_BACKUP_OR_MONITORING_DESTINATIONS

AND Process_Name is contained in reference set ENV_SHAREPOINT_APPROVED_BACKUP_OR_MONITORING_PROCESSES

AND Process_User is contained in reference set ENV_SHAREPOINT_APPROVED_BACKUP_OR_MONITORING_USERS

)

AND NOT (

SharePoint_Server is contained in reference set ENV_SHAREPOINT_APPROVED_INTEGRATION_TARGETS

AND Destination_Domain is contained in reference map ENV_SHAREPOINT_APPROVED_INTEGRATION_DESTINATIONS for SharePoint_Server

AND Source_Destination_Protocol_Tuple is contained in reference map ENV_SHAREPOINT_APPROVED_SOURCE_DESTINATION_PROTOCOL_TUPLES for SharePoint_Server

)

AND SharePoint_Server is not contained in reference set ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

THEN generate offense with context:

SharePoint_Server,

Host_Role,

Exposure_State,

Asset_Criticality,

SharePoint_File_Activity_Time,

SharePoint_Outbound_Communication_Time,

File_Path,

File_Name,

File_Extension,

File_Hash,

File_Size,

Process_User,

Parent_Process_Name,

Process_Name,

Command_Line,

Destination_IP,

Destination_Domain,

Destination_Port,

Protocol,

Destination_Category,

Destination_Reputation,

DNS_Query,

Bytes_Out,

Source_Destination_Protocol_Tuple,

Offense_Grouping_Key,

Time_Delta

SIGMA

Rule

SharePoint IIS Worker Process Suspicious Child Process Execution

Rule Format

SIGMA event-rule template

Detection Purpose

Detect suspicious command execution, scripting, download activity, reconnaissance, or living-off-the-land behavior launched from SharePoint or IIS worker process context

Detection Logic

This SIGMA template identifies endpoint events where SharePoint or IIS worker process context produces suspicious child process execution. It is designed as a portable event-rule template for detecting likely post-exploitation behavior from SharePoint servers. This rule does not provide full behavior-chain correlation by itself and must be mapped into a SIEM backend with SharePoint server scoping, approved workflow exceptions, and local field mapping.

Required Telemetry

Windows process creation telemetry, Sysmon Event ID 1, EDR process events, or equivalent endpoint process telemetry

· Parent process name, process name, command line, process path, parent process path, user context, host name, and event time

· Local enrichment fields identifying SharePoint servers, IIS-hosted SharePoint servers, SharePoint application servers, application pool identities, service accounts, approved child processes, approved administrative command lines, and approved maintenance windows

· Backend SIEM correlation for IIS, SharePoint, identity, file, network, vulnerability, and asset-priority context where available

Engineering Implementation Instructions

Treat this as a SIGMA event-rule template only

· Map all fields, enrichment fields, exception fields, product names, service names, and backend conversion logic to the target SIEM before deployment

· Scope the converted rule to confirmed SharePoint and IIS-hosted SharePoint servers using asset enrichment, host tags, or lookup-backed filtering

· Use SIEM-native correlation to connect this event rule with SharePoint request anomalies, file staging, outbound communication, identity activity, and vulnerability context

· Suppress approved SharePoint administration, patching, backup, monitoring, indexing, deployment, maintenance, and service-account automation

· Do not represent this SIGMA rule as full request-to-execution correlation without backend-specific sequence logic

· Promote to alert mode only after backend conversion, field mapping, enrichment creation, exception validation, and false-positive testing are complete

DRI Assessment

This rule has strong event-level detection value because w3wp.exe or SharePoint service context launching suspicious command interpreters, scripting engines, download utilities, archive utilities, or reconnaissance tools is a durable post-exploitation signal. It is resilient against exploit-string changes because it focuses on execution behavior. Its main weakness is that SIGMA alone cannot express the full SharePoint request-to-execution chain without backend correlation.

DRI

8.1

TCR Assessment

Operational coverage is moderate to strong when converted into a SIEM with reliable process telemetry and SharePoint asset enrichment. Full-telemetry coverage requires SIEM-native correlation with IIS logs, SharePoint application logs, file telemetry, network telemetry, identity telemetry, and exception lists.

Operational TCR

7.4

Full-Telemetry TCR

8.5

Limitations

SIGMA cannot reliably express full temporal request-to-execution correlation across web and endpoint telemetry by itself

· Requires backend field mapping and local enrichment for SharePoint server scoping

· May over-alert without approved child-process, command-line, service-account, and maintenance exceptions

· May miss in-memory activity that does not create observable child processes

· Does not prove the initial exploit path without IIS, SharePoint, identity, application, vulnerability, or network corroboration

· Backend conversion and SIEM-native correlation are required before production deployment

Detection Query Pattern

Use this as a SIGMA event-rule template. Map all fields and local enrichment fields to the target SIEM before deployment.

title: SharePoint IIS Worker Process Suspicious Child Process Execution

id: 3e0c5995-2e22-45c1-b2f9-1f6fd3fffd41

status: experimental

description: Detects suspicious command execution, scripting, download activity, reconnaissance, or living-off-the-land behavior launched from SharePoint or IIS worker process context.

references:

- Internal CyberDax detection model for SharePoint Server RCE and IIS worker process post-exploitation detection coverage

author: CyberDax

date: 2026-07-02

logsource:

product: windows

category: process_creation

detection:

scope_sharepoint_server:

cyberdax.asset.sharepoint_server: true

parent_iis_worker:

ParentImage|endswith:

- '\w3wp.exe'

- '\owstimer.exe'

parent_sharepoint_path:

ParentImage|contains:

- '\inetpub\'

- '\Microsoft Office Servers\'

- '\Web Server Extensions\'

- '\SharePoint\'

sharepoint_service_user:

cyberdax.identity.sharepoint_app_pool_identity: true

suspicious_child_process:

Image|endswith:

- '\cmd.exe'

- '\powershell.exe'

- '\pwsh.exe'

- '\cscript.exe'

- '\wscript.exe'

- '\mshta.exe'

- '\rundll32.exe'

- '\regsvr32.exe'

- '\certutil.exe'

- '\bitsadmin.exe'

- '\curl.exe'

- '\wget.exe'

- '\whoami.exe'

- '\net.exe'

- '\nltest.exe'

- '\ipconfig.exe'

- '\systeminfo.exe'

- '\tasklist.exe'

- '\quser.exe'

- '\ping.exe'

- '\nslookup.exe'

- '\tar.exe'

- '\7z.exe'

- '\rar.exe'

suspicious_command_line:

CommandLine|contains:

- '-enc'

- '-encodedcommand'

- 'downloadstring'

- 'invoke-webrequest'

- 'invoke-expression'

- 'frombase64string'

- 'certutil'

- 'bitsadmin'

- 'curl'

- 'wget'

- ' iwr '

- ' iex '

- 'whoami'

- 'nltest'

- 'net group'

- 'net user'

- 'systeminfo'

- 'tasklist'

- 'quser'

filter_approved_child_process:

cyberdax.exception.sharepoint_approved_child_process: true

filter_approved_admin_command:

cyberdax.exception.sharepoint_approved_admin_command_line: true

filter_approved_admin_user:

cyberdax.exception.sharepoint_approved_admin_or_service_user: true

filter_approved_maintenance_window:

cyberdax.exception.sharepoint_approved_maintenance_window: true

condition: scope_sharepoint_server and (1 of parent_* or sharepoint_service_user) and (suspicious_child_process or suspicious_command_line) and not 1 of filter_*

fields:

- host.name

- user.name

- ParentImage

- Image

- CommandLine

- Hashes

- ProcessId

- ParentProcessId

- cyberdax.asset.sharepoint_server

- cyberdax.identity.sharepoint_app_pool_identity

- event.created

falsepositives:

- Approved SharePoint maintenance script launched from service context

- Approved backup or monitoring agent activity

- Approved patching, indexing, deployment, or administrative workflow

- Approved SharePoint customization or migration tooling

level: high

Rule

SharePoint Webroot Suspicious File Staging

Rule Format

SIGMA event-rule template

Detection Purpose

Detect suspicious file creation or modification in SharePoint, IIS, webroot, layout, upload, temporary, staging, or application-adjacent directories

Detection Logic

This SIGMA template identifies suspicious file creation or modification events in SharePoint and IIS-accessible paths. It is intended to detect possible webshell placement, payload staging, tool placement, script staging, archive creation, or post-exploitation artifact deployment. This rule does not provide full file-to-outbound or request-to-file correlation by itself and must be mapped into a SIEM backend with SharePoint server scoping, approved workflow exceptions, and local field mapping.

Required Telemetry

Windows file creation telemetry, Sysmon Event ID 11, EDR file telemetry, or equivalent endpoint file-monitoring telemetry

· File path, file name, file extension, file hash, file size, process name, parent process name, command line, user context, host name, and event time

· Local enrichment fields identifying SharePoint servers, sensitive SharePoint paths, approved deployment paths, approved file hashes, approved deployment tools, approved administrative users, and approved patching or deployment windows

· Backend SIEM correlation for process lineage, IIS requests, SharePoint application logs, outbound communication, identity activity, and repeated access to newly created artifacts

Engineering Implementation Instructions

Treat this as a SIGMA event-rule template only

· Map all fields, enrichment fields, exception fields, product names, service names, and backend conversion logic to the target SIEM before deployment

· Scope the converted rule to confirmed SharePoint and IIS-hosted SharePoint servers using asset enrichment, host tags, or lookup-backed filtering

· Use SIEM-native correlation to connect this event rule with request anomalies, process execution, outbound communication, identity activity, and post-creation access behavior

· Suppress approved patching, deployment, customization, backup, monitoring, indexing, maintenance, and administrative workflows

· Do not represent this SIGMA rule as full file-to-outbound or request-to-file correlation without backend-specific sequence logic

· Promote to alert mode only after backend conversion, field mapping, enrichment creation, exception validation, and false-positive testing are complete

DRI Assessment

This rule has strong event-level detection value because suspicious file creation in SharePoint or IIS-accessible paths is a durable post-exploitation indicator across webshell placement, payload staging, and tool deployment behavior. It is resilient against specific file names because it focuses on path, extension, user context, and enrichment. Its main weakness is that SIGMA alone cannot correlate file staging with prior SharePoint request activity or subsequent outbound communication without backend-specific SIEM logic.

DRI

7.9

TCR Assessment

Operational coverage is moderate to strong when converted into a SIEM with reliable file telemetry and SharePoint asset enrichment. Full-telemetry coverage requires SIEM-native correlation with process lineage, IIS logs, SharePoint application logs, outbound communication, identity telemetry, and exception lists.

Operational TCR

7.2

Full-Telemetry TCR

8.3

Limitations

SIGMA cannot reliably express full temporal file-to-outbound or request-to-file correlation by itself

· Requires backend field mapping and local enrichment for SharePoint server scoping

· May over-alert during approved patching, deployment, customization, backup, monitoring, indexing, or maintenance workflows

· May miss memory-resident execution that does not create durable file artifacts

· May miss artifacts created and deleted before file telemetry collection

· Backend conversion and SIEM-native correlation are required before production deployment

Detection Query Pattern

Use this as a SIGMA event-rule template. Map all fields and local enrichment fields to the target SIEM before deployment.

title: SharePoint Webroot Suspicious File Staging

id: 4f3c5a65-78fd-43b5-a6f5-dbe0d89960b6

status: experimental

description: Detects suspicious file creation or modification in SharePoint, IIS, webroot, layout, upload, temporary, staging, or application-adjacent directories.

references:

- Internal CyberDax detection model for SharePoint Server RCE and IIS worker process post-exploitation detection coverage

author: CyberDax

date: 2026-07-02

logsource:

product: windows

category: file_event

detection:

scope_sharepoint_server:

cyberdax.asset.sharepoint_server: true

sharepoint_sensitive_path:

TargetFilename|contains:

- '\inetpub\wwwroot\'

- '\inetpub\temp\'

- '\Microsoft Shared\Web Server Extensions\'

- '\Microsoft Office Servers\'

- '\SharePoint\'

- '\TEMPLATE\LAYOUTS\'

- '\TEMPLATE\CONTROLTEMPLATES\'

- '\_layouts\'

- '\_vti_bin\'

- '\App_Data\'

- '\Temp\'

suspicious_file_extension:

TargetFilename|endswith:

- '.aspx'

- '.ashx'

- '.asmx'

- '.dll'

- '.exe'

- '.ps1'

- '.js'

- '.vbs'

- '.bat'

- '.cmd'

- '.zip'

- '.7z'

- '.rar'

- '.tmp'

- '.config'

- '.xml'

suspicious_process_context:

Image|endswith:

- '\w3wp.exe'

- '\cmd.exe'

- '\powershell.exe'

- '\pwsh.exe'

- '\cscript.exe'

- '\wscript.exe'

- '\mshta.exe'

- '\rundll32.exe'

- '\regsvr32.exe'

- '\certutil.exe'

- '\bitsadmin.exe'

suspicious_parent_context:

ParentImage|endswith:

- '\w3wp.exe'

- '\cmd.exe'

- '\powershell.exe'

- '\pwsh.exe'

- '\cscript.exe'

- '\wscript.exe'

- '\mshta.exe'

sharepoint_service_user:

cyberdax.identity.sharepoint_app_pool_identity: true

unapproved_deployment_path:

cyberdax.baseline.sharepoint_approved_deployment_path: false

unapproved_file_hash:

cyberdax.baseline.sharepoint_approved_file_hash: false

filter_approved_deployment_tool:

cyberdax.exception.sharepoint_approved_deployment_or_backup_tool: true

filter_approved_deployment_user:

cyberdax.exception.sharepoint_approved_deployment_or_admin_user: true

filter_approved_patching_window:

cyberdax.exception.sharepoint_approved_patching_or_deployment_window: true

filter_approved_customization:

cyberdax.exception.sharepoint_approved_customization_workflow: true

condition: scope_sharepoint_server and sharepoint_sensitive_path and (suspicious_file_extension or unapproved_deployment_path or unapproved_file_hash) and (suspicious_process_context or suspicious_parent_context or sharepoint_service_user) and not 1 of filter_*

fields:

- host.name

- user.name

- Image

- ParentImage

- CommandLine

- TargetFilename

- Hashes

- cyberdax.asset.sharepoint_server

- cyberdax.identity.sharepoint_app_pool_identity

- event.created

falsepositives:

- Approved SharePoint patching or cumulative update activity

- Approved SharePoint deployment, customization, or migration workflow

- Approved backup, monitoring, or indexing activity

- Approved administrator file deployment in a validated maintenance window

level: high

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, endpoint-driven, network-behavior driven, SIEM-correlation based, identity-context based, and downstream cloud-correlation based rather than static-file or malware-signature based.

YARA may provide limited supporting value only if a confirmed malicious artifact, webshell body, payload structure, encoded artifact, loader, dropper, script artifact, archive artifact, memory artifact, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Rule

Conditional SharePoint-to-AWS Identity and Control-Plane Correlation

Rule Format

AWS downstream correlation pseudologic

Detection Purpose

Detect suspicious AWS control-plane, identity, access-key, storage, secrets, or security-control activity that occurs after SharePoint Server compromise indicators when identity, source, device, session, or infrastructure lineage connects the AWS activity to the SharePoint incident context

Detection Logic

This rule correlates SharePoint Server post-exploitation context with AWS activity that may indicate downstream cloud access, federated identity abuse, credential reuse, access-key misuse, or attacker expansion into AWS resources. The detection is conditional because SharePoint telemetry alone does not prove AWS compromise. High-confidence detections require a SharePoint compromise or post-exploitation context, AWS CloudTrail or security finding activity within a bounded window, identity or source lineage between the SharePoint-side context and AWS-side activity, risky AWS event types, and suppression of approved automation, CI/CD, break-glass, and security-tooling workflows.

Required Telemetry

AWS CloudTrail management events, CloudTrail data events, IAM Identity Center events, STS events, IAM events, S3 data events, Secrets Manager events, KMS events, Organizations events, Config events, GuardDuty findings, Security Hub findings, and VPC flow or proxy context where available

· Normalized SharePoint incident context derived from IIS logs, SharePoint application logs, EDR telemetry, SIEM alerts, file telemetry, network telemetry, identity telemetry, proxy telemetry, vulnerability context, and incident-response case context

· Identity context mapping SharePoint service accounts, administrator accounts, federated users, IAM Identity Center users, role ARNs, AWS account IDs, source IPs, device identifiers, session identifiers, and identity-provider attributes

· Approved-role, approved-source, approved-region, approved-account, approved-user-agent, approved-event, approved-resource, automation, CI/CD, IaC, security-tooling, and break-glass allowlists

· Sensitive AWS resource inventories for privileged IAM roles, access keys, KMS keys, secrets, S3 buckets, Organizations resources, CloudTrail trails, security controls, production workloads, and regulated data repositories

Engineering Implementation Instructions

Treat AWS coverage as conditional downstream correlation only, not as primary SharePoint exploit detection

· Build a normalized SharePoint compromise context view before enabling AWS correlation

· Map all CloudTrail fields, IAM Identity Center fields, STS fields, GuardDuty findings, Security Hub findings, AWS Config fields, identity-provider fields, source context, and local enrichment fields to the target AWS analytics or SIEM environment

· Require identity, source IP, device, session, federated identity, administrator account, role, or incident-case lineage between SharePoint-side context and AWS activity before alert promotion

· Prioritize IAM privilege escalation, access-key creation, role assumption, CloudTrail modification, GuardDuty or Security Hub suppression, S3 enumeration, S3 data access, Secrets Manager access, KMS access, Organizations administration, and suspicious region or account access

· Suppress approved automation, CI/CD, IaC, security tooling, monitoring, backup, deployment, and break-glass activity only when source, identity, event, and resource context all match the approved workflow

· Promote to alert mode only after validating identity joins, time windows, role baselines, source baselines, event baselines, resource criticality, and false-positive suppressions

DRI Assessment

This rule has moderate detection value because it detects potential cloud expansion after SharePoint compromise only when identity or source lineage connects SharePoint-side context to AWS-side activity. It is valuable for organizations where SharePoint administrators, service accounts, or compromised endpoints have federated access into AWS. Its main weakness is that AWS telemetry cannot independently prove SharePoint exploitation and may be unrelated unless strong identity, session, source, or incident-case linkage exists.

DRI

7.6

TCR Assessment

Operational coverage is conditional and depends on whether AWS activity can be linked to SharePoint-side identity, source, device, session, or incident context. Full-telemetry coverage improves when CloudTrail, GuardDuty, Security Hub, AWS Config, IAM Identity Center, identity-provider logs, proxy logs, EDR telemetry, and SIEM case context are available.

Operational TCR

6.8

Full-Telemetry TCR

8.1

Limitations

Conditional downstream correlation only; this rule does not detect SharePoint exploitation directly

· Requires reliable identity, source, session, device, role, or incident-case linkage between SharePoint context and AWS activity

· May miss AWS compromise where the attacker uses unrelated credentials, unrelated infrastructure, or delayed access outside the correlation window

· May over-alert in environments with frequent automation, CI/CD, IaC, security-tooling, or break-glass workflows

· Requires accurate sensitive-resource inventories and role/user baselines

· Requires local mapping of AWS fields, identity fields, enrichment views, and suppression logic before deployment

Detection Query Pattern

Use this pattern as implementation-ready AWS correlation pseudologic and map all CloudTrail fields, identity fields, SharePoint incident-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, and time windows to the target AWS analytics or SIEM environment before deployment. sharepoint_compromise_context represents a normalized correlation view derived from IIS logs, SharePoint application logs, EDR telemetry, SIEM alerts, file telemetry, network telemetry, proxy telemetry, identity-provider context, vulnerability context, help desk context, SOAR context, and incident-response case context. Local teams must create, map, or enrich this view before deploying the AWS correlation pattern.

FROM aws_cloudtrail_management_events,

aws_cloudtrail_data_events,

aws_guardduty_findings,

aws_securityhub_findings,

aws_config_events,

aws_organizations_events,

aws_iam_identity_center_events,

identity_context,

sharepoint_compromise_context

WHERE aws.user_identity_arn IS NOT NULL

AND sharepoint_compromise_context.event_time IS NOT NULL

AND aws.event_time BETWEEN sharepoint_compromise_context.event_time AND sharepoint_compromise_context.event_time + ENV_SHAREPOINT_TO_AWS_WINDOW

AND sharepoint_compromise_context.type IN (

"sharepoint_request_to_process_execution",

"sharepoint_worker_process_child_execution",

"sharepoint_webroot_file_staging",

"sharepoint_rare_outbound_communication",

"sharepoint_internal_expansion",

"sharepoint_service_account_anomaly",

"sharepoint_webshell_or_payload_staging",

"sharepoint_post_exploitation_case",

"sharepoint_high_confidence_edr_alert",

"sharepoint_high_confidence_siem_alert",

"sharepoint_incident_response_case"

)

AND (

sharepoint_compromise_context.normalized_user_id = aws.normalized_user_id

OR sharepoint_compromise_context.user_principal_name = aws.federated_user_principal_name

OR sharepoint_compromise_context.source_ip = aws.source_ip

OR sharepoint_compromise_context.device_id = aws.device_id

OR sharepoint_compromise_context.session_id = aws.session_id

OR sharepoint_compromise_context.federated_identity_id = aws.federated_identity_id

OR sharepoint_compromise_context.identity_provider_account = aws.identity_provider_account

OR sharepoint_compromise_context.iam_identity_center_user = aws.iam_identity_center_user

OR sharepoint_compromise_context.case_id = aws.security_case_id

)

AND (

aws.event_name IN ENV_SUSPICIOUS_AWS_FEDERATED_ACCESS_EVENTS

OR aws.event_name IN ENV_SUSPICIOUS_AWS_ADMIN_EVENTS

OR aws.event_name IN ENV_AWS_IAM_PRIVILEGE_ESCALATION_EVENTS

OR aws.event_name IN ENV_AWS_ACCESS_KEY_EVENTS

OR aws.event_name IN ENV_AWS_SECURITY_CONTROL_MODIFICATION_EVENTS

OR aws.event_name IN ENV_AWS_LOGGING_MODIFICATION_EVENTS

OR aws.event_name IN ENV_AWS_SENSITIVE_DATA_ACCESS_EVENTS

OR aws.event_name IN ENV_AWS_S3_ENUMERATION_OR_EXFILTRATION_EVENTS

OR aws.event_name IN ENV_AWS_SECRETS_OR_KMS_ACCESS_EVENTS

OR aws.event_name IN ENV_AWS_ORGANIZATIONS_ADMIN_EVENTS

OR aws.guardduty_finding_type IN ENV_RELEVANT_GUARDDUTY_FINDINGS

OR aws.securityhub_finding_type IN ENV_RELEVANT_SECURITYHUB_FINDINGS

OR aws.config_change_type IN ENV_AWS_SECURITY_RELEVANT_CONFIG_CHANGES

)

AND (

aws.source_ip NOT IN ENV_APPROVED_AWS_ADMIN_SOURCE_IPS

OR aws.user_agent NOT IN ENV_EXPECTED_AWS_USER_AGENTS_BY_ROLE

OR aws.aws_region NOT IN ENV_EXPECTED_AWS_REGIONS_BY_ROLE

OR aws.role_arn NOT IN ENV_EXPECTED_AWS_ROLES_BY_USER

OR aws.account_id NOT IN ENV_EXPECTED_AWS_ACCOUNTS_BY_USER

OR aws.access_key_id IS NEW_FOR aws.normalized_user_id WITHIN ENV_ACCESS_KEY_NOVELTY_WINDOW

OR aws.event_name IN ENV_HIGH_RISK_AWS_EVENTS_REQUIRING_REVIEW

OR aws.resource_id IN ENV_SENSITIVE_AWS_RESOURCES

OR aws.role_arn IN ENV_PRIVILEGED_AWS_ROLES

OR aws.account_id IN ENV_PRODUCTION_OR_REGULATED_AWS_ACCOUNTS

)

AND NOT (

aws.user_identity_arn IN ENV_APPROVED_AWS_AUTOMATION_IDENTITIES

AND aws.source_ip IN ENV_APPROVED_AWS_AUTOMATION_SOURCE_IPS

AND aws.event_name IN ENV_APPROVED_AWS_AUTOMATION_EVENTS

AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

aws.role_arn IN ENV_APPROVED_CICD_OR_IAC_ROLES

AND aws.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS

AND aws.event_name IN ENV_APPROVED_CICD_OR_IAC_EVENTS

AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

aws.user_identity_arn IN ENV_APPROVED_BREAK_GLASS_IDENTITIES

AND aws.source_ip IN ENV_APPROVED_BREAK_GLASS_SOURCE_IPS

AND aws.event_name IN ENV_APPROVED_BREAK_GLASS_EVENTS

AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

aws.user_identity_arn IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES

AND aws.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS

AND aws.event_name IN ENV_APPROVED_SECURITY_TOOLING_EVENTS

AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW

)

AND aws.user_identity_arn NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

GROUP BY aws.account_id,

aws.normalized_user_id,

aws.user_identity_arn,

aws.role_arn,

aws.source_ip,

aws.user_agent,

aws.aws_region,

aws.event_name,

sharepoint_compromise_context.type

EMIT alert WHEN

count_distinct(aws.event_name) >= ENV_MIN_DISTINCT_AWS_RISK_EVENTS

OR aws.event_name IN ENV_HIGH_RISK_AWS_EVENTS_REQUIRING_REVIEW

OR aws.access_key_id IS NEW_FOR aws.normalized_user_id WITHIN ENV_ACCESS_KEY_NOVELTY_WINDOW

OR aws.guardduty_finding_type IN ENV_RELEVANT_GUARDDUTY_FINDINGS

OR aws.securityhub_finding_type IN ENV_RELEVANT_SECURITYHUB_FINDINGS

OR aws.config_change_type IN ENV_AWS_SECURITY_RELEVANT_CONFIG_CHANGES

Azure

Rule

Conditional SharePoint-to-Azure Identity and Control-Plane Correlation

Rule Format

Azure downstream correlation pseudologic

Detection Purpose

Detect suspicious Azure control-plane, identity, privileged-access, Key Vault, storage, logging, security-control, or network-exposure activity that occurs after SharePoint Server compromise indicators when identity, source, device, session, service-principal, or incident-case lineage connects the Azure activity to the SharePoint incident context

Detection Logic

This rule correlates SharePoint Server post-exploitation context with Azure cloud activity that may indicate downstream identity abuse, privileged access, service-principal misuse, resource access, data access, or cloud-control modification. The detection is conditional because SharePoint telemetry alone does not prove Azure compromise. High-confidence detections require a SharePoint compromise or post-exploitation context, Azure cloud-resource or Entra activity within a bounded window, identity or source lineage between SharePoint-side context and Azure-side activity, risky Azure operation types, and suppression of approved automation, service-principal, break-glass, and security-tooling workflows.

Required Telemetry

Azure Activity Logs, Azure Resource Manager activity, Entra ID audit logs, Entra ID sign-in logs, Privileged Identity Management events, Azure Key Vault logs, Azure Storage logs, Defender for Cloud events, Sentinel administrative events, Azure Policy events, diagnostic-setting events, network security group events, and identity-provider context where available

· Normalized SharePoint incident context derived from IIS logs, SharePoint application logs, EDR telemetry, SIEM alerts, file telemetry, network telemetry, proxy telemetry, identity telemetry, vulnerability context, and incident-response case context

· Identity context mapping SharePoint service accounts, administrator accounts, Entra users, federated users, service principals, managed identities, Azure roles, tenant IDs, subscription IDs, source IPs, device identifiers, session identifiers, and correlation IDs

· Approved-role, approved-source, approved-subscription, approved-resource-group, approved-resource, approved-user-agent, approved-operation, automation, service-principal, managed-identity, security-tooling, and break-glass allowlists

· Sensitive Azure resource inventories for privileged roles, management groups, subscriptions, Key Vaults, secrets, certificates, storage accounts, Sentinel workspaces, Defender for Cloud settings, diagnostic settings, production workloads, and regulated data repositories

Engineering Implementation Instructions

Treat Azure coverage as conditional downstream correlation only, not as primary SharePoint exploit detection

· Build a normalized SharePoint compromise context view before enabling Azure correlation

· Map all Azure Activity Log fields, Entra fields, PIM fields, Key Vault fields, Storage fields, Defender for Cloud fields, Sentinel administrative fields, identity-provider fields, source context, and local enrichment fields to the target Sentinel, SIEM, data-lake, or analytics environment

· Require identity, source IP, device, session, service principal, managed identity, administrator account, correlation ID, or incident-case lineage between SharePoint-side context and Azure activity before alert promotion

· Prioritize role assignment, policy modification, service-principal credential activity, Key Vault secret access, storage access, diagnostic-setting modification, logging modification, Defender for Cloud suppression, Sentinel administration, network exposure changes, management-group changes, and subscription-level administration

· Suppress approved automation, service-principal, managed-identity, CI/CD, IaC, security tooling, monitoring, backup, deployment, and break-glass activity only when source, identity, operation, and resource context all match the approved workflow

· Promote to alert mode only after validating identity joins, time windows, source baselines, role baselines, subscription baselines, resource criticality, operation baselines, and false-positive suppressions

DRI Assessment

This rule has moderate detection value because it detects potential Azure expansion after SharePoint compromise only when identity, source, session, service-principal, device, or incident-case lineage connects SharePoint-side context to Azure-side activity. It is valuable for organizations where SharePoint administrators, service accounts, privileged endpoints, or hybrid identity infrastructure have access to Azure control-plane resources. Its main weakness is that Azure telemetry cannot independently prove SharePoint exploitation and may be unrelated unless strong lineage exists.

DRI

7.7

TCR Assessment

Operational coverage is conditional and depends on whether Azure activity can be linked to SharePoint-side identity, source, device, session, service-principal, correlation, or incident context. Full-telemetry coverage improves when Azure Activity Logs, Entra logs, PIM, Key Vault, Storage, Defender for Cloud, Sentinel, identity-provider logs, proxy logs, EDR telemetry, and SIEM case context are available.

Operational TCR

6.9

Full-Telemetry TCR

8.2

Limitations

Conditional downstream correlation only; this rule does not detect SharePoint exploitation directly

· Requires reliable identity, source, session, device, service-principal, correlation, or incident-case linkage between SharePoint context and Azure activity

· May miss Azure compromise where the attacker uses unrelated credentials, unrelated infrastructure, or delayed access outside the correlation window

· May over-alert in environments with frequent automation, CI/CD, IaC, service-principal, managed-identity, security-tooling, or break-glass workflows

· Requires accurate sensitive-resource inventories, subscription baselines, role baselines, operation baselines, and source baselines

· Requires local mapping of Azure fields, Entra fields, enrichment views, resource baselines, and suppression logic before deployment

Detection Query Pattern

Use this pattern as implementation-ready Azure cloud correlation pseudologic and map all Azure Activity Log fields, Entra fields, cloud-resource fields, SharePoint incident-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, and time windows to the target Sentinel, SIEM, data-lake, or analytics environment before deployment. sharepoint_compromise_context represents a normalized correlation view derived from IIS logs, SharePoint application logs, EDR telemetry, SIEM alerts, file telemetry, network telemetry, proxy telemetry, identity-provider context, vulnerability context, help desk context, SOAR context, and incident-response case context. azure_cloud_activity represents a normalized Azure cloud-resource activity view derived from Azure Activity Logs, Azure Resource Manager activity, Entra ID audit logs, Privileged Identity Management events, Azure Key Vault logs, Azure Storage logs, Defender for Cloud events, Sentinel administrative events, identity context, VPN context, proxy context, and endpoint context. Local teams must create, map, or enrich both views before deploying the Azure cloud correlation pattern.

FROM azure_cloud_activity,

sharepoint_compromise_context

WHERE azure_cloud_activity.user_identity IS NOT NULL

AND sharepoint_compromise_context.event_time IS NOT NULL

AND azure_cloud_activity.event_time BETWEEN sharepoint_compromise_context.event_time AND sharepoint_compromise_context.event_time + ENV_SHAREPOINT_TO_AZURE_CLOUD_WINDOW

AND sharepoint_compromise_context.type IN (

"sharepoint_request_to_process_execution",

"sharepoint_worker_process_child_execution",

"sharepoint_webroot_file_staging",

"sharepoint_rare_outbound_communication",

"sharepoint_internal_expansion",

"sharepoint_service_account_anomaly",

"sharepoint_webshell_or_payload_staging",

"sharepoint_post_exploitation_case",

"sharepoint_high_confidence_edr_alert",

"sharepoint_high_confidence_siem_alert",

"sharepoint_incident_response_case"

)

AND (

sharepoint_compromise_context.normalized_user_id = azure_cloud_activity.normalized_user_id

OR sharepoint_compromise_context.user_principal_name = azure_cloud_activity.user_principal_name

OR sharepoint_compromise_context.entra_user_id = azure_cloud_activity.entra_user_id

OR sharepoint_compromise_context.source_ip = azure_cloud_activity.source_ip

OR sharepoint_compromise_context.device_id = azure_cloud_activity.device_id

OR sharepoint_compromise_context.session_id = azure_cloud_activity.session_id

OR sharepoint_compromise_context.identity_provider_account = azure_cloud_activity.identity_provider_account

OR sharepoint_compromise_context.service_principal_id = azure_cloud_activity.service_principal_id

OR sharepoint_compromise_context.correlation_id = azure_cloud_activity.correlation_id

OR sharepoint_compromise_context.case_id = azure_cloud_activity.security_case_id

)

AND (

azure_cloud_activity.operation_name IN ENV_SUSPICIOUS_AZURE_ADMIN_OPERATIONS

OR azure_cloud_activity.operation_name IN ENV_AZURE_ROLE_OR_POLICY_CHANGE_OPERATIONS

OR azure_cloud_activity.operation_name IN ENV_AZURE_SERVICE_PRINCIPAL_CREDENTIAL_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_KEY_VAULT_RISK_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_STORAGE_RISK_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_SECURITY_CONTROL_MODIFICATION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_LOGGING_OR_DIAGNOSTIC_MODIFICATION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_SENTINEL_ADMIN_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_DEFENDER_FOR_CLOUD_SUPPRESSION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_NETWORK_EXPOSURE_CHANGE_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_MANAGEMENT_GROUP_OR_SUBSCRIPTION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_PIM_PRIVILEGE_ACTIVATION_OR_ASSIGNMENT_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_MANAGED_IDENTITY_OR_FEDERATED_CREDENTIAL_EVENTS

)

AND (

azure_cloud_activity.source_ip NOT IN ENV_APPROVED_AZURE_ADMIN_SOURCE_IPS

OR azure_cloud_activity.user_agent NOT IN ENV_EXPECTED_AZURE_USER_AGENTS_BY_ROLE

OR azure_cloud_activity.subscription_id NOT IN ENV_EXPECTED_SUBSCRIPTIONS_BY_USER_OR_ROLE

OR azure_cloud_activity.resource_group NOT IN ENV_EXPECTED_RESOURCE_GROUPS_BY_USER_OR_ROLE

OR azure_cloud_activity.resource_id IN ENV_SENSITIVE_AZURE_RESOURCES

OR azure_cloud_activity.operation_name IN ENV_HIGH_RISK_AZURE_EVENTS_REQUIRING_REVIEW

OR azure_cloud_activity.role_definition_id IN ENV_PRIVILEGED_AZURE_ROLES

OR azure_cloud_activity.management_group_id IN ENV_SENSITIVE_AZURE_MANAGEMENT_GROUPS

OR azure_cloud_activity.tenant_id IN ENV_PRODUCTION_OR_REGULATED_AZURE_TENANTS

)

AND NOT (

azure_cloud_activity.user_identity IN ENV_APPROVED_AZURE_AUTOMATION_IDENTITIES

AND azure_cloud_activity.source_ip IN ENV_APPROVED_AZURE_AUTOMATION_SOURCE_IPS

AND azure_cloud_activity.operation_name IN ENV_APPROVED_AZURE_AUTOMATION_OPERATIONS

AND azure_cloud_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

azure_cloud_activity.service_principal_id IN ENV_APPROVED_AZURE_SERVICE_PRINCIPALS

AND azure_cloud_activity.source_ip IN ENV_APPROVED_AZURE_SERVICE_PRINCIPAL_SOURCE_IPS

AND azure_cloud_activity.operation_name IN ENV_APPROVED_AZURE_SERVICE_PRINCIPAL_OPERATIONS

AND azure_cloud_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

azure_cloud_activity.managed_identity_id IN ENV_APPROVED_AZURE_MANAGED_IDENTITIES

AND azure_cloud_activity.operation_name IN ENV_APPROVED_AZURE_MANAGED_IDENTITY_OPERATIONS

AND azure_cloud_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

azure_cloud_activity.user_identity IN ENV_APPROVED_BREAK_GLASS_IDENTITIES

AND azure_cloud_activity.source_ip IN ENV_APPROVED_BREAK_GLASS_SOURCE_IPS

AND azure_cloud_activity.operation_name IN ENV_APPROVED_BREAK_GLASS_OPERATIONS

AND azure_cloud_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW

)

AND NOT (

azure_cloud_activity.user_identity IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES

AND azure_cloud_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS

AND azure_cloud_activity.operation_name IN ENV_APPROVED_SECURITY_TOOLING_OPERATIONS

AND azure_cloud_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW

)

AND azure_cloud_activity.user_identity NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

GROUP BY azure_cloud_activity.tenant_id,

azure_cloud_activity.subscription_id,

azure_cloud_activity.normalized_user_id,

azure_cloud_activity.user_identity,

azure_cloud_activity.service_principal_id,

azure_cloud_activity.managed_identity_id,

azure_cloud_activity.source_ip,

azure_cloud_activity.user_agent,

azure_cloud_activity.operation_name,

sharepoint_compromise_context.type

EMIT alert WHEN

count_distinct(azure_cloud_activity.operation_name) >= ENV_MIN_DISTINCT_AZURE_RISK_EVENTS

OR azure_cloud_activity.operation_name IN ENV_HIGH_RISK_AZURE_EVENTS_REQUIRING_REVIEW

OR azure_cloud_activity.operation_name IN ENV_AZURE_SECURITY_CONTROL_MODIFICATION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_KEY_VAULT_RISK_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_STORAGE_RISK_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_LOGGING_OR_DIAGNOSTIC_MODIFICATION_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_SENTINEL_ADMIN_EVENTS

OR azure_cloud_activity.operation_name IN ENV_AZURE_PIM_PRIVILEGE_ACTIVATION_OR_ASSIGNMENT_EVENTS

GCP

Rule

Conditional SharePoint-to-GCP Identity and Control-Plane Correlation

Rule Format

Google Cloud downstream correlation pseudologic

Detection Purpose

Detect suspicious Google Cloud control-plane, IAM, service-account, storage, Secret Manager, KMS, logging, security-control, or network-exposure activity that occurs after SharePoint Server compromise indicators when identity, source, device, session, service-account, workforce-identity, or incident-case lineage connects the Google Cloud activity to the SharePoint incident context

Detection Logic

This rule correlates SharePoint Server post-exploitation context with Google Cloud activity that may indicate downstream cloud access, federated identity abuse, service-account misuse, credential abuse, privileged access, data access, or cloud-control modification. The detection is conditional because SharePoint telemetry alone does not prove Google Cloud compromise. High-confidence detections require a SharePoint compromise or post-exploitation context, Google Cloud audit or security activity within a bounded window, identity or source lineage between SharePoint-side context and Google Cloud-side activity, risky Google Cloud method types, and suppression of approved automation, service-account, break-glass, and security-tooling workflows.

Required Telemetry

Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Cloud Logging changes, Cloud Monitoring changes, Security Command Center events, Cloud Identity logs, Chronicle context, and identity-provider context where available

· Identity context mapping SharePoint service accounts, administrator accounts, federated users, Google accounts, workforce identity federation subjects, workload identity subjects, service accounts, organization IDs, folder IDs, project IDs, source IPs, device identifiers, session identifiers, and identity-provider attributes

· Approved-role, approved-source, approved-project, approved-resource, approved-user-agent, approved-method, approved-service-account, automation, CI/CD, IaC, security-tooling, and break-glass allowlists

· Sensitive Google Cloud resource inventories for privileged IAM roles, custom roles, service accounts, service-account keys, workload identity pools, workforce identity pools, Secret Manager secrets, KMS keys, Cloud Storage buckets, organization policies, logging sinks, audit configurations, Security Command Center settings, production projects, and regulated data repositories

Engineering Implementation Instructions

Treat Google Cloud coverage as conditional downstream correlation only, not as primary SharePoint exploit detection

· Build a normalized SharePoint compromise context view before enabling Google Cloud correlation

· Map all Google Cloud audit fields, IAM fields, service-account fields, workload identity fields, workforce identity fields, Security Command Center fields, Cloud Storage fields, Secret Manager fields, KMS fields, Cloud Logging fields, identity-provider fields, source context, and local enrichment fields to the target Chronicle, SIEM, data-lake, or analytics environment

· Require identity, source IP, device, session, workforce identity, workload identity, service account, administrator account, project, organization, or incident-case lineage between SharePoint-side context and Google Cloud activity before alert promotion

· Prioritize IAM policy changes, role grants, custom role changes, service-account key creation, service-account impersonation, workload identity changes, workforce identity changes, Secret Manager access, KMS access, Cloud Storage data access, logging modification, monitoring modification, Security Command Center suppression, network exposure changes, project administration, folder administration, and organization-level administration

· Suppress approved automation, service-account, CI/CD, IaC, security tooling, monitoring, backup, deployment, and break-glass activity only when source, identity, method, and resource context all match the approved workflow

· Promote to alert mode only after validating identity joins, time windows, source baselines, role baselines, project baselines, resource criticality, method baselines, and false-positive suppressions

DRI Assessment

This rule has moderate detection value because it detects potential Google Cloud expansion after SharePoint compromise only when identity, source, session, service-account, workforce-identity, workload-identity, project, organization, or incident-case lineage connects SharePoint-side context to Google Cloud-side activity. It is valuable for organizations where SharePoint administrators, service accounts, privileged endpoints, or hybrid identity infrastructure have access to Google Cloud resources. Its main weakness is that Google Cloud telemetry cannot independently prove SharePoint exploitation and may be unrelated unless strong lineage exists.

DRI

7.6

TCR Assessment

Operational coverage is conditional and depends on whether Google Cloud activity can be linked to SharePoint-side identity, source, device, session, service-account, workforce-identity, workload-identity, project, organization, or incident context. Full-telemetry coverage improves when Google Cloud audit logs, IAM logs, Data Access logs, Security Command Center, Cloud Identity, Chronicle, identity-provider logs, proxy logs, EDR telemetry, and SIEM case context are available.

Operational TCR

6.8

Full-Telemetry TCR

8.1

Limitations

Conditional downstream correlation only; this rule does not detect SharePoint exploitation directly

· Requires reliable identity, source, session, device, service-account, workforce-identity, workload-identity, project, organization, or incident-case linkage between SharePoint context and Google Cloud activity

· May miss Google Cloud compromise where the attacker uses unrelated credentials, unrelated infrastructure, or delayed access outside the correlation window

· May over-alert in environments with frequent automation, CI/CD, IaC, service-account, security-tooling, or break-glass workflows

· Requires accurate sensitive-resource inventories, project baselines, role baselines, method baselines, and source baselines

· Requires local mapping of Google Cloud audit fields, identity fields, enrichment views, resource baselines, and suppression logic before deployment

Detection Query Pattern

Use this pattern as implementation-ready Google Cloud correlation pseudologic and map all Google Cloud audit fields, identity fields, cloud-resource fields, SharePoint incident-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, and time windows to the target Chronicle, SIEM, data-lake, or analytics environment before deployment. sharepoint_compromise_context represents a normalized correlation view derived from IIS logs, SharePoint application logs, EDR telemetry, SIEM alerts, file telemetry, network telemetry, proxy telemetry, identity-provider context, vulnerability context, help desk context, SOAR context, and incident-response case context. gcp_cloud_activity represents a normalized Google Cloud activity view derived from Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Security Command Center events, Cloud Identity logs, Chronicle context, identity context, VPN context, proxy context, and endpoint context. Local teams must create, map, or enrich both views before deploying the Google Cloud correlation pattern.

FROM gcp_cloud_activity,

sharepoint_compromise_context

WHERE gcp_cloud_activity.principal_email IS NOT NULL

AND sharepoint_compromise_context.event_time IS NOT NULL

AND gcp_cloud_activity.event_time BETWEEN sharepoint_compromise_context.event_time AND sharepoint_compromise_context.event_time + ENV_SHAREPOINT_TO_GCP_CLOUD_WINDOW

AND sharepoint_compromise_context.type IN (

"sharepoint_request_to_process_execution",

"sharepoint_worker_process_child_execution",

"sharepoint_webroot_file_staging",

"sharepoint_rare_outbound_communication",

"sharepoint_internal_expansion",

"sharepoint_service_account_anomaly",

"sharepoint_webshell_or_payload_staging",

"sharepoint_post_exploitation_case",

"sharepoint_high_confidence_edr_alert",

"sharepoint_high_confidence_siem_alert",

"sharepoint_incident_response_case"

)

AND (

sharepoint_compromise_context.normalized_user_id = gcp_cloud_activity.normalized_user_id

OR sharepoint_compromise_context.user_principal_name = gcp_cloud_activity.user_principal_name

OR sharepoint_compromise_context.source_ip = gcp_cloud_activity.source_ip

OR sharepoint_compromise_context.device_id = gcp_cloud_activity.device_id

OR sharepoint_compromise_context.session_id = gcp_cloud_activity.session_id

OR sharepoint_compromise_context.identity_provider_account = gcp_cloud_activity.identity_provider_account

OR sharepoint_compromise_context.google_account_id = gcp_cloud_activity.google_account_id

OR sharepoint_compromise_context.workforce_identity_federation_subject = gcp_cloud_activity.workforce_identity_federation_subject

OR sharepoint_compromise_context.workload_identity_subject = gcp_cloud_activity.workload_identity_subject

OR sharepoint_compromise_context.service_account_id = gcp_cloud_activity.service_account_id

OR sharepoint_compromise_context.case_id = gcp_cloud_activity.security_case_id

)

AND (

gcp_cloud_activity.method_name IN ENV_SUSPICIOUS_GCP_ADMIN_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_IAM_POLICY_OR_ROLE_CHANGE_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_SERVICE_ACCOUNT_CREDENTIAL_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_SERVICE_ACCOUNT_IMPERSONATION_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_WORKLOAD_IDENTITY_CHANGE_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_WORKFORCE_IDENTITY_CHANGE_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_STORAGE_RISK_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_SECRET_MANAGER_RISK_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_KMS_RISK_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_LOGGING_OR_MONITORING_MODIFICATION_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_SECURITY_CONTROL_MODIFICATION_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_SECURITY_COMMAND_CENTER_SUPPRESSION_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_NETWORK_EXPOSURE_CHANGE_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_PROJECT_OR_ORGANIZATION_ADMIN_METHODS

OR gcp_cloud_activity.method_name IN ENV_GCP_FOLDER_OR_ORGANIZATION_POLICY_METHODS

)

AND (

gcp_cloud_activity.source_ip NOT IN ENV_APPROVED_GCP_ADMIN_SOURCE_IPS

OR gcp_cloud_activity.user_agent NOT IN ENV_EXPECTED_GCP_USER_AGENTS_BY_ROLE

OR gcp_cloud_activity.project_id NOT IN ENV_EXPECTED_GCP_PROJECTS_BY_USER_OR_ROLE

OR gcp_cloud_activity.folder_id NOT IN ENV_EXPECTED_GCP_FOLDERS_BY_USER_OR_ROLE

OR gcp_cloud_activity.organization_id NOT IN ENV_EXPECTED_GCP_ORGANIZATIONS_BY_USER_OR_ROLE

OR gcp_cloud_activity.resource_name NOT IN ENV_EXPECTED_GCP_RESOURCES_BY_USER_OR_ROLE

OR gcp_cloud_activity.resource_name IN ENV_SENSITIVE_GCP_RESOURCES

OR gcp_cloud_activity.role_name IN ENV_PRIVILEGED_GCP_ROLES

OR gcp_cloud_activity.service_account_id IN ENV_SENSITIVE_GCP_SERVICE_ACCOUNTS

OR gcp_cloud_activity.method_name IN ENV_HIGH_RISK_GCP_METHODS_REQUIRING_REVIEW

)

AND NOT (

gcp_cloud_activity.principal_email IN ENV_APPROVED_GCP_AUTOMATION_IDENTITIES

AND gcp_cloud_activity.source_ip IN ENV_APPROVED_GCP_AUTOMATION_SOURCE_IPS

AND gcp_cloud_activity.method_name IN ENV_APPROVED_GCP_AUTOMATION_METHODS