[EXP] ASP.NET ViewState Deserialization and Shared MachineKey Exploitation Path

Report Type: EXP

Threat Category: Application Exploitation / ASP.NET ViewState Deserialization / Shared MachineKey Abuse

Assessment Date: May 27, 2026

Primary Impact Domain: Internet-Facing Application Trust and IIS Server Integrity

Secondary Impact Domains: Credential Exposure, User-Side Delivery, Webroot and Application-Content Integrity, Cloud and Identity Expansion, Customer or Student Assurance, Legal and Regulatory Exposure

Affected Asset Class: Internet-Facing ASP.NET Applications, IIS-Hosted Web Servers, Vendor-Managed ASP.NET Portals, LMS Platforms, Authentication-Adjacent Workflows, Application Pool Identities, Webroot Content, Service Credentials, User Endpoints, and Connected Cloud Resources

Threat Objective Classification: Exploit Internet-Facing ASP.NET Application Trust to Enable Server-Side Execution, Application-Content Tampering, Credential Access, User-Side Delivery, and Conditional Downstream Expansion

BLUF

‍  ASP.NET ViewState deserialization and shared machineKey exploitation creates enterprise exposure when internet-facing ASP.NET applications, vendor-managed portals, LMS platforms, authentication-adjacent workflows, or custom IIS-hosted applications can be manipulated through forged or malicious state-bearing requests. The business concern is broader than a single vulnerable application: whether the affected application, IIS server, webroot content, user-facing workflows, service credentials, downstream user endpoints, and connected infrastructure can still be trusted after suspicious ViewState-bearing activity, IIS worker-process behavior, unauthorized file changes, or application-content tampering. Risk is highest when abnormal ASP.NET request activity is paired with IIS child-process execution, web shell-like access, unauthorized application-file modification, external script or payload retrieval, user-download activity, credential exposure, outbound communication, or downstream identity and cloud-control-plane anomalies.

Executive Risk Translation

ASP.NET ViewState deserialization and shared machineKey exploitation shifts business risk from a narrow web-application vulnerability issue to an application trust, server integrity, user-impact, credential-risk, and incident-governance issue. The primary executive concern is not only whether a ViewState exploit attempt occurred, but whether the organization can still trust the affected ASP.NET application, IIS worker process, webroot content, JavaScript, login or authentication workflow, downloadable components, application pool identity, service credentials, user endpoints that interacted with the application, and downstream systems touched during the exposure window. If abuse occurred, response may expand into application containment, machineKey remediation, IIS forensic review, webroot and content restoration, credential rotation, user endpoint scoping, malicious-content delivery analysis, legal and privacy review, customer or student assurance, cyber insurance coordination, vendor-management escalation, and executive incident reporting.

S3 — Why This Matters Now

·        ASP.NET ViewState deserialization and shared machineKey exploitation should be treated as an internet-facing application, IIS server, and user-impact risk, not as a simple patch-management or web-request filtering issue.

·        The primary enterprise concern is whether suspicious ViewState-bearing request activity can move into server-side execution, unauthorized application-file changes, web shell activity, content tampering, credential exposure, outbound communication, or user-side malware delivery before the organization recognizes the activity as hostile.

·        Internet-facing ASP.NET applications may support LMS platforms, customer portals, partner portals, vendor-managed services, authentication-adjacent workflows, document delivery, courseware delivery, and business-facing user interactions that create operational and reputational exposure if trust is lost.

·        Shared, static, reused, exposed, vendor-supplied, or weakly governed machineKey material can turn an application-governance weakness into a repeatable compromise path across more than one ASP.NET deployment.

·        Successful exploitation may not create a stable network signature, obvious malware alert, or single definitive indicator because the strongest evidence often appears after exploitation through IIS child-process execution, file modification, web shell interaction, outbound communication, or user endpoint impact.

·        Business impact increases when suspicious request activity is followed by w3wp.exe child-process execution, application pool identity file writes, modified ASPX or JavaScript content, rare path access, outbound communication, fake component delivery, or user endpoint detections after application access.

·        Organizations with incomplete IIS, reverse proxy, WAF, endpoint, file integrity, DNS, proxy, NDR, user endpoint, identity, cloud, vulnerability, asset, and change-control telemetry may struggle to prove whether activity was blocked, attempted, successful, or followed by post-exploitation.

·        Hosted, vendor-managed, legacy, and externally maintained ASP.NET environments can slow exposure scoping because endpoint telemetry, webroot visibility, application logs, machineKey governance evidence, and deployment records may not be fully available to the security team.

·        Static payload strings, ViewState values, web shell filenames, user agents, source infrastructure, parameter names, and proof-of-concept patterns can change quickly, so executive focus should remain on durable behavior and validated business impact.

·        Executive focus should remain on application trust, machineKey governance, containment speed, IIS and webroot integrity, user-exposure scoping, credential-risk reduction, vendor accountability, and whether downstream compromise can be ruled out defensibly.

S4 — Key Judgments

·        ASP.NET ViewState deserialization and shared machineKey exploitation is most consequential when affected applications support customer portals, LMS platforms, authentication-adjacent workflows, vendor-managed portals, partner access, regulated records, downloadable content, or business-critical web services.

·        The highest-value enterprise risk signal is abnormal ViewState-bearing request activity followed by IIS worker-process child execution, unauthorized application-file modification, web shell-like access, outbound communication, application-content tampering, credential access, or user endpoint impact.

·        A malformed ViewState request, large POST request, blocked WAF event, or isolated scanner pattern should not be treated as confirmed exploitation unless downstream web, endpoint, file, network, identity, cloud, application, or incident-response evidence supports escalation.

·        Application errors, failed request traces, HTTP 500-series responses, validation failures, and application pool instability are important early-warning signals, but they should be assessed against affected endpoint, request timing, server behavior, file changes, and outbound communication.

·        Business impact increases when the affected ASP.NET application supports authentication, user access, downloadable components, courseware, customer or student workflows, partner access, support workflows, or high-trust business functions.

·        The activity model can bypass traditional security assumptions because meaningful impact may occur through forged application state, IIS worker-process abuse, application-content tampering, web shell interaction, or user-side delivery rather than through a simple perimeter alert.

·        Response confidence depends on the organization’s ability to reconstruct a defensible timeline across IIS logs, WAF logs, reverse proxy logs, ASP.NET application logs, endpoint telemetry, file telemetry, DNS, proxy, NDR, user endpoint telemetry, identity logs, cloud logs, vulnerability context, and change-control records.

·        Missing endpoint telemetry on IIS servers, weak webroot file monitoring, incomplete request-size visibility, limited application logs, hosted-environment opacity, or poor machineKey governance records can force broader scoping and increase legal, operational, and customer-assurance costs.

·        Attribution should remain conservative. Activity should be described as aligned with the ASP.NET ViewState deserialization and shared machineKey exploitation path when the behavior chain matches, not as confirmed actor activity without incident-specific validation.

·        Executive risk reduction depends on machineKey remediation, exposed ASP.NET application inventory, application containment readiness, IIS forensic visibility, file integrity monitoring, user-exposure scoping, credential containment, vendor accountability, and validated cross-telemetry correlation.

S5 — Executive Risk Summary

Business Risk

ASP.NET ViewState deserialization and shared machineKey exploitation can create severe business, legal, operational, customer-trust, vendor-management, and infrastructure-integrity risk when internet-facing ASP.NET applications can be manipulated through forged state-bearing requests. Risk increases when affected applications support LMS platforms, customer portals, authentication-adjacent workflows, vendor-managed services, document delivery, courseware delivery, partner access, support portals, regulated records, downloadable components, or user-facing business workflows. Business impact may include application containment, machineKey remediation, IIS forensic review, webroot and content restoration, credential rotation, endpoint scoping for exposed users, malicious-content delivery analysis, vendor escalation, legal and privacy review, customer assurance, cyber insurance coordination, and long-term application governance remediation.

Technical Cause

The risk is driven by exploitation of ASP.NET ViewState handling where static, reused, exposed, vendor-supplied, or weakly governed machineKey material can enable malicious state-bearing requests to be trusted by the application. The enterprise concern is the downstream abuse of application and server trust boundaries, including abnormal ViewState-bearing POST activity, IIS worker-process execution, application pool identity behavior, webroot modification, ASPX or JavaScript changes, web shell-like interaction, credential access, outbound communication, fake component delivery, and user endpoint compromise after interaction with modified application content.

Threat Posture

The threat posture is elevated because the exploitation path begins at internet-facing ASP.NET application exposure and can move into IIS-hosted server execution, application-content manipulation, credential risk, user-side delivery, and downstream infrastructure exposure. Successful activity may not produce a single conclusive exploit signature, stable network indicator, obvious malware alert, or immediate command-and-control event. The operational risk is that suspicious ViewState-bearing requests can transition into server-side execution, webroot tampering, external script retrieval, fake component delivery, or user endpoint compromise before the organization has enough correlated evidence to classify the incident as confirmed compromise.

Executive Decision Requirement

Executives must require proof that the organization can correlate external ASP.NET request activity, IIS and reverse proxy logs, WAF events, ASP.NET application logs, endpoint behavior, application pool identity activity, file changes, outbound communication, user endpoint telemetry, identity events, cloud activity, vulnerability context, asset ownership, vendor-support records, and change-control evidence into a reliable exposure timeline. Leadership should also require validated response workflows for machineKey remediation, application containment, IIS server isolation, webroot restoration, user-exposure scoping, credential rotation, vendor escalation, legal review, customer assurance, and incident governance.

S6 — Executive Cost Summary

ASP.NET ViewState deserialization and shared machineKey exploitation creates financial exposure primarily through emergency application containment, machineKey remediation, IIS forensic review, webroot and content validation, endpoint scoping for exposed users, credential rotation, malicious-content delivery analysis, vendor-management escalation, legal and privacy review, customer or student assurance, and long-term application governance remediation. The cost profile is specific to IIS-hosted and ASP.NET application compromise because the organization may face material response costs even when there is no confirmed ransomware deployment, broad infrastructure outage, or traditional malware-first intrusion. Costs increase when the organization cannot quickly prove whether suspicious ViewState-bearing activity was blocked, whether IIS server-side execution occurred, whether application files or JavaScript were modified, whether users downloaded malicious content, whether credentials were exposed, and whether legal, customer, regulatory, insurance, or operational obligations apply.

Low Impact Scenario

Rapid assessment confirms that suspicious activity was limited to attempted exploitation, blocked ViewState-bearing requests, malformed ASP.NET requests, limited application errors, or low-confidence probing that was contained before confirmed IIS child-process execution, unauthorized file modification, web shell activity, credential access, outbound communication, application-content tampering, user-side malware delivery, or downstream infrastructure expansion. Affected assets are narrow, IIS and WAF logs are sufficient, endpoint telemetry supports a defensible timeline, legal review remains limited, and no confirmed sensitive data exposure, service disruption, customer notification requirement, regulatory notification requirement, or material business interruption is identified.

Estimated Impact

$300K to $1.5M.

Cost Drivers Include

·        IIS, WAF, CDN, reverse proxy, load balancer, and ASP.NET application log review.

·        ASP.NET asset identification, internet-facing exposure validation, ViewState-bearing endpoint review, and machineKey governance assessment.

·        Targeted IIS server review for worker-process instability, failed request traces, application pool recycling, suspicious child-process execution, and abnormal application behavior.

·        Webroot, JavaScript, ASPX, DLL, configuration, upload path, plugin-like path, and temporary compilation directory review.

·        Endpoint and file telemetry review for suspicious application pool identity activity, file writes, process execution, and outbound communication.

·        DNS, proxy, NDR, firewall, and secure web gateway triage to determine whether unusual egress, external script retrieval, callback behavior, or payload retrieval occurred.

·        Limited user-exposure scoping for users who accessed the affected application during the suspected exposure window.

·        Session invalidation, targeted credential rotation, administrative account review, and application owner coordination for affected systems.

·        Limited legal, privacy, vendor-management, and customer-assurance review to determine whether notification thresholds were avoided.

·        SOC surge activity, application-owner coordination, infrastructure review, vendor support engagement, and executive tracking.

Moderate Impact Scenario

Suspicious ASP.NET-facing request activity is paired with IIS worker-process anomalies, application errors, unauthorized file modification, web shell-like access, JavaScript or login-page changes, outbound communication, user download activity, credential-risk indicators, or incomplete exposure confidence. No public leak, confirmed extortion outcome, or enterprise-wide compromise is validated, but the organization must respond as if application content, IIS-hosted infrastructure, service credentials, user endpoints, or connected business workflows may have been exposed or manipulated.

Estimated Impact

$3M to $15M.

Cost Drivers Include

·        Expanded application containment across affected ASP.NET applications, IIS servers, load balancer paths, WAF rules, administrative workflows, and high-risk user-facing paths.

·        Broader reconstruction of WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, DNS, proxy, NDR, identity, and change-control timelines.

·        MachineKey remediation across affected and related ASP.NET applications where keys may be static, reused, vendor-supplied, exposed, or weakly governed.

·        Application-content integrity review covering JavaScript, login pages, authentication workflows, downloadable components, external script references, ASPX files, DLLs, configuration files, upload paths, and plugin-like directories.

·        IIS forensic review covering w3wp.exe child processes, command execution, script interpreter activity, archive handling, credential access, local discovery, outbound communication, persistence attempts, and web shell-like artifacts.

·        User-exposure scoping for employees, customers, students, contractors, partners, or external users who interacted with affected application content during the exposure window.

·        Endpoint investigation for suspicious downloads, fake component execution, browser child-process behavior, beacon-like activity, credential access, or post-download malware behavior.

·        Credential review and rotation for application pool identities, service accounts, database credentials, API keys, deployment secrets, vendor-support credentials, cloud credentials, and backup credentials.

·        Legal, privacy, compliance, cyber insurance, breach counsel, vendor-management, and customer-assurance coordination where exposure cannot be confidently ruled out.

·        Emergency detection engineering, SIEM correlation, field-mapping validation, baseline review, retention review, enrichment work, and SOC triage readiness validation.

·        Increased SOC, application, infrastructure, IAM, endpoint, cloud, legal, communications, vendor-management, and executive incident governance effort.

High Impact Scenario

Confirmed or strongly suspected exploitation affects application integrity, IIS server integrity, user-facing content, webroot files, login or authentication workflows, downloadable components, service credentials, user endpoints, customer or student trust, cloud-hosted resources, managed database access, identity systems, or connected business systems. This scenario applies when the incident includes confirmed server-side execution, web shell deployment, malicious content delivery, credential theft, persistence, outbound command-and-control-like communication, user malware execution, downstream identity abuse, customer-facing service disruption, notification analysis, regulatory exposure, extortion pressure, or extended application and infrastructure remediation.

Estimated Impact

$18M to $75M or higher.

Cost Drivers Include

·        Enterprise-wide ASP.NET exposure review, emergency machineKey remediation, WAF enforcement, administrative access restriction, and internet-facing application containment.

·        Full reconstruction of WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, DNS, proxy, NDR, identity, cloud, vulnerability, asset, vendor-support, and change-control evidence.

·        Investigation of multiple ASP.NET applications, shared machineKey patterns, vendor-supplied configurations, shared hosting paths, shared service accounts, shared credentials, related LMS platforms, and authentication-adjacent portals.

·        Full webroot and application integrity review covering ASPX files, DLLs, JavaScript, configuration files, login pages, downloadable components, upload paths, plugin-like directories, temporary compilation paths, and user-facing content.

·        IIS server forensic review for suspicious child processes, command execution, script interpreter abuse, web shell-like artifacts, credential access, local discovery, archive creation, persistence, defense evasion, and outbound communication.

·        User endpoint investigation for suspicious downloads, fake component execution, browser-driven payload execution, Cobalt Strike-like behavior, credential access, persistence, and post-download beaconing.

·        Cloud and identity scoping for credential use, service account activity, session abuse, metadata access, object storage access, managed database access, IAM changes, conditional-access events, SaaS anomalies, and control-plane activity tied to exposed users or systems.

·        Legal, privacy, compliance, cyber insurance, breach counsel, forensics, communications, vendor-management, and executive incident governance under confirmed or credible exposure conditions.

·        Customer, student, partner, regulator, board, insurer, and third-party communications where data exposure, service integrity, contractual obligations, or public trust require coordinated response.

·        Sensitive data review for user records, customer records, student records, authentication data, downloadable content, support records, regulated records, configuration data, credentials, backups, and confidential business records.

·        Long-term remediation of ASP.NET application governance, machineKey management, IIS monitoring, WAF policy, file integrity monitoring, credential storage, vendor-support controls, service-account governance, cloud workload identity controls, segmentation, backup validation, and deployment security.

·        Extended monitoring for repeat exploitation, web shell reactivation, malicious content reintroduction, credential reuse, user endpoint reinfection, cloud-resource abuse, extortion escalation, and follow-on targeting.

S6A — Key Cost Drivers

·        Number and criticality of affected ASP.NET applications, especially internet-facing LMS platforms, customer portals, authentication-adjacent workflows, vendor-managed portals, partner portals, and business-critical web services.

·        Whether affected applications rely on static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material.

·        Evidence that suspicious ViewState-bearing request activity moved beyond attempted exploitation into IIS worker-process execution, application pool identity abuse, unauthorized file modification, web shell-like access, content tampering, outbound communication, or user-side delivery.

·        Degree of application-content manipulation, including modified JavaScript, altered login pages, external script references, fake authentication prompts, modified downloadable components, or changed user workflows.

·        Whether suspicious activity reached webroot files, ASPX files, DLLs, configuration files, upload directories, plugin-like paths, temporary ASP.NET compilation paths, or vendor application folders.

·        Whether application pool identities, service accounts, database credentials, configuration secrets, API keys, deployment credentials, vendor-support credentials, backup credentials, or cloud credentials were accessed or exposed.

·        Whether users who accessed the affected application downloaded suspicious files, executed fake components, contacted unfamiliar infrastructure, or produced endpoint detections consistent with post-download malware behavior.

·        Whether downstream identity, SaaS, cloud, or control-plane anomalies can be traced to exposed users, stolen credentials, compromised application content, or user endpoint malware delivery.

·        Ability to determine which application paths, endpoints, files, users, sessions, credentials, servers, user endpoints, and downstream systems were accessed or modified.

·        Availability of IIS, WAF, CDN, reverse proxy, load balancer, ASP.NET application, endpoint, file, DNS, proxy, NDR, secure web gateway, identity, cloud, vulnerability, asset, and change-control telemetry.

·        Completeness of request-size visibility, POST metadata, failed request traces, application logs, endpoint command-line telemetry, file telemetry, webroot baselines, user access telemetry, browser download telemetry, and workload identity mapping.

·        Whether legal, privacy, regulatory, cyber insurance, contract, customer assurance, student notification, partner notification, vendor-management, or public disclosure obligations are triggered or cannot be ruled out quickly.

·        Whether incomplete telemetry, short retention windows, hosted-environment opacity, shared machineKey use, weak asset inventory, missing known-good baselines, or poor vendor-support records force conservative breach scoping and broader response.

Most Likely Scenario Justification

The moderate scenario is most likely when suspicious ASP.NET-facing request activity is paired with IIS worker-process anomalies, unauthorized file changes, application-content tampering, web shell-like access, outbound communication, user-delivery indicators, credential-risk signals, or incomplete exposure confidence, but no public leak, confirmed extortion outcome, systemic cloud compromise, or enterprise-wide multi-application compromise has been validated. The estimate moves toward the lower end when affected ASP.NET assets are limited, machineKey remediation is quickly completed, logs are complete, no unauthorized file or content changes are observed, no user-side delivery is validated, no credentials are exposed, and legal review can confidently rule out notification obligations. The estimate moves toward the upper end when affected applications are business-critical, user-facing content was modified, IIS telemetry is incomplete, machineKey reuse is broad, credential exposure is plausible, user endpoints may have been affected, vendor-managed visibility is limited, customer assurance is required, or regulatory, contractual, cyber insurance, or breach-counsel review is necessary.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether affected ASP.NET and IIS-hosted application paths involved customer records, student records, authenticated user data, employee-adjacent data, support records, regulated records, contractual data, payment-adjacent workflows, authentication workflows, downloadable components, configuration data, credentials, or confidential business records. Compliance exposure increases when user access scope cannot be confidently reconstructed, application-content integrity is affected, user endpoint impact cannot be ruled out, credential exposure is plausible, outbound transfer activity is uncertain, customer-facing service integrity is impaired, notification obligations are unclear, customer assurance is required, or cloud-hosted resource access introduces broader data-governance exposure.

Risk Register Entry

Risk Title

ASP.NET ViewState Deserialization and Shared MachineKey Exploitation Exposure

Risk Description

Adversaries may exploit internet-facing ASP.NET application paths that rely on ViewState handling and weakly governed machineKey material to submit malicious state-bearing requests, trigger server-side execution, modify application files, deploy or interact with web shell-like artifacts, tamper with user-facing content, expose credentials, communicate outbound, deliver malicious content to users, or expand into identity, cloud, SaaS, or connected infrastructure. The risk is elevated where vendor-managed portals, LMS platforms, authentication-adjacent workflows, custom ASP.NET applications, service credentials, application pool identities, user endpoints, or cloud-hosted resources are exposed with incomplete logging, weak correlation, limited file integrity monitoring, insufficient machineKey governance, or fragmented application ownership.

Likelihood

High.

Impact

Severe.

Risk Rating

Critical.

Annualized Risk Exposure

Estimated $5M to $30M or higher based on the number of internet-facing ASP.NET assets, machineKey governance quality, business criticality of affected workflows, likelihood of successful exploitation, quality of IIS and WAF logging, endpoint and file telemetry coverage, user-exposure scope, credential-risk scope, vendor-managed visibility, customer assurance requirements, notification obligations, and remediation complexity.

S7 — Risk Drivers

·        Internet-facing ASP.NET applications create direct exposure when ViewState-dependent workflows, authentication-adjacent paths, LMS workflows, upload paths, plugin-like paths, or user-facing forms are reachable from external infrastructure.

·        Static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material can increase the risk that one configuration weakness supports exploitation across multiple ASP.NET applications or environments.

·        Successful exploitation can create business impact through server-side execution, application file modification, web shell-like access, content tampering, credential exposure, user-side delivery, or downstream infrastructure access even without immediate ransomware deployment.

·        ASP.NET applications often support customer portals, student platforms, partner access, support workflows, document delivery, courseware delivery, authentication-adjacent functions, or administrative workflows that can create customer-trust and operational exposure when integrity is uncertain.

·        IIS, WAF, CDN, reverse proxy, load balancer, ASP.NET application, endpoint, file, DNS, proxy, NDR, user endpoint, identity, and cloud logging depth varies significantly by hosting model, ownership model, platform configuration, license tier, and retention policy.

·        Missing request-size detail, request-body visibility, failed request traces, application logs, endpoint command-line telemetry, file telemetry, user access logs, or browser download telemetry can prevent reliable exposure scoping.

·        Vendor-managed, hosted, legacy, and externally maintained ASP.NET environments may limit process visibility, file visibility, webroot baselines, machineKey governance evidence, credential-access telemetry, and workload identity mapping.

·        Legitimate application maintenance, vendor support, deployment automation, content updates, plugin updates, backup jobs, monitoring workflows, vulnerability scanning, and WAF validation can resemble parts of the exploitation model.

·        User-impact scoping can be difficult when users access affected applications from unmanaged devices, external networks, contractor environments, student devices, partner networks, or endpoints outside standard telemetry coverage.

·        Credential exposure risk increases when application configuration files, environment variables, database credentials, application pool identities, service-account tokens, deployment secrets, backup credentials, or cloud credentials are reachable from the IIS-hosted application context.

·        Cloud-hosted ASP.NET environments can expand blast radius if application compromise leads to metadata access, secrets retrieval, object storage access, managed database access, IAM changes, workload identity abuse, SaaS access, or control-plane modification.

·        Over-reliance on static exploit indicators, known payload strings, ViewState values, web shell filenames, named tooling, blocked WAF events, or endpoint malware detections can delay recognition of behavior-led exploitation and downstream impact.

S8 — Bottom Line for Executives

ASP.NET ViewState deserialization and shared machineKey exploitation should be treated as a high-priority internet-facing application, IIS server, credential-risk, and user-impact threat because suspicious state-bearing request activity can become the path to server-side execution, webroot tampering, web shell-like access, malicious content delivery, credential exposure, and downstream infrastructure expansion before the organization has enough evidence to contain the incident confidently. The executive concern is whether the organization can determine which ASP.NET assets were targeted, whether exploitation succeeded, what application or webroot content changed, whether users were exposed to malicious content, whether credentials were accessed, whether cloud or identity systems were reached, and whether legal, customer, regulatory, vendor-management, or operational obligations apply. Risk reduction depends on rapid machineKey remediation, strong WAF controls, reliable IIS and ASP.NET logging, endpoint and file telemetry, user-exposure scoping, credential governance, cloud workload visibility, and response workflows that can contain the request-to-IIS-to-user-impact chain before business exposure expands.

S9 — Board-Level Takeaway

ASP.NET ViewState deserialization and shared machineKey exploitation turns enterprise reliance on internet-facing ASP.NET portals, LMS platforms, vendor-managed applications, authentication-adjacent workflows, and custom IIS-hosted systems into a potential application trust, user-impact, credential-risk, and infrastructure integrity issue. The board-level concern is that a public-facing ASP.NET application may provide a path into IIS-hosted execution, webroot modification, malicious content delivery, service credentials, user endpoints, identity systems, cloud-hosted resources, and connected business workflows before traditional security controls classify the activity as confirmed compromise. Leadership should require evidence that application security, machineKey governance, WAF coverage, IIS logging, endpoint monitoring, file integrity monitoring, credential management, vendor oversight, user-exposure scoping, cloud workload controls, and incident-response procedures can support rapid containment, exposure determination, customer assurance, regulatory review, and executive governance. This report supports governance decisions around internet-facing ASP.NET exposure, shared machineKey risk, telemetry readiness, credential containment, user-delivery blast radius, vendor-managed application visibility, and executive oversight of application-layer exploitation.

S10 — Threat Overview

Figure 2

ASP.NET ViewState deserialization and shared machineKey exploitation risk refers to activity where internet-facing ASP.NET applications, IIS-hosted workflows, ViewState-bearing request paths, application pool identities, webroot content, and downstream user-exposure paths may be abused to create enterprise exposure. The activity is not best understood as a single payload, one vulnerable product, or a narrow web shell signature. It is an internet-facing application exploitation path centered on whether suspicious state-bearing request activity produced downstream IIS execution, unauthorized application changes, web shell-like access, outbound communication, credential exposure, user-side delivery, or identity and cloud expansion.

The core risk is that an attacker may use forged or malicious ViewState-bearing requests against ASP.NET applications that rely on static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material. When the application trusts malicious state-bearing input, the concern extends beyond the request itself to the IIS worker process, application pool identity, webroot integrity, ASPX and JavaScript content, configuration files, downloadable components, service credentials, and users who interact with the affected application. The most important business question is whether the organization can prove that the affected ASP.NET application, IIS server, application content, users, credentials, and connected infrastructure remained protected during and after suspicious request activity.

This activity is difficult to assess through single-event evidence because normal ASP.NET operations can include large postbacks, legitimate ViewState-bearing requests, application errors, deployment activity, vendor maintenance, content updates, upload workflows, administrative access, reporting jobs, and outbound business integrations. High-confidence assessment depends on whether the organization can connect IIS, WAF, CDN, reverse proxy, load balancer, ASP.NET application, endpoint, file, DNS, proxy, NDR, user endpoint, identity, cloud, vulnerability, asset, vendor-support, and change-control evidence into one defensible exposure timeline.

ASP.NET ViewState deserialization and shared machineKey exploitation should therefore be treated as a cross-layer exposure issue spanning the public web application, IIS-hosted server, webroot content, service credentials, user endpoint population, and connected infrastructure. The response objective is not only to identify suspicious ViewState-bearing requests, but to determine whether affected systems and downstream dependencies can still be trusted.

S11 — Threat Classification and Type

Threat Type

Internet-facing web application exploitation and IIS-hosted application trust risk.

Threat Sub-Type

ASP.NET ViewState abuse, shared machineKey exploitation exposure, server-side execution risk, application-content tampering, web shell-like access, credential exposure, outbound callback behavior, user-side malicious content delivery, and conditional identity or cloud expansion.

Operational Classification

Public-facing ASP.NET exploitation path, IIS worker-process abuse risk, application integrity degradation, webroot compromise risk, credential exposure risk, user-delivery risk, and conditional infrastructure expansion.

Primary Function

The primary function is to weaken trust in internet-facing ASP.NET applications and their IIS-hosted execution boundary by manipulating state-bearing request paths that may influence server-side behavior, application-file integrity, user-facing content, service credentials, outbound communication, or downstream user endpoints. The activity may support server-side execution, web shell-like access, application-content tampering, malicious download delivery, credential theft, outbound communication, identity abuse, cloud-resource access, customer-facing service disruption, legal review, customer assurance, vendor escalation, and executive incident governance.

S12 — Campaign or Activity Overview

ASP.NET ViewState deserialization and shared machineKey exploitation does not require a single fixed payload, URI path, parameter name, user-agent, source infrastructure pattern, web shell name, or proof-of-concept string to create enterprise risk. The activity can appear as suspicious ViewState-bearing POST activity against ASP.NET WebForms endpoints, authentication-adjacent workflows, administrative-adjacent paths, LMS workflows, upload paths, plugin-like paths, document delivery paths, courseware delivery paths, or other state-bearing application paths. The most important activity pattern is not a single request artifact, but the relationship between suspicious web activity and surrounding IIS execution, application errors, file behavior, content changes, outbound traffic, credential access, and user endpoint impact.

Relevant activity may begin with external probing, abnormal POST size, unusual bytes received, sparse targeted requests, repeated request variation, suspicious allowed web activity, response-code shifts, HTTP 500-series clusters, failed request traces, application pool instability, or error-to-success transitions against ASP.NET endpoints. In some cases, activity may remain limited to attempted exploitation or blocked request behavior. In higher-risk cases, it may justify review of w3wp.exe child-process execution, application pool identity behavior, ASPX or DLL creation, JavaScript modification, configuration changes, web shell-like access, outbound communication, credential access, malicious content delivery, or suspicious user endpoint activity.

The strongest enterprise concern arises when abnormal ViewState-bearing request activity, IIS worker-process behavior, unauthorized application-file changes, rare path access, web shell-like interaction, outbound communication, application-content tampering, and user endpoint detections appear together. The concern increases further when the affected ASP.NET application supports customer-facing workflows, LMS access, authentication-adjacent functionality, downloadable components, partner access, vendor-managed services, regulated records, or business-critical web services.

This activity should be assessed through a behavior-led model. Static exploit strings, isolated WAF blocks, one-off malformed requests, known payload fragments, ViewState values, web shell filenames, source IP novelty, request volume, and single application errors should not drive the primary risk judgment by themselves. The more durable question is whether external state-bearing request activity produced downstream application, host, file, network, user endpoint, identity, cloud, or business-impact evidence outside approved operational context.

S13 — Targets and Exposure Surface

ASP.NET ViewState deserialization and shared machineKey exploitation is most relevant to environments where internet-facing ASP.NET applications rely on ViewState-dependent workflows and weakly governed machineKey material. The exposure surface extends beyond the vulnerable request path to the IIS worker process, application pool identity, webroot directories, JavaScript and ASPX content, configuration files, upload paths, plugin-like paths, temporary ASP.NET compilation locations, service credentials, user endpoints, and connected infrastructure.

High-priority targets include ASP.NET deployments where compromise or content manipulation could create disproportionate business impact. This includes LMS platforms, customer portals, student portals, partner portals, authentication-adjacent applications, vendor-managed ASP.NET portals, administrative-adjacent workflows, downloadable component paths, support portals, regulated data workflows, and high-visibility user-facing services. These targets create elevated risk because misuse may lead to application trust loss, malicious content delivery, credential exposure, user endpoint compromise, customer assurance requirements, regulatory review, legal escalation, vendor escalation, and incident governance pressure.

The exposure surface also includes application pool identities, service accounts, local administrator contexts, webroot files, ASPX files, DLLs, JavaScript files, configuration files, upload directories, plugin-like directories, temporary compilation paths, downloadable components, deployment records, vendor-support workflows, backup systems, monitoring systems, CI/CD systems, cloud workload identities, object storage, managed databases, and identity control planes. Weakness in any of these areas can reduce confidence that application behavior, file changes, credential use, user delivery, and downstream activity remained authorized and traceable.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology, SaaS, cloud services, software, digital media, and platform organizations operating internet-facing ASP.NET applications, portals, or customer-facing web services.

·        Education, higher education, training providers, research institutions, and LMS-dependent organizations using ASP.NET applications for student access, courseware delivery, user authentication, document access, or administrative workflows.

·        Financial services, fintech, banking, insurance, accounting, payment-adjacent services, and business-services organizations using ASP.NET for customer portals, authentication workflows, support workflows, or regulated content.

·        Healthcare, life sciences, hospitals, care networks, medical research, health-data platforms, and healthcare technology organizations using ASP.NET portals for patient-facing, employee-facing, partner-facing, research, policy, or operational content.

·        Retail, e-commerce, hospitality, travel, logistics, and customer-service-heavy organizations using ASP.NET applications for customer access, support content, loyalty workflows, downloadable components, or business-facing records.

·        Legal, consulting, professional services, accounting, and advisory firms using ASP.NET portals to manage client-facing content, confidential materials, document access, customer workflows, or public trust communications.

·        Public-sector, municipal, government-adjacent, nonprofit, advocacy, trade association, and membership organizations using ASP.NET applications for citizen services, member portals, authenticated resources, public communications, or administrative access.

·        Telecommunications, media, energy, utilities, manufacturing, transportation, and critical infrastructure operators using ASP.NET applications for customer communications, operational documentation, partner access, regulated information sharing, or support workflows.

·        Organizations relying on vendor-managed ASP.NET portals, custom IIS-hosted applications, shared machineKey configurations, cloud-hosted IIS workloads, managed databases, object storage, service-account credentials, or integrated deployment pipelines for business-critical operations.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because ASP.NET and IIS-hosted applications are widely used for internet-facing portals, LMS platforms, customer services, public-sector services, partner workflows, support applications, and business content systems.

·        Countries with large education, healthcare, financial services, public-sector, technology, customer-service, SaaS, cloud-hosted application, or managed-service footprints may face elevated operational exposure.

·        Country-specific impact should be assessed by ASP.NET exposure, ViewState usage, machineKey governance, application criticality, data sensitivity, public-service dependency, regulatory obligations, breach-notification requirements, customer assurance requirements, vendor-management model, cloud-hosting model, telemetry maturity, and incident-response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High.

The activity does not necessarily require advanced malware development, custom post-exploitation tooling, or long-term endpoint persistence. It does require understanding of ASP.NET ViewState behavior, machineKey trust assumptions, IIS-hosted application behavior, request timing, response behavior, application errors, webroot paths, application pool identity context, and hosting environments. Capability increases when the actor combines exploit adaptation, request encoding, application-specific probing, low-noise interaction, web shell-like operation, application-content tampering, credential access, and disciplined post-exploitation tradecraft.

Technical Sophistication

Moderate to High.

Technical sophistication is centered on manipulating internet-facing ASP.NET application behavior in a way that may resemble malformed traffic, scanning, application instability, or ordinary postback behavior until correlated against downstream effects. The activity can remain effective when it blends into state-bearing workflows, authentication-adjacent paths, LMS activity, upload paths, administrative-adjacent browsing, or vendor-managed application behavior. More sophisticated execution may involve careful endpoint selection, forged state-bearing requests, low-noise request variation, rapid transition into IIS execution, short-lived file staging, web shell-like access, JavaScript modification, fake component delivery, credential access, or cloud-resource exploration.

Infrastructure Maturity

Moderate.

This activity does not require mature command-and-control infrastructure to create material business risk. The most important infrastructure may be scanning nodes, cloud-hosted systems, anonymization paths, compromised servers, rotating source infrastructure, staging destinations, direct IP destinations, dynamic DNS, external script-hosting locations, file-transfer paths, or cloud services used for callback, staging, or user delivery. Infrastructure maturity becomes more relevant when the actor coordinates probing across multiple ASP.NET targets, varies source infrastructure, separates exploitation activity from downstream staging, or uses user-delivery infrastructure after application-content tampering.

Operational Scale

Opportunistic to Targeted.

The most likely operational pattern is opportunistic targeting of exposed ASP.NET applications combined with targeted escalation against systems that support LMS access, authentication-adjacent workflows, customer portals, downloadable content, vendor-managed services, or sensitive business workflows. Broader operational scale may emerge when multiple organizations share similar ASP.NET configurations, reused machineKey material, vendor-supplied key patterns, exposed ViewState-bearing endpoints, incomplete WAF coverage, limited request visibility, weak file integrity monitoring, or hosted application visibility gaps.

Escalation Likelihood

Moderate to High.

Escalation likelihood increases when suspicious request activity affects customer-facing ASP.NET applications, LMS platforms, authentication-adjacent workflows, administrative paths, user-facing content, downloadable components, regulated records, or cloud-hosted workloads. Escalation is also more likely when IIS errors, failed request traces, application pool instability, child-process execution, unauthorized file changes, JavaScript modification, web shell-like access, outbound communication, credential access, malicious user delivery, metadata access, secrets retrieval, object storage access, managed database access, or IAM changes appear after suspicious ViewState-bearing activity.

S16 — Targeting Probability Assessment

Overall Targeting Probability

Medium to High.

ASP.NET ViewState deserialization and shared machineKey exploitation becomes materially plausible where internet-facing ASP.NET applications use ViewState-dependent workflows, rely on static or weakly governed machineKey material, support customer-facing or authenticated workflows, and lack sufficient telemetry to prove whether suspicious request activity remained blocked or attempted only. The risk is strongest for organizations that rely on ASP.NET for LMS platforms, customer portals, public communications, regulated workflows, support systems, downloadable components, authentication-adjacent functions, or sensitive business services.

Targeting Drivers

·        Internet-facing ASP.NET applications with ViewState-bearing endpoints, WebForms workflows, authentication-adjacent paths, administrative-adjacent paths, LMS workflows, upload paths, plugin-like paths, document delivery paths, or user-facing forms.

·        ASP.NET deployments using static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material.

·        High-value ASP.NET applications supporting customer portals, student portals, payment-adjacent workflows, support operations, public communications, internal publishing, regulated content, downloadable components, or high-visibility user services.

·        Incomplete machineKey governance, uncertain application ownership, unknown ViewState usage, weak asset inventory, unmanaged vendor portals, legacy ASP.NET deployments, or incomplete patch and configuration validation.

·        Limited ability to correlate WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, network, DNS, proxy, identity, cloud, vulnerability, vendor-support, and change-control evidence.

·        Incomplete request-size visibility, POST metadata, failed request traces, IIS error logs, ASP.NET application logs, endpoint command-line telemetry, file telemetry, webroot baselines, user access telemetry, browser download telemetry, or workload identity mapping.

·        Hosted, vendor-managed, shared hosting, containerized, platform-as-a-service, or cloud-hosted ASP.NET workloads that limit process visibility, file telemetry, workload identity mapping, machineKey evidence, or web-tier forensic detail.

·        Weak governance over application pool identities, service accounts, administrative access, configuration files, upload paths, plugin-like directories, deployment pipelines, vendor-support access, service credentials, and cloud workload identities.

·        Customer-facing services, LMS platforms, regulated data environments, public-sector services, support platforms, authenticated portals, or business records that could create customer assurance, notification, legal, or regulatory exposure if accessed or modified.

Most Likely Targets

·        Internet-facing ASP.NET applications reachable through public web paths and using ViewState-dependent workflows.

·        Customer portals, student portals, LMS platforms, partner portals, support portals, public-service sites, and content systems that support authenticated access or sensitive workflows.

·        ASP.NET WebForms endpoints, authentication-adjacent workflows, administrative-adjacent paths, upload paths, plugin-like paths, document delivery paths, courseware delivery paths, and state-bearing user-facing forms.

·        ASP.NET sites with static or reused machineKey material, uncertain configuration ownership, insufficient WAF tuning, limited IIS logging, weak application audit coverage, or incomplete endpoint visibility.

·        Cloud-hosted IIS workloads with access to managed databases, secrets stores, object storage, metadata services, service-account tokens, CI/CD systems, vendor support tooling, or deployment automation.

·        Web-tier hosts, IIS servers, application pools, application workers, writable web directories, upload directories, temporary ASP.NET compilation paths, plugin-like paths, vendor paths, and deployment paths.

·        Application pool identities, service accounts, configuration files, database credentials, API keys, deployment credentials, backup credentials, cloud credentials, and other credential-bearing artifacts reachable from the application boundary.

·        Organizations with high internet-facing ASP.NET dependency, incomplete telemetry, weak asset inventory, limited file integrity monitoring, fragmented change-control evidence, or limited ability to prove whether users were exposed to malicious content.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — External Reconnaissance and ASP.NET Exposure Identification

External activity identifies an internet-facing ASP.NET application, ViewState-bearing endpoint, WebForms workflow, LMS path, authentication-adjacent path, administrative-adjacent path, upload path, or other state-bearing application route for probing.

·        ATT&CK mapping: Active Scanning T1595.

·        Confidence: Conditional. Applies when scanning, endpoint discovery, route enumeration, technology probing, or repeated access to ASP.NET-facing paths is observed before exploit-shaped activity.

Stage 2 — Public-Facing Application Exploitation Attempt

Suspicious ViewState-bearing or state-bearing POST activity is sent to an exposed ASP.NET application using abnormal request size, unusual bytes received, repeated request variation, endpoint-specific probing, or suspicious allowed web activity.

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

·        Confidence: Likely. Applies when WAF, CDN, reverse proxy, load balancer, IIS, or ASP.NET telemetry shows suspicious request manipulation against internet-facing ASP.NET functionality.

Stage 3 — IIS Server-Side Execution

Suspicious request activity is followed by IIS worker-process child execution, command-shell activity, script interpreter execution, archive utility use, network utility use, or other unexpected process behavior from the IIS application boundary.

·        ATT&CK mapping: Command and Scripting Interpreter T1059.

·        Confidence: Conditional to likely. Applies when endpoint telemetry shows suspicious w3wp.exe or application pool identity execution after abnormal ASP.NET request activity.

Stage 4 — Application File Modification or Web Shell-Like Access

New or modified ASPX files, DLLs, JavaScript files, configuration files, upload-path artifacts, plugin-like artifacts, rare path access, or web shell-like interaction appears after suspicious ASP.NET activity.

·        ATT&CK mapping: Server Software Component T1505.

·        Confidence: Conditional. Applies when file, web, endpoint, or incident-response evidence shows suspicious application artifact changes or web shell-like access aligned to the affected application.

Stage 5 — Credential Access

The activity reaches configuration files, service credentials, application pool identity material, database credentials, API keys, deployment secrets, backup credentials, cloud credentials, or other credential-adjacent artifacts from the IIS or application boundary.

·        ATT&CK mapping: Unsecured Credentials T1552.

·        Confidence: Conditional. Applies when process, file, command-line, endpoint, identity, or incident-response evidence shows credential-path access after suspicious ASP.NET activity.

Stage 6 — Outbound Communication or Payload Retrieval

The affected IIS server contacts rare external destinations, direct IP infrastructure, dynamic DNS, unusual TLS destinations, external script hosts, staging infrastructure, or callback-like destinations after suspicious request, file, or process activity.

·        ATT&CK mapping: Ingress Tool Transfer T1105.

·        ATT&CK mapping: Application Layer Protocol T1071.

·        Confidence: Conditional. Applies when DNS, proxy, NDR, firewall, endpoint-network, or incident-response evidence ties unusual outbound communication to the affected IIS workload.

Stage 7 — User-Side Delivery or Downstream Expansion

Modified application content, fake component prompts, external script references, suspicious downloads, or user endpoint detections appear after users interact with the affected ASP.NET application. Downstream identity, SaaS, or cloud activity may follow only when tied to exposed users, stolen credentials, or user endpoint compromise.

·        ATT&CK mapping: Drive-by Compromise T1189.

·        ATT&CK mapping: Valid Accounts T1078.

·        Confidence: Conditional. Applies only when application access, content-change evidence, download telemetry, endpoint detections, identity logs, cloud logs, or incident-response evidence supports the downstream link.

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

ASP.NET ViewState deserialization and shared machineKey exploitation begins as an internet-facing application trust event rather than a malware-first or endpoint-first compromise event. Initial activity may involve external probing of ASP.NET WebForms endpoints, ViewState-bearing pages, LMS workflows, authentication-adjacent paths, administrative-adjacent paths, upload paths, plugin-like paths, document delivery paths, courseware delivery paths, or other state-bearing application routes. The immediate business concern is whether suspicious request activity reached an ASP.NET path capable of influencing IIS-hosted execution, application-file integrity, service credentials, user-facing content, or downstream user exposure.

After the initial probing or exploit attempt, the actor may submit forged, malicious, unusually large, repeated, abnormal, or otherwise suspicious ViewState-bearing POST activity to the exposed ASP.NET application. This activity may appear as routine scanning, malformed traffic, blocked WAF activity, application instability, failed request traces, or ordinary postback behavior unless assessed against request timing, endpoint context, response behavior, source patterns, and downstream effects. The signal-aligned concern is whether suspicious request activity produced response-code shifts, error-to-success transitions, validation failures, HTTP 500-series clusters, ASP.NET exceptions, worker-process instability, application pool recycling, or abnormal endpoint behavior.

The activity becomes more consequential when suspicious request activity aligns with IIS-hosted server behavior. In an affected ASP.NET environment, downstream effects may include w3wp.exe child-process execution, command-shell activity, script interpreter execution, archive utility use, network utility behavior, suspicious application pool identity activity, file staging, outbound communication, or endpoint detections from the IIS-hosted server. This phase may not prove the original exploit path by itself, but it can create strong compromise evidence when it follows abnormal ViewState-bearing request activity against an exposed ASP.NET application.

Post-exploitation risk increases if application-file modification, web shell-like access, or application-content tampering occurs after suspicious ASP.NET request and IIS behavior. New or modified ASPX files, DLLs, JavaScript files, configuration files, upload-path artifacts, plugin-like artifacts, temporary compilation artifacts, rare path access, web shell-like interaction, modified login pages, external script references, fake component prompts, or changed downloadable components can indicate that the incident has moved beyond attempted exploitation. These signals should not be treated as standalone proof of ViewState exploitation, but they become materially significant when they align with suspicious upstream web activity and IIS-hosted execution evidence.

The final phase may involve credential access, outbound communication, user-side delivery, or downstream identity and cloud expansion. The affected ASP.NET application or IIS server may expose configuration files, service credentials, database credentials, application pool identity context, API keys, deployment secrets, backup credentials, cloud credentials, managed database access, object storage, metadata services, SaaS sessions, or identity-control-plane activity. If user-facing content was modified, the incident may also extend to users who accessed the affected application and later downloaded suspicious files, executed fake components, contacted unfamiliar infrastructure, or produced endpoint detections.

The signal-aligned execution flow should be assessed as a request-to-IIS-to-application-content-to-user-impact chain. The strongest concern exists when suspicious ViewState-bearing request activity, IIS worker-process behavior, unauthorized application-file modification, web shell-like access, outbound communication, application-content tampering, credential access, user endpoint detections, or downstream identity and cloud anomalies appear in sequence. The response objective is to reconstruct the path, determine what application or webroot content changed, validate whether credentials or users were exposed, and contain business impact before exposure expands beyond the ASP.NET application boundary.

S19 — Attack Chain Risk Amplification Summary

ASP.NET ViewState deserialization and shared machineKey exploitation risk amplifies because the activity begins at a public-facing application boundary and may move into IIS-hosted execution, application-content integrity, service credentials, user endpoints, and connected infrastructure. A single exposed ASP.NET application may provide access to customer-facing workflows, LMS access, authenticated user paths, downloadable content, vendor-managed services, application pool identities, webroot files, configuration material, and downstream dependencies. This makes the attack chain highly dependent on machineKey governance, WAF coverage, IIS logging, endpoint visibility, file integrity monitoring, credential management, vendor-support control, user-exposure scoping, cloud workload controls, and evidence retention.

The first amplification point is internet-facing ASP.NET application exposure. ASP.NET applications often support customer portals, LMS platforms, student access, partner workflows, authentication-adjacent functions, document delivery, support workflows, and administrative-adjacent access. If suspicious ViewState-bearing activity reaches a vulnerable or weakly governed state-bearing path, the organization may need to determine whether the activity remained an attempted exploit, produced application instability, triggered IIS execution, or created downstream compromise evidence.

The second amplification point is machineKey governance and application trust. Static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material can increase concern that forged state-bearing requests may be trusted by the application. If machineKey ownership, rotation history, uniqueness, vendor handling, or configuration records are incomplete, the organization may struggle to prove whether the affected application was isolated or whether related ASP.NET applications require broader remediation.

The third amplification point is IIS and webroot integrity. Successful exploitation may lead to w3wp.exe child-process execution, application pool identity activity, unexpected file writes, new ASPX or DLL artifacts, modified JavaScript, configuration changes, rare path access, web shell-like interaction, credential access, or outbound communication. These signals increase the response burden because they shift the incident from application-layer review into host, file-integrity, endpoint, network, and forensic investigation.

The fourth amplification point is user-side delivery and credential exposure. Modified JavaScript, altered login pages, fake component prompts, downloadable content changes, external script references, configuration files, service credentials, database credentials, deployment secrets, backup credentials, and cloud credentials may extend the incident beyond the IIS server. If users interacted with modified content or credentials were exposed, the response may expand into endpoint scoping, password resets, service-account rotation, legal review, customer assurance, vendor escalation, cloud review, and identity monitoring.

The final amplification point is evidence fragmentation. IIS logs, WAF logs, CDN logs, reverse proxy logs, load balancer logs, ASP.NET application logs, endpoint telemetry, file integrity records, DNS logs, proxy logs, NDR telemetry, user endpoint telemetry, identity logs, cloud logs, vulnerability context, vendor-support records, and change-control records may be owned by different teams, retained for different periods, or normalized differently. If these sources cannot be joined into one timeline, the organization may be forced into broader exposure scoping, longer legal review, wider customer assurance, more conservative notification analysis, and extended executive governance.

S20 — Tactics, Techniques, and Procedures

Figure 3

External Reconnaissance and ASP.NET Exposure Identification

·        The actor may identify internet-facing ASP.NET applications, ViewState-bearing endpoints, WebForms workflows, LMS paths, authentication-adjacent paths, administrative-adjacent paths, upload paths, plugin-like paths, document delivery paths, courseware delivery paths, or other state-bearing application routes.

·        Reconnaissance may appear as scanning, endpoint discovery, technology probing, repeated route access, source rotation, abnormal request ordering, or traffic against uncommon ASP.NET functionality.

·        Risk increases when probing targets public-facing ASP.NET assets that support customer portals, LMS access, authenticated workflows, partner access, regulated content, downloadable components, vendor-managed services, or sensitive business workflows.

Public-Facing Application Exploitation Attempt

·        The actor may send forged, malicious, unusually large, repeated, sparse, or otherwise abnormal ViewState-bearing POST activity to exposed ASP.NET functionality.

·        Exploit attempts may appear as blocked WAF events, suspicious allowed traffic, abnormal POST size, unusual bytes received, repeated request variation, response-code shifts, repeated 400-series or 500-series responses, failed request traces, response-size variation, backend timeouts, application pool instability, or error-to-success transitions.

·        Single malformed requests, blocked WAF events, source novelty, request volume, or large ViewState-bearing POST activity should not be treated as confirmed exploitation without downstream web, endpoint, file, network, identity, cloud, user endpoint, or incident-response evidence.

IIS Server-Side Execution

·        The actor may trigger or use IIS worker-process execution, command-shell activity, script interpreter execution, archive utility use, network utility behavior, local discovery, file staging, or unusual administrative utility execution from the affected application boundary.

·        IIS execution risk is highest when w3wp.exe, an application pool identity, an IIS service account, or an ASP.NET application process spawns unexpected child processes or performs activity inconsistent with the application role.

·        Suspicious execution should be prioritized when it follows abnormal ViewState-bearing request activity and aligns with application errors, failed request traces, unauthorized file changes, rare path access, outbound communication, credential access, or missing change-control evidence.

Application File Modification and Web Shell-Like Access

·        The actor may create or modify ASPX files, DLLs, JavaScript files, configuration files, archives, executables, scripts, temporary artifacts, upload-path artifacts, plugin-like artifacts, or vendor application files.

·        Web shell-like interaction may appear as rare path access, newly observed ASPX access, repeated low-volume requests, unusual parameters, abnormal response-size patterns, sparse interactive timing, or repeated access from limited source infrastructure.

·        File and web shell-like signals should be assessed against process lineage, application pool identity context, webroot path, file type, request timing, follow-on access, outbound communication, and approved deployment or vendor-support records.

Application-Content Tampering and User-Side Delivery

·        The actor may modify JavaScript, login pages, authentication workflows, downloadable components, user-facing prompts, external script references, or fake security-component messaging.

·        User-side delivery may appear as suspicious downloads, fake component retrieval, external script loading, browser child-process behavior, beacon-like endpoint activity, or endpoint detections after interaction with the affected application.

·        User-impact attribution should require application access evidence, content-change evidence, download telemetry, browser artifacts, proxy records, endpoint detections, or incident-response evidence tied to the suspected exposure window.

Credential Access and Local Discovery

·        The actor may access application configuration files, database credentials, environment variables, service-account material, application pool identity context, API keys, deployment secrets, backup credentials, cloud credentials, or other credential-adjacent artifacts.

·        Local discovery may include file system review, process context review, user context review, service enumeration, security-product enumeration, database connection discovery, application path discovery, or cloud metadata probing.

·        Credential access materially increases risk because it can extend the incident beyond the ASP.NET application into managed databases, object storage, identity services, SaaS platforms, CI/CD systems, backup systems, or cloud control-plane resources.

Outbound Communication and Payload Retrieval

·        The affected IIS server may communicate with newly observed destinations, direct IP addresses, uncommon ports, dynamic DNS infrastructure, rare domains, external script hosts, file-transfer locations, cloud services, or destinations outside approved integration paths.

·        Payload retrieval or callback behavior may appear as unusual DNS lookups, rare TLS destinations, abnormal session duration, unexpected transfer volume, archive retrieval, external script retrieval, low-volume repeated connections, or destination access following suspicious ASP.NET activity.

·        Outbound communication should be prioritized when it follows suspicious request activity, IIS child-process execution, unauthorized file modification, web shell-like access, credential access, or application-content tampering.

Downstream Identity, Cloud, and Infrastructure Expansion

·        The actor may attempt to reach metadata services, secrets stores, object storage, managed databases, identity services, SaaS control planes, CI/CD systems, backup systems, monitoring systems, or management-plane resources from the affected IIS or application boundary.

·        Cloud or identity expansion becomes higher risk when it follows credential access, service-account exposure, suspicious outbound activity, user endpoint compromise, application-content tampering, or IIS server compromise evidence.

·        Cloud, SaaS, or control-plane activity should be attributed to this exploit path only when it maps to the affected ASP.NET workload, exposed user population, stolen credentials, or user endpoint compromise and follows suspicious upstream web, application, endpoint, file, network, identity, or cloud evidence.

Operational Security and Evasion Considerations

·        The actor may change payload syntax, encode state-bearing data, vary request frequency, rotate source infrastructure, avoid obvious exploit patterns, suppress visible errors, or move quickly from request activity into file changes, credential access, outbound communication, or user delivery.

·        Activity may be distributed across endpoints, request methods, parameters, source addresses, time windows, application paths, hosts, application pools, user endpoints, or cloud resources to resemble normal web traffic, vendor support, deployment activity, monitoring workflows, or administrative behavior.

·        Static indicators may change quickly, so response should prioritize behavior, timing, asset context, request structure, ViewState-bearing workflow context, IIS behavior, application-file changes, credential access, outbound communication, user endpoint impact, and business authorization.

S20A — Adversary Tradecraft Summary

ASP.NET ViewState deserialization and shared machineKey exploitation tradecraft is centered on converting internet-facing application exposure into IIS-hosted execution risk, application-content integrity loss, credential exposure, user-side delivery, and downstream business impact. The activity does not require a conventional malware chain to create material exposure. Instead, it abuses the fact that ASP.NET request handling, machineKey trust, IIS worker processes, application files, service credentials, user-facing content, and connected infrastructure can all become part of the same exploitation path.

The primary tradecraft characteristic is ambiguity at the application boundary. Suspicious ViewState-bearing activity may resemble scanning, malformed traffic, blocked WAF events, application errors, failed postbacks, or routine internet noise. This allows hostile activity to remain difficult to classify unless the organization evaluates request behavior, endpoint context, ASP.NET errors, IIS process behavior, file activity, outbound communication, and user impact together.

The second tradecraft characteristic is leverage through machineKey and application trust. Static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material can weaken confidence that the application can distinguish legitimate state-bearing requests from malicious ones. This creates risk across application integrity, IIS-hosted execution, webroot content, user-facing workflows, service credentials, and related ASP.NET deployments.

The third tradecraft characteristic is IIS and webroot pivot potential. If exploitation produces child-process execution, application pool identity activity, file modification, web shell-like access, JavaScript modification, credential access, or outbound communication, the incident can expand from application triage into host, file-integrity, endpoint, network, credential, and forensic investigation. This raises response complexity and increases the importance of correlating web activity to downstream behavior.

The fourth tradecraft characteristic is user-delivery and credential blast-radius risk. Modified application content, external script references, fake component prompts, suspicious downloads, configuration files, database credentials, application pool identities, service-account material, deployment secrets, backup credentials, and cloud credentials may provide impact beyond the web application itself. If users are exposed or credentials are accessed, the incident can extend into user endpoints, managed databases, object storage, secrets stores, identity systems, SaaS platforms, CI/CD systems, backup systems, or cloud control-plane resources.

The final tradecraft characteristic is pressure through incomplete evidence. If the organization cannot prove whether suspicious request activity affected IIS execution, webroot content, application files, credentials, user endpoints, or cloud resources, the response burden increases. Incomplete WAF visibility, weak IIS logging, limited ASP.NET application logs, missing file telemetry, hosted-environment opacity, weak machineKey governance records, short retention windows, or fragmented change-control evidence can force broader exposure scoping, longer legal review, customer assurance work, vendor escalation, and executive governance.

S21 — Detection Strategy Overview

Detection Philosophy

The detection strategy for ASP.NET ViewState deserialization and shared machineKey exploitation is behavior-led, correlation-driven, and designed to remain effective across vulnerable ASP.NET applications beyond a single vendor case. The KnowledgeDeliver exploitation activity provides the active reporting anchor, but the detection model centers on the broader compromise pattern: malicious ViewState handling, server-side code execution, IIS worker-process abuse, web shell enablement, application-content tampering, and downstream user-impact activity.

·        Detection should prioritize the relationship between suspicious ASP.NET request handling, IIS worker-process behavior, abnormal application-directory changes, unauthorized web-access patterns, and outbound communication.

·        Detection should not depend on a single CVE identifier, vendor product name, web shell family, file name, parameter name, or infrastructure indicator.

·        Detection should separate exploit-attempt indicators from compromise indicators because abnormal ViewState requests may represent scanning or failed exploitation, while IIS child-process execution, unauthorized file creation, or application-content tampering represent stronger compromise evidence.

·        Detection should treat KnowledgeDeliver as the active case study while preserving coverage for vendor-managed ASP.NET portals, custom ASP.NET applications, LMS platforms, authentication-adjacent portals, and other IIS-hosted applications where static, reused, exposed, or vendor-supplied machineKey material can enable forged ViewState payloads.

·        Detection should emphasize durable attacker behavior and defensive validation points rather than exploit construction, payload syntax, or sensitive implementation detail.

Primary Detection Anchors

The primary detection anchors are the observable points where exploitation, execution, persistence, content manipulation, and downstream impact become visible across web, endpoint, file, and network telemetry.

·        ASP.NET requests containing abnormal ViewState-bearing activity, including unusual request size, unexpected request paths, anomalous POST patterns, uncommon source infrastructure, or activity against pages that normally receive predictable form postbacks.

·        IIS worker-process activity involving unexpected child processes, command-shell execution, script interpreter usage, file staging, archive handling, payload execution, or network utility behavior.

·        Unauthorized file creation or modification under application directories, webroot paths, upload directories, plugin-like locations, temporary ASP.NET compilation paths, or vendor-controlled application folders.

·        Web shell behavior involving low-volume interactive requests, rare endpoint access, suspicious parameters, unusual response-size patterns, repeated access from limited source infrastructure, or request timing aligned with server-side execution.

·        Application-content tampering involving modified JavaScript, altered login or authentication workflows, injected remote script references, unauthorized user prompts, or fake security/authentication component delivery.

·        Outbound communication from IIS-hosted application servers to newly observed IP addresses, rare domains, suspicious hosting providers, uncommon ports, or destinations inconsistent with the application’s normal business function.

·        User-endpoint detections after interaction with the compromised application, especially suspicious downloads, fake installer execution, Cobalt Strike-like behavior, or beaconing that aligns with application access telemetry.

Detection Prioritization Model

Detection priority should increase when multiple independent telemetry sources show a progression from exposed application access to server-side execution, unauthorized application change, attacker interaction, outbound communication, or user-side impact.

·        Highest priority should be assigned when abnormal ViewState-bearing request activity is followed by IIS worker-process command execution, unauthorized application-directory modification, web shell access, or outbound communication from the application server.

·        Highest priority should also be assigned when application-content tampering is followed by user downloads, redirect activity, fake authentication prompts, or endpoint malware detections from users who interacted with the affected application.

·        High priority should be assigned when w3wp.exe or an application pool identity creates, modifies, or executes suspicious script, ASPX, DLL, archive, executable, configuration, or JavaScript artifacts in application-controlled directories.

·        High priority should be assigned when rare web-access paths align with process execution, file changes, or external communication from the same server.

·        Medium priority should be assigned to repeated abnormal ViewState-bearing requests against exposed ASP.NET endpoints when no host compromise evidence is available.

·        Medium priority should be assigned to web shell-like access patterns when endpoint, file, or network telemetry is incomplete.

·        Low priority should be assigned to isolated malformed requests, generic scanner traffic, or blocked payload attempts unless they cluster around known exposed ASP.NET applications or coincide with application instability.

·        Priority should increase when the affected application is internet-facing, vendor-managed, legacy, authentication-adjacent, externally used, or tied to customer, student, contractor, or partner access.

Correlation Strategy

Correlation must be enforced to prevent over-attribution, reduce false positives, and keep detection output actionable for SOC and incident-response teams.

·        Abnormal ViewState-bearing request activity should not be treated as confirmed compromise without supporting host, file, web-access, network, or application-change evidence.

·        Suspicious IIS child-process execution should be treated as severe host behavior, but attribution to ViewState deserialization should require timing, request-path, application, or exposure correlation.

·        Webroot and application-directory changes should be correlated with process lineage, application pool identity, file path, file type, write time, request timing, and subsequent access activity.

·        Web shell suspicion should correlate rare endpoint access, suspicious request structure, unusual response-size patterns, repeated interactive timing, file-system changes, and command execution behavior.

·        Application-content tampering should correlate file integrity changes with user-facing application paths, modified login or authentication flows, new remote domains, and user endpoint activity.

·        User endpoint malware detections should not be attributed to the compromised application unless browser history, download telemetry, proxy logs, EDR timeline data, or web access logs show interaction with the affected application during the relevant exposure window.

·        Cloud identity, SaaS, or control-plane anomalies should not be attributed to this exploit path unless upstream evidence connects the compromised application, user malware delivery, stolen credentials, or related session activity to the downstream anomaly.

Telemetry Prioritization

Telemetry should be prioritized according to its ability to support exploit identification, compromise validation, user-impact scoping, containment decisions, and post-incident assurance.

·        IIS web logs and reverse-proxy logs should be prioritized for request paths, methods, source addresses, user agents, response codes, request sizes, timing clusters, and abnormal POST activity against ViewState-bearing endpoints.

·        Endpoint telemetry from IIS-hosted servers should be prioritized for w3wp.exe, application pool identities, process lineage, command lines, module loads, file writes, script execution, and network connections.

·        File integrity telemetry should be prioritized for webroot paths, application directories, JavaScript files, ASPX files, DLLs, configuration files, plugin-like directories, upload paths, and temporary compilation locations.

·        Network telemetry should be prioritized for outbound communication from IIS servers to newly observed domains, suspicious hosting providers, uncommon ports, rare TLS destinations, and external script-hosting infrastructure.

·        DNS, proxy, and secure web gateway telemetry should be prioritized for identifying attacker-controlled domains used by compromised application content, fake component delivery, or post-exploitation communication.

·        EDR telemetry from user endpoints should be prioritized when the compromised application may have delivered malicious content or fake security components to visitors.

·        Vulnerability, asset, and configuration telemetry should be prioritized to identify ASP.NET applications with static, reused, vendor-supplied, exposed, or weakly governed machineKey configurations.

Detection Design Constraints

The detection model must account for the fact that ViewState exploitation may not produce a stable network signature and that the strongest compromise evidence often appears after server-side execution begins.

·        Detection should not rely on exploit payload strings, public proof-of-concept structure, web shell filenames, or attacker-selected parameter names.

·        Detection should not require decrypted HTTP request bodies when endpoint, file, and application telemetry provide stronger compromise evidence.

·        Detection should not assume the vulnerable application is KnowledgeDeliver unless asset, URL, product, or application evidence supports that conclusion.

·        Detection should not assume the observed web shell is Godzilla / BLUEBEAM unless vendor telemetry, file evidence, memory evidence, behavioral evidence, or threat-intelligence context supports that conclusion.

·        Detection should not treat all large ViewState-bearing requests as malicious because some ASP.NET applications legitimately produce large state-bearing requests.

·        Detection should not treat all IIS child-process behavior as equal; severity should increase when the behavior is rare for the application pool, uses command execution, writes files, modifies content, or initiates external communication.

·        Detection should account for hosted, vendor-managed, and legacy ASP.NET environments where endpoint telemetry, file telemetry, or full request visibility may be incomplete.

·        Detection should remain resilient by focusing on request-to-process-to-file-to-network relationships rather than fixed indicators.

Baseline and Deployment Requirements

Deployment requires local baselining of ASP.NET request behavior, IIS process behavior, application update patterns, webroot change activity, and expected outbound communication before detection logic is promoted from hunting to alerting.

·        Establish normal request-size ranges and POST patterns for ViewState-bearing ASP.NET endpoints.

·        Identify externally exposed ASP.NET applications, application pool identities, webroot locations, vendor application directories, and normal administrative update windows.

·        Baseline normal w3wp.exe child-process behavior by application pool, server role, maintenance activity, deployment method, and vendor support workflow.

·        Baseline expected file modifications in webroot, JavaScript, plugin-like, upload, configuration, and temporary application directories.

·        Baseline expected outbound destinations from IIS-hosted application servers.

·        Baseline normal user-download behavior from the application, especially where the application distributes courseware, documents, installers, plugins, or authentication-related components.

·        Confirm availability of web logs, endpoint telemetry, file telemetry, DNS logs, proxy logs, EDR telemetry, vulnerability inventory, and configuration inventory before enabling high-confidence alerting.

·        Validate detection logic against legitimate application updates, vendor maintenance, administrative workflows, deployment tooling, backup processes, and support activity.

Variant Resilience Requirements

The detection strategy must remain effective if the attacker changes the vulnerable ASP.NET application, payload format, web shell family, infrastructure, user-delivery method, or post-exploitation tooling.

·        Preserve coverage for malicious ViewState handling without depending on one vulnerable product.

·        Preserve coverage for web shell behavior without depending on a specific shell name, file path, extension, password parameter, or command syntax.

·        Preserve coverage for application-content tampering without depending on a specific injected JavaScript file, domain, fake installer name, or visual prompt.

·        Preserve coverage for server-side execution by monitoring abnormal IIS child processes, suspicious file writes, content modification, and outbound communication.

·        Preserve coverage for user-side impact by correlating application access with suspicious downloads, payload execution, endpoint detections, and post-download beaconing.

·        Preserve coverage across KnowledgeDeliver, other vendor-managed ASP.NET applications, custom ASP.NET portals, LMS platforms, partner portals, and authentication-adjacent IIS applications.

·        Preserve coverage where network payload visibility is limited by TLS, proxy architecture, hosted application constraints, or incomplete request logging.

·        Preserve coverage for future cases where the exploit primitive remains shared machineKey abuse or ViewState validation bypass, even when the CVE, vendor, payload, or infrastructure changes.

Operational Detection Model

The operational model should move from exposure identification to exploit-attempt detection, compromise validation, user-impact scoping, containment support, and post-remediation assurance.

·        Identify exposed ASP.NET applications that rely on ViewState and determine whether machineKey values are unique, intentionally managed, vendor-supplied, reused, static, or insufficiently governed.

·        Hunt for abnormal ViewState-bearing POST requests against exposed ASP.NET endpoints.

·        Correlate suspicious requests with IIS worker-process child execution, file creation, configuration change, webroot modification, or application-content tampering.

·        Review webroot and application directories for unauthorized ASPX, DLL, JavaScript, archive, temporary, plugin-like, or recently modified artifacts.

·        Identify suspicious outbound communication from IIS-hosted application servers during and after the suspected exploitation window.

·        Review application content for injected remote script references, altered login pages, modified user workflows, fake authentication prompts, or unauthorized security-component messaging.

·        Scope user endpoints that accessed the compromised application during the exposure window.

·        Correlate user endpoint detections with application access, browser downloads, fake installers, suspicious execution chains, and Cobalt Strike-like behavior.

·        Treat confirmed server compromise as both an application incident and a potential user-delivery incident when user-facing content was modified.

·        Use the detection model to support containment decisions, including application isolation, machineKey remediation, application restoration, webroot validation, host forensic review, user endpoint scoping, and credential-risk assessment.

S22 — Primary Detection Signals

Primary Detection Signals

Primary detection should focus on correlated evidence that an exposed ASP.NET application moved from suspicious request handling into server-side execution, unauthorized application change, web shell activity, outbound communication, or user-impact behavior.

·        Abnormal ViewState-bearing POST requests to exposed ASP.NET endpoints where request size, request frequency, source infrastructure, endpoint path, or timing deviates from the application baseline.

·        Suspicious IIS worker-process behavior involving w3wp.exe spawning command shells, script interpreters, archive utilities, network utilities, living-off-the-land binaries, or other unexpected child processes.

·        Application pool identity activity that creates, modifies, executes, or stages files in webroot, vendor application, upload, plugin-like, temporary compilation, or application-controlled directories.

·        Unauthorized ASPX, DLL, JavaScript, archive, executable, configuration, or temporary-file creation under application paths associated with the exposed ASP.NET application.

·        Rare or newly observed web-access paths followed by server-side process execution, file writes, content changes, or outbound communication.

·        Web shell-like interaction patterns involving low-volume repeated requests, unusual parameters, uncommon user agents, abnormal response sizes, repeated access from limited source infrastructure, or timing aligned with host-side execution.

·        Application-content modification involving login pages, authentication flows, JavaScript files, user-facing prompts, downloadable components, or external script references.

·        Outbound communication from the IIS-hosted application server to newly observed IP addresses, rare domains, suspicious hosting providers, uncommon ports, or infrastructure inconsistent with normal application behavior.

·        User endpoint detections after interaction with the affected application, especially suspicious downloads, fake installer execution, beaconing, or Cobalt Strike-like behavior temporally aligned with application access.

Supporting Detection Signals

Supporting signals improve confidence when paired with primary signals, but should not be treated as standalone confirmation of exploitation.

·        Internet-facing ASP.NET application exposure with ViewState-dependent functionality.

·        Known or suspected static, reused, vendor-supplied, exposed, or weakly governed machineKey configuration.

·        Recent application errors, failed requests, 500-series responses, worker-process instability, or application pool recycling near suspicious request windows.

·        New or modified files appearing outside approved maintenance, vendor-support, administrative update, or deployment windows.

·        Rare administrative access to the application server near the suspected exploitation window.

·        Newly observed DNS lookups or outbound TLS sessions from the IIS-hosted server after abnormal web activity.

·        Endpoint alerts on application servers involving suspicious command execution, web shell behavior, credential access, reconnaissance, payload staging, or defense evasion.

·        Endpoint alerts on user systems that accessed the application during the suspected exposure window.

·        Proxy or secure web gateway records showing users downloading unusual files after visiting the affected application.

·        Asset inventory evidence showing legacy ASP.NET applications, unsupported vendor versions, unmanaged IIS deployments, or externally exposed LMS and portal systems.

Exploit Attempt and Instability Signals

Exploit-attempt and instability signals are useful for early warning and exposure scoping, but they require correlation before they are treated as compromise evidence.

·        Repeated POST requests containing abnormal ViewState-bearing traffic against exposed ASP.NET endpoints.

·        Large, malformed, unexpected, or unusually frequent state-bearing requests to pages that normally receive predictable form postbacks.

·        Request bursts from uncommon source infrastructure, anonymization services, hosting providers, or geographically unusual access paths.

·        Increased HTTP 500-series responses, validation errors, application exceptions, or failed request traces around suspicious POST activity.

·        IIS application pool crashes, recycles, hangs, or abnormal worker-process restarts near suspicious request windows.

·        ASP.NET event log entries indicating validation failures, deserialization-related application errors, unexpected exceptions, or application instability.

·        Application logs showing abnormal form submission patterns, unexpected page workflows, or repeated failures against specific endpoints.

·        Reverse-proxy or web application firewall logs showing blocked or anomalous requests to ASP.NET endpoints with ViewState-dependent workflows.

·        Scanner-like activity that clusters around exposed ASP.NET applications, especially when followed by a smaller number of targeted requests.

Outbound Communication Signals

Outbound communication signals become important when a compromised IIS server reaches external infrastructure for staging, command-and-control, payload retrieval, attacker interaction, or malicious content delivery.

·        w3wp.exe or an application pool identity initiating outbound connections inconsistent with the server’s normal role.

·        IIS-hosted application servers communicating with newly observed IP addresses, rare domains, suspicious hosting providers, dynamic DNS infrastructure, or recently registered domains.

·        Outbound connections from application servers to uncommon ports, non-standard protocols, or external endpoints not associated with vendor support, update services, monitoring, or business workflows.

·        DNS lookups from IIS-hosted servers that begin after abnormal ViewState-bearing requests or application-content changes.

·        Repeated low-volume outbound connections that align with web shell interaction, payload staging, or beacon-like timing.

·        External script references introduced into application content and subsequently requested by user browsers.

·        Application servers retrieving archives, scripts, binaries, or configuration-like payloads from external infrastructure.

·        Proxy, firewall, or NDR observations showing new server-to-internet communication shortly after suspicious request or file-modification activity.

·        User endpoints connecting to unfamiliar infrastructure after visiting the affected application or downloading a suspicious component.

Persistence and Post-Exploitation Signals

These signals are conditional and should be evaluated when server compromise, web shell activity, content tampering, or user-side malware delivery is suspected.

·        Newly created or modified scheduled-task, service, registry autorun, startup, script, executable, or persistence-like host artifacts on the IIS server.

·        Suspicious changes to application configuration files, handler mappings, authentication-related settings, or deployment artifacts.

·        Credential access behavior from the application server, including access to local secrets, configuration secrets, service account material, browser stores, or cached credentials.

·        Reconnaissance commands executed from the IIS server, including local account, domain, network, process, service, or security-product enumeration.

·        Defense-evasion behavior involving log clearing, security-tool tampering, process injection, obfuscated script execution, renamed utilities, or staged payload deletion.

·        Additional tooling staged after initial exploitation, including command shells, remote-access tools, credential utilities, tunneling tools, or beacon-like payloads.

·        User-facing content changes that introduce fake security prompts, malicious downloads, credential-collection workflows, or external script loading.

·        User endpoint compromise signals that align with interaction with the affected application during the exposure window.

Lateral Movement and Expansion Signals

These signals are conditional and should be evaluated only when there is evidence the compromised application server was used as a pivot point, credential source, or staging platform for broader intrusion activity.

·        Authentication attempts from the IIS-hosted application server to internal systems that are unusual for its role.

·        New SMB, WinRM, RDP, WMI, LDAP, Kerberos, SQL, or administrative connections originating from the application server.

·        Use of application pool, service account, or locally available credentials against internal hosts.

·        Access to domain controllers, file shares, database servers, identity infrastructure, backup systems, or management platforms outside normal application workflows.

·        Remote process execution or administrative share activity from the application server.

·        Internal scanning, host discovery, port scanning, share enumeration, or domain reconnaissance from the application server.

·        Lateral movement attempts that follow suspicious ViewState activity, IIS child-process execution, web shell access, or credential access behavior.

·        Cloud, SaaS, or control-plane access using credentials that can be traced to users or systems exposed through the compromised application.

·        New privileged sessions, suspicious token use, or anomalous identity behavior following user-side malware delivery linked to the affected application.

Signal Usage Constraints

Signal usage must remain conservative, correlation-based, and resistant to over-attribution.

·        Abnormal ViewState-bearing traffic should be treated as an exploit-attempt signal unless paired with host, file, web shell, outbound, or application-change evidence.

·        IIS child-process execution should be treated as high-severity host behavior, but should not be attributed to ViewState exploitation without timing, request-path, exposure, or application correlation.

·        Web shell-like access patterns should be validated with file, process, response-size, request-timing, authentication, or endpoint evidence before being treated as confirmed web shell activity.

·        Application-content tampering should be validated against approved deployment, vendor support, administrative update, and change-control records.

·        Outbound communication should be compared against known vendor services, monitoring platforms, update repositories, business integrations, and normal application dependencies.

·        User endpoint compromise should not be attributed to the affected application unless application access, download telemetry, browser history, proxy logs, or EDR timeline evidence supports the connection.

·        Lateral movement and cloud-control-plane activity should not be attributed to this exploit path unless upstream application compromise, credential exposure, user malware delivery, or session abuse is established.

·        Godzilla / BLUEBEAM, Cobalt Strike, or any named tooling should be treated as observed case-study context, not as required detection conditions.

·        Detection should avoid reliance on exploit payload syntax, machineKey material, proof-of-concept structure, web shell filenames, or attacker-selected parameters.

·        Alerts should be promoted from hunting to production only after local baselining, field mapping, false-positive review, and SOC triage validation are complete.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry is required to determine whether suspicious ASP.NET request activity resulted in server-side execution, web shell activity, post-exploitation behavior, or lateral expansion from the IIS-hosted application server.

·        EDR or endpoint telemetry from IIS-hosted servers showing process creation, parent-child process lineage, command-line arguments, process start and stop times, user context, and process integrity context.

·        Visibility into w3wp.exe, application pool identities, IIS service accounts, web application processes, script interpreters, command shells, living-off-the-land binaries, archive utilities, remote-access utilities, and network tooling.

·        Process lineage showing w3wp.exe or application pool identities spawning cmd.exe, powershell.exe, pwsh.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe, curl.exe, wget.exe, tar.exe, 7z.exe, or similar utilities.

·        Telemetry showing process execution from webroot, upload, temporary compilation, plugin-like, vendor application, or other application-controlled directories.

·        Security event telemetry for service creation, scheduled task creation, log clearing, privilege use, credential access, remote logon, and administrative session creation.

·        Authentication telemetry showing unusual logons to or from the IIS-hosted application server, especially where an application pool identity, service account, or local administrator context is used outside normal workflows.

·        Endpoint timeline data that can correlate suspicious request windows with process execution, file creation, outbound communication, and user-impact activity.

Memory and Execution Telemetry

Memory and execution telemetry improves confidence when attacker tooling does not leave durable files or when web shell, beacon-like, injected, or in-memory execution activity is suspected.

·        EDR telemetry showing suspicious process injection, reflective loading, unsigned module loading, abnormal memory allocation, suspicious script execution, in-memory payload behavior, or suspicious .NET assembly loading.

·        Module-load visibility for w3wp.exe, spawned child processes, script interpreters, and suspicious processes created during the suspected exploitation window.

·        Detection coverage for obfuscated PowerShell, encoded command execution, unmanaged code execution, abnormal CLR activity, and suspicious runtime behavior.

·        Execution telemetry from temporary directories, application compilation directories, upload locations, or recently modified application paths.

·        Behavioral detections for beacon-like execution, command-and-control behavior, credential access, defense evasion, process hollowing, or suspicious remote-access tooling.

·        Runtime visibility sufficient to identify web shell execution patterns, post-exploitation tool staging, and payload behavior even when filenames, hashes, or staging paths change.

·        Endpoint visibility sufficient to distinguish legitimate application behavior from interactive attacker-driven execution under the IIS worker process or application pool context.

Crash and Fault Telemetry

Crash and fault telemetry is required to identify failed exploit attempts, malformed ViewState activity, unstable payload execution, and early exploitation windows that may precede confirmed compromise.

·        IIS logs showing HTTP 500-series errors, request failures, abnormal response patterns, and endpoint-specific failure clusters.

·        Windows Application logs showing ASP.NET exceptions, validation failures, deserialization-related faults, application crashes, unhandled exceptions, or runtime instability.

·        IIS failed request tracing where available, especially for exposed ASP.NET endpoints that receive ViewState-bearing POST requests.

·        Application pool telemetry showing crashes, hangs, rapid-fail protection events, worker-process recycling, abnormal restarts, or unusual resource exhaustion.

·        Web application logs showing abnormal form submissions, unexpected page workflows, repeated request failures, or validation errors near suspicious request activity.

·        Reverse-proxy, load balancer, WAF, or CDN telemetry showing blocked requests, malformed request attempts, request-size anomalies, or abnormal POST behavior.

·        Time-synchronized fault telemetry that can be correlated with suspicious request sources, endpoint paths, process execution, file writes, and outbound communication.

·        Historical baseline data for normal application errors so exploit-attempt signals can be distinguished from routine application instability.

File and Persistence Telemetry

File and persistence telemetry is required to validate unauthorized application modification, web shell placement, content tampering, payload staging, and host-level persistence.

·        File creation, modification, deletion, and rename telemetry for webroot, vendor application, upload, plugin-like, temporary compilation, configuration, JavaScript, and application-controlled directories.

·        File integrity monitoring for ASPX, DLL, JavaScript, configuration, HTML, archive, executable, script, and plugin-like artifacts associated with the exposed application.

·        Telemetry showing the responsible process, user context, file path, file extension, hash, timestamp, prior file state, and related process lineage for application-file changes.

·        Monitoring for newly created or modified ASPX files, DLLs, JavaScript files, configuration files, archives, executables, scripts, and temporary artifacts outside approved maintenance or deployment windows.

·        Visibility into scheduled tasks, services, startup folders, registry autoruns, handler mappings, application configuration changes, and authentication-related configuration changes on IIS-hosted servers.

·        Detection of staged payloads, renamed utilities, deleted-after-execution files, compressed archives, extracted toolsets, or temporary files created during suspected exploitation windows.

·        Version-control, deployment, vendor-support, or change-management records that can confirm whether application-file changes were authorized.

·        Backup, golden-image, or known-good application baselines that support restoration validation and comparison against suspected tampering.

Network and Outbound Communication Telemetry

Network and outbound communication telemetry is required to identify payload retrieval, attacker interaction, command-and-control activity, external script loading, and user-side delivery paths.

·        Firewall, proxy, DNS, NDR, NetFlow, Zeek, load balancer, and secure web gateway telemetry for IIS-hosted application servers.

·        Outbound destination visibility from application servers, including destination IP, domain, URL path where available, port, protocol, TLS metadata, timing, volume, and connection frequency.

·        DNS telemetry showing newly observed domains, rare lookups, dynamic DNS use, suspicious hosting providers, recently registered domains, and lookups initiated after suspicious web activity.

·        Proxy or secure web gateway logs showing application servers retrieving scripts, archives, binaries, configuration-like files, or external content inconsistent with normal server behavior.

·        NDR or network behavioral analytics showing rare server-to-internet communication, beacon-like timing, abnormal TLS sessions, uncommon ports, or connections to infrastructure inconsistent with the application role.

·        Web traffic telemetry showing external script references introduced into application content and subsequently requested by user browsers.

·        User endpoint proxy, DNS, and secure web gateway telemetry showing suspicious downloads, fake component retrieval, or unfamiliar outbound connections after interaction with the affected application.

·        Network telemetry sufficient to distinguish vendor update services, monitoring platforms, business integrations, and normal application dependencies from suspicious attacker-controlled infrastructure.

Web and Application Telemetry

Web and application telemetry is conditionally required where available because it provides the strongest context for abnormal ViewState request activity, affected endpoints, application workflows, and user-exposure scoping.

·        IIS web logs containing timestamp, source IP, method, URI stem, URI query, status code, substatus, Win32 status, user agent, referrer, authenticated user where available, bytes sent, bytes received, and time taken.

·        Reverse-proxy, WAF, load balancer, or CDN logs showing source infrastructure, request size, request method, request path, response status, user agent, geo-location, TLS metadata, and blocked request details.

·        Application logs showing form submissions, validation failures, authentication flow events, plugin activity, user workflow changes, administrative actions, and application-specific error conditions.

·        Visibility into ViewState-bearing endpoints, normal POST patterns, request-size ranges, expected referrers, normal authenticated workflows, and high-risk externally exposed pages.

·        Logs showing rare or newly observed endpoint access, repeated low-volume interaction, abnormal response-size patterns, and access to newly created or modified application files.

·        Content-change telemetry for user-facing JavaScript, login pages, authentication prompts, downloadable components, and external script references.

·        User access telemetry identifying which users, systems, browsers, source networks, or sessions interacted with the affected application during the suspected exposure window.

·        Administrative and vendor-support logs showing legitimate maintenance activity, application updates, configuration changes, and authorized file modifications.

Telemetry Availability Requirements

The detection model requires enough telemetry coverage to connect suspicious request activity to host behavior, application changes, outbound communication, and user-impact scoping. Without these connections, detection should remain in hunting or exposure-review mode.

·        Minimum viable telemetry should include IIS or reverse-proxy logs, endpoint process telemetry from IIS-hosted servers, file modification telemetry for application paths, and outbound DNS or network telemetry.

·        High-confidence compromise validation should include process lineage, command-line visibility, application pool identity context, file write details, web access logs, and outbound connection telemetry.

·        User-impact scoping should include proxy, DNS, secure web gateway, browser download, EDR, or endpoint timeline telemetry from users who accessed the application during the suspected exposure window.

·        Lateral movement assessment should include authentication logs, Windows security logs, EDR telemetry, network flow data, and identity telemetry for connections originating from the application server.

·        Cloud or SaaS impact assessment should include identity logs, session logs, control-plane audit logs, conditional-access events, and credential-use telemetry tied to exposed users or systems.

·        Telemetry should be time-synchronized across web, endpoint, file, DNS, proxy, network, identity, and application data sources.

·        Telemetry retention should cover the suspected exploitation window, staging period, user-exposure period, and post-compromise activity window.

·        Detection engineering teams should confirm field availability, index names, sourcetypes, data normalization, asset mapping, identity enrichment, application ownership, and log retention before converting this model into production alerts.

Telemetry Limitations and Gaps

Telemetry limitations must be documented before rule deployment because many ASP.NET exploitation cases occur in hosted, legacy, vendor-managed, or partially monitored environments.

·        Lack of endpoint telemetry on IIS-hosted servers may prevent confirmation of server-side execution, web shell behavior, file staging, and post-exploitation activity.

·        Lack of file integrity telemetry may prevent reliable validation of webroot modification, application-content tampering, and unauthorized artifact placement.

·        Lack of request-size, bytes-received, or POST-body metadata may reduce visibility into abnormal ViewState-bearing request activity.

·        Encrypted traffic, reverse-proxy architecture, CDN placement, or incomplete request logging may limit direct visibility into exploit-attempt characteristics.

·        Hosted or vendor-managed application environments may restrict access to process telemetry, file telemetry, IIS logs, failed request tracing, or application logs.

·        Insufficient DNS, proxy, or network telemetry may prevent identification of payload retrieval, web shell communication, external script loading, and command-and-control activity.

·        Limited user endpoint telemetry may prevent confirmation that compromised application content delivered suspicious downloads, fake components, or follow-on malware.

·        Poor asset inventory may prevent reliable identification of exposed ASP.NET applications, application pool identities, vendor-managed portals, legacy LMS platforms, and ViewState-dependent workflows.

·        Weak identity enrichment may prevent correlation between application access, user endpoint activity, credential exposure, lateral movement, and cloud-control-plane anomalies.

·        Short retention windows may prevent reconstruction of the full exploitation timeline, especially when initial access, content tampering, and user-side impact occur across separate time windows.

S24 — Detection Opportunities and Gaps

Detection Opportunities

The strongest detection opportunity is correlation across abnormal ASP.NET request behavior, IIS worker-process execution, unauthorized application change, outbound communication, and user-side impact. This exploit path should not be detected through one signal family. It should be detected through a progression of related behaviors that move from exposed web application interaction into server-side compromise and potential downstream delivery.

·        Correlate abnormal ViewState-bearing POST requests with IIS worker-process child execution, unauthorized application-file changes, application-content tampering, or outbound communication.

·        Identify exposed ASP.NET applications where ViewState-dependent workflows, static machineKey governance risk, legacy vendor-managed deployments, weak ownership, or incomplete logging increase detection priority.

·        Detect w3wp.exe or application pool identities spawning command shells, script interpreters, archive utilities, living-off-the-land binaries, network utilities, or unusual child processes.

·        Detect unauthorized creation or modification of ASPX, DLL, JavaScript, configuration, executable, archive, script, or plugin-like artifacts under application-controlled paths.

·        Detect rare web-access paths, low-volume repeated requests, abnormal response sizes, and web shell-like interaction patterns that align with host-side execution or file modification.

·        Detect application-content tampering that changes login pages, authentication flows, JavaScript, downloadable components, external script references, or user-facing prompts.

·        Detect new outbound communication from IIS-hosted servers to rare domains, newly observed IP addresses, suspicious hosting providers, uncommon ports, or external script-hosting infrastructure.

·        Correlate user endpoint detections with application access, suspicious downloads, browser execution chains, fake component execution, or beacon-like post-download activity.

·        Use crash, fault, and application instability telemetry to identify failed exploit attempts, malformed request activity, and early targeting windows.

·        Use asset and configuration telemetry to prioritize exposed ASP.NET systems where local logging, endpoint visibility, or application ownership is incomplete.

High-Value Correlation Opportunities

The most valuable detections combine independent telemetry sources rather than relying on one indicator class.

·        Abnormal ViewState-bearing POST request followed by w3wp.exe child-process execution.

·        Abnormal ViewState-bearing POST request followed by webroot, application-directory, JavaScript, ASPX, DLL, or configuration modification.

·        Suspicious IIS child-process execution followed by outbound communication to rare or newly observed external infrastructure.

·        Unauthorized application-file modification followed by rare access to the modified path.

·        Web shell-like request patterns followed by command execution, file staging, credential access, or outbound communication.

·        Application-content modification followed by user downloads, fake security prompts, external script loading, or user endpoint malware alerts.

·        IIS application instability followed by successful low-volume access, file writes, or outbound communication.

·        Application pool identity activity followed by authentication attempts to internal hosts or access to credential-bearing files.

·        User endpoint malware activity following interaction with the affected application during the suspected exposure window.

·        Cloud, SaaS, or control-plane anomalies following credential exposure or user-side malware delivery tied to the compromised application.

Detection Gaps

The primary detection gaps involve incomplete visibility across hosted ASP.NET applications, vendor-managed deployments, encrypted request paths, weak file integrity monitoring, and limited user-exposure telemetry.

·        Organizations may not have endpoint telemetry on IIS-hosted application servers, especially when the application is vendor-managed, hosted externally, or treated as a business application rather than a security-monitored server.

·        IIS logs may not capture enough request-size, bytes-received, user identity, reverse-proxy, or ViewState-relevant metadata to distinguish suspicious requests from normal application behavior.

·        Encrypted traffic, CDN placement, reverse-proxy architecture, WAF filtering, or incomplete request retention may limit direct visibility into exploit-attempt characteristics.

·        File integrity monitoring may be absent from webroot, vendor application, upload, temporary compilation, plugin-like, JavaScript, and configuration paths.

·        Application-content tampering may be missed when JavaScript, login-page, and downloadable-component changes are not monitored against known-good baselines.

·        Web shell behavior may blend into normal web traffic when request volume is low, attacker interaction is sparse, or endpoint and file telemetry are unavailable.

·        Outbound communication may be difficult to classify when IIS servers already communicate with vendor update services, cloud platforms, content-delivery networks, monitoring tools, or third-party integrations.

·        User-impact scoping may be incomplete when proxy, browser download, DNS, secure web gateway, or endpoint telemetry is not retained for users who accessed the affected application.

·        Identity correlation may be weak when user access logs, endpoint identities, application sessions, service accounts, and cloud sign-ins cannot be reliably mapped.

·        Detection teams may lack authoritative ownership, maintenance, vendor-support, and deployment records needed to separate malicious application changes from legitimate updates.

False Positive and Over-Attribution Risks

The detection model must avoid treating common ASP.NET, IIS, or application-maintenance behavior as confirmed compromise without supporting correlation.

·        Large ViewState-bearing requests may be legitimate for some ASP.NET applications and should not be treated as compromise evidence by themselves.

·        Application errors, validation failures, worker-process restarts, and HTTP 500-series responses may reflect routine application instability, patching, traffic spikes, or deployment defects.

·        w3wp.exe child-process execution may occur during legitimate administrative workflows, vendor support activity, backup operations, reporting jobs, or application maintenance.

·        Webroot and application-directory file changes may occur during approved deployments, content updates, vendor patches, plugin updates, or emergency fixes.

·        Outbound connections from IIS-hosted servers may reflect legitimate vendor services, monitoring platforms, update repositories, certificate validation, business integrations, or content-delivery dependencies.

·        User endpoint detections after application access may be coincidental unless access logs, download telemetry, browser artifacts, proxy records, or EDR timelines support the link.

·        Cloud and SaaS activity should not be attributed to the exploit path unless upstream application compromise, credential exposure, user malware delivery, or session abuse is established.

·        Named tooling such as Godzilla / BLUEBEAM or Cobalt Strike should not be treated as required detection conditions or assumed present without supporting evidence.

Coverage Strengths

Coverage is strongest when the organization has synchronized web, endpoint, file, network, identity, and user endpoint telemetry across the application server and exposed user population.

·        Strong coverage exists when IIS or reverse-proxy logs can be correlated with EDR process lineage from the application server.

·        Strong coverage exists when file modification telemetry covers webroot, vendor application, JavaScript, ASPX, DLL, configuration, upload, plugin-like, and temporary compilation paths.

·        Strong coverage exists when outbound DNS, proxy, firewall, NDR, or network flow telemetry can identify new external communication from the IIS-hosted server.

·        Strong coverage exists when application-change records, deployment logs, vendor-support logs, and known-good baselines can distinguish authorized updates from suspicious changes.

·        Strong coverage exists when user access logs can identify users, systems, browsers, and sessions that interacted with the application during the suspected exposure window.

·        Strong coverage exists when user endpoint telemetry can validate suspicious downloads, fake component execution, beaconing, or post-download malware behavior.

·        Strong coverage exists when asset inventory identifies externally exposed ASP.NET applications, application owners, application pool identities, vendor-managed portals, and ViewState-dependent workflows.

·        Strong coverage exists when identity telemetry can trace unusual logons, service account use, lateral movement attempts, or cloud activity back to exposed users or systems.

Coverage Weaknesses

Coverage is weakest when the environment treats the affected ASP.NET application as a black-box business system with limited host, file, and application visibility.

·        Weak coverage exists when only perimeter logs are available and no endpoint telemetry is collected from the IIS-hosted server.

·        Weak coverage exists when application logs are unavailable, incomplete, vendor-controlled, or retained for too short a period.

·        Weak coverage exists when reverse-proxy, WAF, CDN, and IIS logs cannot be connected to the same session, source, path, or time window.

·        Weak coverage exists when application directories are excluded from file integrity monitoring or EDR file-event collection.

·        Weak coverage exists when deployment records and vendor-support activity are not centrally recorded.

·        Weak coverage exists when outbound server communication is not baselined or is allowed broadly without destination classification.

·        Weak coverage exists when user endpoint telemetry is incomplete, especially for external users, unmanaged devices, contractors, students, or partners.

·        Weak coverage exists when application owners cannot confirm ViewState usage, machineKey governance, deployment timelines, or known-good application content.

·        Weak coverage exists when cloud, SaaS, and identity telemetry cannot be linked to application access or user endpoint activity.

Hunt Opportunities

Hunting should prioritize high-confidence behavior chains and exposure-driven scoping before moving to production alerting.

·        Hunt for exposed ASP.NET endpoints with abnormal ViewState-bearing POST activity and unusual request-size patterns.

·        Hunt for w3wp.exe or application pool identities spawning command shells, script interpreters, archive utilities, living-off-the-land binaries, or network utilities.

·        Hunt for newly created or modified ASPX, DLL, JavaScript, configuration, archive, executable, script, or plugin-like artifacts under application-controlled paths.

·        Hunt for rare web paths accessed after recent file creation or modification.

·        Hunt for low-volume repeated requests with unusual parameters, abnormal response sizes, or timing that aligns with host-side execution.

·        Hunt for IIS-hosted servers initiating new outbound DNS, TLS, proxy, firewall, or network connections after suspicious request activity.

·        Hunt for application-content changes that introduce external script references, fake authentication prompts, unusual downloadable components, or modified login workflows.

·        Hunt for user endpoints that accessed the affected application and then downloaded suspicious files, executed fake components, or showed beacon-like behavior.

·        Hunt for service account, application pool identity, or local administrator activity from the application server that deviates from normal workflows.

·        Hunt for cloud or SaaS activity tied to users or systems exposed through the compromised application, but only after upstream application or user-endpoint evidence is established.

Alerting Opportunities

Alerting should be reserved for correlation patterns that have enough supporting evidence to justify SOC triage without creating excessive noise.

·        Alert when abnormal ViewState-bearing request activity is followed by IIS worker-process child execution.

·        Alert when w3wp.exe or an application pool identity writes suspicious files into application-controlled paths and those files are later accessed over HTTP.

·        Alert when rare web-access paths align with process execution, file creation, or outbound communication from the same application server.

·        Alert when application-content modification affects login pages, JavaScript, downloadable components, or user-facing prompts outside approved deployment windows.

·        Alert when IIS-hosted servers initiate outbound communication to rare external infrastructure shortly after suspicious web activity or file modification.

·        Alert when web shell-like request patterns align with command execution, file staging, credential access, or outbound communication.

·        Alert when users who accessed the affected application show suspicious download execution, fake component behavior, or beacon-like activity.

·        Alert when application pool identities or service accounts initiate unusual internal authentication, administrative connections, or credential-access behavior after suspected application compromise.

Residual Gaps After Detection Deployment

Even with strong telemetry, residual gaps remain because attackers can change payload shape, interaction timing, infrastructure, web shell family, and user-delivery methods.

·        Detection may miss exploit attempts that fail silently and do not produce application errors, process execution, or file changes.

·        Detection may miss server-side execution if endpoint telemetry is absent, degraded, delayed, or blocked by hosted or vendor-managed constraints.

·        Detection may miss fileless or memory-resident activity if runtime and memory telemetry are limited.

·        Detection may miss web shell interaction if attacker traffic blends into normal application access and host-side effects are not captured.

·        Detection may miss application-content tampering if the environment lacks known-good baselines or content-change monitoring.

·        Detection may miss user-side delivery when users access the application from unmanaged devices or external networks outside telemetry coverage.

·        Detection may miss lateral movement when identity telemetry, service account mapping, or internal network visibility is incomplete.

·        Detection may miss cloud impact when exposed credentials are used outside the observed application or endpoint timeline.

·        Detection may remain unable to prove ViewState exploitation if evidence begins only after compromise and no request, application, or timing correlation remains.

Operational Gap Closure Priorities

Gap closure should focus on improving correlation readiness, reducing blind spots around IIS-hosted applications, and preparing detection logic for controlled production deployment.

·        Confirm inventory of externally exposed ASP.NET applications, ViewState-dependent workflows, application owners, application pool identities, vendor-managed portals, and legacy LMS systems.

·        Ensure IIS, reverse-proxy, WAF, load balancer, CDN, and application logs retain enough metadata and history to support exploit-attempt and exposure-window reconstruction.

·        Deploy or validate endpoint telemetry on IIS-hosted servers, including process lineage, command line, user context, file writes, network connections, and suspicious runtime behavior.

·        Add file integrity monitoring for webroot, vendor application, upload, JavaScript, configuration, plugin-like, and temporary compilation directories.

·        Baseline normal outbound communication from IIS-hosted application servers and classify vendor, monitoring, update, business-integration, and content-delivery destinations.

·        Preserve known-good application baselines, deployment records, vendor-support logs, and change-control evidence for application directories and user-facing content.

·        Improve user-exposure scoping by retaining proxy, DNS, secure web gateway, browser download, and endpoint telemetry for users who access exposed applications.

·        Improve identity enrichment so application access, user endpoint activity, service account behavior, lateral movement, and cloud activity can be correlated.

·        Validate alert logic against local field mappings, index names, sourcetypes, normal maintenance activity, vendor workflows, exception lists, and SOC triage procedures before production deployment.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

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

·        NDR / Network Behavioral Analytics is conditionally viable for detecting suspicious network behavior associated with ASP.NET ViewState abuse, IIS-hosted application exposure, abnormal inbound POST behavior, web shell-like access patterns, server-side callback behavior, external script or payload retrieval, user-delivery staging, and infrastructure expansion from the IIS application boundary.

·        NDR / Network Behavioral Analytics is strongest where network-flow telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, WAF telemetry, CDN logs, reverse proxy logs, load balancer logs, IIS web logs, destination enrichment, asset inventory, ASP.NET application context, IIS server context, application pool context, approved dependency maps, approved outbound destination inventories, and SIEM correlation can be combined.

·        NDR / Network Behavioral Analytics can identify suspicious sequencing between abnormal ViewState-bearing POST activity, application response anomalies, unusual DNS activity, callback-like egress, rare path access, web shell-like interaction timing, external script retrieval, unexpected internal service access, identity-service interaction, cloud API activity, and management-plane interaction.

·        NDR / Network Behavioral Analytics is not a standalone source for confirming ASP.NET ViewState deserialization, shared machineKey exploitation, web shell deployment, Cobalt Strike delivery, credential theft, cloud compromise, or actor attribution because payload structure, ViewState validation behavior, server-side process execution, application file changes, and application state changes may not be fully visible in network telemetry.

·        NDR / Network Behavioral Analytics rules must be correlated with WAF logs, CDN logs, reverse proxy logs, load balancer logs, IIS web logs, IIS error logs, ASP.NET application logs, endpoint telemetry, file telemetry, identity logs, cloud logs, asset inventory, vulnerability context, change-control records, and SIEM enrichment before classifying activity as probable compromise.

·        NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for exploit-attempt detection, callback detection, web shell interaction identification, user-delivery scoping, internal movement identification, blast-radius scoping, and post-exploitation triage, not direct CVE confirmation or actor attribution by itself.

·        NDR / Network Behavioral Analytics rules should not generate high-confidence alerting from network-only anomalies, large POST requests alone, destination novelty alone, unusual DNS alone, inbound request volume alone, rare path access alone, cloud API access alone, metadata endpoint access alone, direct database access alone, or high byte volume alone.

Rule

Abnormal ViewState-Bearing POST Activity Followed by IIS Server Outbound Anomaly

Rule Format

NDR behavioral web-to-network correlation rule suitable for network-flow telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, WAF telemetry, CDN logs, reverse proxy logs, load balancer logs, IIS web log correlation, destination enrichment, ASP.NET asset inventory, IIS server inventory, application pool context, workload-boundary enrichment, approved integration baselines, approved destination baselines, and SIEM correlation after ASP.NET asset validation, ViewState-bearing endpoint validation, inbound-request validation, IIS server attribution, destination validation, dependency-map validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious inbound request behavior against ASP.NET or IIS-hosted infrastructure followed by abnormal outbound, internal, cloud-bound, or management-plane network behavior from the same IIS application boundary.

·        Identify the network-visible portion of a ViewState request-to-post-exploitation sequence without relying on a single CVE payload, exploit string, ViewState value, machineKey material, URI path, user-agent, source IP, web shell name, or proof-of-concept pattern.

·        Prioritize activity involving internet-facing ASP.NET applications, LMS platforms, vendor-managed IIS portals, authentication-adjacent workflows, administrative-adjacent workflows, upload paths, plugin-like paths, and other application paths that normally process ViewState-bearing POST traffic.

·        Support early escalation when abnormal ASP.NET request activity is followed by unusual egress, unexpected DNS activity, external script retrieval, payload-like retrieval, internal service access, identity-service access, cloud API activity, or management-plane interaction.

·        This rule does not prove successful ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, Cobalt Strike delivery, credential theft, cloud compromise, data theft, or confirmed actor attribution without supporting web, WAF, IIS, ASP.NET, endpoint, identity, cloud, file, change-control, or incident-response evidence.

Detection Logic

·        Identify inbound POST activity against confirmed or suspected ASP.NET-facing assets.

·        Prioritize request activity involving ViewState-bearing pages, authentication-adjacent paths, administrative-adjacent paths, LMS workflows, upload paths, plugin-like paths, courseware or document delivery paths, login-related workflows, and user-facing forms.

·        Prioritize abnormal request behavior involving unusually large POST size, abnormal bytes received, repeated request variation, unexpected endpoint targeting, uncommon methods, abnormal request cadence, sparse targeted requests, repeated failures followed by successful responses, uncommon user agents, rare source ASNs, unusual geographies, hosting-provider sources, or anonymization infrastructure.

·        Correlate suspicious inbound activity to downstream network behavior from the same IIS web server, application host, load balancer backend, application pool boundary, service account, workload identity, or application boundary.

·        Increase confidence when suspicious inbound request activity is followed by newly observed outbound destinations, direct IP egress, unusual DNS lookups, uncommon destination ports, dynamic DNS infrastructure, low-reputation infrastructure, uncommon TLS SNI values, abnormal HTTP host values, or destinations outside approved ASP.NET application integration paths.

·        Increase confidence when suspicious inbound request activity is followed by access to internal services, cloud APIs, identity services, database services, backup infrastructure, monitoring systems, CI/CD systems, management consoles, or administrative interfaces outside the approved IIS application dependency map.

·        Increase confidence when response behavior shows repeated 400-series or 500-series responses followed by successful 200-series responses, response-size variation, response-time changes, redirect changes, backend timeouts, application pool instability, or error-to-success transitions against the same endpoint family.

·        Increase confidence when WAF, CDN, reverse proxy, load balancer, application gateway, or IIS telemetry shows abnormal allowed POST traffic, request-size anomalies, request normalization anomalies, suspicious allowed traffic, partial blocking, repeated retrial after blocking, or endpoint-specific probing.

·        Increase confidence when ASP.NET, IIS, endpoint, or file telemetry shows validation failures, application exceptions, worker-process instability, suspicious child-process execution, application-file changes, webroot modification, credential access, or web shell-like behavior after the suspicious request activity.

·        Reduce severity for authorized vulnerability scanning, approved penetration testing, WAF validation, uptime monitoring, search indexing, deployment automation, backup jobs, approved integrations, vendor support, managed hosting operations, documented maintenance, incident response, and known administrative activity when behavior is consistent with source, application, destination, dependency map, and time window.

·        Do not classify suspicious inbound ASP.NET request behavior as confirmed exploitation without downstream application, endpoint, file, identity, cloud, network, or incident-response evidence.

·        Do not treat large POST requests, ViewState-bearing requests, destination novelty, inbound request volume, blocked WAF events, unusual DNS, direct IP egress, non-standard internal access, cloud API activity, or high byte volume as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        DNS logs.

·        Proxy logs.

·        Secure web gateway logs where available.

·        WAF logs where available.

·        CDN logs where available.

·        Reverse proxy logs where available.

·        Load balancer logs where available.

·        IIS web server access logs where available.

·        IIS web server error logs where available.

·        NDR session metadata.

·        Source IP, hostname, device identity, service account, workload identity, user agent, ASN, geolocation, network type, and reputation where available.

·        Destination IP, domain, hostname, port, category, ASN, geolocation, reputation, first-seen timestamp, and domain age where available.

·        TLS SNI, HTTP host, URL path, request method, request size, bytes received, bytes sent, response size, response code, response timing, protocol, directionality, timestamp, session duration, byte count, and connection count where available.

·        Internal service classification.

·        Database destination classification.

·        Cloud service classification.

·        Identity-service destination classification.

·        CI/CD destination classification.

·        Management-plane destination classification.

·        ASP.NET asset inventory.

·        IIS server inventory.

·        Internet-facing exposure inventory.

·        ViewState-bearing endpoint inventory where available.

·        Application pool identity mapping where available.

·        WAF placement context.

·        CDN path context.

·        Reverse proxy path context.

·        Load balancer backend mapping.

·        Approved ASP.NET dependency map.

·        Approved application integration inventory.

·        Approved outbound destination inventory.

·        Approved database dependency inventory.

·        Approved cloud service dependency inventory.

·        Vulnerability and patch context.

·        ASP.NET application logs where available.

·        IIS failed request tracing where available.

·        Endpoint telemetry where available.

·        File telemetry where available.

·        Cloud control-plane telemetry where available.

·        Identity logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Approved scanner inventory.

·        Approved penetration testing inventory.

·        Approved incident-response activity records.

·        Managed hosting operation records where available.

Engineering Implementation Instructions

·        Build ASP.NET-facing asset groups covering internet-facing IIS web servers, load balancer backends, application hosts, application pools, service accounts, workload identities, vendor-managed portals, LMS systems, authentication-adjacent portals, and hosting boundaries.

·        Build ASP.NET endpoint groups for ViewState-bearing pages, authentication-adjacent workflows, administrative-adjacent workflows, user-facing forms, upload paths, plugin-like paths, login-related workflows, document delivery paths, courseware delivery paths, and other state-bearing application paths.

·        Build suspicious request-behavior groups for abnormal POST size, abnormal bytes received, endpoint-specific request bursts, sparse targeted requests, repeated request variation, response-code shifts, error-to-success patterns, abnormal response size, abnormal request cadence, unusual user agents, rare source ASNs, hosting-provider sources, anonymization infrastructure, and unusual geography.

·        Build downstream network anomaly groups for newly observed outbound destinations, direct IP egress, unusual DNS lookups, uncommon ports, dynamic DNS destinations, low-reputation destinations, rare TLS SNI values, unusual HTTP host values, destinations outside approved integrations, internal service access anomalies, database-path anomalies, cloud API activity, identity-service access, CI/CD access, backup-system access, monitoring-system access, and management-plane interaction.

·        Validate whether NDR, DNS, proxy, secure web gateway, WAF, CDN, reverse proxy, load balancer, IIS logs, ASP.NET application logs, endpoint telemetry, file telemetry, cloud logs, identity logs, and SIEM telemetry can reliably join on asset, source IP, destination IP, hostname, application pool, service account, workload identity, request path, timestamp, and session context.

·        Use dynamic baselines by ASP.NET application, endpoint family, source ASN, source geography, source reputation, request method, response code, request size, bytes received, destination category, outbound destination, internal dependency, cloud service, application pool identity, service account, and time of day.

·        Use shorter correlation windows when suspicious inbound request activity is followed immediately by unusual egress, DNS lookup, internal service access, cloud API activity, or non-standard database access.

·        Use moderate correlation windows when suspicious inbound activity is followed by ASP.NET application errors, IIS instability, failed request traces, application-file changes, repeated internal connection attempts, or progressive internal service discovery.

·        Use longer correlation windows for delayed callback behavior, low-and-slow internal discovery, staged outbound communication, repeated rare destination access, or slow post-exploitation expansion.

·        Add severity weighting for internet-facing exposure, business criticality, authentication adjacency, LMS or portal exposure, abnormal response behavior, source novelty, destination novelty, rare outbound communication, identity-service access, cloud API access, workload-boundary deviation, and corroborating endpoint or file telemetry.

·        Treat newly observed source clusters, unusual ASNs, anonymization infrastructure, hosting-provider sources, unfamiliar geographies, unusual user agents, direct IP egress, and unusual DNS behavior as confidence amplifiers, not standalone detection criteria.

·        Avoid broad suppression for cloud providers, CDNs, hosting providers, developer platforms, object storage, monitoring platforms, backup services, managed hosting destinations, vendor support destinations, or CI/CD systems without validation because legitimate workflows and attacker staging paths may overlap.

·        Use change-management records, maintenance windows, approved scanner lists, penetration testing records, deployment records, backup schedules, managed hosting records, incident-response records, and approved integration inventories as triage evidence before classifying activity as suspicious.

·        Validate all environment variables, ASP.NET asset groups, endpoint groups, suspicious request patterns, destination groups, dependency maps, workload-boundary mappings, service-account mappings, timing windows, enrichment fields, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until field availability, correlation reliability, baseline quality, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to a durable web-to-network exploitation sequence rather than static CVE strings, known payloads, known URIs, user agents, source infrastructure, ViewState values, machineKey material, or destination novelty alone.

·        The rule remains useful if an adversary changes request syntax, payload encoding, infrastructure, source ASN, timing, endpoint order, outbound destination, cloud service, web shell family, or post-exploitation tooling.

·        The score is supported by the durability of suspicious ASP.NET request behavior, abnormal response behavior, downstream egress, internal service access, workload-boundary deviation, and cross-layer enrichment.

·        The score is constrained by TLS visibility limits, upstream traffic termination, incomplete request-size visibility, shared hosting, NAT, proxy aggregation, incomplete workload-boundary mapping, missing ASP.NET application logs, and missing endpoint telemetry.

·        The rule is durable as a supporting NDR correlation but should not be treated as standalone proof of exploitation, actor attribution, or confirmed compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on NDR visibility, DNS visibility, proxy visibility, WAF context, CDN context, IIS logs, destination enrichment, asset inventory, dependency mapping, workload-boundary mapping, and reliable source-to-asset correlation.

·        Operational confidence is reduced where network telemetry cannot distinguish request structure, ViewState-bearing endpoint behavior, upload or download directionality, application route context, or internal dependency intent.

·        Operational confidence is reduced where ASP.NET assets have broad approved egress, shared hosting infrastructure, incomplete dependency maps, or high-volume legitimate scanning and monitoring activity.

·        Full-telemetry confidence improves when NDR events are enriched with WAF logs, CDN logs, reverse proxy logs, load balancer logs, IIS web logs, ASP.NET application logs, IIS failed request traces, endpoint telemetry, file telemetry, cloud logs, identity context, vulnerability context, and change-control records.

·        Even under full telemetry conditions, this rule should support incident escalation and scoping rather than standalone confirmation of ViewState deserialization or shared machineKey exploitation.

Limitations

·        This rule detects suspicious network behavior after ASP.NET-facing request anomalies, not confirmed exploitation by itself.

·        NDR may not observe full request parameters, request bodies, decoded payloads, normalized payloads, ViewState validation behavior, application state changes, file writes, or server-side process execution.

·        TLS encryption, upstream traffic termination, CDN abstraction, proxy aggregation, NAT, shared hosting, managed hosting, and hosting-provider abstraction may reduce fidelity.

·        Legitimate vulnerability scanning, penetration testing, WAF validation, uptime monitoring, deployment automation, backup activity, managed hosting operations, vendor support, incident response, and approved integrations can produce similar network patterns.

·        Missing ASP.NET application logs, IIS failed request traces, endpoint telemetry, or file telemetry significantly reduces confidence that suspicious network behavior reflects exploitation rather than benign malformed traffic or routine operations.

·        Missing workload identity, application pool identity, service-account, dependency-map, and approved-integration enrichment increases false positives.

·        The rule may miss exploitation that remains fully inside application, endpoint, file, identity, or database telemetry without observable egress, internal movement, or network-visible expansion.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR ASP.NET web-to-network correlation query pattern requiring platform syntax validation, ASP.NET asset validation, ViewState-bearing endpoint validation, WAF correlation validation, IIS log correlation validation, workload-boundary validation, destination categorization validation, dependency-map validation, baseline validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS InboundAspNetActivity
WHERE InboundAspNetActivity.Direction IN ANY (
"INBOUND",
"EXTERNAL_TO_INTERNAL",
"CLIENT_TO_SERVER",
"WEB_REQUEST"
)
AND InboundAspNetActivity.DestinationAsset IN ASSET_GROUP(
"ASP.NET Facing Assets",
"Internet Facing ASP.NET Assets",
"IIS Load Balancer Backends",
"IIS Application Hosts",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"Authentication Adjacent ASP.NET Applications",
"IIS Application Boundaries"
)
AND (
InboundAspNetActivity.RequestPathCategory IN ANY (
"viewstate_bearing_endpoint",
"aspnet_webforms_endpoint",
"aspnet_authentication_adjacent",
"aspnet_administrative_adjacent",
"aspnet_upload_path",
"aspnet_plugin_like_path",
"aspnet_login_workflow",
"aspnet_document_delivery",
"aspnet_lms_workflow",
"state_bearing_application_path"
)
OR InboundAspNetActivity.RequestPattern IN ANY (
"abnormal_post_size",
"abnormal_bytes_received",
"unusual_post_frequency",
"sparse_targeted_requests",
"repeated_request_variation",
"unexpected_endpoint_targeting",
"abnormal_request_cadence",
"suspicious_allowed_web_activity"
)
OR InboundAspNetActivity.ResponsePattern IN ANY (
"repeated_400_series",
"repeated_500_series",
"error_then_success",
"response_size_variation",
"response_time_anomaly",
"redirect_change",
"backend_timeout",
"application_pool_instability"
)
OR InboundAspNetActivity.SourceContext IN ANY (
"newly_observed_source",
"rare_asn",
"unusual_geography",
"anonymization_infrastructure",
"suspicious_hosting",
"source_cluster_with_limited_history"
)
)
AND EVENT_NEAR WITHIN ENV_ASPNET_REQUEST_TO_NETWORK_WINDOW (
NetworkEvent AS DownstreamActivity
WHERE DownstreamActivity.SourceAsset IN SAME_APPLICATION_BOUNDARY(InboundAspNetActivity.DestinationAsset)
AND DownstreamActivity.Direction IN ANY (
"OUTBOUND",
"INTERNAL",
"EAST_WEST",
"CLOUD_BOUND",
"MANAGEMENT_PLANE"
)
AND (
DownstreamActivity.DestinationReputation IN ANY (
"rare",
"newly_observed",
"unknown",
"suspicious",
"high_risk"
)
OR DownstreamActivity.DestinationPattern IN ANY (
"direct_ip_egress",
"unusual_dns_lookup",
"dynamic_dns_destination",
"uncommon_destination_port",
"rare_sni",
"unusual_http_host",
"destination_outside_approved_integration"
)
OR DownstreamActivity.InternalAccessPattern IN ANY (
"internal_service_access_anomaly",
"non_standard_database_path",
"backup_infrastructure_access",
"management_interface_access"
)
OR DownstreamActivity.CloudAccessPattern IN ANY (
"cloud_api_access",
"identity_service_access",
"cicd_resource_access",
"management_plane_access"
)
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_APPLICATION_CONTEXT_WINDOW (
AspNetEvent.EventType IN ANY (
"ViewState Validation Failure",
"ASP.NET Exception",
"Unhandled Application Exception",
"Application Pool Recycle",
"Failed Request Trace",
"Authentication Workflow Anomaly",
"Configuration Changed",
"Application File Changed",
"Administrative Workflow Anomaly"
)
AND AspNetEvent.Asset IN SAME_APPLICATION_BOUNDARY(InboundAspNetActivity.DestinationAsset)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_OR_FILE_CONTEXT_WINDOW (
EndpointEvent.EventType IN ANY (
"Web Process Spawned Shell",
"IIS Worker Process Child Execution",
"Unexpected File Write",
"Web Shell Like Artifact",
"Credential Access",
"Local Discovery",
"Archive Creation",
"Persistence Attempt"
)
AND EndpointEvent.Asset IN SAME_APPLICATION_BOUNDARY(InboundAspNetActivity.DestinationAsset)
)
AND InboundAspNetActivity.SourceIP NOT IN ASSET_GROUP(
"Approved Vulnerability Scanners",
"Approved Penetration Testing Infrastructure",
"Approved WAF Validation Sources",
"Approved Uptime Monitoring Sources",
"Approved Search Indexing Sources"
)
AND DownstreamActivity.Destination NOT IN ASSET_GROUP(
"Approved ASP.NET Integrations",
"Approved ASP.NET Update Destinations",
"Approved Monitoring Destinations",
"Approved Backup Destinations",
"Approved Managed Hosting Destinations",
"Approved Deployment Destinations",
"Approved Database Dependencies",
"Approved Cloud Service Dependencies"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_maintenance",
"approved_backup_activity",
"approved_managed_hosting_operation",
"approved_penetration_test",
"approved_vulnerability_scan",
"approved_vendor_support",
"approved_incident_response_activity"
)

Rule

ASP.NET Web Shell-Like Interaction or Rare Path Access After Suspicious Request Activity

Rule Format

NDR behavioral web-interaction correlation rule suitable for network-flow telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, WAF telemetry, CDN logs, reverse proxy logs, load balancer logs, IIS web logs, path-frequency baselines, response-size baselines, source enrichment, application-path inventory, webroot change context, endpoint correlation, file telemetry correlation, ASP.NET asset inventory, IIS server inventory, approved administrative path inventories, approved vendor-support path inventories, and SIEM correlation after rare-path validation, application workflow validation, file-change validation, source validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect web shell-like interaction patterns against ASP.NET application endpoints after suspicious inbound request activity.

·        Identify rare, newly observed, low-frequency, or sparse interactive access to ASP.NET paths that may represent attacker interaction with a web shell or newly placed application artifact.

·        Prioritize activity involving upload directories, plugin-like paths, temporary application paths, newly observed ASPX endpoints, administrative-adjacent paths, authentication-adjacent paths, vendor application folders, and application paths that recently changed.

·        Support escalation when rare path access aligns with abnormal ViewState-bearing request activity, unusual response-size patterns, IIS child-process execution, file modification, outbound communication, credential access, or post-exploitation behavior.

·        This rule does not prove web shell deployment, server compromise, ViewState deserialization, credential theft, Cobalt Strike delivery, or actor attribution without supporting file, endpoint, IIS, ASP.NET, identity, network, change-control, or incident-response evidence.

Detection Logic

·        Identify rare, newly observed, or low-frequency access paths within confirmed or suspected ASP.NET-facing assets.

·        Prioritize paths associated with ASPX files, upload directories, plugin-like directories, vendor application directories, temporary application paths, authentication-adjacent workflows, administrative-adjacent workflows, recently modified application content, and paths not previously seen in normal user workflows.

·        Prioritize request behavior involving repeated low-volume interaction, sparse interactive timing, unusual parameters, abnormal response-size patterns, uncommon user agents, missing or unusual referrers, repeated access from limited source infrastructure, hosting-provider sources, rare ASNs, anonymization services, or geographies inconsistent with the user population.

·        Correlate rare path access with prior abnormal ViewState-bearing POST activity, application errors, request-size anomalies, response-code shifts, or other suspicious ASP.NET request behavior against the same application boundary.

·        Increase confidence when rare path access follows file creation, file modification, application-content change, new path discovery, or approved-baseline deviation in the same application directory.

·        Increase confidence when rare path access aligns with IIS worker-process child execution, command-shell activity, script interpreter execution, archive activity, payload staging, credential access, or outbound communication from the application server.

·        Increase confidence when the same path shows interactive timing, repeated low-volume access, response-size variation, command-like request cadence, or source concentration inconsistent with normal browser-driven workflows.

·        Increase confidence when access is observed from infrastructure not expected for normal users, administrators, vendors, monitoring services, support teams, or search indexing.

·        Reduce severity for approved administrative panels, vendor-support workflows, deployment validation, application health checks, monitoring probes, API workflows, search indexing, content publication, courseware updates, and documented maintenance when behavior is consistent with source, destination, path, user population, and time window.

·        Do not classify rare ASP.NET path access as web shell activity without supporting file, endpoint, process, response-size, timing, authentication, or incident-response evidence.

·        Do not rely on web shell filenames, static path names, known shell markers, password parameter names, exploit payload syntax, or named tool families as required detection conditions.

Required Telemetry

·        Network-flow telemetry.

·        WAF logs where available.

·        CDN logs where available.

·        Reverse proxy logs where available.

·        Load balancer logs where available.

·        IIS web server access logs where available.

·        IIS web server error logs where available.

·        NDR session metadata.

·        Proxy logs where available.

·        Secure web gateway logs where available.

·        DNS logs where available.

·        Source IP, hostname, device identity, user agent, ASN, geolocation, network type, and reputation where available.

·        Destination IP, hostname, and application context.

·        URL path, URI stem, URI query, request method, request frequency, request timing, referrer, response code, response size, response timing, bytes sent, bytes received, session duration, and connection count where available.

·        Path first-seen timestamp where available.

·        Path frequency baseline.

·        Endpoint family classification.

·        Application path classification.

·        Upload path classification.

·        Plugin-like path classification.

·        Administrative path classification.

·        Authentication-adjacent path classification.

·        Vendor-support path classification.

·        ASP.NET asset inventory.

·        IIS server inventory.

·        Webroot path inventory where available.

·        Approved application path inventory.

·        Approved administrative path inventory.

·        Approved vendor-support path inventory.

·        Approved monitoring path inventory.

·        File modification telemetry where available.

·        File integrity telemetry where available.

·        Endpoint process telemetry where available.

·        Application deployment records.

·        Vendor-support records.

·        Change-control records.

·        Maintenance-window records.

·        Approved scanner inventory.

·        Approved monitoring inventory.

·        Approved search indexing inventory.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build ASP.NET application path groups covering known user-facing paths, ViewState-bearing paths, upload paths, plugin-like paths, administrative paths, authentication-adjacent paths, vendor application paths, temporary application paths, document delivery paths, LMS workflow paths, and approved API paths.

·        Build rare path baselines by application, endpoint family, source population, user-agent pattern, referrer behavior, response size, response code, request timing, and time of day.

·        Build suspicious interaction groups for repeated low-volume access, sparse interactive timing, unusual parameters, abnormal response-size patterns, uncommon user agents, missing referrers, source concentration, hosting-provider sources, rare ASNs, anonymization infrastructure, and geographies inconsistent with the user population.

·        Build precursor groups for abnormal ViewState-bearing POST activity, abnormal request-size behavior, repeated request variation, application errors, response-code shifts, error-to-success transitions, and other suspicious ASP.NET request behavior.

·        Build correlation groups for file creation, file modification, application-content change, IIS worker-process child execution, outbound communication, credential access, payload staging, and post-exploitation behavior where host telemetry is available.

·        Validate whether NDR, WAF, CDN, reverse proxy, load balancer, IIS web logs, proxy logs, endpoint telemetry, file telemetry, application deployment records, vendor-support records, and SIEM telemetry can reliably join on asset, path, hostname, source IP, timestamp, session context, and application boundary.

·        Use shorter correlation windows when rare path access follows recent file modification, application-content change, abnormal ViewState-bearing request activity, or IIS child-process execution.

·        Use moderate correlation windows when rare path access follows application errors, endpoint-specific probing, repeated failed requests, or suspicious request clusters.

·        Use longer correlation windows for low-and-slow web shell interaction, delayed operator return, staged access to newly created paths, or repeated sparse interaction from limited source infrastructure.

·        Add severity weighting for newly observed paths, ASPX path novelty, upload-path access, plugin-like path access, rare source infrastructure, response-size anomalies, prior suspicious request activity, file modification, IIS process execution, and outbound communication.

·        Treat source novelty, rare path access, missing referrer, uncommon user agent, and low-volume interaction as confidence amplifiers, not standalone detection criteria.

·        Avoid broad suppression for administrative paths, vendor-support paths, monitoring paths, deployment validation paths, and API paths without application-owner validation because legitimate workflows and attacker interaction paths may overlap.

·        Use deployment records, release notes, content update records, vendor-support tickets, maintenance windows, search indexing inventories, approved scanner records, and incident-response records as triage evidence before classifying activity as suspicious.

·        Validate all application path groups, rare-path thresholds, source-population baselines, response-size baselines, timing windows, enrichment fields, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until path baselines, application-owner validation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and evidence requirements are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to rare ASP.NET path interaction after suspicious request activity rather than static web shell names, known file paths, password parameters, source IPs, user agents, or named tooling.

·        The rule remains useful if an adversary changes web shell filename, path location, parameter names, user-agent, interaction timing, source infrastructure, or web shell family.

·        The score is supported by the durability of rare path access, sparse interactive timing, abnormal response-size behavior, source concentration, prior suspicious ASP.NET activity, and cross-layer correlation with file or endpoint telemetry.

·        The score is constrained by dynamic application paths, legitimate administrative activity, vendor-support workflows, upload workflows, monitoring probes, application updates, and incomplete file or endpoint telemetry.

·        The rule is durable as a web shell interaction detector but should not be treated as standalone proof that a web shell exists.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on rare-path baselines, source enrichment, response-size visibility, IIS web log fidelity, WAF or reverse-proxy context, file telemetry, endpoint telemetry, and application-owner validation.

·        Operational confidence is reduced where applications use dynamic paths, plugin systems, frequent content updates, vendor-support sessions, sparse administrative workflows, or custom API patterns.

·        Operational confidence is reduced where NDR cannot confirm whether the path corresponds to a newly created or modified application artifact.

·        Full-telemetry confidence improves when rare path access is enriched with file modification telemetry, IIS worker-process execution, outbound communication, application deployment records, vendor-support records, and change-control context.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of web shell deployment.

Limitations

·        This rule detects web shell-like interaction patterns, not confirmed web shell deployment by itself.

·        Rare or newly observed ASP.NET paths may be legitimate after deployments, content updates, plugin changes, vendor support, administrative maintenance, or API changes.

·        Sparse interactive timing may resemble legitimate troubleshooting, vendor support, administrative work, or monitoring validation.

·        NDR may not observe full request parameters, command content, file contents, or server-side process execution.

·        Missing file telemetry or endpoint telemetry reduces confidence that rare path access reflects malicious artifact interaction.

·        Dynamic application routing, upload workflows, plugin systems, and vendor-managed portals can increase false positives.

·        The rule may miss web shell interaction that uses normal paths, blends into legitimate workflows, or occurs from expected administrative infrastructure.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR ASP.NET rare-path and web shell-like interaction query pattern requiring platform syntax validation, ASP.NET application validation, path-baseline validation, rare-path validation, response-size validation, source-context validation, file-change validation, endpoint-correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS AspNetRarePathActivity
WHERE AspNetRarePathActivity.Direction IN ANY (
"INBOUND",
"EXTERNAL_TO_INTERNAL",
"CLIENT_TO_SERVER",
"WEB_REQUEST"
)
AND AspNetRarePathActivity.DestinationAsset IN ASSET_GROUP(
"ASP.NET Facing Assets",
"Internet Facing ASP.NET Assets",
"IIS Application Hosts",
"IIS Load Balancer Backends",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"Authentication Adjacent ASP.NET Applications",
"IIS Application Boundaries"
)
AND (
AspNetRarePathActivity.PathContext IN ANY (
"newly_observed_path",
"rare_path_for_application",
"rare_path_for_endpoint_family",
"upload_path_access",
"plugin_like_path_access",
"temporary_application_path_access",
"new_aspx_path_access",
"administrative_adjacent_path_access",
"authentication_adjacent_path_access",
"recently_modified_path_access"
)
OR AspNetRarePathActivity.InteractionPattern IN ANY (
"repeated_low_volume_requests",
"sparse_interactive_timing",
"unusual_parameter_pattern",
"abnormal_response_size",
"response_size_variation",
"missing_referrer",
"uncommon_user_agent",
"source_concentration",
"command_like_request_cadence"
)
OR AspNetRarePathActivity.SourceContext IN ANY (
"rare_asn",
"unusual_geography",
"anonymization_infrastructure",
"suspicious_hosting",
"limited_source_history",
"source_not_expected_for_user_population"
)
)
AND EVENT_NEAR WITHIN ENV_ASPNET_RARE_PATH_PRECURSOR_WINDOW (
NetworkEvent AS AspNetPrecursorActivity
WHERE AspNetPrecursorActivity.DestinationAsset IN SAME_APPLICATION_BOUNDARY(AspNetRarePathActivity.DestinationAsset)
AND (
AspNetPrecursorActivity.RequestPathCategory IN ANY (
"viewstate_bearing_endpoint",
"aspnet_webforms_endpoint",
"aspnet_authentication_adjacent",
"aspnet_administrative_adjacent",
"aspnet_upload_path",
"aspnet_plugin_like_path",
"state_bearing_application_path"
)
OR AspNetPrecursorActivity.RequestPattern IN ANY (
"abnormal_post_size",
"abnormal_bytes_received",
"unusual_post_frequency",
"sparse_targeted_requests",
"repeated_request_variation",
"suspicious_allowed_web_activity"
)
OR AspNetPrecursorActivity.ResponsePattern IN ANY (
"repeated_400_series",
"repeated_500_series",
"error_then_success",
"response_size_variation",
"response_time_anomaly",
"backend_timeout"
)
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_FILE_CONTEXT_WINDOW (
FileEvent.EventType IN ANY (
"New File Created",
"Application File Modified",
"Webroot File Modified",
"ASPX File Created",
"DLL File Created",
"JavaScript File Modified",
"Configuration File Modified",
"Suspicious Temporary File Created"
)
AND FileEvent.Asset IN SAME_APPLICATION_BOUNDARY(AspNetRarePathActivity.DestinationAsset)
AND FileEvent.FilePath IN SAME_OR_RELATED_PATH(AspNetRarePathActivity.RequestPath)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent.EventType IN ANY (
"IIS Worker Process Child Execution",
"Web Process Spawned Shell",
"Command Shell Execution",
"Script Interpreter Execution",
"Archive Utility Execution",
"Credential Access",
"Outbound Connection From IIS Process",
"Persistence Attempt"
)
AND EndpointEvent.Asset IN SAME_APPLICATION_BOUNDARY(AspNetRarePathActivity.DestinationAsset)
)
AND AspNetRarePathActivity.RequestPath NOT IN ASSET_GROUP(
"Approved Administrative Paths",
"Approved API Paths",
"Approved Vendor Support Paths",
"Approved Monitoring Paths",
"Approved Deployment Validation Paths",
"Approved Search Indexing Paths",
"Approved Health Check Paths"
)
AND AspNetRarePathActivity.SourceIP NOT IN ASSET_GROUP(
"Approved Administrators",
"Approved Vendor Support Infrastructure",
"Approved Monitoring Infrastructure",
"Approved Vulnerability Scanners",
"Approved Penetration Testing Infrastructure",
"Approved Search Indexing Sources"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_content_update",
"approved_vendor_support",
"approved_plugin_update",
"approved_application_maintenance",
"approved_monitoring_validation",
"approved_incident_response_activity"
)

Rule

IIS-Hosted Application Server External Script or Payload Retrieval Anomaly

Rule Format

NDR behavioral egress and user-delivery correlation rule suitable for network-flow telemetry, DNS telemetry, proxy telemetry, secure web gateway logs, firewall telemetry, egress gateway telemetry, WAF telemetry, CDN logs, reverse proxy logs, load balancer logs, IIS web log correlation, user web access telemetry, destination enrichment, ASP.NET asset inventory, IIS workload-boundary enrichment, approved-destination baselines, application-content change context, endpoint correlation, file telemetry correlation, and SIEM correlation after destination validation, ASP.NET precursor validation, upload or download direction validation, user-exposure validation, workload-attribution validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect external script loading, payload retrieval, callback behavior, fake component delivery, or command-and-control-like communication associated with IIS-hosted ASP.NET application compromise.

·        Identify post-exploitation network behavior that may follow ViewState abuse, application-file modification, web shell deployment, application-content tampering, credential access, or user-facing malicious content delivery.

·        Prioritize outbound activity from IIS-hosted application servers to newly observed domains, direct IP destinations, uncommon ports, dynamic DNS infrastructure, low-reputation infrastructure, rare ASNs, rare SNI values, or destinations outside approved ASP.NET integration paths.

·        Prioritize user endpoint network activity when users access the affected application and subsequently retrieve unusual files, fake components, external scripts, or suspicious content from unfamiliar infrastructure.

·        Support incident escalation when suspicious inbound ASP.NET activity is followed by unusual egress, external script retrieval, suspicious downloads, or user-side beacon-like behavior without requiring confirmed malware execution before detection.

·        This rule does not prove successful exploitation, web shell deployment, Cobalt Strike delivery, user compromise, data theft, command-and-control, or actor attribution without supporting web, WAF, ASP.NET, IIS, endpoint, DNS, proxy, file, identity, change-control, or incident-response evidence.

Detection Logic

·        Evaluate this rule through two distinct branches that may alert independently or reinforce each other when both are present.

·        Branch A should evaluate IIS server egress after suspicious ASP.NET precursor activity.

·        Branch B should evaluate user endpoint delivery after interaction with affected or modified ASP.NET application content.

·        For Branch A, identify outbound communication from IIS-hosted ASP.NET web servers, application hosts, application pools, service accounts, workload identities, or application boundaries.

·        For Branch A, correlate outbound activity to prior suspicious ASP.NET-facing inbound request activity involving the same server, application boundary, load balancer backend, application pool identity, service account, or workload identity.

·        For Branch A, prioritize inbound precursors involving ViewState-bearing endpoints, authentication-adjacent workflows, administrative-adjacent workflows, upload paths, plugin-like paths, login-related workflows, LMS workflows, or other state-bearing application paths.

·        For Branch A, prioritize egress involving newly observed domains, direct IP destinations, uncommon destination ports, dynamic DNS destinations, low-reputation infrastructure, rare ASNs, rare SNI values, unusual HTTP host values, uncommon user agents, abnormal session duration, unusual request cadence, unexpected content type, or unexpected transfer volume.

·        For Branch A, increase confidence when IIS-hosted application server egress follows application errors, IIS worker-process instability, failed request traces, application-file modification, JavaScript modification, webroot changes, credential access, endpoint execution, suspicious archive retrieval, or web shell-like path access.

·        For Branch B, identify user endpoint DNS, proxy, secure web gateway, browser download, or NDR activity after users access the affected ASP.NET application.

·        For Branch B, correlate user endpoint activity to prior access to a recently modified application page, suspicious external script reference, fake component prompt, unusual downloadable component, or application path associated with suspected compromise.

·        For Branch B, prioritize user endpoint activity involving suspicious downloads, fake component retrieval, external script loading, direct IP destination access, newly observed domains, rare SNI values, dynamic DNS infrastructure, uncommon content types, or beacon-like post-download communication.

·        For Branch B, increase confidence when the affected user endpoint accessed the application during the suspected exposure window and then executed a suspicious download, contacted unfamiliar infrastructure, or produced endpoint detections consistent with post-download malware behavior.

·        Increase confidence for either branch when DNS telemetry shows newly observed domains, randomized hostnames, dynamic DNS infrastructure, rare domains, direct infrastructure resolution, or destinations unrelated to approved ASP.NET operations.

·        Increase confidence for either branch when proxy, firewall, secure web gateway, egress gateway, or NDR telemetry identifies abnormal byte volume, unusual session duration, unusual TLS metadata, unexpected content type, repeated communication to rare infrastructure, or transfer behavior inconsistent with the source role.

·        Reduce severity for approved integrations, update checks, monitoring destinations, backup destinations, deployment platforms, vendor support, managed hosting operations, analytics platforms, content delivery workflows, disaster recovery activity, incident response, and documented maintenance when behavior is consistent with source, destination, application, and time window.

·        Do not classify IIS server egress as exploitation-related without suspicious upstream ASP.NET activity, application-content change, host evidence, or corroborating downstream telemetry.

·        Do not classify user-side downloads or beacon-like behavior as application-delivered compromise without application access evidence, user-exposure evidence, application-content change evidence, or endpoint corroboration.

·        Do not treat direct IP egress, uncommon port use, newly observed domains, dynamic DNS, rare SNI, unusual DNS, high byte volume, external script loading, or suspicious downloads as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        DNS logs.

·        Proxy logs.

·        Secure web gateway logs where available.

·        Firewall logs.

·        Egress gateway logs where available.

·        WAF logs where available.

·        CDN logs where available.

·        Reverse proxy logs where available.

·        Load balancer logs where available.

·        IIS web server logs where available.

·        IIS error logs where available.

·        NDR session metadata.

·        Source IP, hostname, device identity, workload identity, service account, application context, user agent, ASN, geolocation, network type, and reputation where available.

·        Destination IP, domain, hostname, port, category, ASN, geolocation, reputation, first-seen timestamp, and domain age where available.

·        TLS SNI, HTTP host, URL path, protocol, directionality, upload or download directionality, timestamp, session duration, byte count, connection count, transfer pattern, and content type where available.

·        ASP.NET asset inventory.

·        IIS server inventory.

·        IIS workload-boundary mapping.

·        Application pool identity mapping where available.

·        Service-account mapping where available.

·        Approved destination inventory.

·        Approved ASP.NET integration inventory.

·        Approved update path inventory.

·        Approved monitoring destination inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved vendor-support destination inventory.

·        Application-content change telemetry where available.

·        File telemetry where available.

·        Endpoint telemetry where available.

·        User access telemetry where available.

·        User endpoint DNS telemetry where available.

·        User endpoint proxy telemetry where available.

·        User endpoint secure web gateway telemetry where available.

·        Browser download telemetry where available.

·        EDR telemetry from user endpoints where available.

·        Destination reputation enrichment.

·        Newly observed destination enrichment.

·        Change-control records.

·        Maintenance-window records.

·        Managed hosting operation records where available.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build IIS workload-boundary groups covering web servers, application hosts, application pools, service accounts, workload identities, load balancer backends, vendor-managed portals, LMS systems, and hosting boundaries.

·        Build user-exposure groups covering users, devices, browsers, sessions, source networks, and endpoints that accessed the affected application during the suspected exposure window.

·        Build suspicious inbound precursor groups for ViewState-bearing endpoint activity, abnormal POST size, abnormal bytes received, authentication-adjacent workflows, administrative-adjacent workflows, upload paths, plugin-like paths, login-related workflows, response-code shifts, error-to-success patterns, backend timeouts, and suspicious allowed web activity.

·        Build application-content change groups for modified JavaScript, altered login pages, external script references, unusual downloadable components, fake component prompts, modified authentication workflows, and user-facing content changes.

·        Build destination groups for approved ASP.NET integrations, approved update paths, monitoring destinations, backup destinations, deployment destinations, vendor-support destinations, managed hosting destinations, cloud providers, developer platforms, file-transfer services, object storage, dynamic DNS, direct IP destinations, rare external destinations, and low-reputation infrastructure.

·        Build user-delivery groups for external script references, suspicious download destinations, fake component retrieval, unusual browser download paths, rare destination access after application visit, and beacon-like user endpoint communication after affected application access.

·        Implement Branch A as an IIS server egress correlation requiring suspicious ASP.NET precursor activity and unusual outbound communication from the same IIS application boundary.

·        Implement Branch B as a user delivery correlation requiring user access to the affected or modified application content followed by suspicious user endpoint download, external script retrieval, or beacon-like activity.

·        Allow Branch A and Branch B to raise separate alerts, but increase severity when both branches occur within the same incident window.

·        Validate whether NDR, DNS, proxy, firewall, secure web gateway, egress gateway, WAF, CDN, reverse proxy, load balancer, IIS logs, ASP.NET logs, endpoint telemetry, file telemetry, user endpoint telemetry, browser download telemetry, and SIEM telemetry can reliably join on asset, source IP, hostname, user, device, destination domain, timestamp, URL path, session context, and application boundary.

·        Use dynamic baselines by IIS workload, outbound destination, destination category, DNS pattern, destination first-seen time, destination reputation, destination ASN, destination geography, port, protocol, session duration, byte count, connection count, transfer pattern, service account, application pool identity, user population, and time of day.

·        Use shorter correlation windows when suspicious inbound request activity is followed by immediate DNS lookup, direct IP egress, rare destination contact, dynamic DNS contact, unusual TLS behavior, external script retrieval, suspicious download activity, or abnormal transfer volume.

·        Use moderate correlation windows when suspicious inbound activity is followed by application errors, IIS instability, file activity, endpoint execution, credential access, web shell-like access, delayed callback behavior, or user-facing content modification.

·        Use longer correlation windows for low-and-slow outbound activity, repeated rare destination reuse, delayed data staging, delayed user delivery, delayed fake component retrieval, or delayed callback behavior after suspected exploitation.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, destination novelty, destination reputation, direct IP egress, unusual port use, abnormal transfer volume, suspicious DNS behavior, external script retrieval, application-content change, JavaScript modification, suspicious file activity, credential access, endpoint execution, and user endpoint follow-on behavior.

·        Avoid broad suppression for cloud providers, CDNs, developer platforms, file-transfer services, monitoring services, update services, object storage, managed hosting destinations, vendor support destinations, or content-delivery destinations without validation because legitimate workflows and attacker staging paths may overlap.

·        Use change-management records, approved integration inventories, monitoring inventories, backup schedules, deployment records, vendor-support records, managed hosting records, disaster recovery records, and incident-response records as triage evidence before classifying activity as suspicious.

·        Validate all environment variables, destination groups, approved destination lists, IIS workload groups, user-exposure groups, inbound precursor logic, content-change logic, user-delivery logic, upload or download fields, enrichment fields, timing windows, baseline logic, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until field availability, destination baselines, workload attribution, user-exposure validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious ASP.NET-facing activity followed by IIS server egress, external script retrieval, payload retrieval, callback behavior, or user-delivery activity rather than static infrastructure, destination novelty, direct IP access, or transfer volume alone.

·        The rule remains useful if an adversary changes payload structure, callback infrastructure, DNS provider, cloud provider, user-agent, transfer method, request timing, web shell family, user-delivery method, or post-exploitation toolset.

·        The score is supported by the durability of suspicious inbound precursor activity, unusual egress, DNS novelty, destination abnormality, workload-boundary attribution, transfer timing, external script loading, user-delivery timing, and cross-layer enrichment.

·        The score is constrained by encrypted traffic, shared egress infrastructure, NAT, proxy aggregation, incomplete destination inventories, missing process-to-network mapping, missing application-content telemetry, missing user endpoint telemetry, and legitimate high-volume application workflows.

·        The rule is durable as an egress and user-delivery detection but should not be treated as standalone proof of exploitation, data theft, user compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on egress telemetry, DNS visibility, proxy visibility, firewall visibility, destination enrichment, ASP.NET asset inventory, IIS workload-boundary mapping, approved destination inventories, user access telemetry, and reliable correlation to suspicious inbound activity.

·        Operational confidence is reduced where shared egress, NAT, proxy aggregation, CDN abstraction, managed hosting, or vendor-controlled infrastructure prevents attribution to a specific IIS workload.

·        Operational confidence is reduced where approved integrations, monitoring, backup, update, deployment, analytics, content delivery, vendor support, and managed hosting workflows are not well documented.

·        Full-telemetry confidence improves when egress and user-delivery events are enriched with WAF logs, CDN logs, reverse proxy logs, IIS logs, ASP.NET application logs, endpoint telemetry, file telemetry, user endpoint telemetry, browser download telemetry, identity context, and change-control context.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of exploitation, user compromise, or data theft.

Limitations

·        This rule detects unusual outbound or user-delivery behavior after suspicious ASP.NET-facing activity, not confirmed exploitation by itself.

·        Branch A may detect legitimate IIS server egress related to integrations, update checks, monitoring workflows, backup operations, analytics services, content delivery workflows, deployment automation, disaster recovery, vendor support, managed hosting activity, or incident response.

·        Branch B may detect legitimate user downloads, training materials, courseware, browser activity, software updates, content delivery workflows, or helpdesk-guided downloads unless tied to affected application access and supporting evidence.

·        Missing DNS, proxy, firewall, secure web gateway, or egress telemetry may reduce visibility into destination category, destination reputation, transfer direction, and transfer volume.

·        Missing WAF, IIS, ASP.NET, endpoint, file, user access, or browser download telemetry may prevent confirmation that egress or user-side activity followed exploitation rather than normal application behavior.

·        Shared egress paths may make attribution to a specific IIS workload difficult.

·        Encrypted traffic may limit content visibility and prevent confirmation of file contents, commands, or data sensitivity.

·        The rule may miss attackers who complete objectives through application manipulation, credential extraction, internal movement, cloud control-plane abuse, or user delivery without obvious external script retrieval or outbound callback behavior.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR ASP.NET external script, payload retrieval, and user-delivery correlation query pattern requiring platform syntax validation, IIS workload validation, affected-user validation, inbound precursor validation, application-content validation, destination-enrichment validation, DNS correlation validation, upload or download direction validation, user-exposure validation, approved-destination validation, workload-attribution validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NETWORK_CORRELATION_RULE "IIS Hosted Application External Script Or Payload Retrieval Anomaly"

BRANCH_A_IIS_SERVER_EGRESS:

NetworkEvent AS IisServerEgress
WHERE IisServerEgress.Direction IN ANY (
"OUTBOUND",
"UPLOAD",
"DOWNLOAD",
"EXTERNAL_TRANSFER",
"CLOUD_APPLICATION_TRANSFER",
"SERVER_TO_EXTERNAL"
)
AND IisServerEgress.SourceAsset IN ASSET_GROUP(
"IIS Web Tier",
"ASP.NET Application Hosts",
"IIS Application Pools",
"IIS Service Accounts",
"IIS Workload Identities",
"IIS Load Balancer Backends",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"ASP.NET Workload Boundaries"
)
AND (
IisServerEgress.DestinationFirstSeen WITHIN ENV_NEW_DESTINATION_WINDOW
OR IisServerEgress.DomainAge <= ENV_NEW_DOMAIN_AGE_WINDOW
OR IisServerEgress.DestinationReputation IN ANY (
"rare",
"newly_observed",
"unknown",
"suspicious",
"high_risk"
)
OR IisServerEgress.DestinationPattern IN ANY (
"direct_ip_destination",
"dynamic_dns_destination",
"rare_sni",
"unusual_http_host",
"uncommon_port",
"unusual_dns_lookup",
"unexpected_user_agent",
"abnormal_session_duration",
"unexpected_transfer_volume",
"external_script_reference",
"suspicious_download_destination"
)
OR IisServerEgress.TransferPattern IN ANY (
"large_upload",
"repeated_upload",
"unusual_duration",
"callback_like_traffic",
"rare_destination_reuse",
"non_standard_protocol_use",
"unexpected_content_type",
"payload_like_retrieval"
)
)
AND EVENT_NEAR WITHIN ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW (
NetworkEvent AS InboundAspNetActivity
WHERE InboundAspNetActivity.DestinationAsset IN SAME_APPLICATION_BOUNDARY(IisServerEgress.SourceAsset)
AND InboundAspNetActivity.Direction IN ANY (
"INBOUND",
"EXTERNAL_TO_INTERNAL",
"CLIENT_TO_SERVER",
"WEB_REQUEST"
)
AND (
InboundAspNetActivity.RequestPathCategory IN ANY (
"viewstate_bearing_endpoint",
"aspnet_webforms_endpoint",
"aspnet_authentication_adjacent",
"aspnet_administrative_adjacent",
"aspnet_upload_path",
"aspnet_plugin_like_path",
"aspnet_login_workflow",
"aspnet_lms_workflow",
"state_bearing_application_path"
)
OR InboundAspNetActivity.RequestPattern IN ANY (
"abnormal_post_size",
"abnormal_bytes_received",
"unusual_post_frequency",
"sparse_targeted_requests",
"repeated_request_variation",
"suspicious_allowed_web_activity"
)
OR InboundAspNetActivity.ResponsePattern IN ANY (
"repeated_400_series",
"repeated_500_series",
"error_then_success",
"response_size_variation",
"response_time_anomaly",
"backend_timeout"
)
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_CONTENT_OR_FILE_CONTEXT_WINDOW (
FileEvent.EventType IN ANY (
"Application File Modified",
"JavaScript File Modified",
"Login Page Modified",
"External Script Reference Added",
"Downloadable Component Modified",
"Suspicious File Created",
"Configuration File Modified"
)
AND FileEvent.Asset IN SAME_APPLICATION_BOUNDARY(IisServerEgress.SourceAsset)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_IIS_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent.EventType IN ANY (
"IIS Worker Process Child Execution",
"Outbound Connection From IIS Process",
"Credential Access",
"Archive Creation",
"Web Shell Like Behavior",
"Post Exploitation Tool Staging"
)
AND EndpointEvent.Asset IN SAME_APPLICATION_BOUNDARY(IisServerEgress.SourceAsset)
)
AND IisServerEgress.DestinationDomain NOT IN ASSET_GROUP(
"Approved ASP.NET Integrations",
"Approved Update Destinations",
"Approved Monitoring Destinations",
"Approved Backup Destinations",
"Approved Deployment Destinations",
"Approved Vendor Support Destinations",
"Approved Managed Hosting Destinations",
"Approved Analytics Destinations",
"Approved Content Delivery Destinations"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_backup_activity",
"approved_monitoring_activity",
"approved_vendor_support",
"approved_managed_hosting_operation",
"approved_disaster_recovery_activity",
"approved_incident_response_activity",
"approved_application_integration"
)

BRANCH_B_USER_ENDPOINT_DELIVERY:

NetworkEvent AS UserEndpointDelivery
WHERE UserEndpointDelivery.Direction IN ANY (
"DOWNLOAD",
"CLIENT_TO_EXTERNAL",
"EXTERNAL_TRANSFER",
"CLOUD_APPLICATION_TRANSFER",
"WEB_REQUEST"
)
AND UserEndpointDelivery.SourceAsset IN ASSET_GROUP(
"User Endpoints Recently Accessing Affected Application",
"Users Exposed To Modified ASP.NET Application Content",
"Browsers Accessing Affected ASP.NET Application",
"Devices Accessing Affected LMS Or Portal"
)
AND (
UserEndpointDelivery.DestinationFirstSeen WITHIN ENV_NEW_DESTINATION_WINDOW
OR UserEndpointDelivery.DomainAge <= ENV_NEW_DOMAIN_AGE_WINDOW
OR UserEndpointDelivery.DestinationReputation IN ANY (
"rare",
"newly_observed",
"unknown",
"suspicious",
"high_risk"
)
OR UserEndpointDelivery.DestinationPattern IN ANY (
"direct_ip_destination",
"dynamic_dns_destination",
"rare_sni",
"unusual_http_host",
"uncommon_port",
"unusual_dns_lookup",
"external_script_reference",
"suspicious_download_destination",
"fake_component_destination"
)
OR UserEndpointDelivery.TransferPattern IN ANY (
"suspicious_download",
"fake_component_retrieval",
"unexpected_content_type",
"beacon_like_user_endpoint_activity",
"rare_destination_reuse",
"post_download_callback"
)
)
AND EVENT_NEAR WITHIN ENV_USER_ACCESS_TO_DELIVERY_WINDOW (
WebAccessEvent AS AffectedApplicationAccess
WHERE AffectedApplicationAccess.UserOrDevice IN SAME_USER_OR_DEVICE(UserEndpointDelivery.SourceAsset)
AND AffectedApplicationAccess.DestinationApplication IN ASSET_GROUP(
"Affected ASP.NET Application",
"Suspected Compromised ASP.NET Application",
"Modified ASP.NET Application Page",
"Affected LMS Or Portal",
"Application With Suspicious Content Change"
)
AND AffectedApplicationAccess.EventType IN ANY (
"Application Page Accessed",
"Login Page Accessed",
"Download Page Accessed",
"Modified JavaScript Page Accessed",
"External Script Loading Page Accessed",
"Fake Component Prompt Page Accessed"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_CONTENT_CHANGE_WINDOW (
FileEvent.EventType IN ANY (
"JavaScript File Modified",
"Login Page Modified",
"External Script Reference Added",
"Downloadable Component Modified",
"User Facing Content Modified",
"Suspicious File Created"
)
AND FileEvent.Asset IN ASSET_GROUP(
"Affected ASP.NET Application",
"Suspected Compromised ASP.NET Application",
"Affected LMS Or Portal"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_USER_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent.EventType IN ANY (
"Suspicious Download Executed",
"Fake Component Executed",
"Beacon Like Behavior",
"Post Download Malware Behavior",
"Suspicious Browser Child Process",
"Credential Access",
"Persistence Attempt"
)
AND EndpointEvent.Asset IN SAME_USER_OR_DEVICE(UserEndpointDelivery.SourceAsset)
)
AND UserEndpointDelivery.DestinationDomain NOT IN ASSET_GROUP(
"Approved Application Content Destinations",
"Approved LMS Content Destinations",
"Approved Training Content Destinations",
"Approved Software Distribution Destinations",
"Approved Vendor Support Destinations",
"Approved Content Delivery Destinations",
"Approved Analytics Destinations"
)
AND NOT ChangeContext IN ANY (
"approved_content_update",
"approved_training_distribution",
"approved_software_distribution",
"approved_vendor_support",
"approved_helpdesk_activity",
"approved_incident_response_activity",
"approved_application_integration"
)

ALERT LOGIC:

ALERT WHEN BRANCH_A_IIS_SERVER_EGRESS IS TRUE
OR BRANCH_B_USER_ENDPOINT_DELIVERY IS TRUE

INCREASE SEVERITY WHEN BRANCH_A_IIS_SERVER_EGRESS IS TRUE
AND BRANCH_B_USER_ENDPOINT_DELIVERY IS TRUE
WITHIN ENV_ASPNET_SERVER_TO_USER_DELIVERY_INCIDENT_WINDOW

SentinelOne

Detection Viability Assessment

SentinelOne has three rules for this EXP report.

·        SentinelOne is highly viable for detecting host-side behavior associated with ASP.NET ViewState deserialization and shared machineKey exploitation because the strongest compromise evidence often appears on IIS-hosted servers after the initial web request succeeds.

·        SentinelOne is strongest where process telemetry, parent-child process lineage, command-line telemetry, file-write telemetry, endpoint network telemetry, user context, application pool identity context, PowerShell telemetry, script execution telemetry, module-load telemetry, file reputation, signer context, and endpoint timeline data can be combined.

·        SentinelOne can identify suspicious sequencing between IIS worker-process execution, application pool identity behavior, command execution, application-file modification, webroot tampering, JavaScript modification, credential access, outbound communication, archive staging, defense evasion, persistence attempts, and post-exploitation tool behavior.

·        SentinelOne is not a standalone source for confirming the original exploit primitive because endpoint telemetry may show post-exploitation behavior without proving ViewState deserialization, shared machineKey abuse, or the exact application entry path.

·        SentinelOne rules must be correlated with IIS logs, WAF logs, reverse proxy logs, ASP.NET application logs, file integrity telemetry, network telemetry, vulnerability context, asset inventory, application ownership, and change-control records before classifying activity as probable exploitation.

·        SentinelOne detection content should be treated as high-value behavioral coverage for compromise validation, post-exploitation detection, payload staging detection, application-content tampering detection, containment scoping, and host triage, not direct CVE confirmation or actor attribution by itself.

·        SentinelOne rules should not generate high-confidence alerting from child-process execution alone, file creation alone, outbound communication alone, application pool identity activity alone, file extension alone, or named tooling references alone without local baseline and supporting context.

Rule

IIS Worker Process Suspicious Child Process Execution

Rule Format

SentinelOne behavioral endpoint detection rule suitable for process telemetry, parent-child process lineage, command-line telemetry, user context, process integrity context, application pool identity mapping, endpoint network telemetry, script execution telemetry, module-load telemetry, file telemetry, IIS server inventory, ASP.NET application inventory, and SIEM correlation after IIS host validation, application pool identity validation, process baseline validation, command-line validation, maintenance-window validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious child-process execution from IIS worker processes or ASP.NET application contexts that may indicate server-side code execution, web shell interaction, command execution, payload staging, or post-exploitation activity.

·        Identify host-side execution behavior without relying on exploit payload syntax, machineKey material, web shell filenames, public proof-of-concept strings, specific vulnerable product names, or attacker-selected parameters.

·        Prioritize execution involving w3wp.exe, application pool identities, IIS service accounts, ASP.NET worker contexts, vendor-managed application directories, upload paths, plugin-like paths, temporary compilation directories, and webroot-adjacent paths.

·        Support escalation when IIS worker-process child execution aligns with abnormal ViewState-bearing request activity, application errors, failed request traces, suspicious file staging, webroot modification, outbound communication, credential access, or web shell-like access patterns.

·        This rule does not prove ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, credential theft, Cobalt Strike delivery, or actor attribution without supporting web, IIS, ASP.NET, file, network, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify process creation events where the parent process is w3wp.exe, an IIS worker process, an ASP.NET application process, or a process running under an application pool identity context.

·        Prioritize child processes involving command shells, PowerShell, script interpreters, HTML application execution, living-off-the-land binaries, archive utilities, network utilities, credential utilities, remote-access tooling, or unusual administrative utilities.

·        Prioritize command lines involving encoded execution, hidden execution, remote content retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, execution from application-controlled directories, or command execution inconsistent with the application role.

·        Prioritize execution where the user context maps to an application pool identity, IIS service account, vendor application account, service account, or local account that normally should not perform interactive administrative activity.

·        Increase confidence when suspicious child-process execution occurs shortly after abnormal ASP.NET request activity, ViewState-bearing POST anomalies, HTTP 500-series bursts, failed request traces, application pool instability, web shell-like access, or rare path access.

·        Increase confidence when suspicious child-process execution is followed by file creation, webroot modification, application-content tampering, outbound network communication, credential access, local discovery, archive creation, defense evasion, or persistence-like behavior.

·        Increase confidence when execution originates from or references webroot paths, upload paths, plugin-like directories, temporary ASP.NET compilation paths, vendor application directories, user-writable directories, or recently modified application paths.

·        Increase confidence when SentinelOne telemetry shows suspicious script behavior, suspicious PowerShell behavior, unexpected module loading, process injection, beacon-like network behavior, defense evasion, suspicious archive handling, or post-exploitation tool staging.

·        Reduce severity for approved deployment automation, backup jobs, monitoring agents, vendor support tools, software update workflows, reporting jobs, administrative scripts, IIS maintenance tasks, incident-response activity, and documented operational jobs when behavior is consistent with process, user, host, path, and time window.

·        Do not classify IIS child-process execution as ViewState exploitation without timing, request-path, exposure, application, file, or network correlation.

·        Do not treat w3wp.exe child execution as compromise evidence by itself when the environment has known application maintenance, reporting, deployment, automation, or vendor support workflows that legitimately spawn child processes.

Required Telemetry

·        SentinelOne process telemetry.

·        Parent process name.

·        Parent process path.

·        Parent process command line.

·        Child process name.

·        Child process path.

·        Child process command line.

·        Process start time.

·        Process end time where available.

·        Process user context.

·        Application pool identity context where available.

·        Process integrity context where available.

·        Process hash where available.

·        Process signer where available.

·        Process reputation where available.

·        Script execution telemetry.

·        PowerShell telemetry where available.

·        Module-load telemetry where available.

·        File creation telemetry.

·        File modification telemetry.

·        Endpoint network connection telemetry.

·        DNS telemetry where available.

·        Endpoint alert telemetry.

·        Behavioral indicator telemetry.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Application pool identity mapping.

·        Service-account mapping.

·        Webroot path inventory.

·        Upload path inventory where available.

·        Vendor application path inventory.

·        Temporary ASP.NET compilation path inventory.

·        Approved administrative script inventory.

·        Approved deployment tool inventory.

·        Approved backup job inventory.

·        Approved monitoring tool inventory.

·        Approved vendor-support tool inventory.

·        Approved reporting job inventory.

·        IIS logs where available.

·        WAF logs where available.

·        Reverse proxy logs where available.

·        ASP.NET application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build IIS host groups covering internet-facing IIS servers, ASP.NET application servers, vendor-managed portals, LMS systems, authentication-adjacent portals, load balancer backends, and application servers that process ViewState-bearing workflows.

·        Build process ancestry groups for w3wp.exe, IIS worker processes, ASP.NET application processes, application pool identities, IIS service accounts, and vendor application service accounts.

·        Build suspicious child-process groups for command shells, PowerShell, script interpreters, LOLBins, archive utilities, network utilities, credential utilities, remote-access tools, and unusual administrative utilities.

·        Build suspicious command-line groups for encoded commands, hidden execution, remote retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, execution from application-controlled paths, and commands inconsistent with the normal application role.

·        Build application path groups for webroot directories, upload directories, plugin-like directories, temporary ASP.NET compilation paths, vendor application paths, user-writable paths, and recently modified application directories.

·        Validate whether SentinelOne telemetry, IIS logs, WAF logs, reverse proxy logs, ASP.NET logs, file telemetry, network telemetry, asset inventory, and SIEM telemetry can reliably join on host, process, user, path, timestamp, application pool identity, service account, and application boundary.

·        Use shorter correlation windows when suspicious IIS child-process execution follows abnormal ASP.NET request activity, failed request traces, application pool instability, web shell-like access, or rare path access.

·        Use moderate correlation windows when child-process execution is followed by file staging, webroot modification, outbound communication, credential access, local discovery, archive creation, or defense evasion.

·        Use longer correlation windows for delayed operator interaction, staged payload execution, low-and-slow discovery, delayed outbound callback behavior, or delayed persistence attempts.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, application pool identity context, suspicious command-line behavior, execution from application-controlled paths, file writes, outbound communication, credential access, and supporting web telemetry.

·        Treat suspicious child-process execution as a high-value compromise signal, but require correlation before attributing it to ViewState deserialization or shared machineKey exploitation.

·        Avoid broad suppression for deployment tools, administrative automation, vendor support utilities, backup jobs, monitoring tools, reporting jobs, or incident-response tools without validation because legitimate and malicious execution paths may overlap.

·        Use deployment records, maintenance windows, backup schedules, vendor-support tickets, approved script inventories, reporting job inventories, incident-response records, and application-owner validation as triage evidence before classifying activity as suspicious.

·        Validate all process groups, path groups, command-line patterns, identity mappings, timing windows, enrichment fields, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until parent-child process fidelity, command-line coverage, local baselines, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to IIS worker-process child execution, which is a durable post-exploitation signal across many ASP.NET application compromise scenarios.

·        The rule remains useful if an adversary changes ViewState payload structure, web shell family, file path, source infrastructure, command syntax, staging method, or outbound infrastructure.

·        The score is supported by the durability of abnormal parent-child process lineage, application pool identity behavior, command-line context, execution path context, and cross-layer correlation with file or network telemetry.

·        The score is constrained by legitimate administrative automation, vendor support workflows, backup jobs, deployment tools, reporting jobs, applications that legitimately spawn child processes, and environments with incomplete command-line visibility.

·        The rule is durable as a compromise-validation detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on SentinelOne process telemetry, command-line visibility, application pool identity context, host inventory, webroot path mapping, baseline process behavior, and application-owner validation.

·        Operational confidence is reduced where legitimate application workflows spawn command shells, scripts, reporting tools, archive utilities, or vendor support tooling from the IIS server.

·        Operational confidence is reduced where command-line telemetry is incomplete, application pool identities are poorly mapped, or maintenance, reporting, and deployment workflows are undocumented.

·        Full-telemetry confidence improves when process execution is enriched with IIS logs, WAF logs, ASP.NET logs, file telemetry, network telemetry, vulnerability context, and change-control records.

·        Under full telemetry conditions, this rule provides strong host-side evidence for escalation, but confirmed exploitation still requires supporting web, file, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious IIS worker-process child execution, not confirmed ViewState exploitation by itself.

·        Legitimate deployment tools, backup jobs, reporting workflows, application maintenance, vendor support, administrative automation, and incident-response activity may produce similar parent-child process patterns.

·        Missing command-line telemetry reduces the ability to distinguish benign child-process execution from malicious execution.

·        Missing application pool identity mapping may reduce confidence in whether the process belongs to the affected ASP.NET application.

·        Missing IIS, WAF, or ASP.NET telemetry may prevent confirmation that suspicious execution followed abnormal request activity.

·        The rule may miss exploitation that avoids child-process creation, remains in-process, or uses memory-resident execution without visible process creation.

·        The rule may miss activity if endpoint telemetry is disabled, delayed, tampered with, or unavailable in hosted or vendor-managed environments.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne IIS worker-process child execution query pattern requiring platform syntax validation, IIS host validation, application pool identity validation, command-line validation, path validation, baseline validation, timing-window tuning, and environment-specific allowlisting before production deployment.

EndpointEvent AS IisChildProcess
WHERE IisChildProcess.EventType IN ANY (
"Process Created",
"Process Started",
"Child Process Created"
)
AND IisChildProcess.ParentProcessName IN ANY (
"w3wp.exe",
"iisexpress.exe"
)
AND IisChildProcess.Host IN ASSET_GROUP(
"IIS Web Tier",
"ASP.NET Application Hosts",
"Internet Facing IIS Servers",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"Authentication Adjacent ASP.NET Applications"
)
AND (
IisChildProcess.ChildProcessName IN ANY (
"cmd.exe",
"powershell.exe",
"pwsh.exe",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"certutil.exe",
"bitsadmin.exe",
"curl.exe",
"wget.exe",
"tar.exe",
"7z.exe"
)
OR IisChildProcess.ChildProcessCategory IN ANY (
"command_shell",
"script_interpreter",
"living_off_the_land_binary",
"archive_utility",
"network_utility",
"credential_utility",
"remote_access_tool",
"unusual_administrative_utility"
)
OR IisChildProcess.CommandLinePattern IN ANY (
"encoded_command",
"hidden_execution",
"remote_content_retrieval",
"download_or_upload_behavior",
"archive_extraction",
"temporary_path_execution",
"inline_script_execution",
"suspicious_interpreter_chain",
"execution_from_application_controlled_path",
"command_inconsistent_with_application_role"
)
OR IisChildProcess.UserContext IN ANY (
"application_pool_identity",
"iis_service_account",
"vendor_application_service_account",
"service_account_unusual_for_interactive_execution"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_WEB_PRECURSOR_WINDOW (
WebEvent.EventType IN ANY (
"Abnormal ViewState Bearing POST",
"Abnormal POST Size",
"Repeated 500 Series Responses",
"Error Then Success Pattern",
"Failed Request Trace",
"Web Shell Like Access",
"Rare Path Access"
)
AND WebEvent.Asset IN SAME_APPLICATION_BOUNDARY(IisChildProcess.Host)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_IIS_FILE_OR_NETWORK_WINDOW (
EndpointEvent.EventType IN ANY (
"Application File Modified",
"Webroot File Modified",
"Suspicious File Created",
"Outbound Connection From IIS Process",
"Credential Access",
"Local Discovery",
"Archive Creation",
"Defense Evasion",
"Persistence Attempt"
)
AND EndpointEvent.Asset IN SAME_APPLICATION_BOUNDARY(IisChildProcess.Host)
)
AND IisChildProcess.CommandLine NOT IN ASSET_GROUP(
"Approved Deployment Commands",
"Approved Backup Commands",
"Approved Monitoring Commands",
"Approved Vendor Support Commands",
"Approved Reporting Commands",
"Approved Administrative Automation",
"Approved Incident Response Commands"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_maintenance",
"approved_backup_activity",
"approved_vendor_support",
"approved_monitoring_activity",
"approved_reporting_job",
"approved_incident_response_activity"
)

Rule

Application Pool Identity Writing Suspicious Application or Webroot Artifacts

Rule Format

SentinelOne behavioral file and identity correlation rule suitable for endpoint file telemetry, process telemetry, parent-child process lineage, user context, application pool identity mapping, webroot path inventory, application directory inventory, file hash telemetry, file reputation telemetry, signer telemetry, endpoint timeline telemetry, IIS server inventory, ASP.NET asset inventory, change-control records, application deployment records, file integrity baselines, known-good application baselines, and SIEM correlation after IIS host validation, application path validation, file-context validation, responsible-process validation, identity validation, deployment-window validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious file creation or modification by application pool identities, IIS worker processes, IIS-adjacent processes, or ASP.NET application contexts under webroot, vendor application, upload, plugin-like, temporary compilation, configuration, JavaScript, or application-controlled directories.

·        Identify potential web shell placement, payload staging, application-content tampering, malicious JavaScript modification, configuration manipulation, or fake component delivery preparation.

·        Prioritize file activity involving high-risk application artifacts outside approved deployment and maintenance windows rather than alerting on file extension alone.

·        Support escalation when suspicious file activity aligns with abnormal ASP.NET request activity, IIS worker-process child execution, rare path access, outbound communication, credential access, application-content tampering, or user-delivery signals.

·        This rule does not prove web shell placement, ViewState deserialization, application compromise, user compromise, or actor attribution without supporting web, process, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify file creation, modification, rename, deletion, or overwrite events under IIS webroot, vendor application, upload, plugin-like, temporary compilation, configuration, JavaScript, login-page, downloadable-component, or application-controlled directories.

·        Prioritize file activity where the responsible process is w3wp.exe, an IIS worker process, a script interpreter, a suspicious child process spawned by IIS, or a process running under an application pool identity.

·        Prioritize high-risk file context involving new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, new external script references, configuration changes, archive staging, executable staging, deleted-after-execution files, or suspicious temporary artifacts.

·        Treat high-risk file extension matches as supporting context only unless they are paired with suspicious file context, suspicious responsible-process context, abnormal change timing, unusual path behavior, or follow-on evidence.

·        Prioritize file writes that occur outside approved deployment windows, vendor-support windows, content update windows, backup windows, build windows, cache generation workflows, or documented maintenance activity.

·        Increase confidence when suspicious file activity follows abnormal ViewState-bearing POST activity, application errors, failed request traces, web shell-like access, rare path access, or suspicious IIS child-process execution.

·        Increase confidence when the file is later accessed over HTTP, loaded by the application, referenced by modified content, executed by a suspicious process, or associated with outbound communication.

·        Increase confidence when file telemetry shows suspicious hash reputation, unsigned or unexpected signer attributes, unusual extension mismatch, newly observed filename, unusual path depth, unexpected responsible process, or deleted-after-execution behavior.

·        Increase confidence when JavaScript, login pages, authentication workflows, downloadable components, or external script references are modified in user-facing application content.

·        Reduce severity for approved deployments, application releases, content publishing, vendor patches, plugin updates, backup jobs, application build processes, cache generation, emergency fixes, and documented administrative maintenance when behavior is consistent with path, process, user, file type, and time window.

·        Do not classify suspicious file modification as web shell placement or malicious content tampering without supporting process, access, network, application, or change-control evidence.

·        Do not rely on web shell filenames, known malicious hashes, public artifact strings, specific JavaScript names, file extension alone, or named tooling as required detection conditions.

Required Telemetry

·        SentinelOne file telemetry.

·        File creation events.

·        File modification events.

·        File rename events.

·        File deletion events.

·        File path.

·        File name.

·        File extension.

·        File hash where available.

·        File signer where available.

·        File reputation where available.

·        File size where available.

·        Responsible process name.

·        Responsible process path.

·        Responsible process command line.

·        Parent process name.

·        Parent process path.

·        User context.

·        Application pool identity context where available.

·        Process integrity context where available.

·        Endpoint process telemetry.

·        Endpoint network telemetry where available.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Webroot path inventory.

·        Vendor application path inventory.

·        Upload path inventory where available.

·        Plugin-like path inventory where available.

·        Temporary ASP.NET compilation path inventory.

·        Configuration path inventory.

·        JavaScript path inventory.

·        Login-page path inventory where available.

·        Downloadable-component path inventory where available.

·        Approved deployment path inventory.

·        Approved application release records.

·        Approved content update records.

·        Approved build records.

·        Approved cache generation context where available.

·        Vendor-support records.

·        Change-control records.

·        Maintenance-window records.

·        IIS logs where available.

·        Reverse proxy logs where available.

·        ASP.NET application logs where available.

·        File integrity baselines where available.

·        Known-good application baselines where available.

Engineering Implementation Instructions

·        Build protected application path groups covering webroot directories, vendor application directories, upload directories, plugin-like paths, temporary ASP.NET compilation directories, JavaScript directories, configuration directories, login-page locations, downloadable component locations, and user-facing content paths.

·        Build high-risk file-context groups covering new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, new external script references, configuration changes, archive staging, executable staging, suspicious temporary files, and deleted-after-execution artifacts.

·        Build responsible-process groups covering w3wp.exe, IIS worker processes, application pool identities, script interpreters, suspicious IIS child processes, deployment tools, build tools, backup tools, cache generation processes, and vendor support utilities.

·        Build approved-change groups for deployments, content updates, plugin updates, vendor patches, backup jobs, build activity, cache generation, emergency fixes, incident response, and documented administrative maintenance.

·        Validate whether SentinelOne telemetry, IIS logs, reverse proxy logs, ASP.NET logs, file integrity records, known-good baselines, deployment records, vendor-support records, and SIEM telemetry can reliably join on host, process, user, path, file hash, timestamp, application identity, and change context.

·        Use shorter correlation windows when suspicious file activity follows abnormal ASP.NET request activity, web shell-like access, failed request traces, rare path access, or IIS child-process execution.

·        Use moderate correlation windows when file activity is followed by rare path access, outbound communication, endpoint alerting, user downloads, or application-content changes.

·        Use longer correlation windows for delayed operator access, staged payload activation, content tampering, fake component delivery, or user-side delivery after application modification.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, file-context sensitivity, path sensitivity, application pool identity context, responsible process, unsigned or suspicious files, rare file names, content changes, outbound communication, and follow-on web access.

·        Treat file writes by application pool identities into sensitive application paths as high-value signals, but require context before classifying them as web shell placement or malicious tampering.

·        Avoid broad suppression for deployment tools, content update processes, vendor support utilities, backup jobs, plugin updates, build tools, cache generation processes, or emergency fixes without validation because legitimate and malicious file activity may overlap.

·        Use deployment records, release notes, vendor-support tickets, content update records, maintenance windows, backup schedules, known-good baselines, cache-generation records, and application-owner validation as triage evidence before classifying activity as suspicious.

·        Validate all path groups, file-context groups, process groups, identity mappings, hash reputation fields, signer fields, timing windows, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until file telemetry fidelity, path coverage, baseline quality, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and restoration evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious file creation or modification under IIS application paths by application pool or IIS-adjacent contexts.

·        The rule remains useful if an adversary changes web shell filename, payload name, JavaScript filename, extension, path, source infrastructure, or post-exploitation toolset.

·        The score is supported by the durability of unauthorized file placement, sensitive application path modification, application pool identity context, responsible-process context, file-context sensitivity, path sensitivity, and cross-layer correlation with web or process telemetry.

·        The score is constrained by legitimate deployments, content updates, vendor support, plugin updates, build activity, backup processes, cache generation, and emergency maintenance.

·        The rule is durable as a compromise-validation and content-tampering detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on SentinelOne file telemetry, protected path coverage, responsible-process visibility, application pool identity mapping, known-good baselines, deployment records, and application-owner validation.

·        Operational confidence is reduced where applications frequently update content, generate files dynamically, use plugin systems, write to upload directories, or rely on vendor-managed update workflows.

·        Operational confidence is reduced where file telemetry does not capture responsible process context, hash information, signer details, or prior file state.

·        Full-telemetry confidence improves when file events are enriched with IIS logs, web access to modified paths, process execution, outbound communication, ASP.NET logs, file integrity baselines, and change-control evidence.

·        Under full telemetry conditions, this rule provides strong host-side evidence for escalation and containment scoping, but confirmed exploitation still requires supporting web, process, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious application-file activity, not confirmed web shell deployment or ViewState exploitation by itself.

·        Legitimate deployments, content updates, vendor patches, plugin updates, backup jobs, build processes, cache generation, emergency fixes, and administrative maintenance may create similar file events.

·        Missing responsible-process telemetry reduces confidence in whether the file change was caused by IIS, a deployment tool, an administrator, or attacker activity.

·        Dynamic applications may create temporary files, uploaded content, generated scripts, cached artifacts, or generated application content that resembles suspicious changes.

·        Hosted or vendor-managed environments may restrict access to complete file telemetry or known-good baselines.

·        The rule may miss fileless execution, memory-resident tooling, or web shell activity that does not create durable files.

·        The rule may miss malicious content changes when the environment lacks JavaScript, login-page, downloadable-component, or known-good application baselines.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne application-file modification query pattern requiring platform syntax validation, IIS host validation, application path validation, responsible-process validation, application pool identity validation, file-context validation, baseline validation, timing-window tuning, and environment-specific allowlisting before production deployment.

EndpointEvent AS SuspiciousApplicationFileActivity
WHERE SuspiciousApplicationFileActivity.EventType IN ANY (
"File Created",
"File Modified",
"File Renamed",
"File Deleted",
"File Overwritten"
)
AND SuspiciousApplicationFileActivity.Host IN ASSET_GROUP(
"IIS Web Tier",
"ASP.NET Application Hosts",
"Internet Facing IIS Servers",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"Authentication Adjacent ASP.NET Applications"
)
AND SuspiciousApplicationFileActivity.FilePath IN PATH_GROUP(
"IIS Webroot Paths",
"ASP.NET Application Paths",
"Vendor Application Paths",
"Upload Paths",
"Plugin Like Paths",
"Temporary ASP.NET Compilation Paths",
"JavaScript Paths",
"Configuration Paths",
"Downloadable Component Paths",
"Login Page Paths"
)
AND (
SuspiciousApplicationFileActivity.FileContext IN ANY (
"new_aspx_file",
"modified_javascript",
"modified_login_page",
"external_script_reference_added",
"downloadable_component_modified",
"unexpected_dll_placement",
"configuration_changed",
"archive_staged",
"executable_staged",
"deleted_after_execution",
"suspicious_temporary_file"
)
OR SuspiciousApplicationFileActivity.ResponsibleProcess IN ANY (
"w3wp.exe",
"iis_worker_process",
"application_pool_identity_process",
"suspicious_iis_child_process",
"script_interpreter",
"command_shell"
)
OR (
SuspiciousApplicationFileActivity.FileExtension IN ANY (
".aspx",
".ashx",
".asmx",
".dll",
".js",
".config",
".ps1",
".vbs",
".bat",
".cmd",
".zip",
".7z",
".exe"
)
AND (
SuspiciousApplicationFileActivity.ChangeContext NOT IN ANY (
"approved_deployment",
"approved_content_update",
"approved_plugin_update",
"approved_vendor_support",
"approved_backup_activity",
"approved_build_activity",
"approved_cache_generation",
"approved_emergency_fix",
"approved_application_maintenance",
"approved_incident_response_activity"
)
OR SuspiciousApplicationFileActivity.PathContext IN ANY (
"new_path_for_application",
"rare_path_for_application",
"upload_path_write",
"plugin_like_path_write",
"temporary_application_path_write",
"login_page_write",
"downloadable_component_write",
"configuration_path_write",
"unexpected_path_depth"
)
OR SuspiciousApplicationFileActivity.FollowOnContext IN ANY (
"modified_path_accessed",
"rare_path_access",
"outbound_connection_from_iis_process",
"web_shell_like_access",
"iis_worker_process_child_execution",
"user_download_from_modified_page",
"external_script_loaded_from_modified_page"
)
)
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_WEB_OR_PROCESS_CONTEXT_WINDOW (
EndpointEvent.EventType IN ANY (
"IIS Worker Process Child Execution",
"Command Shell Execution",
"Script Interpreter Execution",
"Outbound Connection From IIS Process",
"Credential Access"
)
OR WebEvent.EventType IN ANY (
"Abnormal ViewState Bearing POST",
"Web Shell Like Access",
"Rare Path Access",
"Failed Request Trace",
"Error Then Success Pattern"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_FOLLOWON_CONTEXT_WINDOW (
WebEvent.EventType IN ANY (
"Modified Path Accessed",
"Rare Path Access",
"User Download From Modified Page",
"External Script Loaded From Modified Page"
)
OR EndpointEvent.EventType IN ANY (
"Beacon Like Behavior",
"Post Download Malware Behavior",
"Suspicious Download Executed",
"Persistence Attempt"
)
)
AND SuspiciousApplicationFileActivity.FilePath NOT IN PATH_GROUP(
"Approved Deployment Paths",
"Approved Build Output Paths",
"Approved Backup Paths",
"Approved Vendor Support Paths",
"Approved Temporary Application Paths",
"Approved Cache Paths",
"Approved Generated Content Paths"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_content_update",
"approved_plugin_update",
"approved_vendor_support",
"approved_backup_activity",
"approved_build_activity",
"approved_cache_generation",
"approved_emergency_fix",
"approved_application_maintenance",
"approved_incident_response_activity"
)

Rule

IIS Server Post-Exploitation Behavior With Outbound Communication

Rule Format

SentinelOne behavioral endpoint-to-network correlation rule suitable for process telemetry, command-line telemetry, parent-child process lineage, endpoint network telemetry, DNS telemetry where available, file telemetry, user context, application pool identity context, behavioral indicators, IIS server inventory, ASP.NET application inventory, approved destination inventory, asset enrichment, identity enrichment, and SIEM correlation after IIS host validation, post-exploitation behavior validation, destination validation, identity validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect post-exploitation behavior from IIS-hosted ASP.NET servers when suspicious host-side activity is followed by outbound communication, callback-like behavior, payload retrieval, or infrastructure contact.

·        Identify activity that may occur after successful ViewState abuse, web shell execution, payload staging, application-content tampering, credential access, or operator interaction.

·        Prioritize endpoint behaviors involving suspicious IIS process lineage, credential access, local discovery, archive creation, suspicious file staging, defense evasion, persistence attempts, and outbound network communication to rare or suspicious destinations.

·        Support escalation when host-side behavior aligns with abnormal ASP.NET request activity, suspicious file changes, rare path access, external script retrieval, user-delivery evidence, or application-content tampering.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, cloud compromise, or actor attribution without supporting web, IIS, ASP.NET, file, network, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify IIS-hosted ASP.NET servers with suspicious host-side behavior that occurs before or near outbound network communication.

·        Prioritize post-exploitation behavior involving credential access, local discovery, domain discovery, service enumeration, security-product enumeration, archive creation, suspicious file staging, defense evasion, persistence attempts, deleted-after-execution artifacts, or suspicious remote-access behavior.

·        Prioritize outbound communication from suspicious IIS processes, IIS child processes, application pool identities, service accounts, or recently modified application contexts.

·        Prioritize destinations that are newly observed, rare for the host, rare for the application, low reputation, direct IP-based, dynamic DNS-associated, uncommon by port, unusual by TLS SNI, or outside approved vendor, monitoring, update, backup, deployment, and business-integration inventories.

·        Increase confidence when outbound communication follows abnormal ViewState-bearing request activity, web shell-like access, rare path access, application errors, application pool instability, suspicious file modification, JavaScript modification, or application-content tampering.

·        Increase confidence when SentinelOne behavioral indicators identify command-and-control-like behavior, suspicious PowerShell, process injection, credential access, remote-access behavior, defense evasion, persistence behavior, or post-exploitation tool staging.

·        Increase confidence when outbound communication aligns with suspicious archive creation, payload retrieval, JavaScript modification, fake component delivery preparation, or user-side delivery evidence.

·        Reduce severity for approved vendor services, monitoring platforms, backup destinations, deployment systems, update repositories, administrative automation, incident-response tooling, managed hosting operations, and approved business integrations when behavior is consistent with source, destination, process, identity, and time window.

·        Do not classify outbound communication as exploitation-related without host-side suspicious behavior, upstream ASP.NET request context, application-file context, or incident-response evidence.

·        Do not treat destination novelty, direct IP connections, unusual ports, DNS rarity, or high byte volume as compromise evidence by itself.

·        Do not let this rule duplicate Rule 1 unless outbound communication or post-exploitation behavior materially changes the risk context beyond child-process execution alone.

Required Telemetry

·        SentinelOne process telemetry.

·        SentinelOne endpoint network telemetry.

·        Parent process name.

·        Child process name.

·        Process command line.

·        Process user context.

·        Application pool identity context where available.

·        Process hash where available.

·        Process signer where available.

·        Process reputation where available.

·        Destination IP.

·        Destination domain where available.

·        Destination port.

·        Destination reputation where available.

·        Destination first-seen timestamp where available.

·        TLS SNI where available.

·        Protocol.

·        Directionality.

·        Connection timestamp.

·        Connection count.

·        Session duration where available.

·        Byte count where available.

·        DNS telemetry where available.

·        Behavioral indicator telemetry.

·        File creation telemetry.

·        File modification telemetry.

·        Archive creation telemetry.

·        Credential access telemetry.

·        Persistence telemetry.

·        Defense evasion telemetry.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Application pool identity mapping.

·        Service-account mapping.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Webroot path inventory.

·        Application path inventory.

·        IIS logs where available.

·        WAF logs where available.

·        ASP.NET application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build IIS host groups covering internet-facing IIS servers, ASP.NET application servers, vendor-managed portals, LMS platforms, authentication-adjacent portals, and load balancer backends.

·        Build post-exploitation behavior groups for credential access, local discovery, domain discovery, service enumeration, security-product enumeration, archive creation, defense evasion, persistence attempts, suspicious file staging, deleted-after-execution artifacts, suspicious PowerShell, process injection, remote-access behavior, and post-exploitation tool staging.

·        Build outbound destination groups for newly observed destinations, rare destinations, low-reputation destinations, direct IP destinations, dynamic DNS destinations, uncommon ports, rare SNI values, cloud-hosted infrastructure, developer platforms, object storage, file-transfer services, and destinations outside approved dependencies.

·        Build approved destination groups for vendor services, monitoring platforms, backup systems, deployment systems, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Validate whether SentinelOne process telemetry, network telemetry, file telemetry, behavioral indicators, IIS logs, WAF logs, ASP.NET logs, asset inventory, destination enrichment, identity enrichment, and SIEM telemetry can reliably join on host, process, user, destination, timestamp, application pool identity, and application boundary.

·        Use shorter correlation windows when post-exploitation behavior is followed immediately by outbound communication, DNS lookup, direct IP contact, payload retrieval, rare destination access, or callback-like behavior.

·        Use moderate correlation windows when outbound behavior follows abnormal web activity, application errors, file modification, credential access, archive creation, rare path access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, staged payload execution, repeated low-volume communication, delayed operator return, low-and-slow post-exploitation activity, or delayed user-delivery preparation.

·        Add severity weighting for internet-facing exposure, application pool identity context, post-exploitation behavior type, credential access, archive creation, persistence attempts, rare destination communication, direct IP egress, unusual port use, destination reputation, and supporting web or file telemetry.

·        Treat outbound communication from suspicious IIS process contexts as a high-value signal, but require context before classifying it as command-and-control, payload retrieval, or exploitation-related behavior.

·        Avoid broad suppression for cloud providers, developer platforms, file-transfer services, monitoring platforms, backup systems, update services, vendor support destinations, managed hosting destinations, business integrations, and incident-response infrastructure without validation because legitimate workflows and attacker staging paths may overlap.

·        Use approved destination inventories, vendor-support records, deployment records, backup schedules, monitoring inventories, maintenance windows, business-integration inventories, and incident-response records as triage evidence before classifying activity as suspicious.

·        Validate all post-exploitation behavior groups, process groups, destination groups, identity mappings, path mappings, timing windows, enrichment fields, exception logic, parser behavior, and local schema mappings before production deployment.

·        Do not enable high-severity alerting until endpoint network telemetry fidelity, destination baselines, process-to-network mapping, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious IIS post-exploitation behavior followed by outbound communication rather than static destination indicators, known malware names, known C2 patterns, or destination novelty alone.

·        The rule remains useful if an adversary changes web shell family, payload name, command syntax, callback infrastructure, destination domain, protocol, timing, or post-exploitation toolset.

·        The score is supported by the durability of post-exploitation behavior, application pool identity context, endpoint network telemetry, destination abnormality, credential access, archive creation, defense evasion, persistence behavior, and cross-layer enrichment.

·        The score is constrained by legitimate server egress, vendor support workflows, monitoring tools, backup systems, deployment platforms, business integrations, shared egress, missing destination enrichment, and incomplete process-to-network mapping.

·        The rule is durable as a post-exploitation detector but should not be treated as standalone proof of exploitation, command-and-control, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on SentinelOne process telemetry, endpoint network telemetry, command-line visibility, destination enrichment, application pool identity mapping, approved destination inventories, and process-to-network correlation.

·        Operational confidence is reduced where IIS servers have broad egress, weak destination inventories, shared service accounts, shared egress paths, or legitimate automation that contacts rare destinations.

·        Operational confidence is reduced where endpoint network telemetry cannot tie outbound communication to the responsible process, user context, or post-exploitation behavior.

·        Full-telemetry confidence improves when endpoint network events are enriched with IIS logs, WAF logs, ASP.NET logs, file telemetry, identity context, destination reputation, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for post-exploitation activity, but confirmed compromise still requires corroborating application, web, file, identity, or incident-response evidence.

Limitations

·        This rule detects suspicious IIS post-exploitation behavior with outbound communication, not confirmed exploitation by itself.

·        Legitimate vendor support, update checks, monitoring workflows, backup operations, deployment automation, administrative activity, managed hosting operations, business integrations, and incident response may produce similar endpoint-to-network patterns.

·        Missing endpoint network telemetry may prevent process-to-destination correlation.

·        Missing destination enrichment may reduce the ability to distinguish suspicious destinations from legitimate dependencies.

·        Shared service accounts, shared egress paths, and broad server internet access can increase false positives.

·        The rule may miss attackers who avoid external communication, use approved infrastructure, operate fully in-process, or complete objectives through local application manipulation.

·        The rule may miss activity where endpoint telemetry is disabled, delayed, tampered with, or unavailable in hosted or vendor-managed environments.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne IIS post-exploitation outbound communication query pattern requiring platform syntax validation, IIS host validation, post-exploitation behavior validation, process validation, network telemetry validation, destination-enrichment validation, identity validation, timing-window tuning, and environment-specific allowlisting before production deployment.

EndpointEvent AS IisPostExploitationNetworkActivity
WHERE IisPostExploitationNetworkActivity.Host IN ASSET_GROUP(
"IIS Web Tier",
"ASP.NET Application Hosts",
"Internet Facing IIS Servers",
"Vendor Managed ASP.NET Portals",
"LMS Platforms",
"Authentication Adjacent ASP.NET Applications"
)
AND IisPostExploitationNetworkActivity.EventType IN ANY (
"Network Connection",
"DNS Query",
"Outbound Connection",
"Process Network Connection"
)
AND IisPostExploitationNetworkActivity.Direction IN ANY (
"OUTBOUND",
"SERVER_TO_EXTERNAL",
"CLOUD_BOUND"
)
AND (
IisPostExploitationNetworkActivity.ProcessContext IN ANY (
"w3wp.exe",
"iis_worker_process",
"application_pool_identity_process",
"suspicious_iis_child_process",
"command_shell",
"script_interpreter",
"network_utility",
"remote_access_tool"
)
OR IisPostExploitationNetworkActivity.DestinationContext IN ANY (
"newly_observed_destination",
"rare_for_host",
"rare_for_application",
"direct_ip_destination",
"dynamic_dns_destination",
"low_reputation_destination",
"uncommon_port",
"rare_sni",
"outside_approved_dependency"
)
)
AND EVENT_NEAR WITHIN ENV_IIS_POST_EXPLOITATION_TO_NETWORK_WINDOW (
EndpointEvent AS SuspiciousIisPostExploitationBehavior
WHERE SuspiciousIisPostExploitationBehavior.Asset IN SAME_APPLICATION_BOUNDARY(IisPostExploitationNetworkActivity.Host)
AND SuspiciousIisPostExploitationBehavior.EventType IN ANY (
"Credential Access",
"Local Discovery",
"Domain Discovery",
"Service Enumeration",
"Security Product Enumeration",
"Archive Creation",
"Suspicious File Staging",
"Defense Evasion",
"Persistence Attempt",
"Suspicious PowerShell",
"Process Injection",
"Remote Access Behavior",
"Post Exploitation Tool Staging"
)
)
AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ASPNET_WEB_OR_FILE_CONTEXT_WINDOW (
WebEvent.EventType IN ANY (
"Abnormal ViewState Bearing POST",
"Web Shell Like Access",
"Rare Path Access",
"Failed Request Trace",
"Error Then Success Pattern"
)
OR FileEvent.EventType IN ANY (
"Webroot File Modified",
"JavaScript File Modified",
"Application File Modified",
"Suspicious File Created",
"Configuration File Modified"
)
)
AND IisPostExploitationNetworkActivity.Destination NOT IN ASSET_GROUP(
"Approved Vendor Services",
"Approved Monitoring Destinations",
"Approved Backup Destinations",
"Approved Deployment Destinations",
"Approved Update Destinations",
"Approved Managed Hosting Destinations",
"Approved Business Integrations",
"Approved Incident Response Infrastructure"
)
AND NOT ChangeContext IN ANY (
"approved_deployment",
"approved_maintenance",
"approved_backup_activity",
"approved_vendor_support",
"approved_monitoring_activity",
"approved_managed_hosting_operation",
"approved_business_integration",
"approved_incident_response_activity"
)

Splunk

Detection Viability Assessment

Splunk has three rules for this EXP report.

·        Splunk is viable for detecting ASP.NET ViewState deserialization and shared machineKey exploitation because it can correlate IIS logs, reverse proxy logs, WAF logs, Windows telemetry, EDR events, file integrity events, DNS logs, proxy logs, firewall logs, and asset inventory across the full exploitation sequence.

·        Splunk is strongest where IIS web logs, Windows Event Logs, Sysmon or EDR telemetry, file integrity telemetry, DNS telemetry, proxy telemetry, firewall telemetry, WAF telemetry, application inventory, application pool identity mapping, and asset enrichment are normalized into reliable indexes, sourcetypes, field extractions, and lookup structures.

·        Splunk can identify suspicious sequencing between abnormal ViewState-bearing POST activity, IIS worker-process execution, application-file modification, rare path access, outbound communication, web shell-like behavior, application-content tampering, and user-delivery evidence.

·        Splunk is not a standalone source for confirming ViewState deserialization or shared machineKey abuse unless web request evidence, host execution evidence, file evidence, timing correlation, and application context support that conclusion.

·        Splunk rules must be correlated with application ownership, approved maintenance windows, deployment records, vendor-support records, known-good application baselines, approved destination inventories, and SOC triage validation before production deployment.

·        Splunk detection content should be treated as high-value correlation coverage for exploit-attempt detection, compromise validation, web shell interaction detection, application-content tampering detection, outbound communication detection, and incident scoping, not direct CVE confirmation or actor attribution by itself.

·        Splunk rules should not generate high-confidence alerting from large POST requests alone, IIS child-process execution alone, file extension alone, destination novelty alone, rare path access alone, or user endpoint detections alone without supporting correlation and local baseline validation.

Rule

Abnormal ASP.NET ViewState Request Followed by IIS Process Execution

Rule Format

Splunk correlation search suitable for IIS web logs, reverse proxy logs, WAF logs, Windows Security logs, Sysmon logs, EDR process telemetry, endpoint process sourcetypes, asset inventory, application ownership enrichment, application pool identity mapping, IIS host grouping, ViewState-bearing endpoint inventory, and SIEM correlation after index validation, sourcetype validation, field mapping, time-window tuning, baseline validation, host normalization, lookup validation, event-pair correlation validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious ASP.NET request activity followed by IIS worker-process child execution or application pool identity execution on the same application server.

·        Identify the web-to-host portion of a ViewState abuse or ASP.NET server-side execution chain without relying on exploit payload syntax, machineKey material, known proof-of-concept strings, web shell names, fixed source infrastructure, or named tooling.

·        Prioritize externally exposed ASP.NET applications, IIS-hosted LMS platforms, vendor-managed portals, authentication-adjacent workflows, administrative-adjacent workflows, upload paths, plugin-like paths, and state-bearing application paths.

·        Support escalation when abnormal request behavior aligns with w3wp.exe child-process execution, script interpreter use, command-shell execution, suspicious PowerShell, archive utility execution, network utility execution, file writes, or outbound communication.

·        This rule does not prove ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, credential theft, Cobalt Strike delivery, or actor attribution without supporting IIS, endpoint, file, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify inbound ASP.NET or IIS web requests to confirmed or suspected ViewState-bearing application endpoints.

·        Prioritize abnormal request behavior involving unusually large POST size, abnormal bytes received, unexpected endpoint targeting, sparse targeted requests, repeated request variation, request bursts, repeated failures, error-to-success transitions, unusual user agents, rare source ASNs, suspicious hosting-provider sources, or anonymization infrastructure.

·        Correlate suspicious web activity to process creation events on the same IIS host, load balancer backend, application server, application pool boundary, or mapped application asset.

·        Prioritize process events where w3wp.exe, IIS worker processes, ASP.NET application contexts, or application pool identities spawn command shells, PowerShell, script interpreters, archive utilities, network utilities, living-off-the-land binaries, or unusual administrative utilities.

·        Increase confidence when suspicious process execution occurs shortly after abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, application pool instability, web shell-like access, or rare path access.

·        Increase confidence when process execution is followed by file creation, webroot modification, application-content tampering, outbound communication, credential access, local discovery, archive creation, defense evasion, or persistence-like behavior.

·        Increase confidence when command-line telemetry shows encoded execution, hidden execution, remote content retrieval, download or upload behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, or execution from application-controlled directories.

·        Reduce severity for approved deployment automation, backup jobs, monitoring agents, vendor support, software updates, reporting jobs, administrative scripts, IIS maintenance, authorized scanning, approved penetration testing, incident-response activity, and documented operational jobs.

·        Do not classify suspicious ASP.NET request behavior as successful exploitation without host, file, application, network, or incident-response evidence.

·        Do not classify IIS child-process execution as ViewState exploitation without timing, request-path, application, exposure, file, or network correlation.

Required Telemetry

·        Splunk indexes containing IIS logs.

·        Splunk indexes containing reverse proxy logs where available.

·        Splunk indexes containing WAF logs where available.

·        Splunk indexes containing Windows Security logs.

·        Splunk indexes containing Sysmon or EDR process telemetry.

·        IIS source IP field.

·        IIS host or backend host field.

·        IIS method field.

·        IIS URI stem field.

·        IIS URI query field where available.

·        IIS status code field.

·        IIS response time field where available.

·        IIS bytes received field where available.

·        IIS bytes sent field where available.

·        IIS user-agent field.

·        IIS referrer field where available.

·        WAF action field where available.

·        WAF rule or anomaly field where available.

·        Process host field.

·        Process parent image field.

·        Process image field.

·        Process command line field.

·        Process user field.

·        Process start time.

·        Process hash where available.

·        Application pool identity mapping.

·        IIS server asset inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        ViewState-bearing endpoint inventory where available.

·        Approved scanner inventory.

·        Approved penetration testing inventory.

·        Approved deployment tool inventory.

·        Approved administrative automation inventory.

·        Approved vendor-support inventory.

·        Approved reporting job inventory.

·        Change-control records.

·        Maintenance-window records.

·        Asset enrichment.

·        Identity enrichment.

·        Application owner enrichment.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build Splunk asset lookups for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build endpoint group lookups for ViewState-bearing paths, ASP.NET WebForms paths, login workflows, upload paths, plugin-like paths, administrative-adjacent paths, authentication-adjacent paths, document delivery paths, and LMS workflow paths.

·        Build suspicious request logic using method, URI path, bytes received, response code, response time, source IP, source ASN, user agent, referrer, request frequency, and endpoint baseline.

·        Build process logic for w3wp.exe, IIS worker processes, application pool identities, command shells, PowerShell, script interpreters, living-off-the-land binaries, archive utilities, network utilities, credential utilities, and unusual administrative utilities.

·        Normalize hostnames across IIS logs, WAF logs, reverse proxy logs, Windows logs, EDR logs, and asset inventories so web events can be reliably connected to endpoint process events.

·        Preserve event-pair timing between web events and process events. Do not reduce correlation to only the first event per application boundary.

·        Implement event-pair correlation using the locally preferred Splunk pattern, such as transaction, streamstats, eventstats, accelerated data models, tstats, summary indexes, or lookup-backed pair expansion.

·        Prefer stats, eventstats, accelerated data models, summary indexes, and lookup-driven enrichment over broad raw joins where production data volume is high.

·        Validate Splunk indexes, sourcetypes, field extractions, CIM mappings, lookup joins, event timestamps, host normalization, application-boundary mapping, and event-pair timing before production deployment.

·        Use shorter correlation windows when abnormal ASP.NET request activity is followed quickly by IIS child-process execution or suspicious command-line behavior.

·        Use moderate correlation windows when process execution is followed by file creation, webroot modification, outbound communication, credential access, archive creation, or rare path access.

·        Use longer correlation windows for delayed operator interaction, staged payload execution, delayed callback behavior, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, abnormal POST size, error-to-success behavior, suspicious process lineage, application pool identity context, suspicious command line, execution from application-controlled paths, and supporting file or network evidence.

·        Use approved scanner lists, penetration testing records, deployment records, vendor-support tickets, maintenance windows, backup schedules, reporting job inventories, and incident-response records as triage evidence.

·        Validate SPL performance against production index size, event volume, lookup size, acceleration coverage, scheduled-search frequency, and search concurrency before enabling alerting.

·        Do not enable high-severity alerting until sourcetypes, field mappings, host normalization, time synchronization, baselines, exceptions, event-pair correlation quality, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to web-to-host correlation rather than static exploit strings, payload syntax, machineKey material, web shell filenames, or known infrastructure.

·        The rule remains useful if an adversary changes request syntax, payload shape, source infrastructure, command syntax, child process choice, file path, or web shell family.

·        The score is supported by the durability of abnormal ASP.NET request behavior followed by suspicious IIS worker-process execution.

·        The score is constrained by missing bytes-received fields, inconsistent host normalization, incomplete endpoint process telemetry, weak application inventory, and legitimate administrative workflows that spawn child processes.

·        The rule is durable as a compromise-validation correlation but should not be treated as standalone proof of ViewState deserialization or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on IIS log fidelity, process telemetry, command-line visibility, host normalization, application inventory, application pool identity mapping, and request-to-host correlation.

·        Operational confidence is reduced where reverse proxies obscure source or destination context, WAF logs cannot be joined to backend hosts, or endpoint telemetry does not capture command lines.

·        Operational confidence is reduced where deployment, maintenance, reporting, backup, vendor support, or administrative automation workflows legitimately produce child-process activity.

·        Full-telemetry confidence improves when Splunk correlation includes IIS logs, WAF logs, reverse proxy logs, EDR telemetry, Windows logs, file telemetry, outbound network telemetry, vulnerability context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence but still requires supporting application, file, network, or incident-response evidence for confirmed exploitation.

Limitations

·        This rule detects suspicious ASP.NET request activity followed by IIS host execution, not confirmed exploitation by itself.

·        Large ViewState-bearing POST requests may be legitimate for some ASP.NET applications.

·        IIS child-process execution may be legitimate during deployments, reporting jobs, vendor support, maintenance, backup workflows, or incident response.

·        Reverse proxies, CDNs, WAFs, NAT, load balancing, and inconsistent host normalization may make request-to-host correlation difficult.

·        Missing command-line telemetry reduces the ability to distinguish malicious execution from benign process activity.

·        Missing IIS failed request tracing or ASP.NET application logs may reduce confidence in the exploitation sequence.

·        The rule may miss in-process exploitation that does not spawn visible child processes.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk ASP.NET request-to-IIS-process correlation query pattern requiring SPL syntax validation, index validation, sourcetype validation, host normalization, field mapping, lookup validation, timing-window tuning, acceleration assessment, event-pair preservation, and environment-specific allowlisting before production deployment.

(index=ENV_WEB_INDEX sourcetype IN (
  ENV_IIS_SOURCETYPE,
  ENV_WAF_SOURCETYPE,
  ENV_REVERSE_PROXY_SOURCETYPE
))
(
  http_method="POST"
  OR method="POST"
  OR cs_method="POST"
)
AND (
  uri_path IN LOOKUP("viewstate_bearing_aspnet_paths")
  OR uri_path IN LOOKUP("aspnet_authentication_adjacent_paths")
  OR uri_path IN LOOKUP("aspnet_administrative_adjacent_paths")
  OR uri_path IN LOOKUP("aspnet_upload_paths")
  OR uri_path IN LOOKUP("aspnet_lms_workflow_paths")
)
AND (
  bytes_received > LOOKUP_BASELINE("aspnet_endpoint_post_size_p95")
  OR request_size > LOOKUP_BASELINE("aspnet_endpoint_post_size_p95")
  OR response_status IN ("500","502","503")
  OR event_pattern IN (
    "error_then_success",
    "repeated_request_variation",
    "sparse_targeted_requests",
    "abnormal_request_cadence",
    "suspicious_allowed_web_activity"
  )
  OR src_ip IN CONTEXT("rare_source_for_application")
  OR src_asn IN CONTEXT("rare_asn")
  OR src_category IN CONTEXT("hosting_or_anonymization_infrastructure")
)
| eval app_boundary=coalesce(app_boundary, backend_host, dest_host, host)
| eval correlation_type="web_precursor"
| eval web_event_time=_time
| eval web_event_id=coalesce(event_id, md5(app_boundary . src_ip . uri_path . tostring(_time)))
| fields correlation_type, web_event_id, web_event_time, app_boundary, src_ip, user_agent, uri_path, http_method, response_status, bytes_received, request_size
| append [
  search index=ENV_ENDPOINT_INDEX sourcetype IN (
    ENV_WINDOWS_SECURITY_SOURCETYPE,
    ENV_SYSMON_SOURCETYPE,
    ENV_EDR_PROCESS_SOURCETYPE
  )
  (
    parent_process_name IN ("w3wp.exe","iisexpress.exe")
    OR parent_process_path="*\\inetsrv\\*"
    OR user IN LOOKUP("iis_application_pool_identities")
  )
  AND (
    process_name IN (
      "cmd.exe",
      "powershell.exe",
      "pwsh.exe",
      "wscript.exe",
      "cscript.exe",
      "mshta.exe",
      "rundll32.exe",
      "regsvr32.exe",
      "certutil.exe",
      "bitsadmin.exe",
      "curl.exe",
      "wget.exe",
      "tar.exe",
      "7z.exe"
    )
    OR process_category IN (
      "command_shell",
      "script_interpreter",
      "living_off_the_land_binary",
      "archive_utility",
      "network_utility",
      "credential_utility"
    )
    OR command_line IN CONTEXT("suspicious_iis_child_process_command_patterns")
  )
  | eval app_boundary=coalesce(app_boundary, host, dest)
  | eval correlation_type="process_followon"
  | eval process_event_time=_time
  | eval process_event_id=coalesce(event_id, md5(app_boundary . host . process_name . command_line . tostring(_time)))
  | fields correlation_type, process_event_id, process_event_time, app_boundary, host, parent_process_name, process_name, command_line, user
]
| eventstats
  values(web_event_id) AS candidate_web_event_ids
  values(web_event_time) AS candidate_web_times
  values(process_event_id) AS candidate_process_event_ids
  values(process_event_time) AS candidate_process_times
  BY app_boundary
| where correlation_type IN ("web_precursor","process_followon")
| eval pairing_requirement="Preserve individual web-to-process event pairs. Implementation should expand candidate web/process pairs and retain only pairs where process_event_time >= web_event_time and process_event_time <= web_event_time + ENV_ASPNET_REQUEST_TO_PROCESS_WINDOW."
| PAIR_EVENTS key=app_boundary start_type="web_precursor" end_type="process_followon" start_time=web_event_time end_time=process_event_time maxspan=ENV_ASPNET_REQUEST_TO_PROCESS_WINDOW
| where process_event_time >= web_event_time
AND process_event_time <= web_event_time + ENV_ASPNET_REQUEST_TO_PROCESS_WINDOW
| where NOT src_ip IN LOOKUP("approved_scanners")
AND NOT command_line IN LOOKUP("approved_deployment_or_admin_commands")
AND NOT ChangeContext IN LOOKUP("approved_change_context")

Rule

IIS Application File Modification Followed by Rare Web Access

Rule Format

Splunk correlation search suitable for file integrity telemetry, EDR file events, Sysmon file events, IIS web logs, reverse proxy logs, WAF logs, webroot path inventory, application path inventory, application deployment records, known-good application baselines, file hash enrichment, path frequency baselines, asset inventory, and SIEM correlation after index validation, sourcetype validation, protected-path validation, file-context validation, path-frequency validation, change-control validation, event-pair correlation validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious application-file creation or modification followed by rare or newly observed web access to the same or related path.

·        Identify possible web shell placement, unauthorized ASPX artifact creation, application-content tampering, JavaScript modification, fake component staging, or modified downloadable content.

·        Prioritize file activity under webroot, vendor application, upload, plugin-like, temporary compilation, JavaScript, configuration, login-page, and downloadable-component paths.

·        Support escalation when file modification aligns with abnormal ASP.NET request activity, IIS process execution, rare path access, outbound communication, user downloads, or external script loading.

·        This rule does not prove web shell placement, ViewState exploitation, application compromise, user compromise, or actor attribution without supporting process, web, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify file creation, modification, rename, overwrite, or deletion events under protected IIS or ASP.NET application paths.

·        Prioritize high-risk file context involving new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script reference additions, configuration changes, archive staging, executable staging, or suspicious temporary artifacts.

·        Prioritize file activity where the responsible process is w3wp.exe, an IIS worker process, a suspicious IIS child process, a script interpreter, a command shell, or an application pool identity.

·        Treat high-risk file extension matches as supporting context only unless paired with suspicious file context, suspicious responsible process, abnormal change timing, unusual path context, or follow-on evidence.

·        Correlate suspicious file activity with subsequent rare web access, newly observed path access, low-frequency path access, rare source access, abnormal response-size patterns, web shell-like timing, user downloads, or external script loading.

·        Preserve file-to-web event-pair timing so each suspicious file event is correlated to the specific subsequent web access event, not only the earliest file and earliest web event for the application.

·        Increase confidence when file modification follows abnormal ViewState-bearing POST activity, failed request traces, rare path access, IIS child-process execution, credential access, outbound communication, or application errors.

·        Increase confidence when the modified file is later accessed over HTTP, loaded by the application, referenced by modified content, downloaded by users, or associated with outbound communication.

·        Reduce severity for approved deployments, content updates, plugin updates, vendor patches, backup jobs, build jobs, cache generation, emergency fixes, incident response, and documented maintenance.

·        Do not classify file modification as malicious content tampering or web shell placement without supporting process, web access, network, application, or change-control evidence.

·        Do not rely on file extension alone, known web shell filenames, known hashes, public artifact strings, specific JavaScript names, or named tooling as required detection conditions.

Required Telemetry

·        Splunk indexes containing file integrity telemetry.

·        Splunk indexes containing EDR file events.

·        Splunk indexes containing Sysmon file events where available.

·        Splunk indexes containing IIS web logs.

·        Splunk indexes containing WAF logs where available.

·        Splunk indexes containing reverse proxy logs where available.

·        File path.

·        File name.

·        File extension.

·        File hash where available.

·        File signer where available.

·        File reputation where available.

·        File size where available.

·        File event type.

·        Responsible process name.

·        Responsible process path.

·        Responsible process command line.

·        Parent process name.

·        User context.

·        Application pool identity context where available.

·        IIS host field.

·        Web request path.

·        Web source IP.

·        Web user-agent.

·        Web response code.

·        Web response size where available.

·        Path first-seen timestamp where available.

·        Path frequency baseline.

·        Webroot path inventory.

·        Vendor application path inventory.

·        Upload path inventory where available.

·        Plugin-like path inventory where available.

·        Temporary ASP.NET compilation path inventory.

·        JavaScript path inventory.

·        Configuration path inventory.

·        Login-page path inventory where available.

·        Downloadable-component path inventory where available.

·        Approved deployment path inventory.

·        Approved content update records.

·        Approved vendor-support records.

·        Approved build records.

·        Approved cache-generation records.

·        Known-good application baselines.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build protected path lookups for webroot directories, ASP.NET application paths, vendor application paths, upload directories, plugin-like paths, temporary ASP.NET compilation paths, JavaScript directories, configuration directories, login-page paths, downloadable-component paths, and user-facing content locations.

·        Build high-risk file-context lookups for new ASPX files, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script references, configuration changes, archive staging, executable staging, deleted-after-execution artifacts, and suspicious temporary files.

·        Build responsible-process logic for w3wp.exe, IIS worker processes, application pool identities, suspicious IIS child processes, script interpreters, command shells, deployment tools, build tools, backup tools, cache generation processes, and vendor support utilities.

·        Build rare-path logic using path first-seen time, path frequency baseline, response-size baseline, request timing, source concentration, user-agent profile, source ASN, and approved administrative or vendor-support path inventories.

·        Normalize file paths and URI paths so file-to-web matching can evaluate exact path, related path, derived URL path, and application-relative path relationships.

·        Preserve file-to-web event-pair timing rather than only earliest file and earliest web access per application boundary.

·        Implement event-pair correlation using local Splunk architecture, such as transaction, streamstats, eventstats, accelerated data models, tstats, summary indexes, or lookup-backed pair expansion.

·        Validate indexes, sourcetypes, file path normalization, URI path normalization, host normalization, responsible-process fields, lookup joins, event-pair timing, and timestamp alignment before production deployment.

·        Use shorter correlation windows when suspicious file modification follows abnormal ASP.NET request activity, failed request traces, web shell-like access, rare path access, or IIS child-process execution.

·        Use moderate correlation windows when file modification is followed by rare web access, outbound communication, user downloads, external script loading, or endpoint detections.

·        Use longer correlation windows for delayed operator access, delayed web shell interaction, staged payload activation, user-side delivery, or delayed fake component retrieval.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, protected path sensitivity, file-context sensitivity, responsible-process context, application pool identity context, rare path access, user downloads, and outbound communication.

·        Use deployment records, content update records, vendor-support tickets, build records, cache-generation records, known-good baselines, and application-owner validation as triage evidence.

·        Validate SPL performance against production index size, event volume, lookup cardinality, correlation method, and scheduled-search frequency before enabling alerting.

·        Do not enable high-severity alerting until file telemetry coverage, path baselines, responsible-process mapping, change-control enrichment, event-pair correlation quality, false-positive rate, query performance, and SOC triage procedures are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious application-file modification followed by rare or newly observed web access.

·        The rule remains useful if an adversary changes web shell filename, artifact name, path, extension, source infrastructure, user-agent, or interaction timing.

·        The score is supported by the durability of unauthorized file placement, protected path modification, responsible-process context, rare path access, path first-seen analysis, and web-to-file correlation.

·        The score is constrained by legitimate deployments, content updates, plugin systems, vendor support, build workflows, generated content, cache generation, and weak known-good baselines.

·        The rule is durable as a content-tampering and web shell interaction detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on file telemetry, protected path coverage, responsible-process fields, path first-seen baselines, IIS web logs, host normalization, change-control records, and application-owner validation.

·        Operational confidence is reduced where applications frequently generate files, update content, write to upload paths, use plugin systems, or rely on vendor-managed update workflows.

·        Operational confidence is reduced where file events cannot be tied to responsible process context or where web access logs cannot be tied to the modified path.

·        Full-telemetry confidence improves when file events are enriched with IIS process execution, abnormal ASP.NET request activity, outbound communication, application logs, known-good baselines, and change-control evidence.

·        Under full telemetry conditions, this rule provides strong escalation evidence for suspicious application-file changes, but confirmed exploitation still requires supporting process, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious application-file modification followed by rare web access, not confirmed web shell deployment by itself.

·        Legitimate deployments, plugin updates, content publishing, cache generation, build workflows, vendor support, emergency fixes, and incident-response activity may produce similar file and path-access patterns.

·        Missing responsible-process fields reduce confidence in whether file changes were caused by IIS, deployment tooling, administrators, or attacker activity.

·        Missing path first-seen baselines may reduce the ability to distinguish rare path access from normal application behavior.

·        Dynamic applications may create generated files, cache artifacts, temporary files, or uploaded content that resembles suspicious artifact placement.

·        Hosted or vendor-managed environments may restrict file telemetry, known-good baselines, or deployment records.

·        The rule may miss fileless or memory-resident activity that does not create durable application artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk application-file modification followed by rare web access query pattern requiring SPL syntax validation, index validation, sourcetype validation, protected-path validation, file-context validation, responsible-process validation, rare-path validation, change-control validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

(index=ENV_FILE_OR_EDR_INDEX sourcetype IN (
  ENV_EDR_FILE_SOURCETYPE,
  ENV_SYSMON_FILE_SOURCETYPE,
  ENV_FILE_INTEGRITY_SOURCETYPE
))
event_type IN ("File Created","File Modified","File Renamed","File Overwritten","File Deleted")
file_path IN LOOKUP("protected_iis_aspnet_paths")
AND (
  file_context IN LOOKUP("high_risk_aspnet_file_contexts")
  OR responsible_process IN LOOKUP("suspicious_iis_responsible_processes")
  OR (
    file_extension IN (".aspx",".ashx",".asmx",".dll",".js",".config",".ps1",".vbs",".bat",".cmd",".zip",".7z",".exe")
    AND (
      change_context NOT IN LOOKUP("approved_change_context")
      OR path_context IN LOOKUP("unusual_or_sensitive_application_paths")
      OR followon_context IN LOOKUP("suspicious_file_followon_context")
    )
  )
)
| eval app_boundary=coalesce(app_boundary, host, dest)
| eval modified_path=normalize_path(file_path)
| eval file_event_time=_time
| eval file_event_id=coalesce(event_id, md5(app_boundary . modified_path . file_name . tostring(_time)))
| eval correlation_type="file_precursor"
| fields correlation_type, file_event_id, file_event_time, app_boundary, host, modified_path, file_name, file_extension, file_context, responsible_process, process_command_line, user
| append [
  search index=ENV_WEB_INDEX sourcetype IN (
    ENV_IIS_SOURCETYPE,
    ENV_WAF_SOURCETYPE,
    ENV_REVERSE_PROXY_SOURCETYPE
  )
  (
    uri_path IN CONTEXT("rare_path_for_application")
    OR uri_path IN CONTEXT("newly_observed_path")
    OR event_pattern IN ("web_shell_like_access","low_volume_interactive_access","abnormal_response_size")
  )
  | eval app_boundary=coalesce(app_boundary, backend_host, dest_host, host)
  | eval web_event_time=_time
  | eval web_event_id=coalesce(event_id, md5(app_boundary . src_ip . uri_path . tostring(_time)))
  | eval correlation_type="web_followon"
  | fields correlation_type, web_event_id, web_event_time, app_boundary, src_ip, uri_path, user_agent, response_status, response_size
]
| eventstats
  values(file_event_id) AS candidate_file_event_ids
  values(file_event_time) AS candidate_file_times
  values(modified_path) AS candidate_modified_paths
  values(web_event_id) AS candidate_web_event_ids
  values(web_event_time) AS candidate_web_times
  values(uri_path) AS candidate_uri_paths
  BY app_boundary
| eval pairing_requirement="Preserve individual file-to-web event pairs. Implementation should expand candidate file/web pairs and retain only pairs where web_event_time >= file_event_time, web_event_time <= file_event_time + ENV_ASPNET_FILE_TO_WEB_ACCESS_WINDOW, and uri_path matches or relates to modified_path."
| PAIR_EVENTS key=app_boundary start_type="file_precursor" end_type="web_followon" start_time=file_event_time end_time=web_event_time maxspan=ENV_ASPNET_FILE_TO_WEB_ACCESS_WINDOW
| where web_event_time >= file_event_time
AND web_event_time <= file_event_time + ENV_ASPNET_FILE_TO_WEB_ACCESS_WINDOW
AND (
  uri_path IN SAME_OR_RELATED_PATH(modified_path)
  OR uri_path IN CONTEXT("rare_path_for_application")
  OR uri_path IN CONTEXT("newly_observed_path")
)
| where NOT modified_path IN LOOKUP("approved_deployment_paths")
AND NOT change_context IN LOOKUP("approved_change_context")
AND NOT src_ip IN LOOKUP("approved_administrators_or_vendor_support")

Rule

IIS Server Outbound Communication After Suspicious ASP.NET Activity

Rule Format

Splunk correlation search suitable for IIS logs, WAF logs, reverse proxy logs, Windows logs, EDR process telemetry, EDR network telemetry, DNS logs, proxy logs, firewall logs, destination enrichment, asset inventory, application pool identity mapping, approved destination inventories, and SIEM correlation after index validation, sourcetype validation, host normalization, process-to-network validation, destination validation, approved-destination validation, event-pair correlation validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from IIS-hosted ASP.NET servers after abnormal ASP.NET request activity, suspicious process execution, application-file modification, rare path access, or post-exploitation behavior.

·        Identify possible callback behavior, payload retrieval, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact.

·        Prioritize outbound communication from w3wp.exe, IIS child processes, application pool identities, suspicious command shells, script interpreters, network utilities, or recently modified application contexts.

·        Support escalation when outbound activity aligns with ViewState-bearing request anomalies, IIS child-process execution, suspicious file changes, application-content tampering, credential access, archive creation, defense evasion, or user-delivery evidence.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, user compromise, cloud compromise, or actor attribution without supporting web, endpoint, file, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify outbound network, DNS, proxy, firewall, or endpoint network events from confirmed IIS-hosted ASP.NET servers.

·        Prioritize destinations that are newly observed within the local first-seen window, rare for the host, rare for the application, low reputation, direct IP-based, dynamic DNS-associated, uncommon by port, unusual by TLS SNI, unusual by HTTP host, or outside approved vendor, monitoring, update, backup, deployment, and business-integration inventories.

·        Correlate outbound communication with prior or nearby suspicious ASP.NET activity, including abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, error-to-success patterns, rare path access, or web shell-like access.

·        Correlate outbound communication with nearby host-side evidence, including IIS child-process execution, suspicious command lines, application-file modification, credential access, local discovery, archive creation, defense evasion, persistence attempts, or post-exploitation tool staging.

·        Preserve context-to-outbound event-pair timing so each outbound event is correlated to the specific preceding web, host, or file context event that supports it.

·        Increase confidence when outbound communication is process-linked to w3wp.exe, IIS child processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities.

·        Increase confidence when outbound communication follows modified JavaScript, login-page changes, external script reference additions, downloadable-component changes, suspicious file creation, or user-delivery evidence.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, deployment destinations, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Do not classify outbound communication as exploitation-related without suspicious web, host, file, application, or incident-response evidence.

·        Do not treat destination novelty, direct IP connections, unusual ports, DNS rarity, cloud hosting, or high byte volume as compromise evidence by itself.

·        Do not let this rule duplicate the process-execution rule unless outbound communication materially changes the risk context.

Required Telemetry

·        Splunk indexes containing IIS logs.

·        Splunk indexes containing WAF logs where available.

·        Splunk indexes containing reverse proxy logs where available.

·        Splunk indexes containing endpoint process telemetry.

·        Splunk indexes containing endpoint network telemetry.

·        Splunk indexes containing DNS logs.

·        Splunk indexes containing proxy logs.

·        Splunk indexes containing firewall logs.

·        Host field.

·        Source asset field.

·        Destination IP.

·        Destination domain.

·        Destination port.

·        Destination reputation where available.

·        Destination first-seen timestamp where available.

·        TLS SNI where available.

·        HTTP host where available.

·        Protocol.

·        Directionality.

·        Connection timestamp.

·        Session duration where available.

·        Byte count where available.

·        Process name where available.

·        Parent process name where available.

·        Process command line where available.

·        Process user where available.

·        Application pool identity context where available.

·        DNS query field where available.

·        Proxy URL field where available.

·        Firewall action field where available.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Application pool identity mapping.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Destination reputation enrichment.

·        Asset enrichment.

·        Identity enrichment.

·        IIS logs where available.

·        ASP.NET application logs where available.

·        File telemetry where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build Splunk asset lookups for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build outbound destination lookups for approved vendor services, monitoring platforms, backup systems, deployment systems, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Build suspicious destination logic for newly observed destinations within the local first-seen window, rare destinations, low-reputation destinations, direct IP destinations, dynamic DNS destinations, uncommon ports, rare SNI values, unusual HTTP hosts, cloud-hosted infrastructure, developer platforms, object storage, file-transfer services, and destinations outside approved dependencies.

·        Build precursor logic for abnormal ViewState-bearing POST activity, rare path access, failed request traces, error-to-success patterns, IIS child-process execution, application-file modification, credential access, archive creation, defense evasion, and application-content tampering.

·        Preserve context-to-outbound event-pair timing rather than only earliest context and earliest outbound activity per application boundary.

·        Implement event-pair correlation using local Splunk architecture, such as transaction, streamstats, eventstats, accelerated data models, tstats, summary indexes, or lookup-backed pair expansion.

·        Validate indexes, sourcetypes, process-to-network fields, DNS fields, proxy fields, firewall fields, destination enrichment, asset lookups, identity enrichment, timestamp alignment, host normalization, and event-pair timing before production deployment.

·        Use shorter correlation windows when suspicious web or host activity is followed quickly by outbound communication, DNS lookup, direct IP contact, payload retrieval, rare destination access, or callback-like behavior.

·        Use moderate correlation windows when outbound behavior follows abnormal request activity, application errors, file modification, credential access, archive creation, rare path access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, repeated low-volume communication, staged payload retrieval, delayed operator return, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, application pool identity context, process-linked outbound communication, post-exploitation behavior, credential access, archive creation, persistence attempts, rare destination communication, direct IP egress, unusual port use, destination reputation, and supporting web or file evidence.

·        Avoid broad suppression for cloud providers, developer platforms, file-transfer services, monitoring platforms, backup systems, update services, vendor support destinations, managed hosting destinations, business integrations, and incident-response infrastructure without validation.

·        Use approved destination inventories, vendor-support records, deployment records, backup schedules, monitoring inventories, maintenance windows, business-integration inventories, and incident-response records as triage evidence.

·        Validate SPL performance against production index size, event volume, correlation strategy, lookup cardinality, and scheduled-search frequency before enabling alerting.

·        Do not enable high-severity alerting until network telemetry fidelity, destination baselines, process-to-network mapping, field mappings, event-pair correlation quality, false-positive rate, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to outbound communication after suspicious ASP.NET, host, or file activity rather than destination novelty alone.

·        The rule remains useful if an adversary changes destination domain, IP address, protocol, web shell family, payload staging method, callback timing, or post-exploitation toolset.

·        The score is supported by the durability of suspicious server egress when correlated with web, host, file, and application context.

·        The score is constrained by legitimate server egress, weak destination inventories, shared egress paths, incomplete process-to-network mapping, and broad approved dependencies.

·        The rule is durable as a post-exploitation correlation but should not be treated as standalone proof of exploitation, command-and-control, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on DNS, proxy, firewall, endpoint network telemetry, destination enrichment, process-to-network mapping, asset inventory, and approved destination inventories.

·        Operational confidence is reduced where IIS servers have broad egress, weak destination baselines, shared egress paths, or legitimate automation that contacts rare destinations.

·        Operational confidence is reduced where outbound communication cannot be linked to the responsible host, process, user, or application boundary.

·        Full-telemetry confidence improves when outbound events are enriched with IIS logs, WAF logs, EDR process telemetry, file telemetry, ASP.NET application logs, destination reputation, identity context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for post-exploitation activity, but confirmed compromise still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET, host, or file activity, not confirmed exploitation by itself.

·        Legitimate vendor services, update checks, monitoring workflows, backup operations, deployment automation, business integrations, managed hosting operations, and incident response may produce similar outbound patterns.

·        Missing process-to-network telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        Missing destination enrichment may reduce the ability to distinguish suspicious destinations from legitimate dependencies.

·        Reverse proxy, NAT, shared egress, and hosted infrastructure may make workload attribution difficult.

·        The rule may miss attackers who avoid outbound communication, use approved infrastructure, operate fully in-process, or complete objectives through local application manipulation.

·        The rule may miss activity where network telemetry is unavailable, delayed, or not retained.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk IIS server outbound communication after suspicious ASP.NET activity query pattern requiring SPL syntax validation, index validation, sourcetype validation, host normalization, destination enrichment validation, process-to-network validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

(index=ENV_NETWORK_OR_ENDPOINT_NETWORK_INDEX sourcetype IN (
  ENV_EDR_NETWORK_SOURCETYPE,
  ENV_DNS_SOURCETYPE,
  ENV_PROXY_SOURCETYPE,
  ENV_FIREWALL_SOURCETYPE
))
src_host IN LOOKUP("iis_aspnet_server_assets")
AND direction IN ("OUTBOUND","SERVER_TO_EXTERNAL","CLOUD_BOUND")
AND (
  dest_first_seen >= relative_time(now(), "-ENV_NEW_DESTINATION_WINDOW")
  OR dest_reputation IN ("rare","newly_observed","unknown","suspicious","high_risk")
  OR dest_context IN (
    "direct_ip_destination",
    "dynamic_dns_destination",
    "low_reputation_destination",
    "uncommon_port",
    "rare_sni",
    "unusual_http_host",
    "outside_approved_dependency"
  )
  OR process_name IN LOOKUP("suspicious_iis_network_processes")
)
| eval app_boundary=coalesce(app_boundary, src_host, host)
| eval outbound_event_time=_time
| eval outbound_event_id=coalesce(event_id, md5(app_boundary . src_host . dest_ip . dest_domain . tostring(_time)))
| eval correlation_type="outbound_followon"
| fields correlation_type, outbound_event_id, outbound_event_time, app_boundary, src_host, process_name, process_command_line, user, dest_ip, dest_domain, dest_port, dest_reputation, dest_context
| append [
  search index IN (ENV_WEB_INDEX, ENV_ENDPOINT_INDEX, ENV_FILE_OR_EDR_INDEX)
  (
    event_type IN (
      "Abnormal ViewState Bearing POST",
      "Web Shell Like Access",
      "Rare Path Access",
      "Failed Request Trace",
      "Error Then Success Pattern",
      "IIS Worker Process Child Execution",
      "Command Shell Execution",
      "Credential Access",
      "Archive Creation",
      "Defense Evasion",
      "Application File Modified",
      "JavaScript File Modified",
      "Suspicious File Created"
    )
    OR event_pattern IN (
      "suspicious_aspnet_request_activity",
      "suspicious_iis_host_behavior",
      "suspicious_application_file_activity"
    )
  )
  | eval app_boundary=coalesce(app_boundary, host, dest_host, backend_host)
  | eval context_event_time=_time
  | eval context_event_id=coalesce(event_id, md5(app_boundary . host . event_type . event_pattern . tostring(_time)))
  | eval correlation_type="supporting_precursor"
  | fields correlation_type, context_event_id, context_event_time, app_boundary, host, event_type, event_pattern
]
| eventstats
  values(context_event_id) AS candidate_context_event_ids
  values(context_event_time) AS candidate_context_times
  values(outbound_event_id) AS candidate_outbound_event_ids
  values(outbound_event_time) AS candidate_outbound_times
  BY app_boundary
| eval pairing_requirement="Preserve individual context-to-outbound event pairs. Implementation should expand candidate context/outbound pairs and retain only pairs where outbound_event_time >= context_event_time and outbound_event_time <= context_event_time + ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW."
| PAIR_EVENTS key=app_boundary start_type="supporting_precursor" end_type="outbound_followon" start_time=context_event_time end_time=outbound_event_time maxspan=ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW
| where outbound_event_time >= context_event_time
AND outbound_event_time <= context_event_time + ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW
| where NOT dest_domain IN LOOKUP("approved_iis_destinations")
AND NOT dest_ip IN LOOKUP("approved_iis_destination_ips")
AND NOT ChangeContext IN LOOKUP("approved_change_context")

Elastic

Detection Viability Assessment

Elastic has three rules for this EXP report.

·        Elastic is viable for detecting ASP.NET ViewState deserialization and shared machineKey exploitation when IIS, Windows, endpoint, file, DNS, proxy, firewall, WAF, reverse proxy, and web telemetry are normalized into ECS-aligned fields.

·        Elastic is strongest where event.*, host.*, process.*, file.*, user.*, url.*, http.*, source.*, destination.*, dns.*, tls.*, and network.* fields are consistently populated across web, endpoint, file, and network data sources.

·        Elastic can identify suspicious sequencing between abnormal ASP.NET request activity, IIS worker-process execution, application-file modification, rare path access, outbound communication, web shell-like behavior, and post-exploitation host behavior.

·        Elastic is not a standalone source for confirming ViewState deserialization or shared machineKey exploitation unless web telemetry, endpoint telemetry, file telemetry, network telemetry, timing correlation, and application context support that conclusion.

·        Elastic rules must be validated against local index patterns, ECS mappings, ingest pipelines, field aliases, exception lists, host normalization, application-boundary mapping, application ownership, and SOC triage workflows before production alerting.

·        Elastic detection content should be treated as high-value behavior-led coverage for exploit-attempt correlation, host compromise validation, suspicious application-file change detection, rare path interaction detection, and outbound communication scoping, not direct CVE confirmation or actor attribution by itself.

·        Elastic rules should not generate high-confidence alerting from file extension alone, process name alone, large POST requests alone, destination novelty alone, rare path access alone, cloud-hosted destination context alone, or generic event category matching without supporting correlation.

Rule

IIS Worker Process Command Execution From ASP.NET Application Context

Rule Format

Elastic EQL or KQL correlation rule suitable for ECS-aligned endpoint process events, Windows logs, Sysmon telemetry, EDR process telemetry, IIS server inventory, ASP.NET application inventory, web request telemetry, WAF telemetry, reverse proxy telemetry, application pool identity mapping, host enrichment, application-boundary enrichment, and SIEM correlation after index-pattern validation, ECS field validation, process-event validation, host normalization, application-boundary mapping, time-window tuning, exception testing, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious command execution from IIS worker processes, ASP.NET application contexts, or application pool identities that may indicate server-side execution, web shell interaction, payload staging, or post-exploitation activity.

·        Identify host-side execution behavior without relying on exploit payload syntax, machineKey material, proof-of-concept strings, web shell filenames, fixed source infrastructure, or named tooling.

·        Prioritize w3wp.exe, IIS worker processes, ASP.NET application processes, application pool identities, IIS service accounts, vendor application service accounts, and web-facing application hosts.

·        Support escalation when IIS worker-process execution aligns with abnormal ViewState-bearing request activity, failed request traces, application errors, rare path access, application-file changes, outbound communication, or credential access.

·        This rule does not prove ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, credential theft, Cobalt Strike delivery, or actor attribution without supporting web, file, network, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify process start events where the parent process is w3wp.exe, an IIS worker process, an ASP.NET application process, or a process running under an application pool identity.

·        Prioritize child processes involving command shells, PowerShell, script interpreters, HTML application execution, living-off-the-land binaries, archive utilities, network utilities, credential utilities, or unusual administrative utilities.

·        Prioritize command lines involving encoded execution, hidden execution, remote content retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, or execution from application-controlled directories.

·        Prioritize execution where the user context maps to an application pool identity, IIS service account, vendor application service account, or service account that normally should not perform interactive administrative activity.

·        Increase confidence when process execution follows abnormal ASP.NET request activity, large or unusual POST activity, HTTP 500-series bursts, failed request traces, application pool instability, web shell-like access, or rare path access.

·        Increase confidence when process execution is followed by file creation, webroot modification, application-content tampering, outbound communication, credential access, local discovery, archive creation, defense evasion, or persistence-like behavior.

·        Increase confidence when execution originates from or references webroot paths, upload paths, plugin-like directories, temporary ASP.NET compilation paths, vendor application paths, user-writable directories, or recently modified application directories.

·        Reduce severity for approved deployment tools, backup jobs, monitoring agents, vendor support tools, reporting jobs, software update workflows, administrative automation, IIS maintenance tasks, incident-response activity, and documented operational jobs.

·        Do not classify IIS child-process execution as ViewState exploitation without timing, request-path, exposure, application, file, or network correlation.

·        Do not treat w3wp.exe child execution as compromise evidence by itself where legitimate application workflows, reporting jobs, backup operations, vendor support, or deployment automation spawn child processes.

Required Telemetry

·        Elastic endpoint process events.

·        Windows process creation events.

·        Sysmon process creation events where available.

·        EDR process telemetry where available.

·        IIS web logs where available.

·        WAF logs where available.

·        Reverse proxy logs where available.

·        event.category.

·        event.type.

·        event.action.

·        event.reason where available.

·        host.name.

·        host.id.

·        Application-boundary enrichment field where available.

·        process.name.

·        process.executable.

·        process.command_line.

·        process.parent.name.

·        process.parent.executable.

·        process.parent.command_line.

·        process.pid.

·        process.parent.pid.

·        user.name.

·        user.domain.

·        user.id where available.

·        process.hash.* where available.

·        process.code_signature.* where available.

·        process.pe.original_file_name where available.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Application-boundary mapping.

·        Application pool identity mapping.

·        Service-account mapping.

·        Webroot path inventory.

·        Upload path inventory where available.

·        Vendor application path inventory.

·        Temporary ASP.NET compilation path inventory.

·        File telemetry where available.

·        Network telemetry where available.

·        Change-control records.

·        Maintenance-window records.

·        Approved deployment tool inventory.

·        Approved administrative automation inventory.

·        Approved vendor-support inventory.

·        Approved reporting job inventory.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build Elastic asset lists for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build identity lists for application pool identities, IIS service accounts, vendor application service accounts, and service accounts that should not perform interactive command execution.

·        Build process groups for w3wp.exe, IIS worker processes, command shells, PowerShell, script interpreters, living-off-the-land binaries, archive utilities, network utilities, credential utilities, and unusual administrative utilities.

·        Build command-line pattern groups for encoded commands, hidden execution, remote content retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, and execution from application-controlled paths.

·        Build application path groups for webroot directories, upload directories, plugin-like paths, temporary ASP.NET compilation paths, vendor application paths, user-writable paths, and recently modified directories.

·        Normalize backend host, proxy host, load balancer backend, endpoint host, and application-boundary fields before relying on EQL sequence logic.

·        Use host.id only when web and endpoint events reliably resolve to the same IIS host.

·        Use an enriched application_boundary, normalized IIS backend host, workload boundary, load balancer backend mapping, or transform-backed correlation key when WAF, CDN, reverse proxy, NAT, shared sensor, or load balancer telemetry does not share the endpoint host.id.

·        Preserve event-pair timing between suspicious web events and process events when implementing cross-index correlation.

·        Use Elastic EQL sequences, event correlation rules, timeline templates, transforms, or detection rule exceptions depending on local architecture and license capabilities.

·        Use shorter correlation windows when abnormal ASP.NET request activity is followed quickly by IIS child-process execution or suspicious command-line behavior.

·        Use moderate correlation windows when process execution is followed by file staging, webroot modification, outbound communication, credential access, archive creation, or rare path access.

·        Use longer correlation windows for delayed operator interaction, staged payload execution, delayed callback behavior, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, application pool identity context, suspicious command-line behavior, execution from application-controlled paths, file writes, outbound communication, credential access, and supporting web telemetry.

·        Use deployment records, maintenance windows, backup schedules, vendor-support tickets, reporting job inventories, approved script inventories, and incident-response records as triage evidence.

·        Validate rule performance against data volume, index pattern coverage, exception list behavior, timeline usability, alert grouping, sequence behavior, and SOC triage workflow before production deployment.

·        Do not enable high-severity alerting until ECS mappings, index patterns, host normalization, application-boundary mapping, baselines, exception lists, event-pair correlation quality, and SOC triage procedures are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to IIS worker-process child execution, which is a durable post-exploitation signal across ASP.NET application compromise scenarios.

·        The rule remains useful if an adversary changes ViewState payload structure, command syntax, child process selection, file path, web shell family, or outbound infrastructure.

·        The score is supported by the durability of process ancestry, command-line context, application pool identity context, execution path context, and cross-layer correlation with web, file, or network evidence.

·        The score is constrained by legitimate administrative automation, vendor support workflows, backup jobs, reporting jobs, deployment tools, applications that legitimately spawn child processes, incomplete command-line visibility, and incomplete application-boundary enrichment.

·        The rule is durable as a compromise-validation detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on process telemetry, command-line visibility, ECS field quality, application pool identity mapping, host inventory, webroot path mapping, process baselines, application-boundary mapping, and application-owner validation.

·        Operational confidence is reduced where legitimate application workflows spawn command shells, scripts, reporting tools, archive utilities, backup tools, or vendor support tooling from the IIS server.

·        Operational confidence is reduced where endpoint telemetry lacks command-line fields, process parent fields, reliable application pool identity mapping, or reliable application-boundary enrichment.

·        Full-telemetry confidence improves when process execution is enriched with IIS logs, WAF logs, ASP.NET application logs, file telemetry, outbound network telemetry, vulnerability context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence, but confirmed exploitation still requires supporting web, file, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious IIS worker-process child execution, not confirmed ViewState exploitation by itself.

·        Legitimate deployment tools, backup jobs, reporting workflows, application maintenance, vendor support, administrative automation, and incident-response activity may produce similar parent-child process patterns.

·        Missing command-line telemetry reduces the ability to distinguish malicious execution from benign process activity.

·        Missing application pool identity mapping may reduce confidence in whether the process belongs to the affected ASP.NET application.

·        Missing IIS, WAF, or ASP.NET telemetry may prevent confirmation that suspicious execution followed abnormal request activity.

·        WAF, CDN, reverse proxy, load balancer, NAT, and hosted infrastructure may prevent direct host-level pairing unless backend or application-boundary enrichment is available.

·        The rule may miss exploitation that avoids child-process creation, remains in-process, or uses memory-resident execution without visible process creation.

·        The rule may miss activity if endpoint telemetry is disabled, delayed, tampered with, or unavailable in hosted or vendor-managed environments.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic IIS worker-process command execution query pattern requiring EQL or KQL syntax validation, ECS field validation, index-pattern validation, host normalization, application-boundary normalization, application pool identity validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

The sequence key must be implemented as host.id only when web and endpoint telemetry resolve to the same IIS backend host. In WAF, CDN, reverse proxy, load balancer, NAT, shared sensor, or hosted environments, production implementations must sequence by a normalized IIS backend host, enriched application_boundary, workload-boundary key, or transform-backed correlation field.

sequence by COALESCE(host.id, application_boundary) with maxspan=ENV_ASPNET_REQUEST_TO_PROCESS_WINDOW
  [any where
    event.category in ("web", "network")
    and event.type in ("access", "connection", "info")
    and (
      http.request.method == "POST"
      or http.request.method == "post"
    )
    and (
      url.path in $viewstate_bearing_aspnet_paths
      or url.path in $aspnet_authentication_adjacent_paths
      or url.path in $aspnet_administrative_adjacent_paths
      or url.path in $aspnet_upload_paths
      or url.path in $aspnet_lms_workflow_paths
    )
    and (
      http.request.bytes > $aspnet_endpoint_post_size_p95
      or http.response.status_code in (500, 502, 503)
      or event.reason in (
        "error_then_success",
        "repeated_request_variation",
        "sparse_targeted_requests",
        "abnormal_request_cadence",
        "suspicious_allowed_web_activity"
      )
      or source.as.organization.name in $rare_or_suspicious_source_asns
      or source.ip in $rare_sources_for_application
    )
  ]
  [process where
    event.category == "process"
    and event.type == "start"
    and (
process.parent.name in ("w3wp.exe", "iisexpress.exe")
      or process.parent.executable : "*\\inetsrv\\*"
      or user.name in $iis_application_pool_identities
    )
    and (
process.name in (
        "cmd.exe",
        "powershell.exe",
        "pwsh.exe",
        "wscript.exe",
        "cscript.exe",
        "mshta.exe",
        "rundll32.exe",
        "regsvr32.exe",
        "certutil.exe",
        "bitsadmin.exe",
        "curl.exe",
        "wget.exe",
        "tar.exe",
        "7z.exe"
      )
      or process.command_line : (
        "*-enc*",
        "*EncodedCommand*",
        "*download*",
        "*upload*",
        "*http://*",
        "*https://*",
        "*\\Temporary ASP.NET Files\\*",
        "*\\inetpub\\wwwroot\\*"
      )
    )
    and not process.command_line in $approved_deployment_or_admin_commands
    and not user.name in $approved_administrative_automation_users
  ]

Rule

Suspicious Application Directory File Modification With Follow-On Web Access

Rule Format

Elastic EQL or KQL correlation rule suitable for ECS-aligned file events, endpoint events, Sysmon file telemetry, file integrity telemetry, IIS web logs, WAF logs, reverse proxy logs, webroot inventory, application path inventory, known-good baselines, path frequency baselines, path-relationship enrichment, asset enrichment, and SIEM correlation after index-pattern validation, ECS field validation, protected-path validation, file-context validation, path-normalization validation, rare-path validation, change-control validation, event-pair preservation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious application-file creation or modification followed by rare, newly observed, or web shell-like access to the same or related application path.

·        Identify possible web shell placement, unauthorized ASPX artifact creation, application-content tampering, JavaScript modification, fake component staging, or modified downloadable content.

·        Prioritize file activity under webroot, vendor application, upload, plugin-like, temporary compilation, JavaScript, configuration, login-page, and downloadable-component paths.

·        Support escalation when suspicious file activity aligns with abnormal ASP.NET request activity, IIS process execution, rare path access, outbound communication, user downloads, or external script loading.

·        This rule does not prove web shell placement, ViewState exploitation, application compromise, user compromise, or actor attribution without supporting process, web, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify file creation, modification, rename, overwrite, or deletion events under protected IIS or ASP.NET application paths.

·        Prioritize high-risk file context involving new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script reference additions, configuration changes, archive staging, executable staging, or suspicious temporary artifacts.

·        Prioritize file activity where the responsible process is w3wp.exe, an IIS worker process, a suspicious IIS child process, a script interpreter, a command shell, or an application pool identity.

·        Treat high-risk file extension matches as supporting context only unless paired with suspicious file context, suspicious responsible process, abnormal change timing, unusual path context, or follow-on evidence.

·        Correlate suspicious file activity with subsequent rare web access, newly observed path access, low-frequency path access, abnormal response-size patterns, web shell-like timing, user downloads, or external script loading.

·        Preserve file-to-web event-pair timing so each suspicious file event is correlated to the specific subsequent web access event, not only the earliest file and earliest web event for the application.

·        Use normalized file-to-URL relationship mapping where the deployment path, webroot path, virtual directory, application route, or rewritten URL prevents direct file.path to url.path matching.

·        Increase confidence when file modification follows abnormal ViewState-bearing POST activity, failed request traces, rare path access, IIS child-process execution, credential access, outbound communication, or application errors.

·        Increase confidence when the modified file is later accessed over HTTP, loaded by the application, referenced by modified content, downloaded by users, or associated with outbound communication.

·        Reduce severity for approved deployments, content updates, plugin updates, vendor patches, backup jobs, build jobs, cache generation, emergency fixes, incident response, and documented maintenance.

·        Do not classify file modification as malicious content tampering or web shell placement without supporting process, web access, network, application, or change-control evidence.

·        Do not rely on file extension alone, known web shell filenames, known hashes, public artifact strings, specific JavaScript names, or named tooling as required detection conditions.

Required Telemetry

·        Elastic file events.

·        Elastic endpoint events.

·        Sysmon file telemetry where available.

·        File integrity telemetry where available.

·        IIS web logs where available.

·        WAF logs where available.

·        Reverse proxy logs where available.

·        event.category.

·        event.type.

·        event.action.

·        event.reason where available.

·        host.name.

·        host.id.

·        Application-boundary enrichment field where available.

·        file.path.

·        file.name.

·        file.extension.

·        file.hash.* where available.

·        file.size where available.

·        File context enrichment where available.

·        File path context enrichment where available.

·        File follow-on context enrichment where available.

·        process.name where available.

·        process.executable where available.

·        process.command_line where available.

·        process.parent.name where available.

·        user.name.

·        url.path.

·        http.response.status_code.

·        http.response.bytes where available.

·        source.ip.

·        user_agent.original where available.

·        Path first-seen context where available.

·        Path frequency baseline.

·        File-to-URL relationship mapping where available.

·        Webroot path inventory.

·        Vendor application path inventory.

·        Upload path inventory where available.

·        Plugin-like path inventory where available.

·        Temporary ASP.NET compilation path inventory.

·        JavaScript path inventory.

·        Configuration path inventory.

·        Login-page path inventory where available.

·        Downloadable-component path inventory where available.

·        Approved deployment path inventory.

·        Approved content update records.

·        Approved vendor-support records.

·        Approved build records.

·        Approved cache-generation records.

·        Known-good application baselines.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build protected application path lists for webroot directories, ASP.NET application paths, vendor application paths, upload directories, plugin-like paths, temporary ASP.NET compilation paths, JavaScript directories, configuration directories, login-page paths, downloadable-component paths, and user-facing content paths.

·        Build high-risk file-context lists for new ASPX files, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script references, configuration changes, archive staging, executable staging, deleted-after-execution artifacts, and suspicious temporary files.

·        Build responsible-process logic for w3wp.exe, IIS worker processes, application pool identities, suspicious IIS child processes, script interpreters, command shells, deployment tools, build tools, backup tools, cache generation processes, and vendor support utilities.

·        Build rare-path logic using path first-seen time, path frequency baseline, response-size baseline, request timing, source concentration, user-agent profile, source ASN, and approved administrative or vendor-support path inventories.

·        Normalize file paths and URI paths so file-to-web matching can evaluate exact path, related path, derived URL path, virtual directory mapping, rewritten route, and application-relative path relationships.

·        Preserve file-to-web event-pair timing between file events and web access events.

·        Use Elastic EQL sequences when file and web events share reliable host.id or application-boundary enrichment.

·        Use transforms, enrich processors, runtime fields, or timeline-based triage where file-to-URL relationship mapping cannot be expressed safely in a single EQL sequence.

·        Use shorter correlation windows when suspicious file modification follows abnormal ASP.NET request activity, failed request traces, web shell-like access, rare path access, or IIS child-process execution.

·        Use moderate correlation windows when file modification is followed by rare web access, outbound communication, user downloads, external script loading, or endpoint detections.

·        Use longer correlation windows for delayed operator access, delayed web shell interaction, staged payload activation, user-side delivery, or delayed fake component retrieval.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, protected path sensitivity, file-context sensitivity, responsible-process context, application pool identity context, rare path access, user downloads, and outbound communication.

·        Use deployment records, content update records, vendor-support tickets, build records, cache-generation records, known-good baselines, and application-owner validation as triage evidence.

·        Validate Elastic rule performance against index volume, field coverage, event correlation behavior, exception list behavior, timeline usability, and SOC triage workflow before production deployment.

·        Do not enable high-severity alerting until file telemetry coverage, path baselines, responsible-process mapping, change-control enrichment, event-pair correlation quality, false-positive rate, rule performance, and SOC triage procedures are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious application-file modification followed by rare or newly observed web access.

·        The rule remains useful if an adversary changes web shell filename, artifact name, path, extension, source infrastructure, user-agent, or interaction timing.

·        The score is supported by the durability of unauthorized file placement, protected path modification, responsible-process context, rare path access, path first-seen analysis, and web-to-file correlation.

·        The score is constrained by legitimate deployments, content updates, plugin systems, vendor support, build workflows, generated content, cache generation, weak known-good baselines, and missing file-to-URL relationship mapping.

·        The rule is durable as a content-tampering and web shell interaction detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on file telemetry, protected path coverage, responsible-process fields, path first-seen baselines, IIS web logs, host normalization, application-boundary enrichment, file-to-URL relationship mapping, change-control records, and application-owner validation.

·        Operational confidence is reduced where applications frequently generate files, update content, write to upload paths, use plugin systems, or rely on vendor-managed update workflows.

·        Operational confidence is reduced where file events cannot be tied to responsible process context or where web access logs cannot be tied to the modified path.

·        Full-telemetry confidence improves when file events are enriched with IIS process execution, abnormal ASP.NET request activity, outbound communication, application logs, known-good baselines, and change-control evidence.

·        Under full telemetry conditions, this rule provides strong escalation evidence for suspicious application-file changes, but confirmed exploitation still requires supporting process, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious application-file modification followed by rare web access, not confirmed web shell deployment by itself.

·        Legitimate deployments, plugin updates, content publishing, cache generation, build workflows, vendor support, emergency fixes, and incident-response activity may produce similar file and path-access patterns.

·        Missing responsible-process fields reduce confidence in whether file changes were caused by IIS, deployment tooling, administrators, or attacker activity.

·        Missing path first-seen baselines may reduce the ability to distinguish rare path access from normal application behavior.

·        Dynamic applications may create generated files, cache artifacts, temporary files, or uploaded content that resembles suspicious artifact placement.

·        Hosted or vendor-managed environments may restrict file telemetry, known-good baselines, or deployment records.

·        File-to-web matching may be unreliable when applications use URL rewriting, virtual directories, generated routes, CDN path rewriting, or custom routing unless file-to-URL enrichment exists.

·        The rule may miss fileless or memory-resident activity that does not create durable application artifacts.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic application-file modification followed by rare web access query pattern requiring EQL or KQL syntax validation, ECS field validation, index-pattern validation, protected-path validation, file-context validation, responsible-process validation, path-normalization validation, rare-path validation, file-to-URL enrichment validation, change-control validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

sequence by COALESCE(host.id, application_boundary) with maxspan=ENV_ASPNET_FILE_TO_WEB_ACCESS_WINDOW
  [file where
    event.category == "file"
    and event.type in ("creation", "change", "deletion")
    and file.path in $protected_iis_aspnet_paths
    and (
      file.Ext.context in $high_risk_aspnet_file_contexts
      or process.name in $suspicious_iis_responsible_processes
      or (
        file.extension in ("aspx", "ashx", "asmx", "dll", "js", "config", "ps1", "vbs", "bat", "cmd", "zip", "7z", "exe")
        and (
          not event.reason in $approved_change_context
          or file.Ext.path_context in $unusual_or_sensitive_application_paths
          or file.Ext.followon_context in $suspicious_file_followon_context
        )
      )
    )
    and not file.path in $approved_deployment_paths
    and not event.reason in $approved_change_context
  ]
  [any where
    event.category in ("web", "network")
    and (
      url.path in $rare_paths_for_application
      or url.path in $newly_observed_paths
      or url.path in $paths_related_to_recent_suspicious_file_changes
      or event.reason in ("web_shell_like_access", "low_volume_interactive_access", "abnormal_response_size")
    )
    and not source.ip in $approved_administrators_or_vendor_support
  ]

Rule

IIS Server Rare Destination Communication After Suspicious Web or Host Activity

Rule Format

Elastic EQL or KQL correlation rule suitable for ECS-aligned endpoint network events, DNS events, proxy events, firewall events, IIS web logs, WAF logs, reverse proxy logs, endpoint process telemetry, file telemetry, destination enrichment, asset inventory, application pool identity mapping, approved destination inventories, and SIEM correlation after index-pattern validation, ECS field validation, host normalization, application-boundary mapping, destination-enrichment validation, process-to-network validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from IIS-hosted ASP.NET servers after abnormal ASP.NET request activity, suspicious process execution, application-file modification, rare path access, or post-exploitation behavior.

·        Identify possible callback behavior, payload retrieval, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact.

·        Prioritize outbound communication from w3wp.exe, IIS child processes, application pool identities, suspicious command shells, script interpreters, network utilities, or recently modified application contexts.

·        Support escalation when outbound activity aligns with ViewState-bearing request anomalies, IIS child-process execution, suspicious file changes, application-content tampering, credential access, archive creation, defense evasion, or user-delivery evidence.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, user compromise, cloud compromise, or actor attribution without supporting web, endpoint, file, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify outbound network, DNS, proxy, firewall, or endpoint network events from confirmed IIS-hosted ASP.NET servers.

·        Prioritize destinations that are newly observed within the local first-seen window, rare for the host, rare for the application, low reputation, direct IP-based, dynamic DNS-associated, uncommon by port, unusual by TLS SNI, unusual by HTTP host, or outside approved vendor, monitoring, update, backup, deployment, and business-integration inventories.

·        Correlate outbound communication with specific prior or nearby suspicious ASP.NET activity, including abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, error-to-success patterns, rare path access, or web shell-like access.

·        Correlate outbound communication with specific nearby host-side or file evidence, including IIS child-process execution, suspicious command lines, application-file modification, credential access, local discovery, archive creation, defense evasion, persistence attempts, or post-exploitation tool staging.

·        Preserve context-to-outbound event-pair timing so each outbound event is correlated to the specific preceding web, host, or file context event that supports it.

·        Increase confidence when outbound communication is process-linked to w3wp.exe, IIS child processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities.

·        Increase confidence when outbound communication follows modified JavaScript, login-page changes, external script reference additions, downloadable-component changes, suspicious file creation, or user-delivery evidence.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, deployment destinations, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Do not classify outbound communication as exploitation-related without suspicious web, host, file, application, or incident-response evidence.

·        Do not treat destination novelty, direct IP connections, unusual ports, DNS rarity, cloud hosting, or high byte volume as compromise evidence by itself.

·        Do not let this rule duplicate the process-execution rule unless outbound communication materially changes the risk context.

Required Telemetry

·        Elastic endpoint network events.

·        Elastic DNS events.

·        Proxy events where available.

·        Firewall events where available.

·        IIS web logs where available.

·        WAF logs where available.

·        Reverse proxy logs where available.

·        Endpoint process telemetry.

·        File telemetry where available.

·        event.category.

·        event.type.

·        event.action.

·        event.reason where available.

·        host.name.

·        host.id.

·        Application-boundary enrichment field where available.

·        source.ip.

·        source.port where available.

·        destination.ip.

·        destination.domain.

·        destination.port.

·        destination.as.* where available.

·        destination.geo.* where available.

·        network.direction.

·        network.protocol.

·        network.transport.

·        network.bytes.

·        dns.question.name where available.

·        tls.server.x509.subject.common_name where available.

·        url.domain where available.

·        url.path where available.

·        process.name where available.

·        process.command_line where available.

·        process.parent.name where available.

·        user.name where available.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Application-boundary mapping.

·        Application pool identity mapping.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Asset enrichment.

·        Identity enrichment.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build Elastic asset lists for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build destination lists for approved vendor services, monitoring platforms, backup systems, deployment systems, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Build suspicious destination logic for newly observed destinations within the local first-seen window, rare destinations, low-reputation destinations, direct IP destinations, dynamic DNS destinations, uncommon ports, rare TLS context, unusual HTTP hosts, cloud-hosted infrastructure, developer platforms, object storage, file-transfer services, and destinations outside approved dependencies.

·        Build precursor logic for abnormal ViewState-bearing POST activity, rare path access, failed request traces, error-to-success patterns, IIS child-process execution, application-file modification, credential access, archive creation, defense evasion, and application-content tampering.

·        Avoid broad precursor conditions such as generic event.category in ("web", "process", "file") without a specific suspicious reason, indicator, behavior, or enriched context.

·        Preserve context-to-outbound event-pair timing rather than only earliest context and earliest outbound activity per application boundary.

·        Use host.id only when precursor and outbound events resolve to the same IIS server or normalized workload boundary.

·        Use application-boundary enrichment, transforms, or timeline-based correlation when WAF, proxy, load balancer, NAT, or shared egress layers prevent direct host-level sequencing.

·        Use Elastic EQL sequences, event correlation rules, transforms, timeline templates, or detection exceptions depending on local architecture and license capabilities.

·        Validate ECS mappings, index patterns, process-to-network fields, DNS fields, proxy fields, firewall fields, destination enrichment, asset lists, identity enrichment, timestamp alignment, host normalization, application-boundary mapping, and event-pair timing before production deployment.

·        Use shorter correlation windows when suspicious web or host activity is followed quickly by outbound communication, DNS lookup, direct IP contact, payload retrieval, rare destination access, or callback-like behavior.

·        Use moderate correlation windows when outbound behavior follows abnormal request activity, application errors, file modification, credential access, archive creation, rare path access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, repeated low-volume communication, staged payload retrieval, delayed operator return, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, application pool identity context, process-linked outbound communication, post-exploitation behavior, credential access, archive creation, persistence attempts, rare destination communication, direct IP egress, unusual port use, destination reputation, and supporting web or file evidence.

·        Avoid broad suppression for cloud providers, developer platforms, file-transfer services, monitoring platforms, backup systems, update services, vendor support destinations, managed hosting destinations, business integrations, and incident-response infrastructure without validation.

·        Use approved destination inventories, vendor-support records, deployment records, backup schedules, monitoring inventories, maintenance windows, business-integration inventories, and incident-response records as triage evidence.

·        Validate Elastic rule performance against index volume, event correlation behavior, exception list behavior, timeline usability, and SOC triage workflow before enabling alerting.

·        Do not enable high-severity alerting until network telemetry fidelity, destination baselines, process-to-network mapping, field mappings, event-pair correlation quality, false-positive rate, rule performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to outbound communication after suspicious ASP.NET, host, or file activity rather than destination novelty alone.

·        The rule remains useful if an adversary changes destination domain, IP address, protocol, web shell family, payload staging method, callback timing, or post-exploitation toolset.

·        The score is supported by the durability of suspicious server egress when correlated with web, host, file, and application context.

·        The score is constrained by legitimate server egress, weak destination inventories, shared egress paths, incomplete process-to-network mapping, broad approved dependencies, and incomplete application-boundary enrichment.

·        The rule is durable as a post-exploitation correlation but should not be treated as standalone proof of exploitation, command-and-control, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on endpoint network telemetry, DNS telemetry, proxy or firewall telemetry, destination enrichment, process-to-network mapping, asset inventory, approved destination inventories, and application-boundary mapping.

·        Operational confidence is reduced where IIS servers have broad egress, weak destination baselines, shared egress paths, or legitimate automation that contacts rare destinations.

·        Operational confidence is reduced where outbound communication cannot be linked to the responsible host, process, user, application boundary, or workload boundary.

·        Full-telemetry confidence improves when outbound events are enriched with IIS logs, WAF logs, EDR process telemetry, file telemetry, ASP.NET application logs, destination reputation, identity context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for post-exploitation activity, but confirmed compromise still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET, host, or file activity, not confirmed exploitation by itself.

·        Legitimate vendor services, update checks, monitoring workflows, backup operations, deployment automation, business integrations, managed hosting operations, and incident response may produce similar outbound patterns.

·        Missing process-to-network telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        Missing destination enrichment may reduce the ability to distinguish suspicious destinations from legitimate dependencies.

·        Reverse proxy, NAT, shared egress, and hosted infrastructure may make workload attribution difficult.

·        WAF, CDN, reverse proxy, load balancer, NAT, and shared egress environments may require application-boundary enrichment before EQL sequencing is reliable.

·        The rule may miss attackers who avoid outbound communication, use approved infrastructure, operate fully in-process, or complete objectives through local application manipulation.

·        The rule may miss activity where network telemetry is unavailable, delayed, or not retained.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic IIS server rare destination communication after suspicious ASP.NET activity query pattern requiring EQL or KQL syntax validation, ECS field validation, index-pattern validation, host normalization, application-boundary mapping, destination enrichment validation, process-to-network validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

The sequence key must be implemented as host.id only when precursor and outbound telemetry resolve to the same IIS backend host or normalized workload boundary. In WAF, CDN, reverse proxy, load balancer, NAT, shared sensor, shared egress, or hosted environments, production implementations must sequence by a normalized IIS backend host, enriched application_boundary, workload-boundary key, or transform-backed correlation field.

sequence by COALESCE(host.id, application_boundary) with maxspan=ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW
  [any where
    (
      event.reason in (
        "suspicious_aspnet_request_activity",
        "abnormal_viewstate_bearing_post",
        "web_shell_like_access",
        "rare_path_access",
        "failed_request_trace",
        "error_then_success_pattern",
        "iis_worker_process_child_execution",
        "command_shell_execution",
        "credential_access",
        "archive_creation",
        "defense_evasion",
        "application_file_modified",
        "javascript_file_modified",
        "suspicious_file_created"
      )
      or (
        event.category == "process"
        and event.type == "start"
        and (
process.parent.name in ("w3wp.exe", "iisexpress.exe")
          or process.name in $suspicious_iis_child_processes
          or process.command_line in $suspicious_iis_command_patterns
        )
      )
      or (
        event.category == "file"
        and file.path in $protected_iis_aspnet_paths
        and (
          file.Ext.context in $high_risk_aspnet_file_contexts
          or process.name in $suspicious_iis_responsible_processes
          or file.Ext.followon_context in $suspicious_file_followon_context
        )
      )
    )
    and (
host.id in $iis_aspnet_server_assets
      or application_boundary in $iis_aspnet_application_boundaries
    )
  ]
  [network where
    event.category == "network"
    and network.direction in ("outbound", "egress", "external")
    and (
host.id in $iis_aspnet_server_assets
      or application_boundary in $iis_aspnet_application_boundaries
    )
    and (
      destination.domain in $newly_observed_destinations
      or destination.domain in $rare_destinations_for_host
      or destination.domain in $low_reputation_destinations
      or destination.ip in $direct_ip_or_unapproved_destinations
      or destination.port in $uncommon_iis_egress_ports
      or dns.question.name in $dynamic_dns_or_rare_dns_patterns
      or process.name in $suspicious_iis_network_processes
    )
    and not destination.domain in $approved_iis_destinations
    and not destination.ip in $approved_iis_destination_ips
  ]

QRadar

Detection Viability Assessment

QRadar has three rules for this EXP report.

·        QRadar is viable for detecting ASP.NET ViewState deserialization and shared machineKey exploitation when IIS, WAF, reverse proxy, Windows, EDR, file integrity, DNS, proxy, firewall, and asset telemetry are normalized into reliable DSM-parsed events, custom properties, building blocks, reference sets, reference maps, and offense rules.

·        QRadar is strongest where web telemetry, endpoint telemetry, file telemetry, DNS telemetry, proxy telemetry, firewall telemetry, asset context, vulnerability context, application ownership, and application pool identity context can be correlated through normalized host, source IP, destination IP, username, process, path, URL, backend-host, and application-boundary fields.

·        QRadar can identify suspicious sequencing between abnormal ASP.NET request activity, IIS worker-process execution, application-file modification, rare path access, outbound communication, web shell-like behavior, and post-exploitation host behavior.

·        QRadar is not a standalone source for confirming ViewState deserialization or shared machineKey exploitation unless web request evidence, host execution evidence, file evidence, network evidence, timing correlation, and application context support that conclusion.

·        QRadar rules must be validated against local log source types, DSM parsing quality, custom event properties, reference sets, reference maps, building blocks, asset profiles, vulnerability context, CRE rule performance, rule order, offense grouping, and SOC triage workflows before production deployment.

·        QRadar detection content should be treated as high-value behavior-led coverage for exploit-attempt correlation, compromise validation, suspicious application-file change detection, rare path interaction detection, outbound communication scoping, and incident prioritization, not direct CVE confirmation or actor attribution by itself.

·        QRadar rules should not generate high-confidence offenses from large POST requests alone, process name alone, file extension alone, destination novelty alone, rare path access alone, cloud-hosted destination context alone, or generic log-source category matching without supporting correlation and local baseline validation.

Rule

Abnormal ASP.NET Request Followed by IIS Worker Process Command Execution

Rule Format

QRadar CRE correlation rule suitable for IIS logs, WAF logs, reverse proxy logs, Windows Security logs, Sysmon events, EDR process telemetry, custom event properties, asset profiles, application-boundary reference sets, application pool identity reference sets, suspicious request building blocks, suspicious process building blocks, suspicious command-line building blocks, reference maps, and offense correlation after log source validation, DSM parsing validation, custom property validation, reference-set validation, reference-map validation, timing-window tuning, offense grouping validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious ASP.NET request activity followed by IIS worker-process child execution or application pool identity execution on the same IIS host, normalized backend host, or enriched application boundary.

·        Identify the web-to-host portion of a ViewState abuse or ASP.NET server-side execution sequence without relying on exploit payload syntax, machineKey material, proof-of-concept strings, web shell filenames, fixed source infrastructure, or named tooling.

·        Prioritize externally exposed ASP.NET applications, IIS-hosted LMS platforms, vendor-managed portals, authentication-adjacent workflows, administrative-adjacent workflows, upload paths, plugin-like paths, and state-bearing application paths.

·        Support escalation when abnormal request behavior aligns with w3wp.exe child-process execution, script interpreter use, command-shell execution, suspicious PowerShell, archive utility execution, network utility execution, file writes, or outbound communication.

·        This rule does not prove ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, credential theft, Cobalt Strike delivery, or actor attribution without supporting IIS, endpoint, file, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify inbound ASP.NET or IIS web requests to confirmed or suspected ViewState-bearing application endpoints.

·        Prioritize abnormal request behavior involving unusually large POST size, abnormal bytes received, unexpected endpoint targeting, sparse targeted requests, repeated request variation, request bursts, repeated failures, error-to-success transitions, unusual user agents, rare source ASNs, suspicious hosting-provider sources, or anonymization infrastructure.

·        Correlate suspicious web activity to process creation events on the same IIS host, normalized backend host, application server, load balancer backend, application pool boundary, or enriched application boundary.

·        Prioritize process events where w3wp.exe, IIS worker processes, ASP.NET application contexts, or application pool identities spawn command shells, PowerShell, script interpreters, archive utilities, network utilities, living-off-the-land binaries, or unusual administrative utilities.

·        Increase confidence when suspicious process execution occurs shortly after abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, application pool instability, web shell-like access, or rare path access.

·        Increase confidence when process execution is followed by file creation, webroot modification, application-content tampering, outbound communication, credential access, local discovery, archive creation, defense evasion, or persistence-like behavior.

·        Increase confidence when command-line telemetry shows encoded execution, hidden execution, remote content retrieval, download or upload behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, or execution from application-controlled directories.

·        Reduce severity for approved deployment automation, backup jobs, monitoring agents, vendor support, software updates, reporting jobs, administrative scripts, IIS maintenance, authorized scanning, approved penetration testing, incident-response activity, and documented operational jobs.

·        Do not classify suspicious ASP.NET request behavior as successful exploitation without host, file, application, network, or incident-response evidence.

·        Do not classify IIS child-process execution as ViewState exploitation without timing, request-path, application, exposure, file, or network correlation.

Required Telemetry

·        QRadar log sources for IIS logs.

·        QRadar log sources for WAF logs where available.

·        QRadar log sources for reverse proxy logs where available.

·        QRadar log sources for Windows Security logs.

·        QRadar log sources for Sysmon or EDR process telemetry where available.

·        QRadar custom event property for HTTP method.

·        QRadar custom event property for URL path.

·        QRadar custom event property for URI query where available.

·        QRadar custom event property for HTTP status code.

·        QRadar custom event property for bytes received or request size where available.

·        QRadar custom event property for response size where available.

·        QRadar custom event property for user-agent.

·        QRadar custom event property for referrer where available.

·        QRadar custom event property for source IP.

·        QRadar custom event property for source ASN or source category where available.

·        QRadar custom event property for destination host, backend host, or application gateway backend.

·        QRadar custom event property for parent process.

·        QRadar custom event property for child process.

·        QRadar custom event property for process command line.

·        QRadar custom event property for process user.

·        QRadar custom event property for process hash where available.

·        Application-boundary enrichment field where available.

·        Application pool identity reference set.

·        IIS server reference set.

·        ASP.NET application host reference set.

·        Internet-facing exposure reference set.

·        ViewState-bearing endpoint reference set where available.

·        Suspicious source ASN or source category reference set where available.

·        Approved scanner reference set.

·        Approved penetration testing reference set.

·        Approved deployment command reference set.

·        Approved administrative automation reference set.

·        Approved vendor-support reference set.

·        Approved reporting job reference set.

·        Backend-host reference map where available.

·        Application-boundary reference map where available.

·        Workload-boundary reference map where available.

·        Change-control reference data.

·        Maintenance-window reference data.

·        Asset profile enrichment.

·        Identity enrichment.

·        Application owner enrichment.

·        Incident-response reference data where available.

Engineering Implementation Instructions

·        Build QRadar reference sets for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build endpoint reference sets for ViewState-bearing paths, ASP.NET WebForms paths, login workflows, upload paths, plugin-like paths, administrative-adjacent paths, authentication-adjacent paths, document delivery paths, and LMS workflow paths.

·        Build custom event properties for HTTP method, URL path, status code, request size, bytes received, response size, user-agent, source IP, source ASN, backend host, parent process, child process, process command line, process user, and application boundary.

·        Build reference maps that map WAF host, reverse proxy host, application gateway backend, load balancer backend, endpoint host, and IIS host to a normalized application-boundary key.

·        Build suspicious request building blocks for abnormal POST size, repeated failures, error-to-success behavior, sparse targeted requests, repeated request variation, abnormal request cadence, suspicious allowed web activity, rare source ASN, and hosting or anonymization source context.

·        Build suspicious process building blocks for IIS worker-process child execution, application pool identity execution, command shells, PowerShell, script interpreters, living-off-the-land binaries, archive utilities, network utilities, credential utilities, and unusual administrative utilities.

·        Normalize backend host, proxy host, load balancer backend, endpoint host, and application-boundary fields before relying on CRE correlation.

·        Use host identity only when web and endpoint events reliably resolve to the same IIS backend host.

·        Use an enriched application-boundary key, normalized IIS backend host, workload-boundary key, load balancer backend mapping, custom property match, reference-map lookup, asset profile mapping, building block, or offense-scoped correlation when WAF, CDN, reverse proxy, NAT, shared sensor, or load balancer telemetry does not share the endpoint host identity.

·        Preserve event-pair timing between suspicious web events and process events when implementing CRE correlation.

·        Avoid broad CRE conditions that correlate all web activity to all process activity on the same host without a suspicious request building block and suspicious process building block.

·        Use shorter correlation windows when abnormal ASP.NET request activity is followed quickly by IIS child-process execution or suspicious command-line behavior.

·        Use moderate correlation windows when process execution is followed by file staging, webroot modification, outbound communication, credential access, archive creation, or rare path access.

·        Use longer correlation windows for delayed operator interaction, staged payload execution, delayed callback behavior, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, abnormal POST size, error-to-success behavior, suspicious process lineage, application pool identity context, suspicious command line, execution from application-controlled paths, and supporting file or network evidence.

·        Use approved scanner lists, penetration testing records, deployment records, vendor-support tickets, maintenance windows, backup schedules, reporting job inventories, and incident-response records as triage evidence.

·        Validate QRadar rule performance against event volume, custom property extraction cost, reference-set size, reference-map size, CRE rule order, partial-match behavior, offense grouping behavior, and SOC triage workflow before enabling production alerting.

·        Do not enable high-severity offenses until log source coverage, DSM parsing, custom properties, reference sets, reference maps, host normalization, application-boundary mapping, baselines, exception logic, event-pair correlation quality, offense grouping, and SOC triage workflows are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to web-to-host correlation rather than static exploit strings, payload syntax, machineKey material, web shell filenames, or known infrastructure.

·        The rule remains useful if an adversary changes request syntax, payload shape, source infrastructure, command syntax, child process choice, file path, or web shell family.

·        The score is supported by the durability of abnormal ASP.NET request behavior followed by suspicious IIS worker-process execution.

·        The score is constrained by missing request-size fields, inconsistent backend-host normalization, incomplete endpoint process telemetry, weak application inventory, and legitimate administrative workflows that spawn child processes.

·        The rule is durable as a compromise-validation correlation but should not be treated as standalone proof of ViewState deserialization or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on IIS log fidelity, process telemetry, command-line visibility, QRadar custom property quality, DSM parsing quality, backend-host normalization, application inventory, application pool identity mapping, and request-to-host correlation.

·        Operational confidence is reduced where reverse proxies obscure source or destination context, WAF logs cannot be mapped to backend hosts, or endpoint telemetry does not capture command lines.

·        Operational confidence is reduced where deployment, maintenance, reporting, backup, vendor support, or administrative automation workflows legitimately produce child-process activity.

·        Full-telemetry confidence improves when QRadar correlation includes IIS logs, WAF logs, reverse proxy logs, EDR telemetry, Windows logs, file telemetry, outbound network telemetry, vulnerability context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence but still requires supporting application, file, network, or incident-response evidence for confirmed exploitation.

Limitations

·        This rule detects suspicious ASP.NET request activity followed by IIS host execution, not confirmed exploitation by itself.

·        Large ViewState-bearing POST requests may be legitimate for some ASP.NET applications.

·        IIS child-process execution may be legitimate during deployments, reporting jobs, vendor support, maintenance, backup workflows, or incident response.

·        Reverse proxies, CDNs, WAFs, NAT, load balancing, and inconsistent host normalization may make request-to-host correlation difficult.

·        Missing command-line telemetry reduces the ability to distinguish malicious execution from benign process activity.

·        Missing IIS failed request tracing or ASP.NET application logs may reduce confidence in the exploitation sequence.

·        The rule may miss in-process exploitation that does not spawn visible child processes.

·        QRadar custom property extraction gaps or DSM parsing gaps may reduce event quality and correlation reliability.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar ASP.NET request-to-IIS-process CRE rule pattern requiring AQL syntax validation, CRE rule validation, log source validation, DSM parsing validation, custom property validation, reference-set validation, reference-map validation, host normalization, application-boundary normalization, event-pair preservation, timing-window tuning, offense grouping validation, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production QRadar implementations must replace it with locally validated custom event properties, reference maps, reference sets, asset profile mappings, CRE tests, building blocks, or offense-scoped correlation. The correlation must be implemented through a practical QRadar mechanism such as IMPLEMENTED_BY_REFERENCE_MAP_OR_CUSTOM_PROPERTY_MATCH.

The correlation key must be implemented as the normalized IIS backend host when web and endpoint telemetry resolve to the same server. In WAF, CDN, reverse proxy, load balancer, NAT, shared sensor, or hosted environments, production implementations must correlate by an enriched application-boundary key, workload-boundary key, backend-host mapping, or reference-data-backed correlation key.

QRADAR CRE RULE: Abnormal ASP.NET Request Followed By IIS Worker Process Command Execution

WHEN WebEvent.LogSourceType IN (
"IIS",
"WAF",
"Reverse Proxy",
"Application Gateway"
)
AND WebEvent.HTTPMethod = "POST"
AND WebEvent.URLPath IN REFERENCE_SET(
"ViewState Bearing ASP.NET Paths",
"ASP.NET Authentication Adjacent Paths",
"ASP.NET Administrative Adjacent Paths",
"ASP.NET Upload Paths",
"ASP.NET LMS Workflow Paths"
)
AND (
WebEvent.RequestSize > REFERENCE_MAP_VALUE(
"ASP.NET Endpoint POST Size Baseline P95",
WebEvent.URLPath
)
OR WebEvent.StatusCode IN (500, 502, 503)
OR WebEvent.EventPattern IN (
"error_then_success",
"repeated_request_variation",
"sparse_targeted_requests",
"abnormal_request_cadence",
"suspicious_allowed_web_activity"
)
OR WebEvent.SourceIP IN REFERENCE_SET("Rare Sources For Application")
OR WebEvent.SourceASN IN REFERENCE_SET("Rare Or Suspicious Source ASNs")
)
FOLLOWED WITHIN ENV_ASPNET_REQUEST_TO_PROCESS_WINDOW BY ProcessEvent
WHERE ProcessEvent.LogSourceType IN (
"Windows Security",
"Sysmon",
"EDR Process"
)
AND CORRELATION_KEY(
WebEvent.BackendHost,
WebEvent.ApplicationBoundary,
ProcessEvent.Host,
ProcessEvent.ApplicationBoundary
) IS SAME_NORMALIZED_IIS_BACKEND_OR_APPLICATION_BOUNDARY
IMPLEMENTED_BY_REFERENCE_MAP_OR_CUSTOM_PROPERTY_MATCH
AND (
ProcessEvent.ParentProcessName IN ("w3wp.exe", "iisexpress.exe")
OR ProcessEvent.ParentProcessPath CONTAINS "\\inetsrv\\"
OR ProcessEvent.UserName IN REFERENCE_SET("IIS Application Pool Identities")
)
AND (
ProcessEvent.ProcessName IN (
"cmd.exe",
"powershell.exe",
"pwsh.exe",
"wscript.exe",
"cscript.exe",
"mshta.exe",
"rundll32.exe",
"regsvr32.exe",
"certutil.exe",
"bitsadmin.exe",
"curl.exe",
"wget.exe",
"tar.exe",
"7z.exe"
)
OR ProcessEvent.CommandLine MATCHES REFERENCE_SET("Suspicious IIS Command Patterns")
)
AND ProcessEvent.CommandLine NOT IN REFERENCE_SET("Approved Deployment Or Admin Commands")
AND ProcessEvent.UserName NOT IN REFERENCE_SET("Approved Administrative Automation Users")
AND WebEvent.SourceIP NOT IN REFERENCE_SET("Approved Scanners")
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
ProcessEvent.Host,
ProcessEvent.UserName,
ProcessEvent.CommandLine,
ProcessEvent.EventTime
)

Rule

Suspicious Application Directory File Modification With Follow-On Web Access

Rule Format

QRadar CRE correlation rule suitable for file integrity telemetry, EDR file events, Sysmon file events, IIS web logs, WAF logs, reverse proxy logs, webroot inventory, application path inventory, known-good baselines, file hash enrichment, path frequency baselines, file-to-URL relationship mapping, asset profiles, application-boundary reference data, and SIEM correlation after log source validation, DSM parsing validation, custom property validation, protected-path validation, file-context validation, path-normalization validation, rare-path validation, change-control validation, event-pair preservation, offense grouping validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious application-file creation or modification followed by rare, newly observed, or web shell-like access to the same or related application path.

·        Identify possible web shell placement, unauthorized ASPX artifact creation, application-content tampering, JavaScript modification, fake component staging, or modified downloadable content.

·        Prioritize file activity under webroot, vendor application, upload, plugin-like, temporary compilation, JavaScript, configuration, login-page, and downloadable-component paths.

·        Support escalation when suspicious file activity aligns with abnormal ASP.NET request activity, IIS process execution, rare path access, outbound communication, user downloads, or external script loading.

·        This rule does not prove web shell placement, ViewState exploitation, application compromise, user compromise, or actor attribution without supporting process, web, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify file creation, modification, rename, overwrite, or deletion events under protected IIS or ASP.NET application paths.

·        Prioritize high-risk file context involving new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script reference additions, configuration changes, archive staging, executable staging, or suspicious temporary artifacts.

·        Prioritize file activity where the responsible process is w3wp.exe, an IIS worker process, a suspicious IIS child process, a script interpreter, a command shell, or an application pool identity.

·        Treat high-risk file extension matches as supporting context only unless paired with suspicious file context, suspicious responsible process, abnormal change timing, unusual path context, or follow-on evidence.

·        Correlate suspicious file activity with subsequent rare web access, newly observed path access, low-frequency path access, abnormal response-size patterns, web shell-like timing, user downloads, or external script loading.

·        Preserve file-to-web event-pair timing so each suspicious file event is correlated to the specific subsequent web access event, not only the earliest file and earliest web event for the application.

·        Use normalized file-to-URL relationship mapping where the deployment path, webroot path, virtual directory, application route, or rewritten URL prevents direct file path to URL path matching.

·        Increase confidence when file modification follows abnormal ViewState-bearing POST activity, failed request traces, rare path access, IIS child-process execution, credential access, outbound communication, or application errors.

·        Increase confidence when the modified file is later accessed over HTTP, loaded by the application, referenced by modified content, downloaded by users, or associated with outbound communication.

·        Reduce severity for approved deployments, content updates, plugin updates, vendor patches, backup jobs, build jobs, cache generation, emergency fixes, incident response, and documented maintenance.

·        Do not classify file modification as malicious content tampering or web shell placement without supporting process, web access, network, application, or change-control evidence.

·        Do not rely on file extension alone, known web shell filenames, known hashes, public artifact strings, specific JavaScript names, or named tooling as required detection conditions.

Required Telemetry

·        QRadar log sources for file integrity telemetry.

·        QRadar log sources for EDR file events.

·        QRadar log sources for Sysmon file events where available.

·        QRadar log sources for IIS web logs.

·        QRadar log sources for WAF logs where available.

·        QRadar log sources for reverse proxy logs where available.

·        Custom event property for file path.

·        Custom event property for file name.

·        Custom event property for file extension.

·        Custom event property for file hash where available.

·        Custom event property for file size where available.

·        Custom event property for file event type.

·        Custom event property for responsible process.

·        Custom event property for responsible process command line.

·        Custom event property for parent process.

·        Custom event property for username.

·        Custom event property for URL path.

·        Custom event property for response status code.

·        Custom event property for response size where available.

·        Custom event property for source IP.

·        Custom event property for user-agent where available.

·        Application-boundary enrichment field where available.

·        Protected IIS and ASP.NET path reference set.

·        High-risk ASP.NET file context reference set.

·        Suspicious IIS responsible process reference set.

·        Unusual or sensitive application path reference set.

·        Suspicious file follow-on context reference set.

·        Approved deployment path reference set.

·        Approved change context reference data.

·        Approved administrator or vendor-support source reference set.

·        Path first-seen context where available.

·        Path frequency baseline.

·        File-to-URL relationship mapping where available.

·        Webroot path inventory.

·        Vendor application path inventory.

·        Upload path inventory where available.

·        Plugin-like path inventory where available.

·        Temporary ASP.NET compilation path inventory.

·        JavaScript path inventory.

·        Configuration path inventory.

·        Login-page path inventory where available.

·        Downloadable-component path inventory where available.

·        Known-good application baselines.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build protected application path reference sets for webroot directories, ASP.NET application paths, vendor application paths, upload directories, plugin-like paths, temporary ASP.NET compilation paths, JavaScript directories, configuration directories, login-page paths, downloadable-component paths, and user-facing content paths.

·        Build high-risk file-context reference sets for new ASPX files, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script references, configuration changes, archive staging, executable staging, deleted-after-execution artifacts, and suspicious temporary files.

·        Build responsible-process building blocks for w3wp.exe, IIS worker processes, application pool identities, suspicious IIS child processes, script interpreters, command shells, deployment tools, build tools, backup tools, cache generation processes, and vendor support utilities.

·        Build rare-path building blocks using path first-seen time, path frequency baseline, response-size baseline, request timing, source concentration, user-agent profile, source ASN, and approved administrative or vendor-support path inventories.

·        Normalize file paths and URI paths so file-to-web matching can evaluate exact path, related path, derived URL path, virtual directory mapping, rewritten route, and application-relative path relationships.

·        Use reference data or enrichment to map file paths to reachable URL paths when direct file path to URL path matching is unreliable.

·        Preserve file-to-web event-pair timing between file events and web access events.

·        Use shorter correlation windows when suspicious file modification follows abnormal ASP.NET request activity, failed request traces, web shell-like access, rare path access, or IIS child-process execution.

·        Use moderate correlation windows when file modification is followed by rare web access, outbound communication, user downloads, external script loading, or endpoint detections.

·        Use longer correlation windows for delayed operator access, delayed web shell interaction, staged payload activation, user-side delivery, or delayed fake component retrieval.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, protected path sensitivity, file-context sensitivity, responsible-process context, application pool identity context, rare path access, user downloads, and outbound communication.

·        Use deployment records, content update records, vendor-support tickets, build records, cache-generation records, known-good baselines, and application-owner validation as triage evidence.

·        Validate QRadar CRE performance against event volume, custom property extraction cost, reference-set size, rule order, offense grouping behavior, and SOC triage workflow before enabling production alerting.

·        Do not enable high-severity offenses until file telemetry coverage, path baselines, responsible-process mapping, change-control enrichment, event-pair correlation quality, false-positive rate, rule performance, offense grouping, and SOC triage procedures are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to suspicious application-file modification followed by rare or newly observed web access.

·        The rule remains useful if an adversary changes web shell filename, artifact name, path, extension, source infrastructure, user-agent, or interaction timing.

·        The score is supported by the durability of unauthorized file placement, protected path modification, responsible-process context, rare path access, path first-seen analysis, and web-to-file correlation.

·        The score is constrained by legitimate deployments, content updates, plugin systems, vendor support, build workflows, generated content, cache generation, weak known-good baselines, and missing file-to-URL relationship mapping.

·        The rule is durable as a content-tampering and web shell interaction detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on file telemetry, protected path coverage, responsible-process fields, path first-seen baselines, IIS web logs, backend-host normalization, application-boundary enrichment, file-to-URL relationship mapping, change-control records, and application-owner validation.

·        Operational confidence is reduced where applications frequently generate files, update content, write to upload paths, use plugin systems, or rely on vendor-managed update workflows.

·        Operational confidence is reduced where file events cannot be tied to responsible process context or where web access logs cannot be tied to the modified path.

·        Full-telemetry confidence improves when file events are enriched with IIS process execution, abnormal ASP.NET request activity, outbound communication, application logs, known-good baselines, and change-control evidence.

·        Under full telemetry conditions, this rule provides strong escalation evidence for suspicious application-file changes, but confirmed exploitation still requires supporting process, network, application, or incident-response evidence.

Limitations

·        This rule detects suspicious application-file modification followed by rare web access, not confirmed web shell deployment by itself.

·        Legitimate deployments, plugin updates, content publishing, cache generation, build workflows, vendor support, emergency fixes, and incident-response activity may produce similar file and path-access patterns.

·        Missing responsible-process fields reduce confidence in whether file changes were caused by IIS, deployment tooling, administrators, or attacker activity.

·        Missing path first-seen baselines may reduce the ability to distinguish rare path access from normal application behavior.

·        Dynamic applications may create generated files, cache artifacts, temporary files, or uploaded content that resembles suspicious artifact placement.

·        Hosted or vendor-managed environments may restrict file telemetry, known-good baselines, or deployment records.

·        File-to-web matching may be unreliable when applications use URL rewriting, virtual directories, generated routes, CDN path rewriting, or custom routing unless file-to-URL enrichment exists.

·        QRadar custom property extraction gaps or DSM parsing gaps may reduce event quality and correlation reliability.

·        The rule may miss fileless or memory-resident activity that does not create durable application artifacts.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar application-file modification followed by rare web access CRE rule pattern requiring AQL syntax validation, CRE rule validation, log source validation, DSM parsing validation, custom property validation, protected-path validation, file-context validation, responsible-process validation, path-normalization validation, file-to-URL enrichment validation, change-control validation, event-pair preservation, timing-window tuning, offense grouping validation, and environment-specific allowlisting before production deployment.

QRADAR CRE RULE: Suspicious Application Directory File Modification With Follow-On Web Access

WHEN FileEvent.LogSourceType IN (
"File Integrity",
"EDR File",
"Sysmon File"
)
AND FileEvent.FilePath IN REFERENCE_SET("Protected IIS ASP.NET Paths")
AND (
FileEvent.FileContext IN REFERENCE_SET("High Risk ASP.NET File Contexts")
OR FileEvent.ResponsibleProcess IN REFERENCE_SET("Suspicious IIS Responsible Processes")
OR (
FileEvent.FileExtension IN (
"aspx",
"ashx",
"asmx",
"dll",
"js",
"config",
"ps1",
"vbs",
"bat",
"cmd",
"zip",
"7z",
"exe"
)
AND (
FileEvent.ChangeContext NOT IN REFERENCE_SET("Approved Change Context")
OR FileEvent.PathContext IN REFERENCE_SET("Unusual Or Sensitive Application Paths")
OR FileEvent.FollowOnContext IN REFERENCE_SET("Suspicious File Follow-On Context")
)
)
)
AND FileEvent.FilePath NOT IN REFERENCE_SET("Approved Deployment Paths")
AND FileEvent.ChangeContext NOT IN REFERENCE_SET("Approved Change Context")
FOLLOWED WITHIN ENV_ASPNET_FILE_TO_WEB_ACCESS_WINDOW BY WebEvent
WHERE WebEvent.LogSourceType IN (
"IIS",
"WAF",
"Reverse Proxy",
"Application Gateway"
)
AND CORRELATION_KEY(
FileEvent.Host,
FileEvent.ApplicationBoundary,
WebEvent.BackendHost,
WebEvent.ApplicationBoundary
) IS SAME_NORMALIZED_IIS_BACKEND_OR_APPLICATION_BOUNDARY
AND (
WebEvent.URLPath IN REFERENCE_SET("Rare Paths For Application")
OR WebEvent.URLPath IN REFERENCE_SET("Newly Observed Paths")
OR WebEvent.URLPath IN REFERENCE_MAP_VALUE(
"Paths Related To Recent Suspicious File Changes",
FileEvent.FilePath
)
OR WebEvent.EventPattern IN (
"web_shell_like_access",
"low_volume_interactive_access",
"abnormal_response_size"
)
)
AND WebEvent.SourceIP NOT IN REFERENCE_SET("Approved Administrators Or Vendor Support")

Rule

IIS Server Rare Destination Communication After Suspicious Web or Host Activity

Rule Format

QRadar CRE correlation rule suitable for endpoint network events, DNS events, proxy events, firewall events, IIS web logs, WAF logs, reverse proxy logs, endpoint process telemetry, file telemetry, destination enrichment, asset profiles, application-boundary mapping, application pool identity mapping, approved destination inventories, building blocks, reference maps, reference sets, and SIEM correlation after log source validation, DSM parsing validation, custom property validation, host normalization, application-boundary mapping, destination-enrichment validation, process-to-network validation, approved-destination validation, event-pair preservation, timing-window tuning, offense grouping validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from IIS-hosted ASP.NET servers after abnormal ASP.NET request activity, suspicious process execution, application-file modification, rare path access, or post-exploitation behavior.

·        Identify possible callback behavior, payload retrieval, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact.

·        Prioritize outbound communication from w3wp.exe, IIS child processes, application pool identities, suspicious command shells, script interpreters, network utilities, or recently modified application contexts.

·        Support escalation when outbound activity aligns with ViewState-bearing request anomalies, IIS child-process execution, suspicious file changes, application-content tampering, credential access, archive creation, defense evasion, or user-delivery evidence.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, user compromise, cloud compromise, or actor attribution without supporting web, endpoint, file, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify outbound network, DNS, proxy, firewall, or endpoint network events from confirmed IIS-hosted ASP.NET servers.

·        Prioritize destinations that are newly observed within the local first-seen window, rare for the host, rare for the application, low reputation, direct IP-based, dynamic DNS-associated, uncommon by port, unusual by TLS SNI, unusual by HTTP host, or outside approved vendor, monitoring, update, backup, deployment, and business-integration inventories.

·        Correlate outbound communication with specific prior or nearby suspicious ASP.NET activity, including abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, error-to-success patterns, rare path access, or web shell-like access.

·        Correlate outbound communication with specific nearby host-side or file evidence, including IIS child-process execution, suspicious command lines, application-file modification, credential access, local discovery, archive creation, defense evasion, persistence attempts, or post-exploitation tool staging.

·        Preserve context-to-outbound event-pair timing so each outbound event is correlated to the specific preceding web, host, or file context event that supports it.

·        Increase confidence when outbound communication is process-linked to w3wp.exe, IIS child processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities.

·        Increase confidence when outbound communication follows modified JavaScript, login-page changes, external script reference additions, downloadable-component changes, suspicious file creation, or user-delivery evidence.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, deployment destinations, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Do not classify outbound communication as exploitation-related without suspicious web, host, file, application, or incident-response evidence.

·        Do not treat destination novelty, direct IP connections, unusual ports, DNS rarity, cloud hosting, or high byte volume as compromise evidence by itself.

·        Do not let this rule duplicate the process-execution rule unless outbound communication materially changes the risk context.

Required Telemetry

·        QRadar log sources for endpoint network events.

·        QRadar log sources for DNS events.

·        QRadar log sources for proxy events where available.

·        QRadar log sources for firewall events where available.

·        QRadar log sources for IIS web logs where available.

·        QRadar log sources for WAF logs where available.

·        QRadar log sources for reverse proxy logs where available.

·        QRadar log sources for endpoint process telemetry.

·        QRadar log sources for file telemetry where available.

·        Custom event property for source host.

·        Custom event property for source IP.

·        Custom event property for destination IP.

·        Custom event property for destination domain.

·        Custom event property for destination port.

·        Custom event property for destination ASN where available.

·        Custom event property for network direction.

·        Custom event property for network protocol.

·        Custom event property for byte count where available.

·        Custom event property for DNS query where available.

·        Custom event property for TLS SNI or certificate subject where available.

·        Custom event property for HTTP host where available.

·        Custom event property for process name where available.

·        Custom event property for process command line where available.

·        Custom event property for parent process where available.

·        Custom event property for username where available.

·        Application-boundary enrichment field where available.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        IIS server reference set.

·        ASP.NET application boundary reference set.

·        Internet-facing exposure reference set.

·        Application pool identity reference set.

·        Newly observed destination reference set.

·        Rare destination reference set.

·        Low-reputation destination reference set.

·        Direct IP or unapproved destination reference set.

·        Uncommon IIS egress port reference set.

·        Dynamic DNS or rare DNS reference set.

·        Suspicious IIS network process reference set.

·        Approved IIS destination reference set.

·        Approved IIS destination IP reference set.

·        Approved vendor service reference set.

·        Approved monitoring destination reference set.

·        Approved backup destination reference set.

·        Approved deployment destination reference set.

·        Approved update destination reference set.

·        Approved business integration reference set.

·        Backend-host reference map where available.

·        Application-boundary reference map where available.

·        Workload-boundary reference map where available.

·        Asset profile enrichment.

·        Identity enrichment.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build QRadar reference sets for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build destination reference sets for approved vendor services, monitoring platforms, backup systems, deployment systems, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Build suspicious destination reference sets for newly observed destinations within the local first-seen window, rare destinations, low-reputation destinations, direct IP destinations, dynamic DNS destinations, uncommon ports, rare TLS context, unusual HTTP hosts, cloud-hosted infrastructure, developer platforms, object storage, file-transfer services, and destinations outside approved dependencies.

·        Build precursor building blocks for abnormal ViewState-bearing POST activity, rare path access, failed request traces, error-to-success patterns, IIS child-process execution, application-file modification, credential access, archive creation, defense evasion, and application-content tampering.

·        Avoid broad precursor building blocks based on generic log source category without a specific suspicious reason, indicator, behavior, or enriched context.

·        Preserve context-to-outbound event-pair timing rather than only earliest context and earliest outbound activity per application boundary.

·        Use source host identity only when precursor and outbound events resolve to the same IIS server or normalized workload boundary.

·        Use application-boundary enrichment, backend-host mapping, custom event property matching, reference-map correlation, asset profile mapping, building blocks, or offense-scoped correlation when WAF, proxy, load balancer, NAT, shared sensors, or shared egress layers prevent direct host-level sequencing.

·        Validate DSM mappings, custom properties, process-to-network fields, DNS fields, proxy fields, firewall fields, destination enrichment, asset profiles, identity enrichment, timestamp alignment, backend-host normalization, application-boundary mapping, and event-pair timing before production deployment.

·        Use shorter correlation windows when suspicious web or host activity is followed quickly by outbound communication, DNS lookup, direct IP contact, payload retrieval, rare destination access, or callback-like behavior.

·        Use moderate correlation windows when outbound behavior follows abnormal request activity, application errors, file modification, credential access, archive creation, rare path access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, repeated low-volume communication, staged payload retrieval, delayed operator return, or low-and-slow post-exploitation activity.

·        Add severity weighting for internet-facing exposure, application pool identity context, process-linked outbound communication, post-exploitation behavior, credential access, archive creation, persistence attempts, rare destination communication, direct IP egress, unusual port use, destination reputation, and supporting web or file evidence.

·        Avoid broad suppression for cloud providers, developer platforms, file-transfer services, monitoring platforms, backup systems, update services, vendor support destinations, managed hosting destinations, business integrations, and incident-response infrastructure without validation.

·        Use approved destination inventories, vendor-support records, deployment records, backup schedules, monitoring inventories, maintenance windows, business-integration inventories, and incident-response records as triage evidence.

·        Validate QRadar CRE performance against event volume, custom property extraction cost, reference-set size, rule order, offense grouping behavior, and SOC triage workflow before enabling production alerting.

·        Do not enable high-severity offenses until network telemetry fidelity, destination baselines, process-to-network mapping, custom property quality, event-pair correlation quality, false-positive rate, CRE performance, offense grouping, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to outbound communication after suspicious ASP.NET, host, or file activity rather than destination novelty alone.

·        The rule remains useful if an adversary changes destination domain, IP address, protocol, web shell family, payload staging method, callback timing, or post-exploitation toolset.

·        The score is supported by the durability of suspicious server egress when correlated with web, host, file, and application context.

·        The score is constrained by legitimate server egress, weak destination inventories, shared egress paths, incomplete process-to-network mapping, broad approved dependencies, and incomplete application-boundary enrichment.

·        The rule is durable as a post-exploitation correlation but should not be treated as standalone proof of exploitation, command-and-control, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on endpoint network telemetry, DNS telemetry, proxy or firewall telemetry, destination enrichment, process-to-network mapping, asset inventory, approved destination inventories, custom property quality, and application-boundary mapping.

·        Operational confidence is reduced where IIS servers have broad egress, weak destination baselines, shared egress paths, or legitimate automation that contacts rare destinations.

·        Operational confidence is reduced where outbound communication cannot be linked to the responsible host, process, user, application boundary, or workload boundary.

·        Full-telemetry confidence improves when outbound events are enriched with IIS logs, WAF logs, EDR process telemetry, file telemetry, ASP.NET application logs, destination reputation, identity context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for post-exploitation activity, but confirmed compromise still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET, host, or file activity, not confirmed exploitation by itself.

·        Legitimate vendor services, update checks, monitoring workflows, backup operations, deployment automation, business integrations, managed hosting operations, and incident response may produce similar outbound patterns.

·        Missing process-to-network telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        Missing destination enrichment may reduce the ability to distinguish suspicious destinations from legitimate dependencies.

·        Reverse proxy, NAT, shared egress, and hosted infrastructure may make workload attribution difficult.

·        WAF, CDN, reverse proxy, load balancer, NAT, and shared egress environments may require application-boundary enrichment before QRadar CRE correlation is reliable.

·        QRadar custom property extraction gaps or DSM parsing gaps may reduce event quality and correlation reliability.

·        The rule may miss attackers who avoid outbound communication, use approved infrastructure, operate fully in-process, or complete objectives through local application manipulation.

·        The rule may miss activity where network telemetry is unavailable, delayed, or not retained.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar IIS server rare destination communication after suspicious ASP.NET activity CRE rule pattern requiring AQL syntax validation, CRE rule validation, log source validation, DSM parsing validation, custom property validation, host normalization, application-boundary mapping, destination enrichment validation, process-to-network validation, approved-destination validation, event-pair preservation, timing-window tuning, offense grouping validation, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production QRadar implementations must replace it with locally validated custom event properties, reference maps, reference sets, asset profile mappings, CRE tests, building blocks, or offense-scoped correlation. The correlation must be implemented through a practical QRadar mechanism such as IMPLEMENTED_BY_REFERENCE_MAP_OR_CUSTOM_PROPERTY_MATCH.

The correlation key must use source host only when precursor and outbound telemetry resolve to the same IIS backend server or normalized workload boundary. In WAF, CDN, reverse proxy, load balancer, NAT, shared sensor, shared egress, or hosted environments, production implementations must correlate by an enriched application-boundary key, backend-host mapping, workload-boundary key, or reference-data-backed correlation field.

QRADAR CRE RULE: IIS Server Rare Destination Communication After Suspicious Web Or Host Activity

WHEN PrecursorEvent MATCHES BUILDING_BLOCK(
"Suspicious ASP.NET Request Activity",
"IIS Worker Process Child Execution",
"Suspicious IIS Host Behavior",
"Suspicious Application File Activity",
"Rare ASP.NET Path Access",
"Web Shell Like Access"
)
FOLLOWED WITHIN ENV_ASPNET_PRECURSOR_TO_EGRESS_WINDOW BY NetworkEvent
WHERE NetworkEvent.LogSourceType IN (
"EDR Network",
"DNS",
"Proxy",
"Firewall"
)
AND CORRELATION_KEY(
PrecursorEvent.Host,
PrecursorEvent.ApplicationBoundary,
NetworkEvent.SourceHost,
NetworkEvent.ApplicationBoundary
) IS SAME_NORMALIZED_IIS_BACKEND_OR_APPLICATION_BOUNDARY
IMPLEMENTED_BY_REFERENCE_MAP_OR_CUSTOM_PROPERTY_MATCH
AND NetworkEvent.Direction IN (
"OUTBOUND",
"EGRESS",
"SERVER_TO_EXTERNAL"
)
AND (
NetworkEvent.DestinationDomain IN REFERENCE_SET("Newly Observed Destinations")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Rare Destinations For Host")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Low Reputation Destinations")
OR NetworkEvent.DestinationIP IN REFERENCE_SET("Direct IP Or Unapproved Destinations")
OR NetworkEvent.DestinationPort IN REFERENCE_SET("Uncommon IIS Egress Ports")
OR NetworkEvent.DNSQuery IN REFERENCE_SET("Dynamic DNS Or Rare DNS Patterns")
OR NetworkEvent.ProcessName IN REFERENCE_SET("Suspicious IIS Network Processes")
)
AND NetworkEvent.DestinationDomain NOT IN REFERENCE_SET("Approved IIS Destinations")
AND NetworkEvent.DestinationIP NOT IN REFERENCE_SET("Approved IIS Destination IPs")
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
NetworkEvent.SourceHost,
NetworkEvent.ProcessName,
NetworkEvent.DestinationDomain,
NetworkEvent.EventTime
)

SIGMA

Detection Viability Assessment

SIGMA has three rules for this EXP report.

·        SIGMA is viable for this EXP report as a portable detection format for expressing behavior-led Windows, IIS, Sysmon, EDR, proxy, DNS, firewall, and SIEM-correlatable detection logic across environments.

·        SIGMA is strongest when used as a vendor-neutral detection pattern that is translated, tested, tuned, and hardened in the destination SIEM or detection platform before production deployment.

·        SIGMA can express durable host-side and web-adjacent behaviors associated with ASP.NET ViewState abuse, including IIS worker-process child execution, suspicious application-file modification, rare path access, and outbound communication after suspicious web or host activity.

·        SIGMA cannot confirm ViewState deserialization or shared machineKey exploitation by itself because rule fidelity depends on mapped telemetry, parser quality, backend query language, field availability, correlation support, enrichment sources, exception handling, and target platform behavior.

·        SIGMA rules must be validated after backend translation, including field mapping, log source mapping, path normalization, command-line normalization, application-boundary mapping, backend-host correlation, exception logic, false-positive baselining, query performance, and SOC triage workflow.

·        SIGMA detection content should be treated as implementation-ready detection patterns for downstream SIEM engineering, not final production rules until translated and validated against the target backend.

·        SIGMA rules should not generate high-confidence alerts from file extension alone, process name alone, large POST requests alone, destination novelty alone, rare path access alone, direct-IP communication alone, unusual port alone, or cloud-hosted destination context alone without supporting correlation and local validation.

Rule

IIS Worker Process Suspicious Child Process Execution

Rule Format

SIGMA rule pattern suitable for Windows process creation telemetry, Sysmon Event ID 1, EDR process telemetry, command-line telemetry, application pool identity mapping, IIS server inventory, ASP.NET application inventory, and SIEM translation after log source validation, field mapping, command-line normalization, parent-child process validation, application pool identity validation, exception testing, backend query validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious child-process execution from IIS worker processes, ASP.NET application contexts, or application pool identities that may indicate server-side execution, web shell interaction, payload staging, or post-exploitation activity.

·        Identify host-side execution behavior without relying on exploit payload syntax, machineKey material, proof-of-concept strings, web shell filenames, fixed source infrastructure, or named tooling.

·        Prioritize w3wp.exe, IIS worker processes, ASP.NET application processes, application pool identities, IIS service accounts, vendor application service accounts, and web-facing application hosts.

·        Support escalation when IIS worker-process execution aligns with abnormal ASP.NET request activity, failed request traces, application errors, rare path access, application-file changes, outbound communication, or credential access.

·        This rule does not prove ViewState deserialization, KnowledgeDeliver exploitation, web shell deployment, credential theft, Cobalt Strike delivery, or actor attribution without supporting web, file, network, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify process creation events where the parent process is w3wp.exe, an IIS worker process, an ASP.NET application process, or a process running under an application pool identity.

·        Prioritize child processes involving command shells, PowerShell, script interpreters, HTML application execution, living-off-the-land binaries, archive utilities, network utilities, credential utilities, or unusual administrative utilities.

·        Prioritize command lines involving encoded execution, hidden execution, remote content retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, or execution from application-controlled directories.

·        Prioritize execution where the user context maps to an application pool identity, IIS service account, vendor application service account, or service account that normally should not perform interactive administrative activity.

·        Increase confidence when process execution follows abnormal ASP.NET request activity, large or unusual POST activity, HTTP 500-series bursts, failed request traces, application pool instability, web shell-like access, or rare path access in the destination SIEM.

·        Increase confidence when process execution is followed by file creation, webroot modification, application-content tampering, outbound communication, credential access, local discovery, archive creation, defense evasion, or persistence-like behavior in the destination SIEM.

·        Increase confidence when execution originates from or references webroot paths, upload paths, plugin-like directories, temporary ASP.NET compilation paths, vendor application paths, user-writable directories, or recently modified application directories.

·        Reduce severity for approved deployment tools, backup jobs, monitoring agents, vendor support tools, reporting jobs, software update workflows, administrative automation, IIS maintenance tasks, incident-response activity, and documented operational jobs.

·        Do not classify IIS child-process execution as ViewState exploitation without timing, request-path, exposure, application, file, or network correlation.

·        Do not treat w3wp.exe child execution as compromise evidence by itself where legitimate application workflows, reporting jobs, backup operations, vendor support, or deployment automation spawn child processes.

Required Telemetry

·        Windows process creation telemetry.

·        Sysmon Event ID 1 where available.

·        EDR process telemetry where available.

·        Parent process name.

·        Parent process path.

·        Parent process command line where available.

·        Child process name.

·        Child process path.

·        Child process command line.

·        Process user.

·        Process integrity context where available.

·        Process hash where available.

·        Process signer where available.

·        Host name.

·        Host ID where available.

·        Application pool identity mapping.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Webroot path inventory.

·        Upload path inventory where available.

·        Vendor application path inventory.

·        Temporary ASP.NET compilation path inventory.

·        Approved deployment tool inventory.

·        Approved administrative automation inventory.

·        Approved vendor-support inventory.

·        Approved reporting job inventory.

·        Change-control records.

·        Maintenance-window records.

·        Web telemetry where available.

·        File telemetry where available.

·        Network telemetry where available.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build destination-platform lists for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build identity lists for application pool identities, IIS service accounts, vendor application service accounts, and service accounts that should not perform interactive command execution.

·        Build process lists for w3wp.exe, IIS worker processes, command shells, PowerShell, script interpreters, living-off-the-land binaries, archive utilities, network utilities, credential utilities, and unusual administrative utilities.

·        Build command-line patterns for encoded commands, hidden execution, remote content retrieval, upload or download behavior, archive extraction, temporary-path execution, inline script execution, suspicious interpreter chains, and execution from application-controlled paths.

·        Build application path lists for webroot directories, upload directories, plugin-like paths, temporary ASP.NET compilation paths, vendor application paths, user-writable paths, and recently modified directories.

·        Translate the SIGMA rule into the target SIEM using validated backend mappings for ParentImage, ParentCommandLine, Image, CommandLine, User, Computer, ProcessGuid, ProcessId, and equivalent EDR fields.

·        Validate whether the destination platform preserves command-line content, parent-child process ancestry, process user context, process identity, and host identity reliably.

·        Use this SIGMA rule as a host-side compromise-validation detector and correlate it with IIS, WAF, reverse proxy, application, file, and network telemetry in the destination SIEM.

·        Apply environment-specific exceptions for deployment tools, backup jobs, monitoring agents, vendor support tools, reporting jobs, software updates, administrative automation, IIS maintenance, approved penetration testing, and incident-response activity.

·        Validate backend-specific conversion output because SIGMA backends may render contains, endswith, path escaping, list logic, and process field names differently.

·        Do not enable high-severity alerting until backend translation, field mapping, parent-child process fidelity, command-line visibility, host inventory, application pool identity mapping, exception handling, false-positive baselines, query performance, and SOC triage procedures are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to IIS worker-process child execution, which is a durable post-exploitation signal across ASP.NET application compromise scenarios.

·        The rule remains useful if an adversary changes ViewState payload structure, command syntax, child process selection, file path, web shell family, or outbound infrastructure.

·        The score is supported by the durability of process ancestry, command-line context, application pool identity context, execution path context, and cross-layer correlation with web, file, or network evidence.

·        The score is constrained by legitimate administrative automation, vendor support workflows, backup jobs, reporting jobs, deployment tools, applications that legitimately spawn child processes, incomplete command-line visibility, and inconsistent backend field mappings.

·        The rule is durable as a compromise-validation detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on process telemetry, command-line visibility, parent-child process fidelity, backend SIGMA translation quality, application pool identity mapping, host inventory, process baselines, and application-owner validation.

·        Operational confidence is reduced where destination SIEM translation loses parent process fields, command-line fields, user fields, or host identity context.

·        Operational confidence is reduced where legitimate application workflows spawn command shells, scripts, reporting tools, archive utilities, backup tools, or vendor support tooling from the IIS server.

·        Full-telemetry confidence improves when SIGMA-derived host alerts are enriched with IIS logs, WAF logs, ASP.NET application logs, file telemetry, outbound network telemetry, vulnerability context, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence, but confirmed exploitation still requires supporting web, file, network, application, or incident-response evidence.

Limitations

·        This SIGMA rule detects suspicious IIS worker-process child execution, not confirmed ViewState exploitation by itself.

·        SIGMA backend translations may differ materially across Splunk, Elastic, QRadar, Microsoft Sentinel, Chronicle, and EDR-backed SIEMs.

·        Legitimate deployment tools, backup jobs, reporting workflows, application maintenance, vendor support, administrative automation, and incident-response activity may produce similar parent-child process patterns.

·        Missing command-line telemetry reduces the ability to distinguish malicious execution from benign process activity.

·        Missing application pool identity mapping may reduce confidence in whether the process belongs to the affected ASP.NET application.

·        Missing IIS, WAF, or ASP.NET telemetry may prevent confirmation that suspicious execution followed abnormal request activity.

·        The rule may miss exploitation that avoids child-process creation, remains in-process, or uses memory-resident execution without visible process creation.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA IIS worker-process child execution rule pattern requiring backend translation validation, log source validation, field mapping, parent-child process validation, command-line validation, application pool identity validation, exception tuning, query-performance testing, and environment-specific allowlisting before production deployment.

title: IIS Worker Process Suspicious Child Process Execution
id: cyberdax-exp-aspnet-viewstate-iis-child-process
status: test
description: Detects suspicious child-process execution from IIS worker processes or application pool identities that may indicate ASP.NET server-side execution, web shell interaction, payload staging, or post-exploitation behavior. This rule does not confirm ViewState exploitation without supporting web, file, network, application, or incident-response evidence.
references:
  - Internal detection engineering pattern
author: CyberDax
date: 2026/05/27
tags:
  - attack.initial_access
  - attack.execution
  - attack.t1190
  - attack.t1059
  - attack.t1505.003
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\iisexpress.exe'
    ParentImage|contains:
      - '\inetsrv\'
  selection_identity:
    User|contains:
      - 'APPPOOL\'
      - 'IIS APPPOOL\'
  selection_child_process:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\tar.exe'
      - '\7z.exe'
  selection_command_line:
    CommandLine|contains:
      - '-enc'
      - 'EncodedCommand'
      - 'download'
      - 'upload'
      - 'http://'
      - 'https://'
      - '\Temporary ASP.NET Files\'
      - '\inetpub\wwwroot\'
  filter_approved_admin:
    CommandLine|contains:
      - 'APPROVED_DEPLOYMENT_COMMAND_PLACEHOLDER'
      - 'APPROVED_BACKUP_COMMAND_PLACEHOLDER'
      - 'APPROVED_MONITORING_COMMAND_PLACEHOLDER'
      - 'APPROVED_VENDOR_SUPPORT_COMMAND_PLACEHOLDER'
      - 'APPROVED_REPORTING_JOB_PLACEHOLDER'
  condition: (selection_parent or selection_identity) and (selection_child_process or selection_command_line) and not filter_approved_admin
falsepositives:
  - Approved deployment automation.
  - Backup jobs.
  - Monitoring agents.
  - Vendor support tooling.
  - Reporting workflows.
  - IIS maintenance.
  - Approved administrative automation.
  - Incident-response activity.
level: high

Rule

Suspicious ASP.NET Application File Modification With Follow-On Web Access

Rule Format

SIGMA rule pattern suitable for Windows file creation telemetry, Sysmon file telemetry, EDR file telemetry, file integrity telemetry, IIS web logs, WAF logs, reverse proxy logs, webroot inventory, protected application path inventories, file-to-URL relationship mapping, known-good baselines, and SIEM translation after log source validation, field mapping, file-path normalization, URL-path normalization, file-context validation, rare-path validation, correlation validation, exception testing, and backend query validation.

Detection Purpose

·        Detect suspicious application-file creation or modification in IIS or ASP.NET application directories that may be followed by rare, newly observed, or web shell-like access to the same or related application path.

·        Identify possible web shell placement, unauthorized ASPX artifact creation, application-content tampering, JavaScript modification, fake component staging, or modified downloadable content.

·        Prioritize file activity under webroot, vendor application, upload, plugin-like, temporary compilation, JavaScript, configuration, login-page, and downloadable-component paths.

·        Support escalation when suspicious file activity aligns with abnormal ASP.NET request activity, IIS process execution, rare path access, outbound communication, user downloads, or external script loading.

·        This rule does not prove web shell placement, ViewState exploitation, application compromise, user compromise, or actor attribution without supporting process, web, network, application, change-control, or incident-response evidence.

Detection Logic

·        Identify file creation, modification, rename, overwrite, or deletion events under protected IIS or ASP.NET application paths.

·        Prioritize high-risk file context involving new ASPX artifacts, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script reference additions, configuration changes, archive staging, executable staging, or suspicious temporary artifacts.

·        Prioritize file activity where the responsible process is w3wp.exe, an IIS worker process, a suspicious IIS child process, a script interpreter, a command shell, or an application pool identity.

·        Treat high-risk file extension matches as supporting context only when paired with suspicious responsible-process context, suspicious application-path context, abnormal change context, or follow-on evidence after backend translation and enrichment.

·        Correlate suspicious file activity with subsequent rare web access, newly observed path access, low-frequency path access, abnormal response-size patterns, web shell-like timing, user downloads, or external script loading in the destination SIEM.

·        Preserve file-to-web event-pair timing when the destination SIEM supports correlation, sequence, transaction, eventstats, join, rule chaining, or offense/case correlation.

·        Use normalized file-to-URL relationship mapping where the deployment path, webroot path, virtual directory, application route, or rewritten URL prevents direct file path to URL path matching.

·        Reduce severity for approved deployments, content updates, plugin updates, vendor patches, backup jobs, build jobs, cache generation, emergency fixes, incident response, and documented maintenance.

·        Do not classify file modification as malicious content tampering or web shell placement without supporting process, web access, network, application, or change-control evidence.

·        Do not rely on file extension alone, known web shell filenames, known hashes, public artifact strings, specific JavaScript names, or named tooling as required detection conditions.

Required Telemetry

·        Windows file creation telemetry.

·        Sysmon Event ID 11 where available.

·        EDR file telemetry where available.

·        File integrity telemetry where available.

·        File path.

·        File name.

·        File extension.

·        File hash where available.

·        File size where available.

·        Responsible process name.

·        Responsible process command line where available.

·        Parent process name where available.

·        Username.

·        Host name.

·        Host ID where available.

·        IIS web logs where available.

·        WAF logs where available.

·        Reverse proxy logs where available.

·        URL path.

·        HTTP status code.

·        Response size where available.

·        Source IP.

·        User-agent where available.

·        Protected IIS and ASP.NET path inventory.

·        High-risk ASP.NET file-context inventory.

·        Suspicious IIS responsible process inventory.

·        Unusual or sensitive application path inventory.

·        Approved deployment path inventory.

·        Approved change context.

·        Path first-seen baseline where available.

·        Path frequency baseline where available.

·        File-to-URL relationship mapping where available.

·        Known-good application baselines.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build protected path lists for webroot directories, ASP.NET application paths, vendor application paths, upload directories, plugin-like paths, temporary ASP.NET compilation paths, JavaScript directories, configuration directories, login-page paths, downloadable-component paths, and user-facing content paths.

·        Build high-risk file-context lists for new ASPX files, unexpected DLL placement, modified JavaScript, modified login pages, modified downloadable components, external script references, configuration changes, archive staging, executable staging, deleted-after-execution artifacts, and suspicious temporary files.

·        Build responsible-process lists for w3wp.exe, IIS worker processes, application pool identities, suspicious IIS child processes, script interpreters, command shells, deployment tools, build tools, backup tools, cache generation processes, and vendor support utilities.

·        Translate the SIGMA rule into the target SIEM using validated backend mappings for TargetFilename, Image, CommandLine, User, Computer, and equivalent EDR or file telemetry fields.

·        Ensure file extension alone cannot trigger the detection without suspicious file context, responsible-process context, non-approved change context, unusual path context, or follow-on evidence.

·        Normalize file paths and URI paths so file-to-web matching can evaluate exact path, related path, derived URL path, virtual directory mapping, rewritten route, and application-relative path relationships.

·        Use destination-platform correlation, rule chaining, scheduled searches, transforms, lookups, reference maps, or case/offense correlation to connect suspicious file activity with subsequent rare web access.

·        Apply environment-specific exceptions for approved deployments, content updates, plugin updates, vendor patches, backup jobs, build jobs, cache generation, emergency fixes, incident response, and documented maintenance.

·        Validate backend-specific conversion output because SIGMA backends may render TargetFilename, file event category, path escaping, and selection logic differently.

·        Do not enable high-severity alerting until backend translation, field mapping, file-path normalization, URL-path normalization, file-to-URL enrichment, known-good baselines, exception handling, false-positive baselines, query performance, and SOC triage procedures are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious application-file modification under IIS or ASP.NET paths, with stronger confidence when correlated to rare or newly observed web access.

·        The rule remains useful if an adversary changes web shell filename, artifact name, path, extension, source infrastructure, user-agent, or interaction timing.

·        The score is supported by the durability of unauthorized file placement, protected path modification, responsible-process context, rare path access, path first-seen analysis, and web-to-file correlation.

·        The score is constrained by legitimate deployments, content updates, plugin systems, vendor support, build workflows, generated content, cache generation, weak known-good baselines, missing file-to-URL relationship mapping, and inconsistent backend support for multi-event correlation.

·        The rule is durable as a content-tampering and web shell interaction detector but should not be treated as standalone proof of the original exploit vector.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on file telemetry, protected path coverage, responsible-process fields, path first-seen baselines, backend SIGMA translation quality, web log availability, host normalization, file-to-URL relationship mapping, change-control records, and application-owner validation.

·        Operational confidence is reduced where applications frequently generate files, update content, write to upload paths, use plugin systems, or rely on vendor-managed update workflows.

·        Operational confidence is reduced where file events cannot be tied to responsible process context or where web access logs cannot be tied to the modified path.

·        Operational confidence is also reduced because SIGMA by itself is not a full correlation engine; file-to-web correlation often requires target SIEM rule chaining or enrichment outside a single SIGMA rule.

·        Full-telemetry confidence improves when SIGMA-derived file alerts are enriched with IIS process execution, abnormal ASP.NET request activity, outbound communication, application logs, known-good baselines, and change-control evidence.

·        Under full telemetry conditions, this rule provides useful escalation evidence for suspicious application-file changes, but confirmed exploitation still requires supporting process, network, application, or incident-response evidence.

Limitations

·        This SIGMA rule detects suspicious application-file modification patterns, not confirmed web shell deployment by itself.

·        SIGMA backend translations may not preserve multi-event file-to-web sequence logic without additional platform-native correlation.

·        Legitimate deployments, plugin updates, content publishing, cache generation, build workflows, vendor support, emergency fixes, and incident-response activity may produce similar file and path-access patterns.

·        Missing responsible-process fields reduce confidence in whether file changes were caused by IIS, deployment tooling, administrators, or attacker activity.

·        Missing path first-seen baselines may reduce the ability to distinguish rare path access from normal application behavior.

·        Dynamic applications may create generated files, cache artifacts, temporary files, or uploaded content that resembles suspicious artifact placement.

·        File-to-web matching may be unreliable when applications use URL rewriting, virtual directories, generated routes, CDN path rewriting, or custom routing unless file-to-URL enrichment exists.

·        The rule may miss fileless or memory-resident activity that does not create durable application artifacts.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA suspicious ASP.NET application-file modification rule pattern requiring backend translation validation, log source validation, field mapping, file-path normalization, file-context enrichment, responsible-process validation, exception tuning, file-to-web correlation planning, query-performance testing, and environment-specific allowlisting before production deployment.

title: Suspicious ASP.NET Application File Modification
id: cyberdax-exp-aspnet-viewstate-application-file-modification
status: test
description: Detects suspicious file creation or modification under IIS or ASP.NET application directories. File-extension matches are treated as supporting context only and require suspicious process or suspicious path context after destination-platform translation and enrichment.
references:
  - Internal detection engineering pattern
author: CyberDax
date: 2026/05/27
tags:
  - attack.persistence
  - attack.execution
  - attack.t1505.003
  - attack.t1059
logsource:
  product: windows
  category: file_event
detection:
  selection_protected_path:
    TargetFilename|contains:
      - '\inetpub\wwwroot\'
      - '\Temporary ASP.NET Files\'
      - '\wwwroot\'
      - '\Views\'
      - '\Scripts\'
      - '\Content\'
      - '\App_Data\'
      - '\bin\'
  selection_high_risk_extension:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
      - '.dll'
      - '.js'
      - '.config'
      - '.ps1'
      - '.vbs'
      - '.bat'
      - '.cmd'
      - '.zip'
      - '.7z'
      - '.exe'
  selection_suspicious_process:
    Image|endswith:
      - '\w3wp.exe'
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  selection_suspicious_path_context:
    TargetFilename|contains:
      - '\uploads\'
      - '\plugins\'
      - '\login\'
      - '\auth\'
      - '\download\'
      - '\components\'
  filter_approved_paths:
    TargetFilename|contains:
      - 'APPROVED_DEPLOYMENT_PATH_PLACEHOLDER'
      - 'APPROVED_BUILD_OUTPUT_PATH_PLACEHOLDER'
      - 'APPROVED_CACHE_PATH_PLACEHOLDER'
  filter_approved_processes:
    Image|contains:
      - 'APPROVED_DEPLOYMENT_TOOL_PLACEHOLDER'
      - 'APPROVED_BUILD_TOOL_PLACEHOLDER'
      - 'APPROVED_BACKUP_TOOL_PLACEHOLDER'
      - 'APPROVED_VENDOR_SUPPORT_TOOL_PLACEHOLDER'
  condition: selection_protected_path and ((selection_high_risk_extension and (selection_suspicious_process or selection_suspicious_path_context)) or (selection_suspicious_process and selection_suspicious_path_context)) and not filter_approved_paths and not filter_approved_processes
falsepositives:
  - Approved deployments.
  - Content updates.
  - Plugin updates.
  - Vendor patches.
  - Backup jobs.
  - Build workflows.
  - Cache generation.
  - Emergency fixes.
  - Incident-response activity.
level: medium

Rule

IIS Server Rare Destination Communication After Suspicious ASP.NET Activity

Rule Format

SIGMA rule pattern suitable for Windows network telemetry, Sysmon network telemetry, EDR network telemetry, DNS events, proxy events, firewall events, endpoint process telemetry, destination enrichment, IIS server inventory, application-boundary mapping, approved destination inventories, and SIEM translation after log source validation, field mapping, destination normalization, process-to-network mapping, application-boundary mapping, exception testing, backend query validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from IIS-hosted ASP.NET servers after abnormal ASP.NET request activity, suspicious process execution, application-file modification, rare path access, or post-exploitation behavior.

·        Identify possible callback behavior, payload retrieval, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact.

·        Prioritize outbound communication from w3wp.exe, IIS child processes, application pool identities, suspicious command shells, script interpreters, network utilities, or recently modified application contexts.

·        Support escalation when outbound activity aligns with ViewState-bearing request anomalies, IIS child-process execution, suspicious file changes, application-content tampering, credential access, archive creation, defense evasion, or user-delivery evidence.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, user compromise, cloud compromise, or actor attribution without supporting web, endpoint, file, application, identity, change-control, or incident-response evidence.

Detection Logic

·        Identify outbound network, DNS, proxy, firewall, or endpoint network events from confirmed IIS-hosted ASP.NET servers.

·        Prioritize destinations that are newly observed within the local first-seen window, rare for the host, rare for the application, low reputation, direct-IP based, dynamic DNS-associated, uncommon by port, unusual by TLS SNI, unusual by HTTP host, or outside approved vendor, monitoring, update, backup, deployment, and business-integration inventories.

·        Correlate outbound communication with specific prior or nearby suspicious ASP.NET activity, including abnormal ViewState-bearing POST activity, HTTP 500-series bursts, failed request traces, error-to-success patterns, rare path access, or web shell-like access in the destination SIEM.

·        Correlate outbound communication with specific nearby host-side or file evidence, including IIS child-process execution, suspicious command lines, application-file modification, credential access, local discovery, archive creation, defense evasion, persistence attempts, or post-exploitation tool staging in the destination SIEM.

·        Preserve context-to-outbound event-pair timing when the destination SIEM supports correlation, sequence, transaction, eventstats, rule chaining, or offense/case correlation.

·        Increase confidence when outbound communication is process-linked to w3wp.exe, IIS child processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, deployment destinations, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Do not classify outbound communication as exploitation-related without suspicious web, host, file, application, or incident-response evidence.

·        Do not treat destination novelty, direct-IP communication, unusual ports, DNS rarity, cloud hosting, or high byte volume as compromise evidence by itself.

·        Do not let this rule duplicate the process-execution rule unless outbound communication materially changes the risk context.

Required Telemetry

·        Windows network telemetry.

·        Sysmon Event ID 3 where available.

·        EDR network telemetry where available.

·        DNS telemetry where available.

·        Proxy telemetry where available.

·        Firewall telemetry where available.

·        Host name.

·        Host ID where available.

·        Source IP.

·        Destination IP.

·        Destination domain where available.

·        Destination port.

·        Destination ASN where available.

·        Network direction.

·        Network protocol.

·        Byte count where available.

·        DNS query where available.

·        TLS SNI or certificate subject where available.

·        HTTP host where available.

·        Process name where available.

·        Process command line where available.

·        Parent process where available.

·        Username where available.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        IIS server inventory.

·        ASP.NET application boundary inventory.

·        Approved IIS destination inventory.

·        Approved IIS destination IP inventory.

·        Approved vendor service inventory.

·        Approved monitoring destination inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Application-boundary mapping where available.

·        Web telemetry where available.

·        Process telemetry where available.

·        File telemetry where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build destination-platform lists for IIS servers, ASP.NET application hosts, internet-facing applications, vendor-managed portals, LMS systems, authentication-adjacent portals, and load balancer backends.

·        Build suspicious destination lists for newly observed destinations, rare destinations, low-reputation destinations, direct-IP destinations, dynamic DNS destinations, uncommon ports, rare TLS context, unusual HTTP hosts, cloud-hosted infrastructure, developer platforms, object storage, file-transfer services, and destinations outside approved dependencies.

·        Build approved destination lists for vendor services, monitoring platforms, backup systems, deployment systems, update repositories, managed hosting destinations, business integrations, administrative automation, and incident-response infrastructure.

·        Translate the SIGMA rule into the target SIEM using validated backend mappings for Image, DestinationIp, DestinationHostname, DestinationPort, User, Computer, Initiated, and equivalent EDR, DNS, proxy, or firewall fields.

·        Use source host identity only when network events resolve to the same IIS server or normalized workload boundary.

·        Use application-boundary enrichment, backend-host mapping, reference-data correlation, or case/offense correlation when WAF, proxy, load balancer, NAT, shared sensors, or shared egress layers prevent direct host-level sequencing.

·        Use destination-platform correlation, rule chaining, scheduled searches, transforms, lookups, reference maps, or case/offense correlation to connect suspicious outbound communication with suspicious web, host, or file precursor behavior.

·        Apply environment-specific exceptions for approved destinations, vendor services, monitoring systems, backup destinations, deployment destinations, update repositories, business integrations, managed hosting operations, administrative automation, and incident-response infrastructure.

·        Validate backend-specific conversion output because SIGMA backends may render network telemetry fields, destination host fields, destination IP fields, process-to-network joins, and regular-expression operators differently.

·        Do not enable high-severity alerting until backend translation, network telemetry coverage, destination baselines, process-to-network mapping, field mappings, application-boundary enrichment, exception handling, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to outbound communication from IIS-hosted ASP.NET servers rather than destination novelty alone.

·        The rule remains useful if an adversary changes destination domain, IP address, protocol, web shell family, payload staging method, callback timing, or post-exploitation toolset.

·        The score is supported by the durability of suspicious server egress when correlated with web, host, file, and application context in the destination SIEM.

·        The score is constrained by legitimate server egress, weak destination inventories, shared egress paths, incomplete process-to-network mapping, broad approved dependencies, incomplete application-boundary enrichment, and limited SIGMA-native support for multi-event correlation.

·        The rule is durable as a post-exploitation signal pattern but should not be treated as standalone proof of exploitation, command-and-control, or actor attribution.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on endpoint network telemetry, DNS telemetry, proxy or firewall telemetry, destination enrichment, process-to-network mapping, backend SIGMA translation quality, asset inventory, approved destination inventories, and application-boundary mapping.

·        Operational confidence is reduced where IIS servers have broad egress, weak destination baselines, shared egress paths, or legitimate automation that contacts rare destinations.

·        Operational confidence is reduced where outbound communication cannot be linked to the responsible host, process, user, application boundary, or workload boundary.

·        Operational confidence is also reduced because SIGMA by itself is not a full correlation engine; context-to-outbound correlation often requires target SIEM rule chaining or enrichment outside a single SIGMA rule.

·        Full-telemetry confidence improves when SIGMA-derived network alerts are enriched with IIS logs, WAF logs, EDR process telemetry, file telemetry, ASP.NET application logs, destination reputation, identity context, and change-control records.

·        Under full telemetry conditions, this rule provides escalation evidence for post-exploitation activity, but confirmed compromise still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This SIGMA rule detects suspicious outbound communication patterns from IIS-hosted ASP.NET servers, not confirmed exploitation by itself.

·        SIGMA backend translations may not preserve multi-event context-to-outbound sequence logic without additional platform-native correlation.

·        Legitimate vendor services, update checks, monitoring workflows, backup operations, deployment automation, business integrations, managed hosting operations, and incident response may produce similar outbound patterns.

·        Missing process-to-network telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        Missing destination enrichment may reduce the ability to distinguish suspicious destinations from legitimate dependencies.

·        Reverse proxy, NAT, shared egress, and hosted infrastructure may make workload attribution difficult.

·        The rule may miss attackers who avoid outbound communication, use approved infrastructure, operate fully in-process, or complete objectives through local application manipulation.

·        This rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA IIS server rare destination communication rule pattern requiring backend translation validation, log source validation, field mapping, destination enrichment, process-to-network mapping, exception tuning, correlation planning, query-performance testing, and environment-specific allowlisting before production deployment.

title: IIS Server Rare Destination Communication After Suspicious ASP.NET Activity
id: cyberdax-exp-aspnet-viewstate-iis-rare-destination-communication
status: test
description: Detects suspicious outbound communication from IIS-hosted ASP.NET servers. Direct-IP communication, unusual ports, and destination novelty are supporting signals only; this rule is intended to be correlated with suspicious ASP.NET request activity, IIS process execution, application-file modification, or rare path access in the destination SIEM before high-confidence alerting.
references:
  - Internal detection engineering pattern
author: CyberDax
date: 2026/05/27
tags:
  - attack.command_and_control
  - attack.exfiltration
  - attack.t1105
  - attack.t1071
logsource:
  product: windows
  category: network_connection
detection:
  selection_iis_worker_process:
    Image|endswith:
      - '\w3wp.exe'
  selection_suspicious_network_process:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cscript.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  selection_unusual_destination_port:
    DestinationPort:
      - 4443
      - 8080
      - 8443
      - 9001
      - 9443
  selection_rare_or_unusual_destination:
    DestinationHostname|contains:
      - 'RARE_DESTINATION_PLACEHOLDER'
      - 'NEWLY_OBSERVED_DESTINATION_PLACEHOLDER'
      - 'DYNAMIC_DNS_PLACEHOLDER'
      - 'UNAPPROVED_OBJECT_STORAGE_PLACEHOLDER'
  selection_direct_ip:
    DestinationIp|re: '^\d{1,3}(\.\d{1,3}){3}$'
  filter_approved_destinations:
    DestinationHostname|contains:
      - 'APPROVED_VENDOR_DESTINATION_PLACEHOLDER'
      - 'APPROVED_MONITORING_DESTINATION_PLACEHOLDER'
      - 'APPROVED_BACKUP_DESTINATION_PLACEHOLDER'
      - 'APPROVED_DEPLOYMENT_DESTINATION_PLACEHOLDER'
      - 'APPROVED_UPDATE_DESTINATION_PLACEHOLDER'
  condition: ((selection_iis_worker_process and selection_rare_or_unusual_destination) or (selection_suspicious_network_process and (selection_rare_or_unusual_destination or selection_unusual_destination_port or selection_direct_ip))) and not filter_approved_destinations
falsepositives:
  - Approved vendor services.
  - Monitoring platforms.
  - Backup destinations.
  - Deployment systems.
  - Update repositories.
  - Managed hosting operations.
  - Business integrations.
  - Incident-response infrastructure.
level: medium

YARA

Detection Viability Assessment

YARA has zero primary rules for this EXP report.

·        YARA is not recommended for primary S25 detection because the governing detection model is behavior-led, not artifact-led.

·        The report’s strongest detection coverage comes from request-to-host correlation, IIS process behavior, application-file modification, rare path access, outbound server communication, SIEM correlation, endpoint telemetry, and cloud or workload-boundary enrichment where applicable.

·        YARA does not observe ASP.NET ViewState request behavior, shared machineKey exposure conditions, IIS request sequencing, application pool identity behavior, web-to-process timing, file-to-web access timing, destination novelty, process-to-network attribution, WAF context, reverse proxy routing, load balancer backend mapping, or application-boundary movement.

·        YARA can support optional investigative hunting if responders recover a stable web shell, payload, dropper, suspicious uploaded file, modified application artifact, memory artifact, or reusable file-content pattern during incident response.

·        Including a primary YARA rule would create unnecessary artifact dependency and would be weaker than the accepted NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, and SIGMA behavior-led rule sets.

·        YARA should remain a conditional investigative control rather than a primary detection system unless stable artifact evidence becomes available from the affected environment.

·        YARA should not be used to infer ViewState deserialization, shared machineKey exploitation, KnowledgeDeliver exploitation, web shell deployment, actor attribution, credential theft, Cobalt Strike delivery, or successful compromise without supporting web, endpoint, file, network, application, or incident-response evidence.

Final Disposition

No primary YARA rule is included.

AWS

Detection Viability Assessment

AWS has three rules for this EXP report.

·        AWS is viable when the affected ASP.NET / IIS workload is hosted on AWS infrastructure, including EC2, Elastic Load Balancing, AWS WAF, CloudFront-to-ALB routing, ECS on Windows, EKS Windows nodes, or AWS-hosted application infrastructure that emits control-plane, network, identity, object-storage, and workload-adjacent telemetry.

·        AWS is strongest where AWS WAF logs, Application Load Balancer logs, CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, GuardDuty findings, Security Hub findings, EC2 inventory, instance-profile mappings, workload tags, S3 data events, Secrets Manager events, KMS events, IAM events, SSM events, and endpoint telemetry can be correlated with IIS, endpoint, file, and application telemetry.

·        AWS can support detection of suspicious workload egress, metadata access, secrets access, object-storage activity, IAM role use, SSM activity, and cloud-control-plane follow-on behavior after suspicious ASP.NET request activity, IIS process execution, application-file modification, rare path access, or confirmed affected workload context.

·        AWS is not a standalone source for confirming ASP.NET ViewState deserialization, shared machineKey exploitation, KnowledgeDeliver exploitation, or web shell deployment unless AWS-side activity is correlated to web, endpoint, file, application, identity, and workload evidence.

·        AWS cloud-only anomalies must not be attributed to this exploitation path without upstream exposure correlation, such as suspicious ASP.NET request activity, IIS worker-process execution, application-file modification, rare path access, or confirmed affected workload identity.

·        AWS rules must be validated against account structure, AWS Organizations structure, VPC topology, workload tags, ALB / WAF logging, CloudTrail coverage, VPC Flow Log coverage, DNS log coverage, GuardDuty coverage, S3 data-event coverage, Secrets Manager logging, KMS event coverage, IAM baselines, SSM baselines, workload identity mappings, NAT attribution, and incident-response workflows before production deployment.

·        AWS detection content should be treated as cloud-side correlation coverage for AWS-hosted ASP.NET / IIS workloads, not direct proof of ViewState exploitation, web shell deployment, AWS account compromise, data theft, or actor attribution.

Rule

AWS-Hosted ASP.NET Workload Suspicious Request Followed by Unusual Server Egress

Rule Format

AWS correlation rule suitable for AWS WAF logs, Application Load Balancer access logs, CloudFront logs where applicable, VPC Flow Logs, Route 53 Resolver query logs, GuardDuty findings, EC2 asset inventory, workload tags, IIS server mappings, target group mappings, NAT gateway mappings, endpoint network telemetry, proxy logs where available, and SIEM correlation after log-source validation, workload-boundary mapping, NAT attribution validation, field normalization, egress-baseline validation, approved-destination validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from AWS-hosted ASP.NET / IIS workloads after abnormal ASP.NET request activity, suspicious request patterns, rare path access, or workload-adjacent web anomalies.

·        Identify possible payload retrieval, callback behavior, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact from an affected AWS-hosted workload.

·        Prioritize internet-facing ASP.NET applications behind AWS WAF, Application Load Balancer, CloudFront-to-ALB routing, reverse proxy layers, or EC2-hosted IIS workloads.

·        Support escalation when suspicious AWS-side egress aligns with IIS worker-process execution, application-file modification, rare path access, endpoint detections, application errors, or suspicious file activity.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, AWS account compromise, or actor attribution without supporting web, endpoint, file, application, identity, or incident-response evidence.

Detection Logic

·        Identify abnormal ASP.NET web activity in AWS WAF logs, ALB logs, CloudFront logs, reverse proxy logs, or mapped IIS web logs.

·        Prioritize POST requests to ViewState-bearing, authentication-adjacent, upload, administrative-adjacent, LMS, vendor-portal, or state-bearing application paths.

·        Prioritize abnormal web behavior involving large request bodies, repeated request variation, error-to-success patterns, HTTP 500-series bursts, sparse targeted requests, unusual user agents, rare source ASNs, suspicious hosting-provider sources, anonymization infrastructure, or WAF anomaly context.

·        Correlate suspicious web activity to outbound communication from the same AWS workload boundary, backend target, EC2 instance, Auto Scaling group, target group, ECS task, EKS Windows node, NAT source, or enriched application boundary.

·        Prioritize outbound communication to newly observed destinations, rare destinations, direct-IP destinations, dynamic DNS destinations, low-reputation destinations, unusual ports, uncommon protocols, rare TLS SNI values, unusual HTTP hosts, developer platforms, object-storage endpoints, file-transfer services, or destinations outside approved workload dependencies.

·        Increase confidence when outbound communication is process-linked to IIS worker processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities through endpoint telemetry.

·        Increase confidence when outbound communication follows suspicious IIS child-process execution, application-file modification, webroot tampering, rare path access, credential access, archive creation, local discovery, defense evasion, or application-content tampering.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, patching repositories, deployment systems, update services, business integrations, managed hosting dependencies, administrative automation, and incident-response infrastructure.

·        Do not classify AWS egress anomalies as exploitation-related without upstream web, endpoint, file, application, or workload-boundary evidence.

·        Do not treat NAT egress, destination novelty, direct-IP communication, unusual ports, GuardDuty network findings, or cloud-hosted destinations as compromise evidence by itself.

Required Telemetry

·        AWS WAF logs where available.

·        Application Load Balancer access logs where available.

·        CloudFront logs where applicable.

·        VPC Flow Logs.

·        Route 53 Resolver query logs where available.

·        GuardDuty findings where available.

·        Security Hub findings where available.

·        EC2 instance inventory.

·        Target group mappings.

·        Load balancer target mappings.

·        Auto Scaling group mappings where applicable.

·        ECS task mappings where applicable.

·        EKS Windows node mappings where applicable.

·        NAT gateway mappings where applicable.

·        Workload tag inventory.

·        Application-boundary mapping.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring destination inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        Endpoint process-to-network telemetry where available.

·        IIS process telemetry where available.

·        IIS web logs where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-boundary mappings that connect AWS WAF web ACLs, ALB listeners, target groups, EC2 instances, Auto Scaling groups, ECS services, EKS Windows nodes, NAT gateways, IIS servers, workload tags, and application names.

·        Build approved destination inventories for AWS services, vendor services, monitoring platforms, backup systems, patching systems, deployment platforms, update repositories, business integrations, and incident-response infrastructure.

·        Build suspicious destination logic for newly observed destinations, rare destinations, direct-IP communication, dynamic DNS, low-reputation destinations, uncommon ports, rare TLS context, unusual HTTP hosts, developer platforms, file-transfer services, object-storage endpoints, and destinations outside approved dependencies.

·        Normalize WAF, ALB, CloudFront, VPC Flow Log, DNS, GuardDuty, endpoint, and IIS fields so events can be correlated by workload boundary instead of raw source IP alone.

·        Use instance ID, private IP, target group, backend host, workload tag, Auto Scaling group, ECS task, EKS node, NAT mapping, and application-boundary enrichment where available.

·        Preserve web-to-egress event-pair timing so each suspicious web event is correlated to the specific subsequent outbound event or destination cluster.

·        Use shorter correlation windows when suspicious web activity is followed quickly by DNS lookup, direct-IP communication, rare destination access, payload retrieval, or callback-like behavior.

·        Use moderate correlation windows when outbound activity follows IIS process execution, application-file modification, rare path access, archive creation, credential access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, staged payload retrieval, delayed operator return, repeated low-volume communication, or low-and-slow post-exploitation behavior.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, WAF anomaly context, abnormal POST behavior, target group mapping confidence, destination rarity, direct-IP egress, unusual port use, process-linked egress, and supporting host or file evidence.

·        Use approved destination inventories, AWS service dependency maps, deployment records, monitoring records, backup records, change records, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until logging coverage, workload-boundary mapping, NAT attribution, destination baselines, approved-destination inventories, event-pair correlation quality, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious web-to-egress correlation from AWS-hosted ASP.NET workloads rather than static exploit strings, payload syntax, machineKey material, web shell filenames, or known infrastructure.

·        The rule remains useful if an adversary changes request syntax, destination domain, destination IP, callback timing, payload staging method, web shell family, or post-exploitation toolset.

·        The score is supported by the durability of suspicious outbound communication after abnormal web activity when workload-boundary mapping is reliable.

·        The score is constrained by NAT aggregation, shared egress, incomplete process-to-network mapping, broad approved dependencies, weak destination baselines, and incomplete AWS-to-IIS workload mapping.

·        The rule is durable as a cloud-side post-exploitation correlation but should not be treated as standalone proof of exploitation.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on AWS WAF logs, ALB logs, VPC Flow Logs, DNS telemetry, endpoint process-to-network mapping, workload-boundary mapping, approved destination inventories, and IIS / ASP.NET telemetry.

·        Operational confidence is reduced where NAT gateways, shared egress, load balancers, proxies, CDNs, or managed hosting layers obscure workload attribution.

·        Operational confidence is reduced where VPC Flow Logs lack process context or DNS logs cannot be tied to the affected workload.

·        Full-telemetry confidence improves when AWS-side egress is enriched with IIS logs, endpoint telemetry, file telemetry, GuardDuty findings, destination reputation, workload tags, application ownership, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for AWS-hosted workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET web activity, not confirmed exploitation by itself.

·        NAT gateways, shared egress paths, proxies, CDNs, load balancers, and hosted infrastructure may make workload attribution difficult.

·        Legitimate vendor services, monitoring systems, backup jobs, deployment automation, patching workflows, update repositories, and business integrations may produce similar outbound patterns.

·        VPC Flow Logs do not provide process-level attribution by themselves.

·        Missing DNS telemetry may reduce destination-context confidence.

·        Missing endpoint telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        The rule may miss attackers who avoid outbound communication, use approved destinations, operate fully in-process, or complete objectives through local application manipulation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS-hosted ASP.NET suspicious request followed by unusual workload egress query pattern requiring AWS log-source validation, WAF / ALB parsing validation, VPC Flow Log validation, DNS log validation, workload-boundary mapping, NAT attribution validation, destination-baseline validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, instance IDs, private IP mappings, target group mappings, NAT attribution, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AWS CORRELATION RULE: Suspicious ASP.NET Request Followed By AWS Workload Egress

WHEN WebEvent.Source IN (
"AWS WAF",
"Application Load Balancer",
"CloudFront",
"IIS"
)
AND WebEvent.HTTPMethod = "POST"
AND WebEvent.URLPath IN REFERENCE_SET(
"ViewState Bearing ASP.NET Paths",
"ASP.NET Authentication Adjacent Paths",
"ASP.NET Administrative Adjacent Paths",
"ASP.NET Upload Paths",
"ASP.NET LMS Workflow Paths"
)
AND (
WebEvent.RequestSize > REFERENCE_MAP_VALUE(
"ASP.NET Endpoint POST Size Baseline P95",
WebEvent.URLPath
)
OR WebEvent.StatusCode IN (500, 502, 503)
OR WebEvent.EventPattern IN (
"error_then_success",
"repeated_request_variation",
"sparse_targeted_requests",
"abnormal_request_cadence",
"suspicious_allowed_web_activity",
"waf_anomaly_context"
)
OR WebEvent.SourceIP IN REFERENCE_SET("Rare Sources For Application")
OR WebEvent.SourceASN IN REFERENCE_SET("Rare Or Suspicious Source ASNs")
)
FOLLOWED WITHIN ENV_ASPNET_REQUEST_TO_EGRESS_WINDOW BY NetworkEvent
WHERE NetworkEvent.Source IN (
"VPC Flow Logs",
"Route 53 Resolver Query Logs",
"Endpoint Network",
"Proxy",
"Firewall"
)
AND CORRELATION_KEY(
WebEvent.TargetGroup,
WebEvent.BackendInstanceId,
WebEvent.ApplicationBoundary,
NetworkEvent.InstanceId,
NetworkEvent.PrivateIP,
NetworkEvent.NATMapping,
NetworkEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AWS_WORKLOAD_OR_APPLICATION_BOUNDARY
AND (
NetworkEvent.DestinationDomain IN REFERENCE_SET("Newly Observed Destinations")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Rare Destinations For Workload")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Low Reputation Destinations")
OR NetworkEvent.DestinationIP IN REFERENCE_SET("Direct IP Or Unapproved Destinations")
OR NetworkEvent.DestinationPort IN REFERENCE_SET("Uncommon IIS Egress Ports")
OR NetworkEvent.DNSQuery IN REFERENCE_SET("Dynamic DNS Or Rare DNS Patterns")
OR NetworkEvent.ProcessName IN REFERENCE_SET("Suspicious IIS Network Processes")
)
AND (
NetworkEvent.DestinationDomain IS NULL
OR NetworkEvent.DestinationDomain NOT IN REFERENCE_SET("Approved AWS Workload Destinations")
)
AND (
NetworkEvent.DestinationIP IS NULL
OR NetworkEvent.DestinationIP NOT IN REFERENCE_SET("Approved AWS Workload Destination IPs")
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
NetworkEvent.InstanceId,
NetworkEvent.ProcessName,
COALESCE(NetworkEvent.DestinationDomain, NetworkEvent.DestinationIP),
NetworkEvent.EventTime
)

Rule

AWS-Hosted ASP.NET Workload Follow-On Secrets or Metadata Access After Suspicious Host Activity

Rule Format

AWS correlation rule suitable for CloudTrail, GuardDuty findings, Security Hub findings, EC2 instance identity context, IAM role mappings, instance profile mappings, Secrets Manager events, KMS events, SSM activity, STS events, metadata-access telemetry where available, endpoint telemetry, IIS process telemetry, application-file telemetry, and SIEM correlation after CloudTrail validation, workload identity mapping, role-to-instance validation, API baseline validation, metadata-access validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious access to AWS metadata, Secrets Manager, KMS, SSM, STS, or workload credentials after suspicious ASP.NET / IIS host activity.

·        Identify possible cloud-side expansion after server-side execution, web shell interaction, application compromise, or post-exploitation behavior on an AWS-hosted ASP.NET workload.

·        Prioritize activity involving affected EC2 instance roles, application instance profiles, workload IAM roles, SSM sessions, secrets retrieval, unusual KMS decrypt activity, or metadata-service access following suspicious web or host behavior.

·        Support escalation when cloud credential or metadata access follows IIS child-process execution, suspicious command lines, application-file modification, outbound communication, rare path access, or abnormal ASP.NET request activity.

·        This rule does not prove ViewState exploitation, AWS account compromise, credential theft, privilege escalation, or actor attribution without supporting web, endpoint, file, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side context from an AWS-hosted ASP.NET workload, including IIS worker-process child execution, suspicious command lines, webroot modification, application-file modification, rare path access, abnormal ViewState-bearing POST activity, credential access, archive creation, local discovery, defense evasion, or outbound communication.

·        Correlate suspicious host-side context to subsequent AWS metadata access, instance role credential access, Secrets Manager retrieval, KMS decrypt activity, SSM session or command activity, unusual STS activity, or IAM role usage from the same workload boundary.

·        Prioritize metadata access or credential retrieval that is new for the workload, rare for the instance, rare for the application role, outside normal deployment windows, associated with suspicious process context, or followed by unusual AWS API use.

·        Prioritize Secrets Manager activity involving unusual secret names, unusual calling principals, unusual source workload, first-seen access, cross-application access, unexpected burst access, access outside approved application behavior, or access to sensitive secrets outside the workload’s normal dependency map.

·        Prioritize KMS activity involving unusual decrypt volume, unusual key use, unusual calling role, unusual source service, decrypt calls tied to secrets or data stores not normally accessed by the workload, or decrypt activity that follows suspicious host behavior.

·        Prioritize SSM activity involving unexpected command execution, interactive sessions, unusual document execution, new operator identity, unexpected source workload, or use outside maintenance windows.

·        Increase confidence when suspicious cloud-side activity follows IIS child-process execution, application-file modification, rare path access, web-to-egress correlation, endpoint credential-access detections, or application errors.

·        Reduce severity for approved deployment automation, patching workflows, backup operations, monitoring tools, break-glass activity, incident response, maintenance windows, and expected application secret retrieval.

·        Do not classify metadata access, secrets retrieval, KMS decrypt, SSM activity, STS activity, or IAM activity as exploitation-related without upstream web, host, file, application, or workload-boundary evidence.

·        Do not treat normal application secret retrieval as compromise evidence without unusual caller, unusual timing, unusual volume, unusual resource scope, or suspicious host-side context.

Required Telemetry

·        CloudTrail management events.

·        CloudTrail data events where applicable.

·        EC2 instance inventory.

·        Instance profile mappings.

·        IAM role mappings.

·        STS events.

·        Secrets Manager events.

·        KMS events.

·        SSM Session Manager events.

·        SSM Run Command events.

·        GuardDuty findings where available.

·        Security Hub findings where available.

·        VPC Flow Logs where available.

·        Route 53 Resolver query logs where available.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Metadata-access telemetry where available.

·        Workload tag inventory.

·        Application-boundary mapping.

·        Approved secret access baselines.

·        Approved KMS key-use baselines.

·        Approved SSM activity baselines.

·        Approved STS behavior baselines.

·        Approved deployment identity inventory.

·        Approved break-glass identity inventory.

·        Sensitive secret inventory.

·        Sensitive KMS key inventory.

·        Cross-application secret access map.

·        Maintenance-window records.

·        Change-control records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build mappings from EC2 instance IDs, instance profiles, IAM roles, application names, workload tags, target groups, Auto Scaling groups, ECS services, EKS nodes, and ASP.NET applications to normalized workload boundaries.

·        Build approved baselines for Secrets Manager access, KMS decrypt activity, STS usage, SSM sessions, SSM Run Command activity, metadata access, and deployment automation for each AWS-hosted ASP.NET workload.

·        Build sensitive secret, sensitive key, and cross-application access maps so unusual access to sensitive approved resources is not fully suppressed by simple allowlisting.

·        Build suspicious host-side precursor logic from locked endpoint and SIEM rules, including IIS child-process execution, application-file modification, suspicious web activity, rare path access, outbound communication, credential access, archive creation, and defense-evasion behavior.

·        Preserve host-to-cloud event-pair timing so each suspicious host precursor is correlated to the specific subsequent CloudTrail, metadata, secrets, KMS, SSM, or STS activity.

·        Use shorter correlation windows when suspicious host activity is followed quickly by metadata access, secrets retrieval, KMS decrypt, or STS activity.

·        Use moderate correlation windows when SSM activity, unusual IAM role usage, or unusual API activity follows host compromise indicators.

·        Use longer correlation windows for delayed credential use, delayed operator activity, staged cloud reconnaissance, or low-and-slow misuse of workload credentials.

·        Add severity weighting for internet-facing exposure, application role sensitivity, privileged instance profile, unusual secret access, unusual KMS decrypt activity, unusual SSM use, first-seen STS behavior, cross-application access, sensitive-resource access, and supporting endpoint or network evidence.

·        Use deployment records, maintenance windows, expected application startup behavior, expected secret-rotation behavior, backup workflows, monitoring workflows, and incident-response activity as triage evidence.

·        Do not enable high-severity alerting until CloudTrail coverage, event timing, workload identity mapping, role-to-instance mapping, secrets baselines, KMS baselines, SSM baselines, STS baselines, sensitive-resource maps, exception logic, false-positive baselines, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to cloud-side credential, metadata, secrets, KMS, SSM, or STS activity after suspicious AWS-hosted workload behavior.

·        The rule remains useful if an adversary changes web shell family, command syntax, payload staging method, destination infrastructure, credential-access timing, or cloud API usage timing.

·        The score is supported by the durability of post-exploitation attempts to access metadata, secrets, workload credentials, SSM, STS, or cloud APIs from compromised workloads.

·        The score is constrained by normal application secret retrieval, deployment automation, monitoring tools, patching workflows, backup operations, and incomplete workload identity mapping.

·        The rule is durable as a cloud-side escalation detector but should not be treated as standalone proof of ViewState exploitation or AWS account compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on CloudTrail coverage, workload identity mapping, instance profile mapping, endpoint telemetry, secrets baselines, KMS baselines, SSM baselines, STS baselines, metadata visibility, and host-side precursor quality.

·        Operational confidence is reduced where normal application behavior includes frequent secrets retrieval, KMS decrypt activity, metadata interaction, SSM automation, or recurring STS activity.

·        Operational confidence is reduced where role-to-instance mapping, tag hygiene, CloudTrail coverage, sensitive-resource mapping, or endpoint telemetry is incomplete.

·        Full-telemetry confidence improves when suspicious cloud-side events are enriched with IIS logs, endpoint telemetry, file telemetry, WAF logs, ALB logs, VPC Flow Logs, DNS logs, GuardDuty findings, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for possible cloud-side misuse after workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, identity, or incident-response evidence.

Limitations

·        This rule detects suspicious AWS metadata, secrets, KMS, SSM, STS, or IAM activity after suspicious host behavior, not confirmed exploitation by itself.

·        Normal application operation may involve secrets retrieval, KMS decrypt activity, metadata access, STS calls, and role usage.

·        Deployment automation, backup jobs, monitoring agents, patching workflows, incident response, and maintenance activity may produce similar cloud-side behavior.

·        Missing CloudTrail coverage or missing data events may reduce visibility.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and cloud API activity.

·        Missing workload-boundary mapping may prevent attribution to the affected ASP.NET application.

·        Simple allowlists can suppress meaningful activity if sensitive-resource maps, cross-application access maps, or unusual-volume logic are not maintained.

·        The rule may miss attackers who avoid cloud-side activity or use only already-approved application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS-hosted ASP.NET suspicious host activity followed by metadata, secrets, KMS, SSM, STS, or IAM activity query pattern requiring CloudTrail validation, data-event validation, workload identity mapping, instance profile mapping, role-to-workload mapping, metadata-access validation, baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, instance IDs, instance profile mappings, IAM role mappings, principal-to-workload mappings, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AWS CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By AWS Secrets Or Metadata Access

WHEN HostEvent.Source IN (
"EDR Process",
"EDR File",
"IIS",
"SIEM Correlation",
"Endpoint Detection"
)
AND HostEvent.EventPattern IN (
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious ASP.NET Request Activity",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_HOST_TO_AWS_API_WINDOW BY CloudEvent
WHERE CloudEvent.Source IN (
"CloudTrail",
"GuardDuty",
"SecurityHub",
"MetadataAccessTelemetry"
)
AND CORRELATION_KEY(
HostEvent.InstanceId,
HostEvent.PrivateIP,
HostEvent.ApplicationBoundary,
CloudEvent.InstanceId,
CloudEvent.PrincipalArn,
CloudEvent.InstanceProfileArn,
CloudEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AWS_WORKLOAD_ROLE_OR_APPLICATION_BOUNDARY
AND (
CloudEvent.EventName IN (
"GetSecretValue",
"BatchGetSecretValue",
"Decrypt",
"StartSession",
"SendCommand",
"AssumeRole",
"GetCallerIdentity"
)
OR CloudEvent.EventPattern IN (
"metadata_credential_access",
"unusual_instance_profile_use",
"unusual_secret_access",
"unusual_kms_decrypt",
"unexpected_ssm_activity",
"first_seen_role_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_kms_key_use_after_host_precursor"
)
)
AND (
CloudEvent.PrincipalArn IS NULL
OR CloudEvent.PrincipalArn NOT IN REFERENCE_SET("Approved Deployment Or Automation Principals")
OR CloudEvent.EventPattern IN (
"first_seen_role_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_kms_key_use_after_host_precursor"
)
)
AND (
CloudEvent.SecretId IS NULL
OR CloudEvent.SecretId NOT IN REFERENCE_SET("Approved Secrets For Workload")
OR CloudEvent.SecretId IN REFERENCE_SET("Sensitive Secrets Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"cross_application_secret_access",
"unusual_secret_access"
)
)
AND (
CloudEvent.KmsKeyId IS NULL
OR CloudEvent.KmsKeyId NOT IN REFERENCE_SET("Approved KMS Keys For Workload")
OR CloudEvent.KmsKeyId IN REFERENCE_SET("Sensitive KMS Keys Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"unusual_kms_decrypt",
"sensitive_kms_key_use_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
CloudEvent.PrincipalArn,
CloudEvent.EventName,
CloudEvent.ResourceName,
CloudEvent.EventTime
)

Rule

AWS-Hosted ASP.NET Workload Suspicious Object Storage or Staging Activity After Web Compromise Indicators

Rule Format

AWS correlation rule suitable for CloudTrail, S3 data events, S3 server access logs where available, VPC Flow Logs, DNS logs, GuardDuty findings, endpoint telemetry, IIS process telemetry, file telemetry, AWS workload inventory, IAM role mappings, S3 bucket inventories, approved bucket inventories, approved object-prefix inventories, workload-to-bucket dependency maps, and SIEM correlation after data-event validation, bucket baseline validation, workload identity mapping, object-access baseline validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious S3 or object-storage activity by an AWS-hosted ASP.NET workload after web compromise indicators.

·        Identify possible payload staging, tool retrieval, fake component hosting, data staging, archive upload, exfiltration staging, or attacker use of object storage following suspicious ASP.NET / IIS activity.

·        Prioritize activity involving unusual buckets, newly accessed buckets, cross-application buckets, public buckets, object upload bursts, archive uploads, executable-like object access, unusual object download, or object-storage destinations outside approved workload dependencies.

·        Support escalation when S3 or object-storage activity follows suspicious web activity, IIS child-process execution, application-file modification, outbound communication, credential access, archive creation, or rare path access.

·        This rule does not prove ViewState exploitation, data theft, payload staging, AWS account compromise, or actor attribution without supporting web, endpoint, file, network, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side or web-side precursor activity from the AWS-hosted ASP.NET workload.

·        Correlate precursor activity with subsequent S3 data events, object access, object upload, object download, bucket enumeration, unusual bucket access, or object-storage network activity by the same workload role, instance profile, source workload, or application boundary.

·        Prioritize newly observed bucket access, cross-application bucket access, unusual object prefixes, archive uploads, executable-like object names, high-volume object reads, high-volume object writes, public-bucket interaction, external object-storage destinations, or activity outside approved deployment workflows.

·        Prioritize object access by workload roles that do not normally interact with S3 or by application roles accessing buckets outside their approved dependency map.

·        Increase confidence when object-storage activity follows archive creation, credential access, local discovery, file staging, suspicious egress, IIS child-process execution, application-file modification, or application-content tampering.

·        Increase confidence when S3 activity aligns with GuardDuty findings, unusual IAM activity, KMS decrypt anomalies, newly observed destinations, or unusual DNS / VPC egress from the same workload.

·        Reduce severity for approved deployment artifact retrieval, application asset storage, logging buckets, backup buckets, monitoring buckets, patching repositories, business integrations, data pipelines, incident-response activity, and known application workflows.

·        Do not classify S3 activity as exploitation-related without upstream web, endpoint, file, identity, application, or workload-boundary evidence.

·        Do not treat S3 access, bucket novelty, object extension, archive transfer, high byte volume, or public bucket contact as compromise evidence by itself.

Required Telemetry

·        CloudTrail management events.

·        S3 data events for relevant buckets.

·        S3 server access logs where available.

·        VPC Flow Logs where available.

·        Route 53 Resolver query logs where available.

·        GuardDuty findings where available.

·        Security Hub findings where available.

·        IAM role mappings.

·        Instance profile mappings.

·        EC2 instance inventory.

·        Workload tag inventory.

·        ASP.NET application inventory.

·        Application-boundary mapping.

·        Approved bucket inventory.

·        Approved object-prefix inventory where available.

·        Approved workload-to-bucket dependency map.

·        Sensitive bucket inventory.

·        Sensitive object-prefix inventory.

·        Cross-application bucket access map.

·        Approved deployment artifact bucket inventory.

·        Approved backup bucket inventory.

·        Approved logging bucket inventory.

·        Approved monitoring bucket inventory.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-to-bucket dependency maps for each AWS-hosted ASP.NET application.

·        Build approved bucket, object-prefix, deployment artifact, backup, logging, monitoring, data pipeline, and business integration inventories.

·        Build sensitive bucket, sensitive prefix, and cross-application bucket access maps so access to approved but sensitive resources is not fully suppressed by simple allowlisting.

·        Build suspicious object-storage logic for newly observed bucket access, cross-application bucket access, public-bucket interaction, executable-like object access, archive upload, archive download, unusual object prefix, high-volume object access, and access outside approved workflow timing.

·        Build suspicious precursor logic from locked web, endpoint, file, network, and AWS rules, including abnormal ASP.NET request activity, IIS child-process execution, application-file modification, rare path access, credential access, archive creation, suspicious egress, secrets access, KMS activity, and SSM activity.

·        Preserve precursor-to-object-storage event-pair timing so each suspicious web, host, file, or identity event is correlated to the specific subsequent S3 or object-storage activity.

·        Use shorter correlation windows when suspicious host activity is followed quickly by S3 object retrieval, object upload, bucket enumeration, or payload-like staging.

·        Use moderate correlation windows when object-storage activity follows archive creation, credential access, local discovery, suspicious egress, or file staging.

·        Use longer correlation windows for delayed staging, delayed exfiltration preparation, repeated low-volume object access, or delayed operator activity.

·        Add severity weighting for internet-facing exposure, sensitive bucket access, cross-application bucket access, unusual workload role, first-seen bucket access, archive upload, executable-like object access, KMS decrypt alignment, GuardDuty alignment, and supporting host or network evidence.

·        Use deployment records, backup schedules, data pipeline schedules, application-owner validation, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until S3 data-event coverage, workload-to-bucket mapping, bucket baselines, prefix baselines, sensitive-resource maps, workload identity mapping, exception logic, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to suspicious object-storage activity after AWS-hosted workload compromise indicators.

·        The rule remains useful if an adversary changes object names, bucket names, staging timing, destination infrastructure, web shell family, or payload format.

·        The score is supported by the durability of post-compromise object-storage use for payload staging, archive movement, tooling retrieval, or data staging.

·        The score is constrained by legitimate S3-backed application workflows, deployment artifacts, backup processes, logging pipelines, data pipelines, and incomplete S3 data-event coverage.

·        The rule is durable as a cloud-side staging and exposure detector but should not be treated as standalone proof of exploitation or data theft.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on S3 data-event coverage, CloudTrail coverage, workload identity mapping, approved bucket inventories, workload-to-bucket dependency maps, endpoint telemetry, sensitive-resource mapping, and precursor quality.

·        Operational confidence is reduced where applications normally use S3 for content delivery, deployment artifacts, backups, logs, static assets, or data pipelines.

·        Operational confidence is reduced where bucket and prefix baselines are incomplete.

·        Full-telemetry confidence improves when S3 activity is enriched with IIS logs, endpoint telemetry, file telemetry, VPC Flow Logs, DNS logs, GuardDuty findings, KMS events, IAM events, and change-control records.

·        Under full telemetry conditions, this rule provides useful escalation evidence for possible staging or data movement after workload compromise, but confirmed exploitation or data theft still requires corroborating web, endpoint, file, identity, application, or incident-response evidence.

Limitations

·        This rule detects suspicious object-storage activity after suspicious host or web behavior, not confirmed exploitation or data theft by itself.

·        Many AWS-hosted applications legitimately use S3 for content, deployment artifacts, backups, logs, static assets, and business workflows.

·        Missing S3 data events may prevent object-level visibility.

·        Missing workload-to-bucket dependency mapping may reduce confidence.

·        Missing sensitive bucket, sensitive prefix, and cross-application access maps may cause over-suppression or under-detection.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and S3 activity.

·        The rule may miss attackers who avoid S3, use approved buckets, use approved object prefixes, or operate only through local application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS-hosted ASP.NET suspicious web or host activity followed by suspicious S3 or object-storage activity query pattern requiring CloudTrail validation, S3 data-event validation, workload identity mapping, workload-to-bucket dependency mapping, object-prefix baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, instance IDs, instance profile mappings, principal-to-workload mappings, workload-to-bucket dependency maps, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AWS CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By S3 Or Object Storage Activity

WHEN PrecursorEvent.Source IN (
"AWS WAF",
"Application Load Balancer",
"IIS",
"EDR Process",
"EDR File",
"SIEM Correlation",
"Endpoint Detection"
)
AND PrecursorEvent.EventPattern IN (
"Suspicious ASP.NET Request Activity",
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_PRECURSOR_TO_OBJECT_STORAGE_WINDOW BY ObjectStorageEvent
WHERE ObjectStorageEvent.Source IN (
"CloudTrail",
"S3 Data Events",
"S3 Server Access Logs",
"VPC Flow Logs",
"DNS Logs"
)
AND CORRELATION_KEY(
PrecursorEvent.InstanceId,
PrecursorEvent.ApplicationBoundary,
PrecursorEvent.InstanceProfileArn,
ObjectStorageEvent.PrincipalArn,
ObjectStorageEvent.SourceInstanceId,
ObjectStorageEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AWS_WORKLOAD_ROLE_OR_APPLICATION_BOUNDARY
AND (
ObjectStorageEvent.EventName IN (
"GetObject",
"PutObject",
"ListBucket",
"CopyObject",
"CreateMultipartUpload",
"CompleteMultipartUpload"
)
OR ObjectStorageEvent.EventPattern IN (
"newly_observed_bucket_access",
"cross_application_bucket_access",
"public_bucket_interaction",
"archive_upload",
"executable_like_object_access",
"high_volume_object_read",
"high_volume_object_write",
"unusual_object_prefix",
"sensitive_bucket_access_after_host_precursor",
"sensitive_prefix_access_after_host_precursor"
)
)
AND (
ObjectStorageEvent.BucketName IS NULL
OR ObjectStorageEvent.BucketName NOT IN REFERENCE_SET("Approved Buckets For Workload")
OR ObjectStorageEvent.BucketName IN REFERENCE_SET("Sensitive Buckets Requiring Host-Precursor Review")
OR ObjectStorageEvent.EventPattern IN (
"newly_observed_bucket_access",
"cross_application_bucket_access",
"public_bucket_interaction",
"sensitive_bucket_access_after_host_precursor"
)
)
AND (
ObjectStorageEvent.ObjectPrefix IS NULL
OR ObjectStorageEvent.ObjectPrefix NOT IN REFERENCE_SET("Approved Object Prefixes For Workload")
OR ObjectStorageEvent.ObjectPrefix IN REFERENCE_SET("Sensitive Object Prefixes Requiring Host-Precursor Review")
OR ObjectStorageEvent.EventPattern IN (
"archive_upload",
"executable_like_object_access",
"high_volume_object_read",
"high_volume_object_write",
"unusual_object_prefix",
"sensitive_prefix_access_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
ObjectStorageEvent.PrincipalArn,
ObjectStorageEvent.BucketName,
ObjectStorageEvent.EventName,
ObjectStorageEvent.EventTime
)

Azure

Detection Viability Assessment

Azure has three rules for this EXP report.

·        Azure is viable when the affected ASP.NET / IIS workload is hosted in Azure infrastructure, including Azure Virtual Machines, Azure App Service for Windows, Azure Kubernetes Service Windows nodes, Azure Front Door, Application Gateway, Azure Web Application Firewall, Azure Load Balancer, or Azure-hosted application infrastructure that emits control-plane, network, identity, storage, and workload-adjacent telemetry.

·        Azure is strongest where Azure WAF logs, Application Gateway logs, Front Door logs, Azure Activity Logs, Microsoft Entra ID sign-in and audit logs, managed identity sign-in logs, Defender for Cloud alerts, NSG Flow Logs, Azure Firewall logs, Private DNS logs where available, Key Vault logs, Storage Account logs, workload tags, and endpoint telemetry can be correlated with IIS, endpoint, file, and application telemetry.

·        Azure can support detection of suspicious workload egress, managed identity use, Key Vault access, storage account activity, run-command activity, control-plane activity, and cloud-side follow-on behavior after suspicious ASP.NET request activity, IIS process execution, application-file modification, rare path access, or confirmed affected workload context.

·        Azure is not a standalone source for confirming ASP.NET ViewState deserialization, shared machineKey exploitation, KnowledgeDeliver exploitation, or web shell deployment unless Azure-side activity is correlated to web, endpoint, file, application, identity, and workload evidence.

·        Azure cloud-only anomalies must not be attributed to this exploitation path without upstream exposure correlation, such as suspicious ASP.NET request activity, IIS worker-process execution, application-file modification, rare path access, or confirmed affected workload identity.

·        Azure rules must be validated against tenant structure, subscription structure, resource group structure, virtual network topology, workload tags, Application Gateway / WAF logging, Front Door logging, Activity Log coverage, NSG Flow Log coverage, Azure Firewall coverage, DNS coverage, Defender for Cloud coverage, Key Vault logging, Storage Account logging, managed identity baselines, VM run-command baselines, workload identity mappings, NAT / firewall attribution, and incident-response workflows before production deployment.

·        Azure detection content should be treated as cloud-side correlation coverage for Azure-hosted ASP.NET / IIS workloads, not direct proof of ViewState exploitation, web shell deployment, Azure tenant compromise, data theft, or actor attribution.

Rule

Azure-Hosted ASP.NET Workload Suspicious Request Followed by Unusual Server Egress

Rule Format

Azure correlation rule suitable for Azure WAF logs, Application Gateway access logs, Azure Front Door logs, Azure Firewall logs, NSG Flow Logs, Load Balancer context, Defender for Cloud alerts, VM inventory, workload tags, IIS server mappings, backend pool mappings, NAT gateway mappings, endpoint network telemetry, proxy logs where available, and SIEM correlation after log-source validation, workload-boundary mapping, NAT attribution validation, field normalization, egress-baseline validation, approved-destination validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from Azure-hosted ASP.NET / IIS workloads after abnormal ASP.NET request activity, suspicious request patterns, rare path access, or workload-adjacent web anomalies.

·        Identify possible payload retrieval, callback behavior, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact from an affected Azure-hosted workload.

·        Prioritize internet-facing ASP.NET applications behind Azure WAF, Application Gateway, Azure Front Door, reverse proxy layers, or Azure VM-hosted IIS workloads.

·        Support escalation when suspicious Azure-side egress aligns with IIS worker-process execution, application-file modification, rare path access, endpoint detections, application errors, or suspicious file activity.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, Azure tenant compromise, or actor attribution without supporting web, endpoint, file, application, identity, or incident-response evidence.

Detection Logic

·        Identify abnormal ASP.NET web activity in Azure WAF logs, Application Gateway logs, Front Door logs, reverse proxy logs, or mapped IIS web logs.

·        Prioritize POST requests to ViewState-bearing, authentication-adjacent, upload, administrative-adjacent, LMS, vendor-portal, or state-bearing application paths.

·        Prioritize abnormal web behavior involving large request bodies, repeated request variation, error-to-success patterns, HTTP 500-series bursts, sparse targeted requests, unusual user agents, rare source ASNs, suspicious hosting-provider sources, anonymization infrastructure, or WAF anomaly context.

·        Correlate suspicious web activity to outbound communication from the same Azure workload boundary, backend pool target, VM, VM Scale Set instance, App Service instance, AKS Windows node, NAT source, firewall source, or enriched application boundary.

·        Prioritize outbound communication to newly observed destinations, rare destinations, direct-IP destinations, dynamic DNS destinations, low-reputation destinations, unusual ports, uncommon protocols, rare TLS SNI values, unusual HTTP hosts, developer platforms, object-storage endpoints, file-transfer services, or destinations outside approved workload dependencies.

·        Increase confidence when outbound communication is process-linked to IIS worker processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities through endpoint telemetry.

·        Increase confidence when outbound communication follows suspicious IIS child-process execution, application-file modification, webroot tampering, rare path access, credential access, archive creation, local discovery, defense evasion, or application-content tampering.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, patching repositories, deployment systems, update services, business integrations, managed hosting dependencies, administrative automation, and incident-response infrastructure.

·        Do not classify Azure egress anomalies as exploitation-related without upstream web, endpoint, file, application, or workload-boundary evidence.

·        Do not treat NAT egress, destination novelty, direct-IP communication, unusual ports, Defender for Cloud network alerts, or cloud-hosted destinations as compromise evidence by itself.

Required Telemetry

·        Azure WAF logs where available.

·        Application Gateway access logs where available.

·        Azure Front Door logs where applicable.

·        Azure Firewall logs where available.

·        NSG Flow Logs.

·        Defender for Cloud alerts where available.

·        VM inventory.

·        VM Scale Set mappings where applicable.

·        Backend pool mappings.

·        Load balancer mappings where applicable.

·        NAT gateway mappings where applicable.

·        App Service instance mapping where applicable.

·        AKS Windows node mappings where applicable.

·        Workload tag inventory.

·        Application-boundary mapping.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring destination inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        Endpoint process-to-network telemetry where available.

·        IIS process telemetry where available.

·        IIS web logs where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-boundary mappings that connect Azure WAF policies, Application Gateway listeners, backend pools, Front Door routing, VMs, VM Scale Sets, App Service instances, AKS Windows nodes, NAT gateways, Azure Firewall sources, IIS servers, workload tags, and application names.

·        Build approved destination inventories for Azure services, vendor services, monitoring platforms, backup systems, patching systems, deployment platforms, update repositories, business integrations, and incident-response infrastructure.

·        Build suspicious destination logic for newly observed destinations, rare destinations, direct-IP communication, dynamic DNS, low-reputation destinations, uncommon ports, rare TLS context, unusual HTTP hosts, developer platforms, file-transfer services, object-storage endpoints, and destinations outside approved dependencies.

·        Normalize WAF, Application Gateway, Front Door, NSG Flow Log, Azure Firewall, Defender for Cloud, endpoint, and IIS fields so events can be correlated by workload boundary instead of raw source IP alone.

·        Use VM resource ID, private IP, backend pool, workload tag, VM Scale Set instance, App Service instance, AKS node, NAT mapping, Azure Firewall mapping, and application-boundary enrichment where available.

·        Preserve web-to-egress event-pair timing so each suspicious web event is correlated to the specific subsequent outbound event or destination cluster.

·        Use shorter correlation windows when suspicious web activity is followed quickly by DNS lookup, direct-IP communication, rare destination access, payload retrieval, or callback-like behavior.

·        Use moderate correlation windows when outbound activity follows IIS process execution, application-file modification, rare path access, archive creation, credential access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, staged payload retrieval, delayed operator return, repeated low-volume communication, or low-and-slow post-exploitation behavior.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, WAF anomaly context, abnormal POST behavior, backend pool mapping confidence, destination rarity, direct-IP egress, unusual port use, process-linked egress, and supporting host or file evidence.

·        Use approved destination inventories, Azure service dependency maps, deployment records, monitoring records, backup records, change records, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until logging coverage, workload-boundary mapping, NAT attribution, destination baselines, approved-destination inventories, event-pair correlation quality, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious web-to-egress correlation from Azure-hosted ASP.NET workloads rather than static exploit strings, payload syntax, machineKey material, web shell filenames, or known infrastructure.

·        The rule remains useful if an adversary changes request syntax, destination domain, destination IP, callback timing, payload staging method, web shell family, or post-exploitation toolset.

·        The score is supported by the durability of suspicious outbound communication after abnormal web activity when workload-boundary mapping is reliable.

·        The score is constrained by NAT aggregation, shared egress, incomplete process-to-network mapping, broad approved dependencies, weak destination baselines, and incomplete Azure-to-IIS workload mapping.

·        The rule is durable as a cloud-side post-exploitation correlation but should not be treated as standalone proof of exploitation.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Azure WAF logs, Application Gateway logs, Front Door logs, NSG Flow Logs, Azure Firewall logs, endpoint process-to-network mapping, workload-boundary mapping, approved destination inventories, and IIS / ASP.NET telemetry.

·        Operational confidence is reduced where NAT gateways, shared egress, load balancers, proxies, CDNs, or managed hosting layers obscure workload attribution.

·        Operational confidence is reduced where NSG Flow Logs lack process context or DNS logs cannot be tied to the affected workload.

·        Full-telemetry confidence improves when Azure-side egress is enriched with IIS logs, endpoint telemetry, file telemetry, Defender for Cloud alerts, destination reputation, workload tags, application ownership, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for Azure-hosted workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET web activity, not confirmed exploitation by itself.

·        NAT gateways, shared egress paths, proxies, CDNs, load balancers, and hosted infrastructure may make workload attribution difficult.

·        Legitimate vendor services, monitoring systems, backup jobs, deployment automation, patching workflows, update repositories, and business integrations may produce similar outbound patterns.

·        NSG Flow Logs do not provide process-level attribution by themselves.

·        Missing DNS telemetry may reduce destination-context confidence.

·        Missing endpoint telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        The rule may miss attackers who avoid outbound communication, use approved destinations, operate fully in-process, or complete objectives through local application manipulation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure-hosted ASP.NET suspicious request followed by unusual workload egress query pattern requiring Azure log-source validation, WAF / Application Gateway / Front Door parsing validation, NSG Flow Log validation, Azure Firewall validation, workload-boundary mapping, NAT attribution validation, destination-baseline validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM resource IDs, private IP mappings, backend pool mappings, NAT attribution, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AZURE CORRELATION RULE: Suspicious ASP.NET Request Followed By Azure Workload Egress

WHEN WebEvent.Source IN (
"Azure WAF",
"Application Gateway",
"Azure Front Door",
"IIS"
)
AND WebEvent.HTTPMethod = "POST"
AND WebEvent.URLPath IN REFERENCE_SET(
"ViewState Bearing ASP.NET Paths",
"ASP.NET Authentication Adjacent Paths",
"ASP.NET Administrative Adjacent Paths",
"ASP.NET Upload Paths",
"ASP.NET LMS Workflow Paths"
)
AND (
WebEvent.RequestSize > REFERENCE_MAP_VALUE(
"ASP.NET Endpoint POST Size Baseline P95",
WebEvent.URLPath
)
OR WebEvent.StatusCode IN (500, 502, 503)
OR WebEvent.EventPattern IN (
"error_then_success",
"repeated_request_variation",
"sparse_targeted_requests",
"abnormal_request_cadence",
"suspicious_allowed_web_activity",
"waf_anomaly_context"
)
OR WebEvent.SourceIP IN REFERENCE_SET("Rare Sources For Application")
OR WebEvent.SourceASN IN REFERENCE_SET("Rare Or Suspicious Source ASNs")
)
FOLLOWED WITHIN ENV_ASPNET_REQUEST_TO_EGRESS_WINDOW BY NetworkEvent
WHERE NetworkEvent.Source IN (
"NSG Flow Logs",
"Azure Firewall",
"Endpoint Network",
"Proxy",
"Firewall"
)
AND CORRELATION_KEY(
WebEvent.BackendPool,
WebEvent.BackendResourceId,
WebEvent.ApplicationBoundary,
NetworkEvent.ResourceId,
NetworkEvent.PrivateIP,
NetworkEvent.NATMapping,
NetworkEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AZURE_WORKLOAD_OR_APPLICATION_BOUNDARY
AND (
NetworkEvent.DestinationDomain IN REFERENCE_SET("Newly Observed Destinations")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Rare Destinations For Workload")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Low Reputation Destinations")
OR NetworkEvent.DestinationIP IN REFERENCE_SET("Direct IP Or Unapproved Destinations")
OR NetworkEvent.DestinationPort IN REFERENCE_SET("Uncommon IIS Egress Ports")
OR NetworkEvent.DNSQuery IN REFERENCE_SET("Dynamic DNS Or Rare DNS Patterns")
OR NetworkEvent.ProcessName IN REFERENCE_SET("Suspicious IIS Network Processes")
)
AND (
NetworkEvent.DestinationDomain IS NULL
OR NetworkEvent.DestinationDomain NOT IN REFERENCE_SET("Approved Azure Workload Destinations")
)
AND (
NetworkEvent.DestinationIP IS NULL
OR NetworkEvent.DestinationIP NOT IN REFERENCE_SET("Approved Azure Workload Destination IPs")
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
NetworkEvent.ResourceId,
NetworkEvent.ProcessName,
COALESCE(NetworkEvent.DestinationDomain, NetworkEvent.DestinationIP),
NetworkEvent.EventTime
)

Rule

Azure-Hosted ASP.NET Workload Follow-On Key Vault or Managed Identity Activity After Suspicious Host Activity

Rule Format

Azure correlation rule suitable for Azure Activity Logs, Microsoft Entra ID audit logs, Microsoft Entra ID sign-in logs, managed identity sign-in logs, Key Vault diagnostic logs, Defender for Cloud alerts, VM run-command events, VM extension events, endpoint telemetry, IIS process telemetry, application-file telemetry, workload identity context, managed identity mappings, and SIEM correlation after Activity Log validation, identity mapping, role-to-resource validation, API baseline validation, Key Vault baseline validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious access to Azure managed identities, Key Vault secrets, Key Vault keys, VM run-command functions, VM extension operations, role assignments, or Azure control-plane activity after suspicious ASP.NET / IIS host activity.

·        Identify possible cloud-side expansion after server-side execution, web shell interaction, application compromise, or post-exploitation behavior on an Azure-hosted ASP.NET workload.

·        Prioritize activity involving affected VM managed identities, App Service managed identities, workload identities, Key Vault secret retrieval, unusual key use, VM run-command execution, role assignment changes, or control-plane actions following suspicious web or host behavior.

·        Support escalation when cloud credential, Key Vault, managed identity, or control-plane activity follows IIS child-process execution, suspicious command lines, application-file modification, outbound communication, rare path access, or abnormal ASP.NET request activity.

·        This rule does not prove ViewState exploitation, Azure tenant compromise, credential theft, privilege escalation, or actor attribution without supporting web, endpoint, file, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side context from an Azure-hosted ASP.NET workload, including IIS worker-process child execution, suspicious command lines, webroot modification, application-file modification, rare path access, abnormal ViewState-bearing POST activity, credential access, archive creation, local discovery, defense evasion, or outbound communication.

·        Correlate suspicious host-side context to subsequent Key Vault secret retrieval, Key Vault key operation, managed identity sign-in, token acquisition, role assignment activity, VM run-command activity, extension execution, or Azure Activity Log operation from the same workload boundary.

·        Prioritize managed identity activity that is new for the workload, rare for the resource, rare for the application role, outside normal deployment windows, associated with suspicious process context, or followed by unusual Azure API activity.

·        Prioritize Key Vault activity involving unusual secret names, unusual calling principals, unusual source workload, first-seen access, cross-application access, unexpected burst access, access outside approved application behavior, or access to sensitive secrets outside the workload’s normal dependency map.

·        Prioritize key activity involving unusual decrypt, unwrap, sign, or key-use volume, unusual calling identity, unusual source service, or key operations tied to secrets or data stores not normally accessed by the workload.

·        Prioritize VM run-command or extension activity involving unexpected command execution, unusual operator identity, unexpected source workload, or use outside maintenance windows.

·        Increase confidence when suspicious cloud-side activity follows IIS child-process execution, application-file modification, rare path access, web-to-egress correlation, endpoint credential-access detections, or application errors.

·        Reduce severity for approved deployment automation, patching workflows, backup operations, monitoring tools, break-glass activity, incident response, maintenance windows, and expected application secret retrieval.

·        Do not classify managed identity activity, Key Vault access, role activity, run-command activity, extension execution, or control-plane operations as exploitation-related without upstream web, host, file, application, or workload-boundary evidence.

·        Do not treat normal application Key Vault access as compromise evidence without unusual caller, unusual timing, unusual volume, unusual resource scope, or suspicious host-side context.

Required Telemetry

·        Azure Activity Logs.

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID sign-in logs.

·        Managed identity sign-in logs where available.

·        Key Vault diagnostic logs.

·        Key Vault secret access logs.

·        Key Vault key operation logs.

·        Defender for Cloud alerts where available.

·        VM run-command activity.

·        VM extension activity.

·        Azure Resource Manager operation logs.

·        VM inventory.

·        App Service inventory where applicable.

·        VM Scale Set mappings where applicable.

·        Managed identity mappings.

·        Role assignment mappings.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Workload tag inventory.

·        Application-boundary mapping.

·        Approved Key Vault access baselines.

·        Approved key-use baselines.

·        Approved managed identity baselines.

·        Approved run-command baselines.

·        Approved deployment identity inventory.

·        Approved break-glass identity inventory.

·        Sensitive secret inventory.

·        Sensitive key inventory.

·        Cross-application secret access map.

·        Maintenance-window records.

·        Change-control records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build mappings from VM resource IDs, App Service instances, managed identities, role assignments, application names, workload tags, backend pools, VM Scale Sets, AKS Windows nodes, and ASP.NET applications to normalized workload boundaries.

·        Build approved baselines for Key Vault access, key operations, managed identity activity, VM run-command activity, extension execution, role activity, and deployment automation for each Azure-hosted ASP.NET workload.

·        Build sensitive secret, sensitive key, and cross-application access maps so unusual access to sensitive approved resources is not fully suppressed by simple allowlisting.

·        Build suspicious host-side precursor logic from locked endpoint and SIEM rules, including IIS child-process execution, application-file modification, suspicious web activity, rare path access, outbound communication, credential access, archive creation, and defense-evasion behavior.

·        Preserve host-to-cloud event-pair timing so each suspicious host precursor is correlated to the specific subsequent Key Vault, managed identity, role, run-command, extension, or Azure Activity Log event.

·        Use shorter correlation windows when suspicious host activity is followed quickly by managed identity activity, Key Vault access, key operation, or token activity.

·        Use moderate correlation windows when run-command activity, role activity, or unusual API activity follows host compromise indicators.

·        Use longer correlation windows for delayed credential use, delayed operator activity, staged cloud reconnaissance, or low-and-slow misuse of workload identities.

·        Add severity weighting for internet-facing exposure, application identity sensitivity, privileged managed identity, unusual Key Vault access, unusual key operation, unusual run-command use, first-seen identity behavior, cross-application access, sensitive-resource access, and supporting endpoint or network evidence.

·        Use deployment records, maintenance windows, expected application startup behavior, expected secret-rotation behavior, backup workflows, monitoring workflows, and incident-response activity as triage evidence.

·        Do not enable high-severity alerting until Activity Log coverage, Key Vault diagnostic coverage, event timing, workload identity mapping, role-to-resource mapping, Key Vault baselines, managed identity baselines, run-command baselines, sensitive-resource maps, exception logic, false-positive baselines, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to cloud-side managed identity, Key Vault, role, run-command, extension, or control-plane activity after suspicious Azure-hosted workload behavior.

·        The rule remains useful if an adversary changes web shell family, command syntax, payload staging method, destination infrastructure, credential-access timing, or cloud API usage timing.

·        The score is supported by the durability of post-exploitation attempts to access managed identities, Key Vault secrets, keys, run-command functions, or Azure APIs from compromised workloads.

·        The score is constrained by normal application Key Vault retrieval, deployment automation, monitoring tools, patching workflows, backup operations, and incomplete workload identity mapping.

·        The rule is durable as a cloud-side escalation detector but should not be treated as standalone proof of ViewState exploitation or Azure tenant compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Activity Log coverage, Key Vault diagnostic logging, workload identity mapping, managed identity mapping, endpoint telemetry, Key Vault baselines, key-use baselines, run-command baselines, managed identity baselines, and host-side precursor quality.

·        Operational confidence is reduced where normal application behavior includes frequent Key Vault retrieval, key operations, managed identity activity, run-command automation, or recurring control-plane activity.

·        Operational confidence is reduced where role-to-resource mapping, tag hygiene, Activity Log coverage, sensitive-resource mapping, or endpoint telemetry is incomplete.

·        Full-telemetry confidence improves when suspicious cloud-side events are enriched with IIS logs, endpoint telemetry, file telemetry, WAF logs, Application Gateway logs, NSG Flow Logs, Azure Firewall logs, Defender for Cloud alerts, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for possible cloud-side misuse after workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, identity, or incident-response evidence.

Limitations

·        This rule detects suspicious Azure managed identity, Key Vault, role, run-command, extension, or control-plane activity after suspicious host behavior, not confirmed exploitation by itself.

·        Normal application operation may involve Key Vault retrieval, key operations, managed identity activity, role use, and control-plane activity.

·        Deployment automation, backup jobs, monitoring agents, patching workflows, incident response, and maintenance activity may produce similar cloud-side behavior.

·        Missing Activity Log coverage or missing Key Vault diagnostic logging may reduce visibility.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and cloud API activity.

·        Missing workload-boundary mapping may prevent attribution to the affected ASP.NET application.

·        Simple allowlists can suppress meaningful activity if sensitive-resource maps, cross-application access maps, or unusual-volume logic are not maintained.

·        The rule may miss attackers who avoid cloud-side activity or use only already-approved application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure-hosted ASP.NET suspicious host activity followed by managed identity, Key Vault, role, run-command, extension, or control-plane activity query pattern requiring Activity Log validation, Key Vault diagnostic validation, workload identity mapping, managed identity mapping, role-to-resource mapping, baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM resource IDs, managed identity mappings, principal-to-workload mappings, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AZURE CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By Azure Managed Identity Or Key Vault Access

WHEN HostEvent.Source IN (
"EDR Process",
"EDR File",
"IIS",
"SIEM Correlation",
"Endpoint Detection"
)
AND HostEvent.EventPattern IN (
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious ASP.NET Request Activity",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_HOST_TO_AZURE_API_WINDOW BY CloudEvent
WHERE CloudEvent.Source IN (
"Azure Activity Logs",
"Microsoft Entra ID",
"Managed Identity Sign-In Logs",
"Key Vault Diagnostic Logs",
"Defender For Cloud"
)
AND CORRELATION_KEY(
HostEvent.ResourceId,
HostEvent.PrivateIP,
HostEvent.ApplicationBoundary,
CloudEvent.ResourceId,
CloudEvent.PrincipalId,
CloudEvent.ManagedIdentityId,
CloudEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AZURE_WORKLOAD_IDENTITY_OR_APPLICATION_BOUNDARY
AND (
CloudEvent.EventName IN (
"SecretGet",
"KeyDecrypt",
"KeyUnwrap",
"KeySign",
"VirtualMachinesRunCommandAction",
"RunCommand",
"RoleAssignmentWrite",
"GetToken",
"ManagedIdentitySignIn"
)
OR CloudEvent.EventPattern IN (
"managed_identity_token_access",
"unusual_managed_identity_use",
"unusual_key_vault_secret_access",
"unusual_key_operation",
"unexpected_run_command_activity",
"first_seen_identity_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_key_use_after_host_precursor"
)
)
AND (
CloudEvent.PrincipalId IS NULL
OR CloudEvent.PrincipalId NOT IN REFERENCE_SET("Approved Deployment Or Automation Principals")
OR CloudEvent.EventPattern IN (
"first_seen_identity_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_key_use_after_host_precursor"
)
)
AND (
CloudEvent.SecretId IS NULL
OR CloudEvent.SecretId NOT IN REFERENCE_SET("Approved Key Vault Secrets For Workload")
OR CloudEvent.SecretId IN REFERENCE_SET("Sensitive Secrets Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"cross_application_secret_access",
"unusual_key_vault_secret_access"
)
)
AND (
CloudEvent.KeyId IS NULL
OR CloudEvent.KeyId NOT IN REFERENCE_SET("Approved Key Vault Keys For Workload")
OR CloudEvent.KeyId IN REFERENCE_SET("Sensitive Keys Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"unusual_key_operation",
"sensitive_key_use_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
CloudEvent.PrincipalId,
CloudEvent.EventName,
CloudEvent.ResourceName,
CloudEvent.EventTime
)

Rule

Azure-Hosted ASP.NET Workload Suspicious Storage or Staging Activity After Web Compromise Indicators

Rule Format

Azure correlation rule suitable for Azure Activity Logs, Storage Account diagnostic logs, Blob Storage logs, Azure Firewall logs, NSG Flow Logs, Defender for Cloud alerts, endpoint telemetry, IIS process telemetry, file telemetry, Azure workload inventory, managed identity mappings, storage account inventories, approved container inventories, approved blob-prefix inventories, workload-to-storage dependency maps, and SIEM correlation after storage diagnostic validation, container baseline validation, workload identity mapping, object-access baseline validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Azure Storage or object-storage activity by an Azure-hosted ASP.NET workload after web compromise indicators.

·        Identify possible payload staging, tool retrieval, fake component hosting, data staging, archive upload, exfiltration staging, or attacker use of object storage following suspicious ASP.NET / IIS activity.

·        Prioritize activity involving unusual storage accounts, newly accessed containers, cross-application containers, public containers, blob upload bursts, archive uploads, executable-like object access, unusual blob download, or object-storage destinations outside approved workload dependencies.

·        Support escalation when Azure Storage activity follows suspicious web activity, IIS child-process execution, application-file modification, outbound communication, credential access, archive creation, or rare path access.

·        This rule does not prove ViewState exploitation, data theft, payload staging, Azure tenant compromise, or actor attribution without supporting web, endpoint, file, network, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side or web-side precursor activity from the Azure-hosted ASP.NET workload.

·        Correlate precursor activity with subsequent Azure Storage logs, Blob Storage access, blob upload, blob download, container enumeration, unusual storage account access, or object-storage network activity by the same workload identity, managed identity, source workload, or application boundary.

·        Prioritize newly observed storage account access, cross-application container access, unusual blob prefixes, archive uploads, executable-like blob names, high-volume blob reads, high-volume blob writes, public-container interaction, external object-storage destinations, or activity outside approved deployment workflows.

·        Prioritize object access by workload identities that do not normally interact with Azure Storage or by application identities accessing containers outside their approved dependency map.

·        Increase confidence when storage activity follows archive creation, credential access, local discovery, file staging, suspicious egress, IIS child-process execution, application-file modification, or application-content tampering.

·        Increase confidence when Azure Storage activity aligns with Defender for Cloud alerts, unusual managed identity activity, Key Vault anomalies, newly observed destinations, or unusual NSG / firewall egress from the same workload.

·        Reduce severity for approved deployment artifact retrieval, application asset storage, logging containers, backup containers, monitoring containers, patching repositories, business integrations, data pipelines, incident-response activity, and known application workflows.

·        Do not classify Azure Storage activity as exploitation-related without upstream web, endpoint, file, identity, application, or workload-boundary evidence.

·        Do not treat storage access, container novelty, object extension, archive transfer, high byte volume, or public container contact as compromise evidence by itself.

Required Telemetry

·        Azure Activity Logs.

·        Storage Account diagnostic logs.

·        Blob Storage logs.

·        Azure Firewall logs where available.

·        NSG Flow Logs where available.

·        Defender for Cloud alerts where available.

·        Microsoft Entra ID logs where applicable.

·        Managed identity mappings.

·        VM inventory.

·        App Service inventory where applicable.

·        VM Scale Set mappings where applicable.

·        Workload tag inventory.

·        ASP.NET application inventory.

·        Application-boundary mapping.

·        Approved storage account inventory.

·        Approved container inventory.

·        Approved blob-prefix inventory where available.

·        Approved workload-to-storage dependency map.

·        Sensitive storage account inventory.

·        Sensitive container inventory.

·        Sensitive blob-prefix inventory.

·        Cross-application container access map.

·        Approved deployment artifact container inventory.

·        Approved backup container inventory.

·        Approved logging container inventory.

·        Approved monitoring container inventory.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-to-storage dependency maps for each Azure-hosted ASP.NET application.

·        Build approved storage account, container, blob-prefix, deployment artifact, backup, logging, monitoring, data pipeline, and business integration inventories.

·        Build sensitive storage account, sensitive container, sensitive prefix, and cross-application container access maps so access to approved but sensitive resources is not fully suppressed by simple allowlisting.

·        Build suspicious object-storage logic for newly observed storage account access, cross-application container access, public-container interaction, executable-like object access, archive upload, archive download, unusual blob prefix, high-volume object access, and access outside approved workflow timing.

·        Build suspicious precursor logic from locked web, endpoint, file, network, and Azure rules, including abnormal ASP.NET request activity, IIS child-process execution, application-file modification, rare path access, credential access, archive creation, suspicious egress, Key Vault access, managed identity activity, and run-command activity.

·        Preserve precursor-to-storage event-pair timing so each suspicious web, host, file, or identity event is correlated to the specific subsequent Azure Storage activity.

·        Use shorter correlation windows when suspicious host activity is followed quickly by blob retrieval, blob upload, container enumeration, or payload-like staging.

·        Use moderate correlation windows when storage activity follows archive creation, credential access, local discovery, suspicious egress, or file staging.

·        Use longer correlation windows for delayed staging, delayed exfiltration preparation, repeated low-volume object access, or delayed operator activity.

·        Add severity weighting for internet-facing exposure, sensitive storage access, cross-application container access, unusual workload identity, first-seen storage access, archive upload, executable-like object access, Key Vault alignment, Defender for Cloud alignment, and supporting host or network evidence.

·        Use deployment records, backup schedules, data pipeline schedules, application-owner validation, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until Storage diagnostic coverage, workload-to-storage mapping, storage account baselines, container baselines, prefix baselines, sensitive-resource maps, workload identity mapping, exception logic, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to suspicious Azure Storage activity after Azure-hosted workload compromise indicators.

·        The rule remains useful if an adversary changes object names, container names, storage account names, staging timing, destination infrastructure, web shell family, or payload format.

·        The score is supported by the durability of post-compromise object-storage use for payload staging, archive movement, tooling retrieval, or data staging.

·        The score is constrained by legitimate Azure Storage-backed application workflows, deployment artifacts, backup processes, logging pipelines, data pipelines, and incomplete Storage diagnostic coverage.

·        The rule is durable as a cloud-side staging and exposure detector but should not be treated as standalone proof of exploitation or data theft.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on Storage diagnostic coverage, Activity Log coverage, workload identity mapping, approved storage inventories, workload-to-storage dependency maps, endpoint telemetry, sensitive-resource mapping, and precursor quality.

·        Operational confidence is reduced where applications normally use Azure Storage for content delivery, deployment artifacts, backups, logs, static assets, or data pipelines.

·        Operational confidence is reduced where storage account, container, and prefix baselines are incomplete.

·        Full-telemetry confidence improves when Azure Storage activity is enriched with IIS logs, endpoint telemetry, file telemetry, NSG Flow Logs, Azure Firewall logs, Defender for Cloud alerts, Key Vault events, identity events, and change-control records.

·        Under full telemetry conditions, this rule provides useful escalation evidence for possible staging or data movement after workload compromise, but confirmed exploitation or data theft still requires corroborating web, endpoint, file, identity, application, or incident-response evidence.

Limitations

·        This rule detects suspicious object-storage activity after suspicious host or web behavior, not confirmed exploitation or data theft by itself.

·        Many Azure-hosted applications legitimately use Azure Storage for content, deployment artifacts, backups, logs, static assets, and business workflows.

·        Missing Storage diagnostic logs may prevent object-level visibility.

·        Missing workload-to-storage dependency mapping may reduce confidence.

·        Missing sensitive storage, sensitive container, sensitive prefix, and cross-application access maps may cause over-suppression or under-detection.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and Azure Storage activity.

·        The rule may miss attackers who avoid Azure Storage, use approved storage accounts, use approved blob prefixes, or operate only through local application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure-hosted ASP.NET suspicious web or host activity followed by suspicious Azure Storage activity query pattern requiring Activity Log validation, Storage diagnostic validation, workload identity mapping, workload-to-storage dependency mapping, object-prefix baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM resource IDs, managed identity mappings, principal-to-workload mappings, workload-to-storage dependency maps, workload tags, application-boundary mappings, reference maps, or SIEM correlation fields.

AZURE CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By Azure Storage Activity

WHEN PrecursorEvent.Source IN (
"Azure WAF",
"Application Gateway",
"Azure Front Door",
"IIS",
"EDR Process",
"EDR File",
"SIEM Correlation",
"Endpoint Detection"
)
AND PrecursorEvent.EventPattern IN (
"Suspicious ASP.NET Request Activity",
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_PRECURSOR_TO_AZURE_STORAGE_WINDOW BY StorageEvent
WHERE StorageEvent.Source IN (
"Azure Activity Logs",
"Storage Account Diagnostic Logs",
"Blob Storage Logs",
"Azure Firewall",
"NSG Flow Logs"
)
AND CORRELATION_KEY(
PrecursorEvent.ResourceId,
PrecursorEvent.ApplicationBoundary,
PrecursorEvent.ManagedIdentityId,
StorageEvent.PrincipalId,
StorageEvent.SourceResourceId,
StorageEvent.ApplicationBoundary
) IS SAME_NORMALIZED_AZURE_WORKLOAD_IDENTITY_OR_APPLICATION_BOUNDARY
AND (
StorageEvent.EventName IN (
"GetBlob",
"PutBlob",
"ListBlobs",
"CopyBlob",
"CreateContainer",
"SetBlobProperties"
)
OR StorageEvent.EventPattern IN (
"newly_observed_storage_access",
"cross_application_container_access",
"public_container_interaction",
"archive_upload",
"executable_like_object_access",
"high_volume_blob_read",
"high_volume_blob_write",
"unusual_blob_prefix",
"sensitive_storage_access_after_host_precursor",
"sensitive_prefix_access_after_host_precursor"
)
)
AND (
StorageEvent.StorageAccount IS NULL
OR StorageEvent.StorageAccount NOT IN REFERENCE_SET("Approved Storage Accounts For Workload")
OR StorageEvent.StorageAccount IN REFERENCE_SET("Sensitive Storage Accounts Requiring Host-Precursor Review")
OR StorageEvent.EventPattern IN (
"newly_observed_storage_access",
"cross_application_container_access",
"public_container_interaction",
"sensitive_storage_access_after_host_precursor"
)
)
AND (
StorageEvent.BlobPrefix IS NULL
OR StorageEvent.BlobPrefix NOT IN REFERENCE_SET("Approved Blob Prefixes For Workload")
OR StorageEvent.BlobPrefix IN REFERENCE_SET("Sensitive Blob Prefixes Requiring Host-Precursor Review")
OR StorageEvent.EventPattern IN (
"archive_upload",
"executable_like_object_access",
"high_volume_blob_read",
"high_volume_blob_write",
"unusual_blob_prefix",
"sensitive_prefix_access_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
StorageEvent.PrincipalId,
StorageEvent.StorageAccount,
StorageEvent.EventName,
StorageEvent.EventTime
)

GCP

Detection Viability Assessment

GCP has three rules for this EXP report.

·        GCP is viable when the affected ASP.NET / IIS workload is hosted in Google Cloud infrastructure, including Compute Engine Windows workloads, Google Kubernetes Engine Windows nodes, external HTTP(S) Load Balancing, Cloud Armor, Cloud CDN-to-backend routing, managed instance groups, or GCP-hosted application infrastructure that emits control-plane, network, identity, storage, and workload-adjacent telemetry.

·        GCP is strongest where Cloud Armor logs, Load Balancer logs, VPC Flow Logs, Cloud DNS logs where available, Cloud Audit Logs, Security Command Center findings, Compute Engine inventory, service account mappings, workload labels, Secret Manager logs, Cloud KMS logs, Cloud Storage data access logs, IAM activity, OS Login activity, and endpoint telemetry can be correlated with IIS, endpoint, file, and application telemetry.

·        GCP can support detection of suspicious workload egress, service account use, metadata access, Secret Manager access, Cloud KMS activity, Cloud Storage activity, IAM activity, OS Login activity, and cloud-side follow-on behavior after suspicious ASP.NET request activity, IIS process execution, application-file modification, rare path access, or confirmed affected workload context.

·        GCP is not a standalone source for confirming ASP.NET ViewState deserialization, shared machineKey exploitation, KnowledgeDeliver exploitation, or web shell deployment unless GCP-side activity is correlated to web, endpoint, file, application, identity, and workload evidence.

·        GCP cloud-only anomalies must not be attributed to this exploitation path without upstream exposure correlation, such as suspicious ASP.NET request activity, IIS worker-process execution, application-file modification, rare path access, or confirmed affected workload identity.

·        GCP rules must be validated against organization structure, folder structure, project structure, VPC topology, workload labels, Cloud Armor logging, Load Balancer logging, Cloud Audit Log coverage, VPC Flow Log coverage, Cloud NAT logging, firewall logging, DNS coverage, Security Command Center coverage, Secret Manager logging, Cloud KMS logging, Cloud Storage data access logging, service account baselines, OS Login baselines, workload identity mappings, NAT / firewall attribution, and incident-response workflows before production deployment.

·        GCP detection content should be treated as cloud-side correlation coverage for GCP-hosted ASP.NET / IIS workloads, not direct proof of ViewState exploitation, web shell deployment, GCP project compromise, data theft, or actor attribution.

Rule

GCP-Hosted ASP.NET Workload Suspicious Request Followed by Unusual Server Egress

Rule Format

GCP correlation rule suitable for Cloud Armor logs, HTTP(S) Load Balancer logs, Cloud CDN logs where applicable, VPC Flow Logs, Cloud DNS logs where available, Cloud NAT logs where available, firewall logs, Security Command Center findings, Compute Engine inventory, workload labels, IIS server mappings, backend service mappings, managed instance group mappings, endpoint network telemetry, proxy logs where available, and SIEM correlation after log-source validation, workload-boundary mapping, NAT attribution validation, field normalization, egress-baseline validation, approved-destination validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from GCP-hosted ASP.NET / IIS workloads after abnormal ASP.NET request activity, suspicious request patterns, rare path access, or workload-adjacent web anomalies.

·        Identify possible payload retrieval, callback behavior, external script retrieval, command-and-control-like communication, or post-exploitation infrastructure contact from an affected GCP-hosted workload.

·        Prioritize internet-facing ASP.NET applications behind Cloud Armor, external HTTP(S) Load Balancing, Cloud CDN-to-backend routing, reverse proxy layers, or Compute Engine-hosted IIS workloads.

·        Support escalation when suspicious GCP-side egress aligns with IIS worker-process execution, application-file modification, rare path access, endpoint detections, application errors, or suspicious file activity.

·        This rule does not prove ViewState exploitation, web shell deployment, Cobalt Strike delivery, data theft, GCP project compromise, or actor attribution without supporting web, endpoint, file, application, identity, or incident-response evidence.

Detection Logic

·        Identify abnormal ASP.NET web activity in Cloud Armor logs, HTTP(S) Load Balancer logs, Cloud CDN logs, reverse proxy logs, or mapped IIS web logs.

·        Prioritize POST requests to ViewState-bearing, authentication-adjacent, upload, administrative-adjacent, LMS, vendor-portal, or state-bearing application paths.

·        Prioritize abnormal web behavior involving large request bodies, repeated request variation, error-to-success patterns, HTTP 500-series bursts, sparse targeted requests, unusual user agents, rare source ASNs, suspicious hosting-provider sources, anonymization infrastructure, or Cloud Armor anomaly context.

·        Correlate suspicious web activity to outbound communication from the same GCP workload boundary, backend service, backend instance, Compute Engine VM, managed instance group member, GKE Windows node, Cloud NAT source, firewall source, or enriched application boundary.

·        Prioritize outbound communication to newly observed destinations, rare destinations, direct-IP destinations, dynamic DNS destinations, low-reputation destinations, unusual ports, uncommon protocols, rare TLS SNI values, unusual HTTP hosts, developer platforms, object-storage endpoints, file-transfer services, or destinations outside approved workload dependencies.

·        Increase confidence when outbound communication is process-linked to IIS worker processes, command shells, PowerShell, script interpreters, network utilities, or application pool identities through endpoint telemetry.

·        Increase confidence when outbound communication follows suspicious IIS child-process execution, application-file modification, webroot tampering, rare path access, credential access, archive creation, local discovery, defense evasion, or application-content tampering.

·        Reduce severity for approved vendor services, monitoring destinations, backup destinations, patching repositories, deployment systems, update services, business integrations, managed hosting dependencies, administrative automation, and incident-response infrastructure.

·        Do not classify GCP egress anomalies as exploitation-related without upstream web, endpoint, file, application, or workload-boundary evidence.

·        Do not treat NAT egress, destination novelty, direct-IP communication, unusual ports, Security Command Center network findings, or cloud-hosted destinations as compromise evidence by itself.

Required Telemetry

·        Cloud Armor logs where available.

·        HTTP(S) Load Balancer logs where available.

·        Cloud CDN logs where applicable.

·        VPC Flow Logs.

·        Cloud NAT logs where available.

·        Firewall logs where available.

·        Cloud DNS logs where available.

·        Security Command Center findings where available.

·        Compute Engine VM inventory.

·        Managed instance group mappings where applicable.

·        Backend service mappings.

·        Load balancer backend mappings.

·        Cloud NAT mappings where applicable.

·        GKE Windows node mappings where applicable.

·        Workload label inventory.

·        Application-boundary mapping.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Internet-facing exposure inventory.

·        Approved destination inventory.

·        Approved vendor service inventory.

·        Approved monitoring destination inventory.

·        Approved backup destination inventory.

·        Approved deployment destination inventory.

·        Approved update destination inventory.

·        Approved business integration inventory.

·        Destination first-seen enrichment where available.

·        Destination reputation enrichment where available.

·        Endpoint process-to-network telemetry where available.

·        IIS process telemetry where available.

·        IIS web logs where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-boundary mappings that connect Cloud Armor policies, HTTP(S) Load Balancer forwarding rules, backend services, backend instances, Compute Engine VMs, managed instance groups, GKE Windows nodes, Cloud NAT gateways, firewall sources, IIS servers, workload labels, and application names.

·        Build approved destination inventories for GCP services, vendor services, monitoring platforms, backup systems, patching systems, deployment platforms, update repositories, business integrations, and incident-response infrastructure.

·        Build suspicious destination logic for newly observed destinations, rare destinations, direct-IP communication, dynamic DNS, low-reputation destinations, uncommon ports, rare TLS context, unusual HTTP hosts, developer platforms, file-transfer services, object-storage endpoints, and destinations outside approved dependencies.

·        Normalize Cloud Armor, Load Balancer, Cloud CDN, VPC Flow Log, Cloud NAT, firewall, DNS, Security Command Center, endpoint, and IIS fields so events can be correlated by workload boundary instead of raw source IP alone.

·        Use VM instance ID, private IP, backend service, workload label, managed instance group, GKE node, NAT mapping, firewall mapping, and application-boundary enrichment where available.

·        Preserve web-to-egress event-pair timing so each suspicious web event is correlated to the specific subsequent outbound event or destination cluster.

·        Use shorter correlation windows when suspicious web activity is followed quickly by DNS lookup, direct-IP communication, rare destination access, payload retrieval, or callback-like behavior.

·        Use moderate correlation windows when outbound activity follows IIS process execution, application-file modification, rare path access, archive creation, credential access, or application-content tampering.

·        Use longer correlation windows for delayed callbacks, staged payload retrieval, delayed operator return, repeated low-volume communication, or low-and-slow post-exploitation behavior.

·        Add severity weighting for internet-facing exposure, authentication adjacency, LMS or portal exposure, Cloud Armor context, abnormal POST behavior, backend service mapping confidence, destination rarity, direct-IP egress, unusual port use, process-linked egress, and supporting host or file evidence.

·        Use approved destination inventories, GCP service dependency maps, deployment records, monitoring records, backup records, change records, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until logging coverage, workload-boundary mapping, NAT attribution, destination baselines, approved-destination inventories, event-pair correlation quality, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to suspicious web-to-egress correlation from GCP-hosted ASP.NET workloads rather than static exploit strings, payload syntax, machineKey material, web shell filenames, or known infrastructure.

·        The rule remains useful if an adversary changes request syntax, destination domain, destination IP, callback timing, payload staging method, web shell family, or post-exploitation toolset.

·        The score is supported by the durability of suspicious outbound communication after abnormal web activity when workload-boundary mapping is reliable.

·        The score is constrained by NAT aggregation, shared egress, incomplete process-to-network mapping, broad approved dependencies, weak destination baselines, and incomplete GCP-to-IIS workload mapping.

·        The rule is durable as a cloud-side post-exploitation correlation but should not be treated as standalone proof of exploitation.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Armor logs, Load Balancer logs, VPC Flow Logs, Cloud NAT logs, firewall logs, endpoint process-to-network mapping, workload-boundary mapping, approved destination inventories, and IIS / ASP.NET telemetry.

·        Operational confidence is reduced where Cloud NAT, shared egress, load balancers, proxies, CDNs, or managed hosting layers obscure workload attribution.

·        Operational confidence is reduced where VPC Flow Logs lack process context or DNS logs cannot be tied to the affected workload.

·        Full-telemetry confidence improves when GCP-side egress is enriched with IIS logs, endpoint telemetry, file telemetry, Security Command Center findings, destination reputation, workload labels, application ownership, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for GCP-hosted workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, or incident-response evidence.

Limitations

·        This rule detects suspicious outbound communication after suspicious ASP.NET web activity, not confirmed exploitation by itself.

·        Cloud NAT, shared egress paths, proxies, CDNs, load balancers, and hosted infrastructure may make workload attribution difficult.

·        Legitimate vendor services, monitoring systems, backup jobs, deployment automation, patching workflows, update repositories, and business integrations may produce similar outbound patterns.

·        VPC Flow Logs do not provide process-level attribution by themselves.

·        Missing DNS telemetry may reduce destination-context confidence.

·        Missing endpoint telemetry may prevent attribution to w3wp.exe, IIS child processes, command shells, script interpreters, or application pool identities.

·        The rule may miss attackers who avoid outbound communication, use approved destinations, operate fully in-process, or complete objectives through local application manipulation.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP-hosted ASP.NET suspicious request followed by unusual workload egress query pattern requiring GCP log-source validation, Cloud Armor / Load Balancer / Cloud CDN parsing validation, VPC Flow Log validation, Cloud NAT validation, firewall validation, workload-boundary mapping, NAT attribution validation, destination-baseline validation, approved-destination validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM instance IDs, private IP mappings, backend service mappings, NAT attribution, workload labels, application-boundary mappings, reference maps, or SIEM correlation fields.

GCP CORRELATION RULE: Suspicious ASP.NET Request Followed By GCP Workload Egress

WHEN WebEvent.Source IN (
"Cloud Armor",
"HTTP Load Balancer",
"Cloud CDN",
"IIS"
)
AND WebEvent.HTTPMethod = "POST"
AND WebEvent.URLPath IN REFERENCE_SET(
"ViewState Bearing ASP.NET Paths",
"ASP.NET Authentication Adjacent Paths",
"ASP.NET Administrative Adjacent Paths",
"ASP.NET Upload Paths",
"ASP.NET LMS Workflow Paths"
)
AND (
WebEvent.RequestSize > REFERENCE_MAP_VALUE(
"ASP.NET Endpoint POST Size Baseline P95",
WebEvent.URLPath
)
OR WebEvent.StatusCode IN (500, 502, 503)
OR WebEvent.EventPattern IN (
"error_then_success",
"repeated_request_variation",
"sparse_targeted_requests",
"abnormal_request_cadence",
"suspicious_allowed_web_activity",
"cloud_armor_anomaly_context"
)
OR WebEvent.SourceIP IN REFERENCE_SET("Rare Sources For Application")
OR WebEvent.SourceASN IN REFERENCE_SET("Rare Or Suspicious Source ASNs")
)
FOLLOWED WITHIN ENV_ASPNET_REQUEST_TO_EGRESS_WINDOW BY NetworkEvent
WHERE NetworkEvent.Source IN (
"VPC Flow Logs",
"Cloud NAT",
"Firewall Logs",
"Cloud DNS",
"Endpoint Network",
"Proxy"
)
AND CORRELATION_KEY(
WebEvent.BackendService,
WebEvent.BackendInstanceId,
WebEvent.ApplicationBoundary,
NetworkEvent.InstanceId,
NetworkEvent.PrivateIP,
NetworkEvent.NATMapping,
NetworkEvent.ApplicationBoundary
) IS SAME_NORMALIZED_GCP_WORKLOAD_OR_APPLICATION_BOUNDARY
AND (
NetworkEvent.DestinationDomain IN REFERENCE_SET("Newly Observed Destinations")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Rare Destinations For Workload")
OR NetworkEvent.DestinationDomain IN REFERENCE_SET("Low Reputation Destinations")
OR NetworkEvent.DestinationIP IN REFERENCE_SET("Direct IP Or Unapproved Destinations")
OR NetworkEvent.DestinationPort IN REFERENCE_SET("Uncommon IIS Egress Ports")
OR NetworkEvent.DNSQuery IN REFERENCE_SET("Dynamic DNS Or Rare DNS Patterns")
OR NetworkEvent.ProcessName IN REFERENCE_SET("Suspicious IIS Network Processes")
)
AND (
NetworkEvent.DestinationDomain IS NULL
OR NetworkEvent.DestinationDomain NOT IN REFERENCE_SET("Approved GCP Workload Destinations")
)
AND (
NetworkEvent.DestinationIP IS NULL
OR NetworkEvent.DestinationIP NOT IN REFERENCE_SET("Approved GCP Workload Destination IPs")
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
NetworkEvent.InstanceId,
NetworkEvent.ProcessName,
COALESCE(NetworkEvent.DestinationDomain, NetworkEvent.DestinationIP),
NetworkEvent.EventTime
)

Rule

GCP-Hosted ASP.NET Workload Follow-On Secret Manager, Service Account, or Cloud KMS Activity After Suspicious Host Activity

Rule Format

GCP correlation rule suitable for Cloud Audit Logs, IAM audit logs, service account activity, Secret Manager access logs, Cloud KMS logs, OS Login logs, Compute Engine operation logs, Security Command Center findings, endpoint telemetry, IIS process telemetry, application-file telemetry, workload identity context, service account mappings, and SIEM correlation after Cloud Audit Log validation, identity mapping, role-to-resource validation, API baseline validation, Secret Manager baseline validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious access to GCP service accounts, Secret Manager secrets, Cloud KMS keys, OS Login, Compute Engine operations, IAM role changes, or GCP control-plane activity after suspicious ASP.NET / IIS host activity.

·        Identify possible cloud-side expansion after server-side execution, web shell interaction, application compromise, or post-exploitation behavior on a GCP-hosted ASP.NET workload.

·        Prioritize activity involving affected Compute Engine service accounts, workload identities, Secret Manager retrieval, unusual Cloud KMS decrypt or sign activity, OS Login use, service account token use, IAM role changes, or control-plane actions following suspicious web or host behavior.

·        Support escalation when cloud credential, Secret Manager, service account, Cloud KMS, OS Login, or control-plane activity follows IIS child-process execution, suspicious command lines, application-file modification, outbound communication, rare path access, or abnormal ASP.NET request activity.

·        This rule does not prove ViewState exploitation, GCP project compromise, credential theft, privilege escalation, or actor attribution without supporting web, endpoint, file, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side context from a GCP-hosted ASP.NET workload, including IIS worker-process child execution, suspicious command lines, webroot modification, application-file modification, rare path access, abnormal ViewState-bearing POST activity, credential access, archive creation, local discovery, defense evasion, or outbound communication.

·        Correlate suspicious host-side context to subsequent Secret Manager access, Cloud KMS key operation, service account token use, service account impersonation, OS Login activity, IAM role activity, Compute Engine operation, or Cloud Audit Log operation from the same workload boundary.

·        Prioritize service account activity that is new for the workload, rare for the resource, rare for the application role, outside normal deployment windows, associated with suspicious process context, or followed by unusual GCP API activity.

·        Prioritize Secret Manager activity involving unusual secret names, unusual calling principals, unusual source workload, first-seen access, cross-application access, unexpected burst access, access outside approved application behavior, or access to sensitive secrets outside the workload’s normal dependency map.

·        Prioritize Cloud KMS activity involving unusual decrypt, sign, or key-use volume, unusual calling identity, unusual source service, or key operations tied to secrets or data stores not normally accessed by the workload.

·        Prioritize OS Login, Compute Engine, or IAM activity involving unexpected command execution, unexpected SSH or administrative access, unusual operator identity, unexpected source workload, role changes, or use outside maintenance windows.

·        Increase confidence when suspicious cloud-side activity follows IIS child-process execution, application-file modification, rare path access, web-to-egress correlation, endpoint credential-access detections, or application errors.

·        Reduce severity for approved deployment automation, patching workflows, backup operations, monitoring tools, break-glass activity, incident response, maintenance windows, and expected application secret retrieval.

·        Do not classify service account activity, Secret Manager access, Cloud KMS activity, OS Login activity, IAM activity, Compute Engine operations, or control-plane operations as exploitation-related without upstream web, host, file, application, or workload-boundary evidence.

·        Do not treat normal application Secret Manager access as compromise evidence without unusual caller, unusual timing, unusual volume, unusual resource scope, or suspicious host-side context.

Required Telemetry

·        Cloud Audit Logs.

·        IAM audit logs.

·        Service account activity logs.

·        Secret Manager access logs.

·        Cloud KMS logs.

·        OS Login logs where available.

·        Compute Engine operation logs.

·        Security Command Center findings where available.

·        VPC Flow Logs where available.

·        Cloud DNS logs where available.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Compute Engine VM inventory.

·        Managed instance group mappings where applicable.

·        Service account mappings.

·        IAM role mappings.

·        Workload label inventory.

·        Application-boundary mapping.

·        Approved Secret Manager access baselines.

·        Approved Cloud KMS key-use baselines.

·        Approved service account baselines.

·        Approved OS Login baselines.

·        Approved deployment identity inventory.

·        Approved break-glass identity inventory.

·        Sensitive secret inventory.

·        Sensitive Cloud KMS key inventory.

·        Cross-application secret access map.

·        Maintenance-window records.

·        Change-control records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build mappings from Compute Engine instance IDs, service accounts, IAM roles, application names, workload labels, backend services, managed instance groups, GKE Windows nodes, and ASP.NET applications to normalized workload boundaries.

·        Build approved baselines for Secret Manager access, Cloud KMS operations, service account activity, OS Login activity, Compute Engine operations, IAM role activity, and deployment automation for each GCP-hosted ASP.NET workload.

·        Build sensitive secret, sensitive key, and cross-application access maps so unusual access to sensitive approved resources is not fully suppressed by simple allowlisting.

·        Build suspicious host-side precursor logic from locked endpoint and SIEM rules, including IIS child-process execution, application-file modification, suspicious web activity, rare path access, outbound communication, credential access, archive creation, and defense-evasion behavior.

·        Preserve host-to-cloud event-pair timing so each suspicious host precursor is correlated to the specific subsequent Secret Manager, service account, Cloud KMS, OS Login, IAM, Compute Engine, or Cloud Audit Log event.

·        Use shorter correlation windows when suspicious host activity is followed quickly by service account token activity, Secret Manager access, Cloud KMS operation, or API activity.

·        Use moderate correlation windows when OS Login activity, IAM activity, Compute Engine operation, or unusual API activity follows host compromise indicators.

·        Use longer correlation windows for delayed credential use, delayed operator activity, staged cloud reconnaissance, or low-and-slow misuse of workload identities.

·        Add severity weighting for internet-facing exposure, application identity sensitivity, privileged service account, unusual Secret Manager access, unusual Cloud KMS operation, unusual OS Login use, first-seen identity behavior, cross-application access, sensitive-resource access, and supporting endpoint or network evidence.

·        Use deployment records, maintenance windows, expected application startup behavior, expected secret-rotation behavior, backup workflows, monitoring workflows, and incident-response activity as triage evidence.

·        Do not enable high-severity alerting until Cloud Audit Log coverage, Secret Manager logging, Cloud KMS logging, event timing, workload identity mapping, role-to-resource mapping, Secret Manager baselines, Cloud KMS baselines, service account baselines, OS Login baselines, sensitive-resource maps, exception logic, false-positive baselines, and SOC triage workflows are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to cloud-side service account, Secret Manager, Cloud KMS, OS Login, IAM, Compute Engine, or control-plane activity after suspicious GCP-hosted workload behavior.

·        The rule remains useful if an adversary changes web shell family, command syntax, payload staging method, destination infrastructure, credential-access timing, or cloud API usage timing.

·        The score is supported by the durability of post-exploitation attempts to access service accounts, Secret Manager secrets, Cloud KMS keys, OS Login, IAM, or GCP APIs from compromised workloads.

·        The score is constrained by normal application Secret Manager retrieval, deployment automation, monitoring tools, patching workflows, backup operations, and incomplete workload identity mapping.

·        The rule is durable as a cloud-side escalation detector but should not be treated as standalone proof of ViewState exploitation or GCP project compromise.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on Cloud Audit Log coverage, Secret Manager logging, Cloud KMS logging, workload identity mapping, service account mapping, endpoint telemetry, Secret Manager baselines, Cloud KMS baselines, OS Login baselines, service account baselines, and host-side precursor quality.

·        Operational confidence is reduced where normal application behavior includes frequent Secret Manager retrieval, Cloud KMS operations, service account activity, OS Login automation, or recurring control-plane activity.

·        Operational confidence is reduced where role-to-resource mapping, label hygiene, Cloud Audit Log coverage, sensitive-resource mapping, or endpoint telemetry is incomplete.

·        Full-telemetry confidence improves when suspicious cloud-side events are enriched with IIS logs, endpoint telemetry, file telemetry, Cloud Armor logs, Load Balancer logs, VPC Flow Logs, Cloud NAT logs, firewall logs, Security Command Center findings, and change-control records.

·        Under full telemetry conditions, this rule provides strong escalation evidence for possible cloud-side misuse after workload compromise, but confirmed exploitation still requires corroborating web, endpoint, file, application, identity, or incident-response evidence.

Limitations

·        This rule detects suspicious GCP service account, Secret Manager, Cloud KMS, OS Login, IAM, Compute Engine, or control-plane activity after suspicious host behavior, not confirmed exploitation by itself.

·        Normal application operation may involve Secret Manager retrieval, Cloud KMS operations, service account activity, IAM use, and control-plane activity.

·        Deployment automation, backup jobs, monitoring agents, patching workflows, incident response, and maintenance activity may produce similar cloud-side behavior.

·        Missing Cloud Audit Log coverage or missing Secret Manager / Cloud KMS logging may reduce visibility.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and cloud API activity.

·        Missing workload-boundary mapping may prevent attribution to the affected ASP.NET application.

·        Simple allowlists can suppress meaningful activity if sensitive-resource maps, cross-application access maps, or unusual-volume logic are not maintained.

·        The rule may miss attackers who avoid cloud-side activity or use only already-approved application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP-hosted ASP.NET suspicious host activity followed by service account, Secret Manager, Cloud KMS, OS Login, IAM, Compute Engine, or control-plane activity query pattern requiring Cloud Audit Log validation, Secret Manager validation, Cloud KMS validation, workload identity mapping, service account mapping, role-to-resource mapping, baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM instance IDs, service account mappings, principal-to-workload mappings, workload labels, application-boundary mappings, reference maps, or SIEM correlation fields.

GCP CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By GCP Service Account Or Secret Access

WHEN HostEvent.Source IN (
"EDR Process",
"EDR File",
"IIS",
"SIEM Correlation",
"Endpoint Detection"
)
AND HostEvent.EventPattern IN (
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious ASP.NET Request Activity",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_HOST_TO_GCP_API_WINDOW BY CloudEvent
WHERE CloudEvent.Source IN (
"Cloud Audit Logs",
"IAM Audit Logs",
"Service Account Activity",
"Secret Manager Logs",
"Cloud KMS Logs",
"OS Login Logs",
"Security Command Center"
)
AND CORRELATION_KEY(
HostEvent.InstanceId,
HostEvent.PrivateIP,
HostEvent.ApplicationBoundary,
CloudEvent.InstanceId,
CloudEvent.PrincipalEmail,
CloudEvent.ServiceAccountEmail,
CloudEvent.ApplicationBoundary
) IS SAME_NORMALIZED_GCP_WORKLOAD_IDENTITY_OR_APPLICATION_BOUNDARY
AND (
CloudEvent.EventName IN (
"accessSecretVersion",
"decrypt",
"asymmetricSign",
"generateAccessToken",
"signJwt",
"signBlob",
"setIamPolicy",
"compute.instances.setMetadata",
"compute.instances.osLogin"
)
OR CloudEvent.EventPattern IN (
"service_account_token_access",
"unusual_service_account_use",
"unusual_secret_manager_access",
"unusual_kms_operation",
"unexpected_os_login_activity",
"first_seen_identity_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_key_use_after_host_precursor"
)
)
AND (
CloudEvent.PrincipalEmail IS NULL
OR CloudEvent.PrincipalEmail NOT IN REFERENCE_SET("Approved Deployment Or Automation Principals")
OR CloudEvent.EventPattern IN (
"first_seen_identity_activity",
"cross_application_secret_access",
"sensitive_secret_access_after_host_precursor",
"sensitive_key_use_after_host_precursor"
)
)
AND (
CloudEvent.SecretId IS NULL
OR CloudEvent.SecretId NOT IN REFERENCE_SET("Approved Secret Manager Secrets For Workload")
OR CloudEvent.SecretId IN REFERENCE_SET("Sensitive Secrets Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"cross_application_secret_access",
"unusual_secret_manager_access"
)
)
AND (
CloudEvent.KmsKeyId IS NULL
OR CloudEvent.KmsKeyId NOT IN REFERENCE_SET("Approved Cloud KMS Keys For Workload")
OR CloudEvent.KmsKeyId IN REFERENCE_SET("Sensitive Cloud KMS Keys Requiring Host-Precursor Review")
OR CloudEvent.EventPattern IN (
"unusual_kms_operation",
"sensitive_key_use_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
CloudEvent.PrincipalEmail,
CloudEvent.EventName,
CloudEvent.ResourceName,
CloudEvent.EventTime
)

Rule

GCP-Hosted ASP.NET Workload Suspicious Cloud Storage or Staging Activity After Web Compromise Indicators

Rule Format

GCP correlation rule suitable for Cloud Audit Logs, Cloud Storage data access logs, VPC Flow Logs, Cloud NAT logs where available, firewall logs, Cloud DNS logs, Security Command Center findings, endpoint telemetry, IIS process telemetry, file telemetry, GCP workload inventory, service account mappings, storage bucket inventories, approved bucket inventories, approved object-prefix inventories, workload-to-storage dependency maps, and SIEM correlation after data-access validation, bucket baseline validation, workload identity mapping, object-access baseline validation, event-pair timing validation, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Cloud Storage or object-storage activity by a GCP-hosted ASP.NET workload after web compromise indicators.

·        Identify possible payload staging, tool retrieval, fake component hosting, data staging, archive upload, exfiltration staging, or attacker use of object storage following suspicious ASP.NET / IIS activity.

·        Prioritize activity involving unusual buckets, newly accessed buckets, cross-application buckets, public buckets, object upload bursts, archive uploads, executable-like object access, unusual object download, or object-storage destinations outside approved workload dependencies.

·        Support escalation when Cloud Storage activity follows suspicious web activity, IIS child-process execution, application-file modification, outbound communication, credential access, archive creation, or rare path access.

·        This rule does not prove ViewState exploitation, data theft, payload staging, GCP project compromise, or actor attribution without supporting web, endpoint, file, network, identity, application, or incident-response evidence.

Detection Logic

·        Identify suspicious host-side or web-side precursor activity from the GCP-hosted ASP.NET workload.

·        Correlate precursor activity with subsequent Cloud Storage data access logs, object access, object upload, object download, bucket enumeration, unusual bucket access, or object-storage network activity by the same workload identity, service account, source workload, or application boundary.

·        Prioritize newly observed bucket access, cross-application bucket access, unusual object prefixes, archive uploads, executable-like object names, high-volume object reads, high-volume object writes, public-bucket interaction, external object-storage destinations, or activity outside approved deployment workflows.

·        Prioritize object access by workload identities that do not normally interact with Cloud Storage or by application identities accessing buckets outside their approved dependency map.

·        Increase confidence when storage activity follows archive creation, credential access, local discovery, file staging, suspicious egress, IIS child-process execution, application-file modification, or application-content tampering.

·        Increase confidence when Cloud Storage activity aligns with Security Command Center findings, unusual service account activity, Secret Manager anomalies, Cloud KMS anomalies, newly observed destinations, or unusual VPC / firewall egress from the same workload.

·        Reduce severity for approved deployment artifact retrieval, application asset storage, logging buckets, backup buckets, monitoring buckets, patching repositories, business integrations, data pipelines, incident-response activity, and known application workflows.

·        Do not classify Cloud Storage activity as exploitation-related without upstream web, endpoint, file, identity, application, or workload-boundary evidence.

·        Do not treat storage access, bucket novelty, object extension, archive transfer, high byte volume, or public bucket contact as compromise evidence by itself.

Required Telemetry

·        Cloud Audit Logs.

·        Cloud Storage data access logs.

·        VPC Flow Logs where available.

·        Cloud NAT logs where available.

·        Firewall logs where available.

·        Cloud DNS logs where available.

·        Security Command Center findings where available.

·        IAM logs where applicable.

·        Service account mappings.

·        Compute Engine VM inventory.

·        Managed instance group mappings where applicable.

·        Workload label inventory.

·        ASP.NET application inventory.

·        Application-boundary mapping.

·        Approved bucket inventory.

·        Approved object-prefix inventory where available.

·        Approved workload-to-storage dependency map.

·        Sensitive bucket inventory.

·        Sensitive object-prefix inventory.

·        Cross-application bucket access map.

·        Approved deployment artifact bucket inventory.

·        Approved backup bucket inventory.

·        Approved logging bucket inventory.

·        Approved monitoring bucket inventory.

·        Endpoint process telemetry where available.

·        IIS process telemetry where available.

·        File telemetry where available.

·        Application logs where available.

·        Change-control records.

·        Maintenance-window records.

·        Incident-response records where available.

Engineering Implementation Instructions

·        Build workload-to-storage dependency maps for each GCP-hosted ASP.NET application.

·        Build approved bucket, object-prefix, deployment artifact, backup, logging, monitoring, data pipeline, and business integration inventories.

·        Build sensitive bucket, sensitive prefix, and cross-application bucket access maps so access to approved but sensitive resources is not fully suppressed by simple allowlisting.

·        Build suspicious object-storage logic for newly observed bucket access, cross-application bucket access, public-bucket interaction, executable-like object access, archive upload, archive download, unusual object prefix, high-volume object access, and access outside approved workflow timing.

·        Build suspicious precursor logic from locked web, endpoint, file, network, and GCP rules, including abnormal ASP.NET request activity, IIS child-process execution, application-file modification, rare path access, credential access, archive creation, suspicious egress, Secret Manager access, Cloud KMS activity, service account activity, and OS Login activity.

·        Preserve precursor-to-storage event-pair timing so each suspicious web, host, file, or identity event is correlated to the specific subsequent Cloud Storage activity.

·        Use shorter correlation windows when suspicious host activity is followed quickly by object retrieval, object upload, bucket enumeration, or payload-like staging.

·        Use moderate correlation windows when storage activity follows archive creation, credential access, local discovery, suspicious egress, or file staging.

·        Use longer correlation windows for delayed staging, delayed exfiltration preparation, repeated low-volume object access, or delayed operator activity.

·        Add severity weighting for internet-facing exposure, sensitive bucket access, cross-application bucket access, unusual workload identity, first-seen storage access, archive upload, executable-like object access, Secret Manager alignment, Cloud KMS alignment, Security Command Center alignment, and supporting host or network evidence.

·        Use deployment records, backup schedules, data pipeline schedules, application-owner validation, maintenance windows, and incident-response records as triage evidence.

·        Do not enable high-severity alerting until Cloud Storage data access coverage, workload-to-storage mapping, bucket baselines, prefix baselines, sensitive-resource maps, workload identity mapping, exception logic, false-positive baselines, query performance, and SOC triage workflows are validated.

DRI Assessment

DRI

7.5 / 10

·        The rule is behaviorally anchored to suspicious Cloud Storage activity after GCP-hosted workload compromise indicators.

·        The rule remains useful if an adversary changes object names, bucket names, staging timing, destination infrastructure, web shell family, or payload format.

·        The score is supported by the durability of post-compromise object-storage use for payload staging, archive movement, tooling retrieval, or data staging.

·        The score is constrained by legitimate Cloud Storage-backed application workflows, deployment artifacts, backup processes, logging pipelines, data pipelines, and incomplete Cloud Storage data access logging.

·        The rule is durable as a cloud-side staging and exposure detector but should not be treated as standalone proof of exploitation or data theft.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

·        Operational confidence depends on Cloud Storage data access coverage, Cloud Audit Log coverage, workload identity mapping, approved bucket inventories, workload-to-storage dependency maps, endpoint telemetry, sensitive-resource mapping, and precursor quality.

·        Operational confidence is reduced where applications normally use Cloud Storage for content delivery, deployment artifacts, backups, logs, static assets, or data pipelines.

·        Operational confidence is reduced where bucket and prefix baselines are incomplete.

·        Full-telemetry confidence improves when Cloud Storage activity is enriched with IIS logs, endpoint telemetry, file telemetry, VPC Flow Logs, Cloud NAT logs, firewall logs, Security Command Center findings, Secret Manager events, Cloud KMS events, identity events, and change-control records.

·        Under full telemetry conditions, this rule provides useful escalation evidence for possible staging or data movement after workload compromise, but confirmed exploitation or data theft still requires corroborating web, endpoint, file, identity, application, or incident-response evidence.

Limitations

·        This rule detects suspicious object-storage activity after suspicious host or web behavior, not confirmed exploitation or data theft by itself.

·        Many GCP-hosted applications legitimately use Cloud Storage for content, deployment artifacts, backups, logs, static assets, and business workflows.

·        Missing Cloud Storage data access logs may prevent object-level visibility.

·        Missing workload-to-storage dependency mapping may reduce confidence.

·        Missing sensitive bucket, sensitive prefix, and cross-application access maps may cause over-suppression or under-detection.

·        Missing endpoint telemetry may prevent linkage between IIS behavior and Cloud Storage activity.

·        The rule may miss attackers who avoid Cloud Storage, use approved buckets, use approved object prefixes, or operate only through local application behavior.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP-hosted ASP.NET suspicious web or host activity followed by suspicious Cloud Storage activity query pattern requiring Cloud Audit Log validation, Cloud Storage data access validation, workload identity mapping, workload-to-storage dependency mapping, object-prefix baseline validation, event-pair preservation, timing-window tuning, and environment-specific allowlisting before production deployment.

CORRELATION_KEY(...) is conceptual shorthand only. Production implementations must replace it with locally validated workload-boundary fields, VM instance IDs, service account mappings, principal-to-workload mappings, workload-to-storage dependency maps, workload labels, application-boundary mappings, reference maps, or SIEM correlation fields.

GCP CORRELATION RULE: Suspicious ASP.NET Host Activity Followed By Cloud Storage Activity

WHEN PrecursorEvent.Source IN (
"Cloud Armor",
"HTTP Load Balancer",
"Cloud CDN",
"IIS",
"EDR Process",
"EDR File",
"SIEM Correlation",
"Endpoint Detection"
)
AND PrecursorEvent.EventPattern IN (
"Suspicious ASP.NET Request Activity",
"IIS Worker Process Child Execution",
"Suspicious IIS Command Execution",
"Application File Modified",
"Rare ASP.NET Path Access",
"Suspicious Server Egress",
"Credential Access",
"Archive Creation",
"Defense Evasion"
)
FOLLOWED WITHIN ENV_ASPNET_PRECURSOR_TO_GCP_STORAGE_WINDOW BY StorageEvent
WHERE StorageEvent.Source IN (
"Cloud Audit Logs",
"Cloud Storage Data Access Logs",
"VPC Flow Logs",
"Cloud NAT",
"Firewall Logs",
"Cloud DNS"
)
AND CORRELATION_KEY(
PrecursorEvent.InstanceId,
PrecursorEvent.ApplicationBoundary,
PrecursorEvent.ServiceAccountEmail,
StorageEvent.PrincipalEmail,
StorageEvent.SourceInstanceId,
StorageEvent.ApplicationBoundary
) IS SAME_NORMALIZED_GCP_WORKLOAD_IDENTITY_OR_APPLICATION_BOUNDARY
AND (
StorageEvent.EventName IN (
"storage.objects.get",
"storage.objects.create",
"storage.objects.list",
"storage.objects.copy",
"storage.objects.update",
"storage.buckets.get"
)
OR StorageEvent.EventPattern IN (
"newly_observed_bucket_access",
"cross_application_bucket_access",
"public_bucket_interaction",
"archive_upload",
"executable_like_object_access",
"high_volume_object_read",
"high_volume_object_write",
"unusual_object_prefix",
"sensitive_bucket_access_after_host_precursor",
"sensitive_prefix_access_after_host_precursor"
)
)
AND (
StorageEvent.BucketName IS NULL
OR StorageEvent.BucketName NOT IN REFERENCE_SET("Approved Buckets For Workload")
OR StorageEvent.BucketName IN REFERENCE_SET("Sensitive Buckets Requiring Host-Precursor Review")
OR StorageEvent.EventPattern IN (
"newly_observed_bucket_access",
"cross_application_bucket_access",
"public_bucket_interaction",
"sensitive_bucket_access_after_host_precursor"
)
)
AND (
StorageEvent.ObjectPrefix IS NULL
OR StorageEvent.ObjectPrefix NOT IN REFERENCE_SET("Approved Object Prefixes For Workload")
OR StorageEvent.ObjectPrefix IN REFERENCE_SET("Sensitive Object Prefixes Requiring Host-Precursor Review")
OR StorageEvent.EventPattern IN (
"archive_upload",
"executable_like_object_access",
"high_volume_object_read",
"high_volume_object_write",
"unusual_object_prefix",
"sensitive_prefix_access_after_host_precursor"
)
)
AND NOT EXISTS_IN_REFERENCE_DATA(
"Approved Change Context",
StorageEvent.PrincipalEmail,
StorageEvent.BucketName,
StorageEvent.EventName,
StorageEvent.EventTime
)

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the ASP.NET ViewState deserialization and shared machineKey exploitation path to the locked detection engineering model. The purpose is to show how each major adversary behavior is covered by accepted rule families across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

Coverage Position

The detection model is behavior-led. It does not depend on exploit payload syntax, machineKey material, proof-of-concept strings, web shell filenames, fixed infrastructure, known hashes, or attacker-selected artifacts.

Primary Detection Model

·        Suspicious ASP.NET request activity.

·        Abnormal ViewState-bearing POST behavior.

·        IIS worker-process child execution.

·        Suspicious application-file modification.

·        Rare or newly observed application-path access.

·        Suspicious server egress after web or host precursor activity.

·        Cloud-side credential, secret, identity, object-storage, or control-plane activity after upstream workload compromise indicators.

·        Conditional artifact hunting only when stable recovered artifacts become available.

Traceability Item

Initial Suspicious ASP.NET Request Activity

Threat Behavior

·        The adversary targets an exposed ASP.NET application path that processes state-bearing requests.

·        Activity may involve abnormal POST behavior, large request bodies, repeated request variation, error-to-success patterns, sparse targeted access, rare source infrastructure, or WAF / application anomaly context.

·        Request activity may precede server-side execution, application-file modification, rare path interaction, outbound communication, or cloud-side follow-on behavior.

Detection Rule Coverage

·        NDR / Network Behavioral Analytics covers abnormal web request behavior, unusual POST patterns, rare source-to-application interaction, and request-to-response anomalies.

·        Splunk covers abnormal ASP.NET request activity and correlates web anomalies to endpoint, file, network, and cloud-side behavior where logs are available.

·        Elastic covers request anomalies and correlates them with host-side, file, application-path, and network evidence.

·        QRadar covers suspicious ASP.NET activity through CRE correlation, custom properties, reference sets, reference maps, and offense-scoped sequencing.

·        SIGMA provides portable detection patterns for downstream SIEM translation where IIS, WAF, proxy, endpoint, and network telemetry are mapped.

·        AWS covers suspicious web activity from AWS WAF, Application Load Balancer, CloudFront, and mapped IIS logs when the affected workload is AWS-hosted.

·        Azure covers suspicious web activity from Azure WAF, Application Gateway, Azure Front Door, and mapped IIS logs when the affected workload is Azure-hosted.

·        GCP covers suspicious web activity from Cloud Armor, HTTP(S) Load Balancer, Cloud CDN, and mapped IIS logs when the affected workload is GCP-hosted.

Detection Dependency

·        IIS logs.

·        WAF logs.

·        Reverse proxy logs.

·        Load balancer logs.

·        Application logs.

·        Request-size baselines.

·        Path first-seen or path-frequency baselines.

·        Source rarity or source reputation enrichment.

·        Endpoint, file, or network telemetry for escalation.

·        Workload-boundary mapping for cloud correlation.

Traceability Outcome

Covered as an initial access and precursor behavior. Confirmed exploitation still requires host, file, network, application, identity, cloud, or incident-response correlation.

Traceability Item

IIS Worker-Process Child Execution

Threat Behavior

·        The adversary obtains server-side execution through the affected ASP.NET application context.

·        Execution may appear as child processes spawned by w3wp.exe, IIS worker processes, ASP.NET application processes, application pool identities, or suspicious service-account contexts.

·        Child activity may involve command shells, PowerShell, script interpreters, living-off-the-land utilities, archive utilities, network utilities, or credential-related utilities.

Detection Rule Coverage

·        SentinelOne covers suspicious IIS worker-process child execution, command-line behavior, process lineage, application pool identity context, and follow-on endpoint activity.

·        Splunk covers web-to-process correlation and server-side execution patterns.

·        Elastic covers parent-child process behavior, suspicious command execution, and supporting web, file, and network context.

·        QRadar covers suspicious process behavior through custom properties, reference maps, reference sets, building blocks, and offense-scoped correlation.

·        SIGMA provides portable process-creation patterns for downstream SIEM translation.

·        AWS, Azure, and GCP use IIS process execution as host precursor evidence for cloud-side egress, identity, secret, key, and storage correlation when the workload is hosted in those environments.

Detection Dependency

·        Windows process creation telemetry.

·        EDR telemetry.

·        Sysmon Event ID 1 where available.

·        Parent process fields.

·        Child process fields.

·        Command-line fields.

·        Process user fields.

·        Process integrity context where available.

·        Application pool identity mapping.

·        IIS server inventory.

·        ASP.NET application inventory.

·        Web telemetry for precursor context.

·        File and network telemetry for escalation.

Traceability Outcome

Covered as a primary host-side compromise-validation behavior. It does not prove ViewState exploitation by itself, but it is one of the strongest post-exploitation indicators when correlated to suspicious ASP.NET request activity.

Traceability Item

Suspicious Application-File Modification

Threat Behavior

·        The adversary writes, modifies, renames, stages, or removes files within protected ASP.NET or IIS application paths.

·        Activity may involve new ASPX artifacts, modified JavaScript, modified login pages, unexpected DLL placement, configuration modification, archive staging, executable staging, or suspicious temporary artifacts.

·        The behavior may support web shell placement, application-content tampering, fake component staging, or persistence-like access.

Detection Rule Coverage

·        SentinelOne covers suspicious file creation or modification under IIS / ASP.NET application paths.

·        Splunk covers file modification and correlates it with web access, process execution, outbound communication, and cloud-side behavior where applicable.

·        Elastic covers application-file modification with responsible-process, path-context, and web-follow-on enrichment.

·        QRadar covers file modification through event normalization, custom properties, reference sets, reference maps, and offense-scoped correlation.

·        SIGMA provides portable file-event patterns while ensuring file extension alone cannot trigger the rule.

·        AWS, Azure, and GCP use suspicious application-file modification as a host precursor for cloud-side egress, identity, secrets, keys, control-plane, and storage correlation.

Detection Dependency

·        File creation and modification telemetry.

·        EDR file telemetry.

·        Sysmon Event ID 11 where available.

·        File integrity monitoring where available.

·        Responsible process context.

·        Parent process context where available.

·        Protected path inventory.

·        Webroot inventory.

·        Known-good application baselines.

·        File-to-URL mapping where available.

·        Change-control records.

·        Maintenance-window records.

Traceability Outcome

Covered as a primary application-compromise behavior. File extension alone is not sufficient; detection requires suspicious process, path, timing, change, web-access, or follow-on context.

Traceability Item

Rare or Newly Observed Application-Path Access

Threat Behavior

·        The adversary accesses a newly created, rarely used, modified, or suspicious application path after file modification or server-side execution.

·        The access may indicate web shell interaction, staged artifact retrieval, application-content tampering, fake component interaction, or follow-on access to a malicious component.

Detection Rule Coverage

·        NDR / Network Behavioral Analytics covers rare path access, unusual URI interaction, abnormal request cadence, and web-to-response anomalies.

·        Splunk covers rare path access correlated with file modification, process execution, and outbound communication.

·        Elastic covers rare path access correlated with endpoint and application-file evidence.

·        QRadar covers rare path access through reference maps, first-seen path logic, custom properties, and offense-scoped correlation.

·        SIGMA accounts for rare-path interaction as follow-on context after file modification, with final correlation performed in the destination SIEM.

·        AWS, Azure, and GCP use rare path access as a cloud-correlation precursor when mapped to hosted workload boundaries.

Detection Dependency

·        IIS logs.

·        WAF logs.

·        Reverse proxy logs.

·        Load balancer logs.

·        URI path normalization.

·        Path first-seen baselines.

·        Path frequency baselines.

·        File-to-URL mapping.

·        Application route mapping.

·        Host and file telemetry for escalation.

Traceability Outcome

Covered as a web interaction and follow-on validation behavior. It is strongest when paired with suspicious file modification, IIS process execution, or outbound communication.

Traceability Item

Suspicious Server Egress After Web or Host Precursor Activity

Threat Behavior

·        The adversary causes the affected server to contact external infrastructure after suspicious web, process, or file activity.

·        Egress may involve payload retrieval, callback behavior, external script retrieval, object-storage access, file-transfer activity, or command-and-control-like communication.

·        The destination may be newly observed, rare for the workload, direct-IP based, dynamic DNS-associated, low reputation, unusual by port, or outside approved application dependencies.

Detection Rule Coverage

·        NDR / Network Behavioral Analytics covers suspicious server egress and rare destination behavior after web anomalies.

·        SentinelOne covers process-linked network activity from IIS worker processes, shells, interpreters, and network utilities.

·        Splunk covers suspicious web, host, file, and network correlation.

·        Elastic covers egress activity correlated with endpoint, file, and web precursors.

·        QRadar covers network activity correlated with web and host context through reference data and offense logic.

·        SIGMA provides portable network-event patterns while preventing direct-IP communication alone from triggering.

·        AWS covers AWS-hosted workload egress after suspicious request or host precursor activity.

·        Azure covers Azure-hosted workload egress after suspicious request or host precursor activity.

·        GCP covers GCP-hosted workload egress after suspicious request or host precursor activity.

Detection Dependency

·        Endpoint network telemetry.

·        VPC Flow Logs, NSG Flow Logs, or GCP VPC Flow Logs depending on cloud platform.

·        Firewall logs.

·        DNS telemetry.

·        Proxy logs where available.

·        Destination first-seen enrichment.

·        Destination reputation enrichment.

·        Process-to-network mapping.

·        Approved destination inventory.

·        Workload-boundary mapping.

·        NAT attribution.

Traceability Outcome

Covered as a primary post-exploitation behavior. Egress alone is not sufficient; it must be tied to upstream web, host, file, application, identity, or workload-boundary evidence.

Traceability Item

Cloud-Side Secret, Key, Managed Identity, Service Account, or Credential Activity

Threat Behavior

·        The adversary attempts to use compromised workload context to access cloud credentials, secrets, keys, tokens, metadata, managed identities, service accounts, or control-plane APIs.

·        Activity may involve AWS Secrets Manager, AWS KMS, AWS STS, AWS SSM, Azure Key Vault, Azure managed identity use, Azure run-command activity, GCP Secret Manager, GCP Cloud KMS, service account token activity, OS Login, or IAM changes.

Detection Rule Coverage

·        AWS covers metadata, Secrets Manager, KMS, SSM, STS, or IAM activity after suspicious host activity.

·        Azure covers Key Vault, managed identity, run-command, role, extension, or control-plane activity after suspicious host activity.

·        GCP covers Secret Manager, service account, Cloud KMS, OS Login, IAM, Compute Engine, or control-plane activity after suspicious host activity.

·        Splunk, Elastic, and QRadar can correlate cloud-side activity where cloud logs are ingested and mapped to the same workload boundary.

·        SentinelOne provides host precursor evidence required to prevent cloud-only over-attribution.

Detection Dependency

·        Cloud audit logs.

·        Cloud identity logs.

·        Secret access logs.

·        Key management logs.

·        Metadata access telemetry where available.

·        Managed identity, service account, or instance profile mapping.

·        Role-to-workload mapping.

·        Sensitive-resource inventory.

·        Approved access baselines.

·        Host precursor telemetry.

·        Change-control records.

Traceability Outcome

Covered for cloud-hosted workloads. Cloud-only anomalies must not be attributed to this exploitation path without upstream workload, web, host, file, identity, or application evidence.

Traceability Item

Object Storage or Staging Activity After Compromise Indicators

Threat Behavior

·        The adversary uses cloud object storage or similar staging locations for payload retrieval, tool staging, archive movement, data staging, or exfiltration preparation.

·        Activity may involve unusual buckets, storage accounts, containers, object prefixes, archive uploads, executable-like object access, high-volume object reads or writes, cross-application access, or public object-storage interaction.

Detection Rule Coverage

·        AWS covers suspicious S3 or object-storage activity after web, host, identity, or workload precursor activity.

·        Azure covers suspicious Azure Storage or Blob activity after web, host, identity, or workload precursor activity.

·        GCP covers suspicious Cloud Storage activity after web, host, identity, or workload precursor activity.

·        Splunk, Elastic, and QRadar can correlate object-storage activity where cloud audit and data-access logs are ingested.

·        SentinelOne and endpoint telemetry provide host precursor evidence for cloud-storage correlation.

Detection Dependency

·        Cloud storage data-access logs.

·        Cloud audit logs.

·        Workload-to-storage dependency maps.

·        Approved bucket, storage account, container, and prefix inventories.

·        Sensitive storage maps.

·        Cross-application access maps.

·        Endpoint and host precursor telemetry.

·        Object access baselines.

·        Change-control records.

Traceability Outcome

Covered as a cloud-side staging and data-movement behavior. Storage activity alone is not treated as proof of exploitation or data theft.

Traceability Item

Credential Access, Discovery, Archive Creation, and Defense Evasion

Threat Behavior

·        The adversary performs local discovery, accesses credentials, stages files, creates archives, changes execution behavior, or attempts to evade local defenses after gaining server-side execution.

·        These behaviors may occur before outbound communication, cloud API use, object-storage staging, or persistence.

Detection Rule Coverage

·        SentinelOne covers endpoint behaviors such as suspicious process execution, credential-access indicators, archive creation, local discovery, and defense-evasion behavior.

·        Splunk covers endpoint activity correlated with web, file, network, and cloud precursor chains.

·        Elastic covers endpoint and file activity correlated with web and network context.

·        QRadar covers host events, web events, and cloud events through reference data and offense logic.

·        AWS, Azure, and GCP use these host behaviors as precursors for cloud-side detection.

·        SIGMA expresses portable process, file, and network patterns for downstream SIEM translation.

Detection Dependency

·        EDR telemetry.

·        Process telemetry.

·        Command-line telemetry.

·        File telemetry.

·        Network telemetry.

·        Identity context.

·        Host inventory.

·        Application ownership.

·        Change-control records.

·        SOC triage context.

Traceability Outcome

Covered as supporting post-exploitation behavior. These signals increase confidence when tied to suspicious ASP.NET request activity, IIS process execution, application-file modification, suspicious server egress, or cloud-side follow-on activity.

Traceability Item

Artifact-Dependent Detection

Threat Behavior

·        The adversary may deploy a web shell, payload, dropper, memory artifact, modified application artifact, or reusable file-content pattern.

·        No stable artifact is assumed for the primary detection model.

Detection Rule Coverage

·        YARA has zero primary rules for this EXP report.

·        YARA remains a conditional investigative control if responders recover stable artifacts during incident response.

·        Artifact-dependent detection is intentionally excluded from the primary detection model unless stable file, memory, web shell, payload, or reusable content evidence becomes available.

Detection Dependency

·        Recovered artifact.

·        Stable file-content pattern.

·        Stable memory artifact.

·        Stable payload or dropper sample.

·        Incident-response evidence.

·        Malware-analysis validation.

Traceability Outcome

Not included as primary detection. This is a deliberate zero-rule disposition because the report’s governing detection model is behavior-led, not artifact-led.

Coverage Summary

·        Initial suspicious ASP.NET request activity is covered by NDR, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP where telemetry is available.

·        IIS worker-process child execution is covered by SentinelOne, Splunk, Elastic, QRadar, SIGMA, and cloud rules as host precursor evidence.

·        Suspicious application-file modification is covered by SentinelOne, Splunk, Elastic, QRadar, SIGMA, and cloud rules as host precursor evidence.

·        Rare or newly observed path access is covered by NDR, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP where web telemetry is available.

·        Suspicious server egress is covered by NDR, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

·        Cloud-side secret, key, identity, storage, and control-plane follow-on behavior is covered by AWS, Azure, and GCP where the workload is hosted in those environments and mapped to upstream precursor evidence.

·        YARA has no primary rules because no stable artifact governs the detection model.

Residual Detection Gaps

·        Exploitation that remains fully in-process and does not create child processes, files, outbound communication, rare path access, or cloud-side activity may be difficult to detect with high confidence.

·        Environments without IIS logs, WAF logs, endpoint telemetry, process telemetry, file telemetry, DNS telemetry, cloud audit logs, or workload-boundary mapping will have reduced coverage.

·        Environments with weak NAT attribution, application inventory, cloud identity mapping, file-to-URL mapping, path baselines, or destination baselines may struggle to correlate precursor and follow-on behavior.

·        Detection confidence is reduced when legitimate deployment workflows, vendor support, reporting jobs, backup activity, object-storage workflows, secret access, or cloud automation resemble post-exploitation behavior.

·        Production deployment requires customer-specific validation of schemas, field mappings, sourcetypes, indices, custom properties, enrichment, exception lists, false-positive baselines, query performance, and SOC triage procedures.

Threat-to-Detection Traceability Assessment

The detection model provides broad behavior-led coverage across web, endpoint, SIEM, network, portable rule, and cloud-control-plane telemetry. The strongest coverage comes from correlated sequences, not single events. The model is strongest when suspicious ASP.NET request behavior, IIS worker-process execution, application-file modification, rare path access, suspicious server egress, and cloud-side follow-on activity can be tied to the same normalized application or workload boundary.

Figure 4

S27 — Behavior & Log Artifacts

Section Purpose

This section identifies the primary behavior and log artifacts expected from ASP.NET ViewState deserialization abuse, shared machineKey exploitation, and related post-exploitation activity. The artifacts support detection engineering, SOC triage, investigation, and validation of the S21 through S26 detection model.

Artifact Position

The artifact model is behavior-led. No single artifact proves exploitation by itself. The strongest evidence comes from correlated web, endpoint, file, network, identity, and cloud-control-plane activity tied to the same normalized application or workload boundary.

Primary Behavioral Artifacts

·        Abnormal ASP.NET request activity against state-bearing, authentication-adjacent, upload, administrative-adjacent, LMS, vendor-portal, or workflow-heavy application paths.

·        Large or unusual POST request bodies compared against endpoint-specific baselines.

·        Repeated request variation against the same application route or small set of routes.

·        Error-to-success request sequences after abnormal ASP.NET request activity.

·        HTTP 500-series bursts or application exception patterns around targeted routes.

·        Rare source infrastructure interacting with exposed ASP.NET application paths.

·        Newly observed or low-frequency application-path access after suspicious request or file activity.

·        IIS worker-process child execution involving command shells, PowerShell, script interpreters, living-off-the-land binaries, archive utilities, network utilities, or credential-related utilities.

·        Suspicious application-file creation, modification, rename, overwrite, or deletion under protected IIS or ASP.NET paths.

·        Suspicious server egress after web, process, file, or rare-path precursor activity.

·        Cloud-side secret, key, identity, object-storage, metadata, or control-plane activity after upstream workload compromise indicators.

Web and Application Log Sources

·        IIS access logs.

·        IIS failed request tracing where enabled.

·        ASP.NET application logs.

·        WAF logs.

·        Reverse proxy logs.

·        Load balancer logs.

·        CDN or edge access logs where applicable.

·        Application exception logs.

·        Authentication and session logs where available.

Web and Application Log Artifacts

·        POST requests to ViewState-bearing or state-heavy ASP.NET paths.

·        Request-size outliers relative to endpoint baselines.

·        HTTP 500, 502, or 503 bursts around targeted ASP.NET routes.

·        Error-to-success sequences where repeated failed requests precede successful responses.

·        Sparse targeted access to a small number of application paths.

·        Repeated request variation with similar path, method, source, or timing.

·        Rare source IPs, source ASNs, hosting-provider sources, anonymization infrastructure, or previously unseen request origins.

·        Rare or newly observed URI paths after suspicious file activity.

·        Unusual user-agent strings, missing user agents, or inconsistent user-agent rotation.

·        Abnormal response-size patterns after suspicious request activity.

·        WAF anomaly events associated with ASP.NET paths.

·        Failed request traces or application exceptions around deserialization-adjacent code paths without requiring exploit payload inspection.

Web and Application Detection Value

Web and application logs provide the earliest precursor signals. They are strongest when correlated with endpoint execution, file modification, rare path access, or server egress from the same application boundary.

Endpoint and Process Log Sources

·        EDR telemetry.

·        Windows process creation logs.

·        Sysmon Event ID 1 where available.

·        PowerShell logs where available.

·        Command-line telemetry.

·        Application pool identity mapping.

·        Host inventory and IIS server inventory.

Endpoint and Process Artifacts

·        w3wp.exe spawning command shells, PowerShell, script interpreters, archive utilities, network utilities, or unusual administrative tools.

·        Process execution under application pool identities, IIS service accounts, vendor application service accounts, or service accounts that should not perform interactive administrative activity.

·        Command lines involving encoded execution, hidden execution, remote content retrieval, temporary-path execution, archive extraction, or execution from application-controlled paths.

·        Parent-child process chains involving IIS worker processes and unusual follow-on execution.

·        Process activity referencing webroot paths, upload paths, plugin-like paths, temporary ASP.NET compilation paths, or vendor application directories.

·        Local discovery, credential-access indicators, archive creation, staging behavior, or defense-evasion activity after suspicious web requests.

·        Network utility execution after suspicious ASP.NET request or file activity.

Endpoint and Process Detection Value

Endpoint and process artifacts are among the strongest compromise-validation signals. They do not prove the initial exploit vector by themselves, but they materially raise confidence when tied to abnormal ASP.NET request activity.

File and Application-Content Log Sources

·        EDR file telemetry.

·        Sysmon Event ID 11 where available.

·        File integrity monitoring.

·        Windows file creation and modification telemetry.

·        Webroot inventory.

·        Application path inventory.

·        Change-control records.

File and Application-Content Artifacts

·        New or modified files under IIS webroot directories.

·        New or modified files under ASP.NET application directories.

·        Unexpected files in upload directories, plugin-like directories, component directories, login paths, downloadable-content paths, or temporary ASP.NET compilation paths.

·        Modified JavaScript, login pages, configuration files, downloadable components, or application content.

·        Unexpected DLL placement or binary-like artifacts under application-controlled paths.

·        Archive staging or executable-like file creation after suspicious request activity.

·        File creation followed by rare or newly observed web access to the same or related path.

·        File creation or modification by w3wp.exe, suspicious child processes, script interpreters, command shells, deployment-like processes outside change windows, or application pool identities.

·        Deleted-after-use artifacts, temporary staging files, or content changes without approved deployment context.

File and Application-Content Detection Value

File and application-content artifacts support web shell, staging, tampering, and persistence investigation. File extension alone is not sufficient. File activity becomes meaningful when paired with suspicious process, path, timing, web-access, or change-control context.

Network and Egress Log Sources

·        Endpoint network telemetry.

·        NDR / Network Behavioral Analytics telemetry.

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        VPC Flow Logs, NSG Flow Logs, or GCP VPC Flow Logs where applicable.

·        Cloud NAT, NAT gateway, or firewall logs where applicable.

·        Destination reputation and first-seen enrichment.

Network and Egress Artifacts

·        Outbound communication from IIS-hosted servers after suspicious web or host activity.

·        Newly observed destinations for the affected workload.

·        Rare destinations for the host, application, or workload boundary.

·        Direct-IP outbound communication after suspicious precursor activity.

·        Dynamic DNS, low-reputation, or unusual hosting-provider destinations.

·        Uncommon outbound ports for the IIS workload.

·        Rare TLS SNI values or unusual HTTP hostnames.

·        Payload retrieval, callback-like timing, file-transfer activity, or object-storage access after host precursor activity.

·        Process-linked egress from w3wp.exe, IIS child processes, command shells, PowerShell, script interpreters, or network utilities.

·        DNS queries followed by outbound connections to the same newly observed or rare destination.

Network and Egress Detection Value

Network artifacts are strongest when correlated to upstream web, process, or file evidence. Destination novelty, direct-IP communication, cloud hosting, unusual ports, or high byte volume should not be treated as compromise evidence by themselves.

Identity and Cloud-Control Log Sources

·        Cloud audit logs.

·        Cloud identity logs.

·        IAM or role assignment logs.

·        Managed identity or service account activity.

·        Secret access logs.

·        Key management logs.

·        Metadata access telemetry where available.

·        SSM, run-command, OS Login, or compute-operation logs where applicable.

·        GuardDuty, Defender for Cloud, Security Command Center, or equivalent cloud security findings.

Identity and Cloud-Control Artifacts

·        AWS Secrets Manager, KMS, STS, SSM, IAM, metadata, or object-storage activity after suspicious host activity.

·        Azure Key Vault, managed identity, run-command, role assignment, extension, Activity Log, or Storage activity after suspicious host activity.

·        GCP Secret Manager, Cloud KMS, service account token activity, OS Login, IAM, Compute Engine, or Cloud Storage activity after suspicious host activity.

·        First-seen identity behavior from a workload role, instance profile, managed identity, or service account.

·        Cross-application access to secrets, keys, buckets, storage accounts, containers, or object prefixes.

·        Sensitive secret, key, storage, or object access after upstream workload compromise indicators.

·        Object-storage access involving archive upload, executable-like object access, unusual prefix activity, high-volume read or write, or public storage interaction.

·        Cloud API activity that follows endpoint credential-access behavior, archive creation, suspicious egress, or application-file modification.

Identity and Cloud-Control Detection Value

Cloud artifacts provide follow-on exposure and blast-radius evidence for cloud-hosted workloads. Cloud-only anomalies must not be attributed to the exploitation path unless tied to upstream workload, web, host, file, identity, or application evidence.

YARA and Artifact-Hunting Sources

·        Recovered files.

·        Memory captures.

·        Incident-response collections.

·        Malware-analysis outputs.

·        Webroot forensic images.

·        Endpoint quarantine artifacts.

YARA and Artifact-Hunting Artifacts

·        Recovered web shell content.

·        Recovered payloads or droppers.

·        Stable modified application artifacts.

·        Stable memory artifacts.

·        Reusable file-content patterns.

·        Recovered staging or tooling artifacts.

YARA and Artifact-Hunting Detection Value

YARA has no primary detection role in this report. YARA becomes useful only if stable artifacts are recovered and validated during incident response.

Artifact Reliability Assessment

·        High reliability comes from correlated web, process, file, network, identity, and cloud-control-plane sequences tied to the same application or workload boundary.

·        Medium reliability comes from strong single-domain evidence, such as IIS worker-process child execution or suspicious file modification, that still needs supporting context.

·        Low reliability comes from isolated destination novelty, file extension, cloud alert, rare path access, object-storage access, or request-size outlier without corroborating evidence.

·        False-positive reduction depends on application ownership, change-control records, approved deployment paths, approved destination inventories, known-good baselines, and local workload mapping.

Bottom Line

The highest-value artifacts are correlated sequences, not individual indicators. The model is strongest when abnormal ASP.NET request activity is followed by IIS execution, application-file modification, rare path access, suspicious egress, or cloud-side follow-on behavior within the same normalized application or workload boundary.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Section Purpose

This section provides SOC implementation guidance for operationalizing the S21 through S27 detection model. The guidance supports translation of the locked rule families into validated workflows, triage logic, escalation criteria, and production deployment steps.

Operational Position

The detection strategy should be implemented as a correlated detection model, not isolated single-event alerting. The SOC should prioritize event sequences that connect web precursors, endpoint behavior, file changes, network egress, and cloud-side follow-on activity to the same affected ASP.NET application or workload boundary.

Implementation Priorities

·        Confirm the inventory of exposed ASP.NET and IIS-hosted applications.

·        Identify applications using ViewState-bearing, state-heavy, authentication-adjacent, upload, administrative-adjacent, LMS, vendor-portal, or workflow-heavy routes.

·        Map IIS servers, application pools, application pool identities, webroot paths, upload paths, vendor application paths, load balancer backends, and cloud workload boundaries.

·        Validate web telemetry coverage before enabling high-confidence web precursor alerts.

·        Validate endpoint process and file telemetry before enabling high-confidence host compromise alerts.

·        Validate DNS, firewall, proxy, NDR, and cloud network telemetry before enabling egress correlation alerts.

·        Validate cloud audit, identity, secret, key, storage, and object-access telemetry before enabling cloud-side follow-on alerts.

·        Maintain approved deployment, backup, monitoring, vendor support, reporting, and incident-response exception inventories.

·        Require local false-positive baselining before alert-mode deployment.

SOC Triage Workflow

Step One

Confirm the affected application boundary.

·        Identify the application name, IIS server, backend host, load balancer target, cloud workload, application pool identity, and exposed route.

·        Determine whether the event belongs to an internet-facing workload, internal workload, vendor-managed portal, LMS workflow, authentication-adjacent application, or administrative-adjacent workflow.

·        Validate whether the affected host or workload is in scope for ASP.NET ViewState risk.

Step Two

Review web precursor activity.

·        Check for abnormal POST behavior.

·        Check for request-size outliers against endpoint-specific baselines.

·        Check for error-to-success patterns.

·        Check for HTTP 500-series bursts.

·        Check for rare source IPs, rare ASNs, hosting-provider sources, anonymization infrastructure, or unusual user agents.

·        Check for rare or newly observed path access.

·        Check for WAF, reverse proxy, load balancer, or application anomaly context.

Step Three

Review endpoint and file activity.

·        Check whether w3wp.exe, an IIS worker process, or an application pool identity spawned unusual child processes.

·        Review command-line content for encoded execution, hidden execution, remote retrieval, temporary-path execution, archive extraction, or execution from application-controlled paths.

·        Review file creation or modification under webroot, upload, plugin-like, login, component, configuration, temporary ASP.NET compilation, or vendor application paths.

·        Check whether file activity was performed by IIS, an application pool identity, a suspicious child process, or an approved deployment process.

·        Compare file activity against change-control and maintenance-window records.

Step Four

Review network and egress activity.

·        Check whether the affected host or workload contacted newly observed, rare, direct-IP, dynamic DNS, low-reputation, unusual-port, or unapproved destinations.

·        Check whether outbound activity followed web, endpoint, or file precursor activity.

·        Check whether endpoint telemetry links network activity to IIS worker processes, command shells, PowerShell, script interpreters, or network utilities.

·        Check approved destination inventories, vendor dependencies, monitoring systems, backup systems, deployment tools, and business integrations before escalation.

Step Five

Review cloud-side activity where applicable.

·        For AWS-hosted workloads, review Secrets Manager, KMS, STS, SSM, IAM, metadata, S3, and CloudTrail activity tied to the affected workload boundary.

·        For Azure-hosted workloads, review Key Vault, managed identity, run-command, role assignment, extension, Activity Log, Storage, and Entra ID activity tied to the affected workload boundary.

·        For GCP-hosted workloads, review Secret Manager, Cloud KMS, service account, OS Login, IAM, Compute Engine, Cloud Storage, and Cloud Audit activity tied to the affected workload boundary.

·        Do not escalate cloud-only events as exploitation-related unless upstream web, host, file, identity, or application evidence exists.

Step Six

Assess incident confidence.

·        Increase confidence when multiple telemetry domains align within a coherent time sequence.

·        Increase confidence when suspicious web activity is followed by IIS child-process execution.

·        Increase confidence when IIS child-process execution is followed by application-file modification or server egress.

·        Increase confidence when file modification is followed by rare path access.

·        Increase confidence when host compromise indicators are followed by cloud secret, key, identity, object-storage, metadata, or control-plane activity.

·        Reduce confidence when behavior aligns with approved deployment, maintenance, backup, reporting, vendor support, monitoring, or incident-response workflows.

Alert Prioritization Guidance

High Priority

·        Suspicious ASP.NET request activity followed by IIS worker-process child execution.

·        IIS worker-process child execution followed by suspicious file modification or server egress.

·        Suspicious application-file modification followed by rare path access.

·        Suspicious host activity followed by cloud secret, key, identity, metadata, object-storage, or control-plane activity.

·        Any correlated sequence involving internet-facing ASP.NET workloads, authentication-adjacent paths, privileged workload identities, sensitive secrets, sensitive keys, or sensitive storage.

Medium Priority

·        Abnormal ASP.NET request activity with repeated variation, request-size outliers, rare source infrastructure, or WAF anomaly context but no host follow-on evidence.

·        Suspicious file modification under protected application paths without confirmed web access or process linkage.

·        Rare destination egress from an IIS server without confirmed process linkage but with suspicious web precursor activity.

·        Cloud-side activity involving unusual secrets, keys, storage, or identity behavior with weak but plausible workload-boundary evidence.

Low Priority

·        Isolated request-size outliers without source, error, path, process, file, or network correlation.

·        Isolated rare destination communication without web, host, or file precursor evidence.

·        Isolated file extension matches without suspicious process or path context.

·        Isolated cloud alerts without workload-boundary mapping or upstream host evidence.

·        Known deployment, patching, backup, monitoring, reporting, vendor support, or incident-response activity.

False-Positive Control

·        Maintain approved deployment tool inventories.

·        Maintain approved backup and monitoring inventories.

·        Maintain approved vendor support workflows.

·        Maintain approved reporting and automation job lists.

·        Maintain approved destination inventories for each IIS or cloud-hosted workload.

·        Maintain approved webroot, upload, temporary, cache, plugin, and vendor application path inventories.

·        Maintain approved cloud secret, key, identity, bucket, storage account, container, prefix, and object dependency maps.

·        Validate maintenance windows and emergency change records.

·        Use application-owner review for newly observed application paths or unexpected file modifications.

·        Use baseline windows appropriate to each application’s deployment cadence and business cycle.

Hunt-to-Alert Promotion Criteria

·        Promote to alert mode only after field mapping is validated.

·        Promote to alert mode only after application and workload inventories are validated.

·        Promote to alert mode only after approved exceptions are implemented.

·        Promote to alert mode only after false-positive baselines are reviewed.

·        Promote to alert mode only after SOC triage steps are documented.

·        Promote to alert mode only after query performance is tested.

·        Promote to alert mode only after sample alerts are reviewed with application owners.

·        Promote high-severity alerting only when multiple telemetry domains can be correlated with reliable event-pair timing.

Production Validation Requirements

·        Validate SIEM indices, sourcetypes, schemas, custom properties, field names, and parser output.

·        Validate endpoint process lineage and command-line availability.

·        Validate file telemetry and responsible-process fields.

·        Validate WAF, proxy, load balancer, and IIS path normalization.

·        Validate DNS, firewall, proxy, and network telemetry mapping.

·        Validate cloud audit logging, storage data-access logging, secret access logging, key management logging, and identity logging.

·        Validate workload-boundary correlation for AWS, Azure, and GCP.

·        Validate NAT attribution, backend target mapping, load balancer mapping, and application-boundary enrichment.

·        Validate reference sets, reference maps, lookup tables, and exception lists.

·        Validate false-positive rates under normal deployment, backup, reporting, vendor support, and incident-response activity.

·        Validate SOC escalation paths and incident handoff procedures.

SOC Escalation Recommendation

Escalate when a sequence ties suspicious ASP.NET request behavior to host execution, file modification, rare path access, suspicious egress, or cloud-side follow-on activity within the same normalized application or workload boundary. Do not escalate isolated request anomalies, file extensions, direct-IP egress, cloud findings, or object-storage activity as confirmed exploitation without supporting evidence.

Bottom Line

The SOC implementation should prioritize correlation quality over alert volume. The detection model is most effective when web, endpoint, file, network, and cloud events are normalized to the same application boundary and reviewed as a single behavioral chain.

S29 — Detection Coverage Summary

Section Purpose

This section summarizes the detection coverage provided by the S21 through S28 detection model. It identifies where coverage is strong, where coverage is conditional, and where residual gaps remain.

Coverage Position

The detection model provides broad behavior-led coverage for ASP.NET ViewState deserialization and shared machineKey exploitation paths. The model is designed to identify suspicious exploitation attempts, server-side execution, application tampering, outbound communication, and cloud-side follow-on activity without relying on exploit payload strings or static artifacts.

Strong Coverage Areas

Suspicious ASP.NET Request Behavior

·        Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP where web telemetry is available.

·        Strongest when IIS, WAF, reverse proxy, load balancer, edge, or application logs contain request method, URI path, status code, source, user-agent, response size, and request-size context.

·        Strongest when request-size baselines, path rarity baselines, source rarity baselines, and application route mapping are available.

IIS Worker-Process Child Execution

·        Covered by SentinelOne, Splunk, Elastic, QRadar, SIGMA, and cloud rules as host precursor evidence.

·        Strongest when parent process, child process, command line, process user, process tree, host identity, and application pool identity are available.

·        Strongest when correlated to suspicious ASP.NET request activity.

Suspicious Application-File Modification

·        Covered by SentinelOne, Splunk, Elastic, QRadar, SIGMA, and cloud rules as host precursor evidence.

·        Strongest when file path, responsible process, parent process, user, host, hash, file size, protected path inventory, and change-control context are available.

·        Strongest when file modification is followed by rare path access, process execution, or outbound communication.

Rare or Newly Observed Application-Path Access

·        Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP where web telemetry and path baselines are available.

·        Strongest when URI path normalization, file-to-URL mapping, application route mapping, and path first-seen logic are available.

·        Strongest when correlated to suspicious file modification or IIS process execution.

Suspicious Server Egress

·        Covered by NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

·        Strongest when egress follows suspicious web, endpoint, or file activity.

·        Strongest when process-to-network mapping, DNS telemetry, destination first-seen enrichment, approved destination inventories, and workload-boundary mapping are available.

Cloud-Side Follow-On Activity

·        Covered by AWS, Azure, and GCP for cloud-hosted workloads.

·        Strongest when cloud audit logs, identity logs, secret access logs, key management logs, storage data-access logs, workload identity mappings, and sensitive-resource inventories are available.

·        Strongest when cloud-side behavior follows upstream web, host, file, identity, or workload-boundary evidence.

Conditional Coverage Areas

Artifact Hunting

·        YARA has zero primary rules.

·        Coverage becomes available only when stable web shells, payloads, droppers, memory artifacts, modified application files, or reusable file-content patterns are recovered.

·        Artifact hunting is investigative, not primary detection.

Cloud Storage and Object-Staging Activity

·        Coverage depends on storage data-access logging, workload-to-storage dependency maps, bucket or storage account baselines, prefix baselines, and sensitive-resource mapping.

·        Storage activity alone is not proof of exploitation or data theft.

·        Coverage is strongest when storage activity follows host compromise indicators.

Cloud Identity, Secret, and Key Activity

·        Coverage depends on audit log completeness, identity mapping, service account or managed identity mapping, role-to-resource mapping, secret baselines, key baselines, and sensitive-resource inventories.

·        Cloud-only anomalies should not be attributed to this exploit path without upstream workload evidence.

·        Coverage is strongest when suspicious cloud-side activity follows IIS execution, file modification, suspicious egress, or credential-access behavior.

In-Process Exploitation Without Follow-On Activity

·        Coverage is limited when exploitation remains fully in-process.

·        Detection confidence is reduced when there is no child-process execution, file modification, rare path access, outbound communication, cloud activity, or visible application error pattern.

·        Application logs and exception telemetry may provide limited supporting evidence.

Major Coverage Dependencies

·        IIS and application logging.

·        WAF, reverse proxy, load balancer, and edge logging.

·        Endpoint process telemetry.

·        Endpoint command-line visibility.

·        Endpoint file telemetry.

·        Endpoint network telemetry.

·        DNS, firewall, proxy, and NDR telemetry.

·        Cloud audit logs.

·        Cloud identity logs.

·        Cloud secret, key, and storage logs.

·        Workload-boundary mapping.

·        Application inventory.

·        Application pool identity mapping.

·        Cloud identity and resource mapping.

·        NAT attribution.

·        File-to-URL mapping.

·        Path and destination baselines.

·        Approved deployment and change-control records.

Residual Gaps

·        Fully in-process activity without observable file, process, network, path, cloud, or error artifacts may evade high-confidence detection.

·        Environments without endpoint telemetry may miss IIS worker-process child execution and responsible-process file context.

·        Environments without WAF, IIS, load balancer, or application logs may miss initial request precursors.

·        Environments without file telemetry may miss application-content tampering and artifact staging.

·        Environments without DNS, proxy, firewall, NDR, or endpoint network telemetry may miss suspicious egress.

·        Environments without cloud audit, identity, secret, key, or storage logs may miss cloud-side follow-on behavior.

·        Environments with weak workload-boundary mapping may struggle to correlate web, endpoint, network, and cloud events.

·        Environments with noisy deployment workflows may require additional baselining before alert-mode deployment.

Coverage Confidence

High Confidence

·        Suspicious ASP.NET request activity followed by IIS worker-process child execution.

·        IIS worker-process child execution followed by suspicious file modification or outbound communication.

·        Suspicious file modification followed by rare or newly observed application-path access.

·        Suspicious host activity followed by cloud secret, key, identity, object-storage, metadata, or control-plane activity.

·        Multi-domain event chains tied to the same normalized application or workload boundary.

Medium Confidence

·        Abnormal ASP.NET request activity with source rarity, path rarity, error patterns, or WAF anomaly context but no host follow-on evidence.

·        Suspicious file modification under protected application paths with partial process context.

·        Server egress to rare or newly observed destinations with weak process linkage but strong web precursor context.

·        Cloud-side anomalies with plausible but incomplete workload-boundary mapping.

Low Confidence

·        File extension matches without suspicious process, path, timing, or web context.

·        Direct-IP egress without web, host, file, or identity context.

·        Request-size outliers without path, source, error, host, or follow-on evidence.

·        Cloud-only alerts without upstream workload evidence.

·        Object-storage access without host, identity, application, or workload precursor evidence.

Detection Coverage Bottom Line

The detection model provides strong coverage for observable exploitation chains and post-exploitation behavior. Coverage is strongest when web, endpoint, file, network, and cloud telemetry are correlated to the same application or workload boundary. Coverage is weakest when activity remains fully in-process, telemetry is incomplete, or local mappings cannot connect precursor and follow-on events.

S30 — Intelligence Maturity Assessment

Section Purpose

This section assesses the intelligence maturity of the detection model for ASP.NET ViewState deserialization and shared machineKey exploitation. The assessment considers behavioral durability, telemetry dependence, operational readiness, false-positive control, and suitability for production SOC implementation.

Intelligence Maturity Position

The intelligence maturity level is high for behavior-led detection and moderate for exploit-specific confirmation. The report provides durable detection logic for suspicious request activity, IIS execution, application-file modification, rare path access, server egress, and cloud-side follow-on behavior. It does not claim deterministic identification of the exploit vector from a single event.

Maturity Rating

High for behavior-led detection engineering.

Moderate for exploit-specific confirmation.

High for SOC triage and correlation guidance.

Moderate for environments with incomplete telemetry or weak workload-boundary mapping.

Behavioral Durability

·        The detection model is resilient to changes in payload syntax, proof-of-concept strings, web shell filenames, infrastructure, hash values, or attacker-selected artifacts.

·        The model focuses on durable behaviors that are difficult to fully avoid after meaningful server-side compromise.

·        The model remains useful when the adversary changes request structure, staging method, destination infrastructure, file naming, command syntax, or cloud API timing.

·        The model is less durable against activity that remains fully in-process and produces no visible file, process, network, path, cloud, or error artifacts.

Telemetry Maturity

·        Web telemetry maturity is required to detect suspicious ASP.NET request precursors.

·        Endpoint telemetry maturity is required to validate IIS worker-process execution, command-line behavior, file modification, and process-linked egress.

·        Network telemetry maturity is required to identify suspicious egress and rare destination behavior.

·        Cloud telemetry maturity is required to identify secret, key, identity, storage, metadata, and control-plane follow-on activity.

·        Inventory maturity is required to map application boundaries, workload identities, cloud resources, application pool identities, webroot paths, and approved dependencies.

·        Without sufficient telemetry maturity, the model remains useful for hunting but should not be promoted directly to high-confidence alerting.

Analytic Confidence

High Confidence Conditions

·        Suspicious ASP.NET request activity aligns with IIS worker-process child execution.

·        IIS worker-process execution aligns with suspicious command-line behavior, file modification, or server egress.

·        Suspicious file modification aligns with rare or newly observed application-path access.

·        Host compromise indicators align with cloud secret, key, identity, storage, metadata, or control-plane activity.

·        Multiple telemetry domains align within a defensible timing window.

·        Events are tied to the same normalized application or workload boundary.

Moderate Confidence Conditions

·        Suspicious web activity is present without host follow-on evidence.

·        Suspicious file modification is present without web or process correlation.

·        Suspicious egress is present with weak process linkage but plausible web or workload precursor evidence.

·        Cloud-side anomalies are present with partial workload-boundary mapping.

·        Local baselines are incomplete but supporting context exists.

Low Confidence Conditions

·        Isolated file extension matches.

·        Isolated request-size outliers.

·        Isolated direct-IP communication.

·        Isolated rare destination access.

·        Isolated cloud secret, key, identity, or storage activity.

·        Cloud-only alerts without upstream workload evidence.

·        Any single event lacking application, host, identity, or workload correlation.

Operational Maturity

·        The model is suitable for structured SOC hunting after local field mapping.

·        The model is suitable for alert-mode deployment after exception handling, false-positive baselining, workload-boundary mapping, query-performance testing, and SOC triage validation.

·        The model is suitable for executive reporting because it links technical behaviors to operational exposure and follow-on risk.

·        The model is suitable for cloud-hosted workload monitoring when cloud logs can be correlated to upstream host and web evidence.

·        The model is not suitable for standalone exploit confirmation without corroborating telemetry.

False-Positive Maturity

·        False-positive control depends on approved deployment workflows.

·        False-positive control depends on vendor support and maintenance-window records.

·        False-positive control depends on backup, reporting, monitoring, and automation inventories.

·        False-positive control depends on approved destination inventories.

·        False-positive control depends on approved cloud secret, key, identity, storage, and control-plane baselines.

·        False-positive control depends on application-owner validation for file changes and rare path activity.

·        The model should begin in hunting or medium-severity mode before high-severity alerting is enabled.

Collection Maturity Requirements

·        Maintain complete IIS and ASP.NET application logging.

·        Maintain WAF, reverse proxy, load balancer, and edge logging.

·        Maintain endpoint process, command-line, file, and network telemetry.

·        Maintain DNS, proxy, firewall, and NDR telemetry.

·        Maintain cloud audit, identity, secret, key, storage, metadata, and control-plane logs where applicable.

·        Maintain application inventory, webroot inventory, application pool identity mapping, cloud workload mapping, and approved dependency inventories.

·        Maintain change-control, maintenance-window, and incident-response records for triage context.

Intelligence Gaps

·        Single-event telemetry cannot reliably prove ViewState deserialization or shared machineKey exploitation.

·        Public reporting may not provide stable payload, artifact, or infrastructure indicators suitable for durable detection.

·        Application-specific ViewState behavior varies significantly across environments.

·        Shared machineKey exposure may be difficult to infer directly from telemetry.

·        Fully in-process exploitation may produce limited observable telemetry.

·        Cloud-side activity may be difficult to attribute without workload-boundary mapping.

·        YARA coverage remains conditional because no stable artifact governs the primary detection model.

Maturity Improvement Path

·        Improve application inventory and route classification.

·        Build endpoint-specific request-size and path-frequency baselines.

·        Normalize IIS, WAF, proxy, and load balancer paths.

·        Map file paths to URL paths and application routes.

·        Improve application pool identity mapping.

·        Improve process-to-network attribution.

·        Build approved destination inventories for each workload.

·        Build cloud workload-boundary mappings across AWS, Azure, and GCP.

·        Build sensitive secret, key, storage, and object-resource inventories.

·        Validate rule outputs with application owners.

·        Promote only validated, low-noise correlations from hunt mode to alert mode.

Intelligence Maturity Assessment

The detection model is mature for behavior-led detection and SOC triage. It is strongest when applied as a correlated detection strategy across web, endpoint, file, network, and cloud telemetry. It should not be used as a single-event exploit-confirmation model. The intelligence value comes from linking suspicious ASP.NET request behavior to host execution, application-file modification, rare path access, server egress, and cloud-side follow-on activity within the same normalized application or workload boundary.

S31 — Telemetry Dependencies

ASP.NET ViewState deserialization and shared machineKey exploitation detection and response depends on the organization’s ability to reconstruct a single exposure timeline across public request activity, IIS-hosted application behavior, endpoint execution, file modification, credential access, outbound communication, user-side delivery, cloud or identity activity, and change-control evidence. The primary dependency is not one specific tool, but the ability to prove which ASP.NET asset was targeted, whether suspicious ViewState-bearing activity reached a state-bearing endpoint, whether IIS server-side execution occurred, whether application files or user-facing content changed, whether credentials or users were exposed, and whether activity expanded beyond the ASP.NET application boundary.

Web, WAF, and Request Telemetry

·        WAF, CDN, reverse proxy, load balancer, application gateway, IIS web server, and ASP.NET application logs showing URI path, request method, source IP, user-agent, referrer, response code, request timing, bytes received, bytes sent, response size, request disposition, upstream routing, and blocked or allowed request status.

·        Request visibility for ViewState-bearing POST activity, abnormal request size, unusual bytes received, endpoint-specific request bursts, sparse targeted requests, repeated request variation, unexpected endpoint targeting, abnormal request cadence, suspicious allowed traffic, and error-to-success transitions.

·        WAF normalization and inspection output showing decoded payload indicators, blocked suspicious traffic, allowed suspicious traffic, request-size anomalies, request-body inspection results, repeated retrial after blocking, and bypass-like encoding or routing behavior.

·        Response behavior telemetry showing repeated 400-series or 500-series responses, response-size variation, response-time changes, redirects, backend timeouts, failed request traces, application pool instability, and error-to-success transitions.

ASP.NET and IIS Application Telemetry

·        ASP.NET application logs showing validation failures, unhandled exceptions, application workflow anomalies, authentication anomalies, administrative workflow anomalies, configuration changes, content changes, and application-specific error conditions.

·        IIS logs and failed request tracing showing endpoint paths, request methods, substatus codes, Win32 status, time taken, bytes received, bytes sent, referrer, authenticated user where available, and endpoint-specific failure clusters.

·        IIS application pool telemetry showing crashes, hangs, rapid-fail protection events, worker-process recycling, abnormal restarts, resource exhaustion, and timing relationships to suspicious request windows.

·        Application context showing affected endpoint family, ViewState-bearing page, ASP.NET WebForms workflow, authentication-adjacent path, administrative-adjacent path, LMS workflow, upload path, plugin-like path, document delivery path, courseware delivery path, login-related workflow, and user-facing form.

·        Deployment, vendor-support, and change-control records showing approved application updates, configuration changes, content updates, plugin changes, courseware changes, emergency fixes, support access, and maintenance windows.

Endpoint, File, and IIS Workload Telemetry

·        Endpoint process telemetry from IIS-hosted servers showing process creation, parent-child process lineage, command-line arguments, process start and stop times, user context, process integrity context, signer context, hash context, and process reputation where available.

·        Parent-child process relationships involving w3wp.exe, IIS worker processes, ASP.NET application processes, application pool identities, command shells, script interpreters, archive utilities, file-transfer utilities, living-off-the-land binaries, credential utilities, and network utilities.

·        File creation, modification, deletion, rename, overwrite, permission-change, and timestamp-change events in webroot directories, vendor application folders, upload directories, plugin-like directories, JavaScript locations, configuration paths, login-page locations, downloadable-component paths, temporary ASP.NET compilation paths, and application-controlled directories.

·        File integrity monitoring for ASPX files, DLLs, JavaScript files, configuration files, HTML content, archives, executables, scripts, temporary artifacts, downloadable components, and web shell-like artifacts.

·        Responsible-process telemetry linking file activity to w3wp.exe, application pool identities, IIS-adjacent processes, script interpreters, suspicious IIS child processes, deployment tools, build tools, backup tools, cache generation processes, vendor-support utilities, or administrative workflows.

Credential, Secrets, and Identity Telemetry

·        Access to ASP.NET configuration files, database credentials, environment variables, application pool identity material, service-account tokens, API keys, deployment secrets, vendor-support credentials, backup credentials, cloud credential paths, and other credential-adjacent artifacts.

·        Identity and cloud logs showing service-account use, application pool identity behavior, workload identity use, token access, secrets retrieval, IAM changes, managed database access, object storage access, SaaS access, conditional-access events, and control-plane interaction after suspected ASP.NET exploitation.

·        Privileged administrative access records for IIS administrators, application owners, database administrators, vendor-support accounts, cloud administrators, CI/CD users, deployment users, and service accounts.

·        Session and account telemetry showing unfamiliar administrative source context, failed-to-successful administrative access patterns, unusual service account use, new privileged sessions, suspicious token use, or anomalous identity behavior following user-side delivery or credential exposure.

Network, DNS, Egress, and Cloud Telemetry

·        DNS, proxy, firewall, secure web gateway, NDR, egress gateway, endpoint-network, and cloud-network telemetry showing outbound callbacks, newly observed domains, randomized hostnames, direct IP egress, uncommon ports, rare destinations, unusual TLS metadata, external script retrieval, payload retrieval, and abnormal transfer behavior.

·        Network-flow telemetry linking outbound activity to the IIS host, ASP.NET application host, load balancer backend, application pool boundary, service account, workload identity, or hosting boundary associated with suspicious request activity.

·        Internal network telemetry showing access from the IIS workload boundary to databases, identity services, metadata services, secrets stores, object storage, backup systems, CI/CD resources, monitoring systems, management interfaces, and administrative consoles.

·        Cloud control-plane telemetry showing metadata access, secrets retrieval, object storage access, managed database access, IAM changes, workload identity use, service-account activity, SaaS access, and management-plane access after suspected IIS or application compromise.

User Endpoint and Exposure Telemetry

·        User access telemetry identifying which users, devices, browsers, source networks, sessions, or external user populations interacted with the affected ASP.NET application during the suspected exposure window.

·        Browser download, proxy, DNS, secure web gateway, EDR, and endpoint timeline telemetry showing suspicious downloads, fake component retrieval, external script loading, suspicious browser child-process behavior, beacon-like activity, or post-download malware behavior.

·        Endpoint detections from exposed users showing suspicious execution chains, credential access, persistence attempts, beacon-like communication, or Cobalt Strike-like behavior temporally aligned with application access.

·        User population context showing whether affected users were employees, customers, students, contractors, partners, external users, unmanaged devices, or managed endpoints with sufficient telemetry for exposure scoping.

Telemetry Dependency Summary

·        Web and WAF telemetry establishes whether suspicious external request activity targeted ASP.NET-facing functionality.

·        ASP.NET and IIS telemetry establishes whether request activity produced application errors, validation failures, failed request traces, worker-process instability, application pool recycling, or endpoint-specific anomalies.

·        Endpoint and file telemetry establishes whether exploitation moved into IIS execution, application-file modification, web shell-like access, content tampering, credential access, or persistence.

·        User endpoint telemetry establishes whether modified application content, fake components, suspicious downloads, or malicious user-side behavior followed interaction with the affected application.

·        Network, DNS, egress, identity, and cloud telemetry establishes whether activity expanded into callback behavior, payload retrieval, staging, credential use, SaaS access, or cloud-hosted resources.

·        Change-control, asset, vulnerability, vendor-support, deployment, and maintenance records establish whether observed behavior was authorized, expected, or suspicious.

S32 — Detection Limitations

ASP.NET ViewState deserialization and shared machineKey exploitation detection is limited by the fact that activity can begin as ordinary internet noise, malformed request traffic, WAF-blocked probes, application errors, legitimate postback behavior, or approved administrative activity. A suspicious ViewState-bearing request, large POST body, IIS error, application pool recycle, file change, outbound connection, user endpoint alert, or cloud event is not inherently proof of successful exploitation. Risk emerges from the relationship between suspicious request activity, ASP.NET and IIS behavior, file changes, credential access, outbound communication, user-side delivery, and downstream identity or cloud activity.

Request and Web-Layer Limitations

·        WAF, CDN, reverse proxy, application gateway, load balancer, IIS, and web server logs may not retain full request parameters, request bodies, decoded payloads, normalization output, upstream context, bytes received, or ViewState-relevant metadata.

·        TLS termination, proxy aggregation, CDN abstraction, NAT, managed hosting, shared infrastructure, and vendor-managed portals can reduce visibility into source context, request structure, and workload attribution.

·        Large ViewState-bearing requests, blocked WAF events, repeated malformed requests, source novelty, request volume, or scanner-like behavior may reflect probing or testing rather than successful exploitation.

·        Successful exploitation may not produce obvious payload strings, visible ViewState markers, blocked WAF events, noisy response behavior, or a stable network signature if the attacker uses well-formed application-specific requests.

ASP.NET and IIS Application Limitations

·        ASP.NET and IIS logging depth varies by hosting model, application configuration, vendor management model, logging configuration, failed request tracing coverage, and operational maturity.

·        Application logs may not capture detailed ViewState validation behavior, authentication workflow anomalies, administrative workflow changes, configuration changes, user-facing content changes, or application-specific state transitions unless audit depth is sufficient.

·        Legitimate application maintenance, vendor support, deployment activity, content updates, plugin changes, courseware updates, reporting jobs, backup jobs, cache generation, and emergency fixes may resemble suspicious application behavior.

·        Application errors, validation failures, failed request traces, HTTP 500-series responses, and application pool instability should be treated as supporting evidence, not standalone compromise evidence.

Endpoint, File, and IIS Workload Limitations

·        Hosted, vendor-managed, shared hosting, containerized, platform-as-a-service, or externally maintained ASP.NET environments may limit endpoint process visibility, file telemetry, command-line capture, application pool identity mapping, and webroot forensic detail.

·        Short-lived execution, in-process execution, memory-resident behavior, or runtime abuse may not leave durable file artifacts or obvious child-process telemetry.

·        File changes may be legitimate when caused by deployment automation, vendor support, content updates, plugin updates, backup activity, cache generation, build processes, reporting workflows, or administrative maintenance.

·        Endpoint execution or file modification should not be attributed to ASP.NET ViewState exploitation unless it occurs on the affected IIS host, application boundary, application pool context, or related workload after suspicious upstream web activity.

User Endpoint and Content-Delivery Limitations

·        User-side delivery may be difficult to prove when users access affected applications from unmanaged devices, external networks, contractors, students, partners, or endpoints outside enterprise telemetry coverage.

·        Suspicious downloads, fake component execution, browser child-process behavior, or endpoint detections after application access may be coincidental unless supported by access logs, browser history, download telemetry, proxy records, EDR timelines, or content-change evidence.

·        Application-content tampering may be missed when JavaScript, login pages, downloadable components, external script references, and user-facing prompts are not monitored against known-good baselines.

·        Absence of user endpoint detections does not prove that users were not exposed when endpoint coverage, proxy retention, browser telemetry, or secure web gateway visibility is incomplete.

Cloud, Credential, and Expansion Limitations

·        Cloud telemetry may show identity, storage, secrets, managed database, metadata, SaaS, or object storage access without enough upstream application context to prove ASP.NET exploitation.

·        Service-account use, application pool identity behavior, metadata access, secrets retrieval, object storage access, CI/CD access, managed database access, and cloud-control-plane activity may be legitimate during deployment, backup, monitoring, scaling, vendor support, or administrative workflows.

·        Absence of a cloud alert does not prove that credentials were not accessed or that cloud-hosted resources were not reached.

·        Cloud, SaaS, or infrastructure activity should remain conditional unless mapped to the ASP.NET workload boundary, exposed user population, stolen credentials, or user endpoint compromise and correlated with suspicious upstream web, application, file, credential, endpoint, network, identity, or cloud evidence.

Attribution and Classification Limitations

·        The report should not classify activity as confirmed ASP.NET ViewState deserialization or shared machineKey exploitation based on a single suspicious request, WAF alert, large POST, application error, file write, outbound connection, endpoint alert, or cloud event.

·        Activity should be described as aligned with the ASP.NET ViewState deserialization and shared machineKey exploitation path only when the behavior chain matches suspicious ViewState-bearing activity followed by IIS execution, application-file change, web shell-like access, credential access, outbound communication, user-side delivery, or downstream expansion evidence.

·        Confirmed compromise, confirmed credential access, confirmed user-side delivery, confirmed persistence, confirmed exfiltration, and confirmed cloud expansion require incident-specific validation.

·        Actor attribution should remain out of scope unless supported by separate incident intelligence, validated infrastructure overlap, intrusion evidence, or external reporting.

S33 — Defensive Control & Hardening Improvements

ASP.NET ViewState deserialization and shared machineKey exploitation risk reduction depends on strengthening internet-facing application exposure management, machineKey governance, WAF coverage, IIS and ASP.NET logging, endpoint and file visibility, credential protection, user-exposure scoping, cloud workload controls, and response readiness. The most effective improvements reduce the likelihood that malicious state-bearing request activity reaches vulnerable functionality, limit the blast radius of a compromised IIS workload, and improve the organization’s ability to prove what application files, credentials, user endpoints, or downstream resources were affected.

ASP.NET Exposure and MachineKey Hardening

·        Maintain a current inventory of internet-facing ASP.NET assets, ViewState-dependent workflows, machineKey configuration ownership, application versions, hosting models, WAF placement, CDN paths, reverse proxy paths, load balancer paths, application owners, and business criticality.

·        Prioritize emergency configuration validation for internet-facing ASP.NET applications, LMS platforms, customer portals, authentication-adjacent workflows, vendor-managed portals, partner access systems, and business-critical IIS-hosted applications.

·        Ensure machineKey values are unique, intentionally managed, protected, rotated when required, and not reused across unrelated ASP.NET applications unless a documented and secure architecture requires it.

·        Remove or restrict unnecessary exposed WebForms endpoints, administrative-adjacent paths, upload paths, plugin-like paths, legacy functionality, test pages, and state-bearing workflows that do not require public exposure.

·        Require documented change-control evidence for emergency machineKey remediation, application updates, content updates, configuration changes, vendor-support activity, plugin changes, courseware changes, and maintenance windows.

WAF, Web, and Application Hardening

·        Tune WAF, CDN, reverse proxy, application gateway, and load balancer controls for abnormal ViewState-bearing POST activity, unusual request sizes, unexpected bytes received, repeated request variation, sparse targeted requests, suspicious allowed traffic, and response-code shifts.

·        Enforce request normalization, body inspection where feasible, route-specific protections, rate controls, administrative path restrictions, authentication-adjacent path monitoring, and monitoring for error-to-success transitions or abnormal response behavior.

·        Restrict administrative and vendor-support paths using strong authentication, source restrictions, private access where appropriate, step-up controls, and administrative session monitoring.

·        Improve ASP.NET and IIS audit logging for validation failures, application exceptions, failed request traces, authentication workflow anomalies, administrative workflow anomalies, configuration changes, content changes, and application-specific error conditions.

·        Separate public content delivery paths from administrative functions, upload workflows, downloadable components, and high-risk application workflows where operationally feasible.

IIS, File, and Workload Hardening

·        Apply file integrity monitoring to webroot paths, vendor application folders, upload directories, plugin-like paths, JavaScript directories, configuration paths, login-page locations, downloadable component paths, temporary ASP.NET compilation directories, and application-controlled directories.

·        Restrict write permissions for IIS worker processes and application pool identities, and prevent executable content from being written or executed from upload, temporary, plugin-like, cache, or other writable application directories.

·        Harden IIS, ASP.NET runtime, application pool, container, workload, and web server configurations to reduce command execution, file-write, local discovery, script execution, and outbound communication opportunities.

·        Monitor for w3wp.exe child-process execution, command shells, script interpreters, archive utilities, network utilities, credential utilities, suspicious file staging, web shell-like access, and outbound communication from IIS-hosted application servers.

·        Enforce secure hosting baselines, least-privilege application pool identities, service-account governance, restricted administrative access, and clear workload identity boundaries.

Credential, Secrets, and Cloud Hardening

·        Store database credentials, API keys, deployment secrets, service-account tokens, application secrets, vendor-support credentials, backup credentials, and cloud credentials in managed secrets systems rather than static files where feasible.

·        Rotate database credentials, application secrets, service-account tokens, API keys, deployment credentials, vendor-support credentials, backup credentials, and cloud credentials after suspected exploitation or unexplained IIS-hosted activity.

·        Restrict ASP.NET workload access to metadata services, secrets stores, object storage, managed databases, CI/CD systems, backup systems, monitoring systems, SaaS platforms, and cloud control-plane resources.

·        Apply least privilege to application pool identities, service accounts, workload identities, IAM roles, managed database permissions, object storage permissions, SaaS permissions, and deployment automation.

·        Alert on metadata access, secrets retrieval, object storage access, managed database access, service-account use, IAM changes, workload identity use, SaaS access, and cloud control-plane activity after suspected IIS or application compromise.

User-Delivery and Content Integrity Hardening

·        Maintain known-good baselines for JavaScript files, login pages, authentication workflows, downloadable components, user-facing prompts, external script references, and security or authentication-related messages.

·        Monitor for unauthorized JavaScript changes, login-page modification, external script reference additions, fake component prompts, downloadable component changes, and altered user workflows.

·        Retain proxy, DNS, secure web gateway, browser download, and EDR telemetry for users who access exposed ASP.NET applications during suspected exposure windows.

·        Predefine user-exposure scoping workflows for employees, customers, students, contractors, partners, external users, managed endpoints, and unmanaged-device populations.

·        Ensure customer, student, partner, and external-user assurance workflows can be activated when application-content integrity or user-side delivery cannot be confidently ruled out.

Logging and Response Readiness

·        Extend retention for WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file integrity, DNS, proxy, NDR, egress, identity, cloud, asset, vulnerability, vendor-support, deployment, and change-control telemetry.

·        Normalize asset, host, application pool, service account, workload identity, request path, source, destination, user, device, endpoint, file path, and timestamp fields across security telemetry.

·        Pre-build response workflows for ASP.NET containment, machineKey remediation, WAF review, IIS forensic review, webroot restoration, file integrity validation, user-exposure scoping, credential rotation, cloud scoping, legal escalation, customer assurance, and vendor-management escalation.

·        Maintain playbooks for suspected ASP.NET ViewState exploitation, shared machineKey abuse, IIS child-process execution, web shell-like file activity, application-content tampering, credential exposure, unusual outbound communication, user-side delivery, and cloud-hosted expansion.

·        Validate that incident-response teams can rapidly answer which ASP.NET asset was targeted, whether exploitation succeeded, what files or content changed, which credentials were exposed, whether users were affected, whether outbound transfer occurred, and whether cloud-hosted resources were reached.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture for ASP.NET ViewState deserialization and shared machineKey exploitation should be built around a layered request-to-IIS-to-application-content-to-user-impact model. The architecture must assume that public-facing ASP.NET activity can become business-impacting exposure when suspicious ViewState-bearing request activity reaches IIS execution, application files, webroot content, credentials, outbound paths, user endpoints, or cloud-hosted resources.

Exposure Management Layer

·        Maintain authoritative inventory of internet-facing ASP.NET assets, ViewState-dependent workflows, machineKey ownership, machineKey reuse patterns, hosting model, WAF placement, CDN path, reverse proxy path, load balancer path, application ownership, vendor ownership, and business criticality.

·        Prioritize configuration and patch validation for public-facing ASP.NET applications, LMS platforms, customer portals, authenticated workflows, vendor-managed portals, support portals, partner access systems, and authentication-adjacent environments.

·        Track exposed WebForms endpoints, ViewState-bearing pages, administrative-adjacent paths, authentication-adjacent paths, upload paths, plugin-like paths, document delivery paths, courseware delivery paths, login workflows, and high-risk user-facing forms.

·        Link vulnerability management, asset ownership, machineKey governance, vendor-support records, change-control records, and business criticality to detection and response prioritization.

Request Control and Application Protection Layer

·        Enforce WAF, CDN, reverse proxy, application gateway, and load balancer protections for abnormal ViewState-bearing POST activity, unusual request sizes, repeated request variation, endpoint-specific probing, suspicious allowed traffic, and response-code shifts.

·        Apply route-aware protections for ViewState-bearing pages, WebForms workflows, authentication-adjacent paths, administrative-adjacent paths, LMS workflows, upload paths, plugin-like paths, login workflows, document delivery paths, and courseware delivery paths.

·        Restrict administrative paths, vendor-support paths, and high-risk ASP.NET workflows using strong authentication, network restrictions, step-up controls, approved source lists, and administrative session monitoring.

·        Monitor blocked and allowed suspicious request activity, request-size anomalies, request normalization anomalies, response-code shifts, response-time changes, backend timeouts, application pool instability, and error-to-success transitions.

IIS and Application Integrity Layer

·        Monitor ASP.NET validation failures, application exceptions, failed request traces, worker-process instability, application pool recycling, authentication workflow anomalies, administrative workflow anomalies, configuration changes, and application-file changes.

·        Monitor IIS worker-process behavior, w3wp.exe child-process execution, command-shell activity, script interpreter execution, archive utility use, network utility behavior, suspicious application pool identity activity, and unexpected process behavior.

·        Enforce least privilege for application pool identities, IIS service accounts, service accounts, deployment accounts, vendor-support access, and administrative roles.

·        Correlate ASP.NET and IIS events to WAF, web server, endpoint, file, source path, application pool identity, service account, workload identity, asset inventory, and change-control evidence.

Webroot and Content Integrity Layer

·        Monitor file creation, file modification, file deletion, file rename, permission changes, hash changes, signer changes, and timestamp changes under webroot, vendor application, upload, plugin-like, JavaScript, configuration, login-page, downloadable-component, and temporary compilation paths.

·        Apply known-good baselines to ASPX files, DLLs, JavaScript files, configuration files, login pages, downloadable components, user-facing prompts, external script references, and authentication workflows.

·        Restrict write and execution permissions for application-controlled directories, upload directories, temporary ASP.NET compilation locations, plugin-like paths, and other writable application paths.

·        Monitor rare path access, newly observed ASPX access, web shell-like interaction patterns, abnormal response-size patterns, repeated low-volume interaction, and access to recently modified application content.

Credential and Cloud Containment Layer

·        Store credentials and secrets in managed secrets systems and restrict direct access from the ASP.NET workload where feasible.

·        Apply least privilege to application pool identities, service accounts, workload identities, IAM roles, managed database access, object storage permissions, metadata access, CI/CD access, backup systems, SaaS platforms, and cloud management-plane resources.

·        Monitor metadata service access, secrets retrieval, object storage access, managed database access, IAM changes, service-account use, workload identity use, SaaS access, and control-plane activity after suspected IIS or application compromise.

·        Rotate database credentials, service-account tokens, application secrets, deployment secrets, vendor-support credentials, backup credentials, and cloud credentials after suspected credential access or unexplained IIS-hosted activity.

User-Exposure and Delivery Visibility Layer

·        Correlate application access, user identity, device identity, browser activity, proxy logs, DNS logs, secure web gateway logs, browser download telemetry, EDR telemetry, and endpoint timeline data for users who accessed the affected application during the suspected exposure window.

·        Track suspicious downloads, fake component retrieval, external script loading, browser child-process behavior, beacon-like endpoint activity, unfamiliar outbound connections, and post-download malware behavior after affected application access.

·        Monitor user-facing content changes involving JavaScript, login pages, authentication workflows, downloadable components, user prompts, external script references, and security or authentication messages.

·        Preserve evidence required for user-exposure scoping, customer assurance, student notification analysis, partner notification analysis, legal review, cyber insurance coordination, regulatory analysis, and executive reporting.

Transfer and Expansion Visibility Layer

·        Correlate DNS, proxy, firewall, NDR, egress gateway, cloud-network, endpoint-network, secure web gateway, and DLP telemetry with IIS workload context.

·        Track unusual outbound destinations, direct IP egress, uncommon ports, dynamic DNS, rare domains, unusual TLS metadata, abnormal transfer volume, external script retrieval, archive retrieval, payload retrieval, and callback-like behavior.

·        Monitor access from the ASP.NET workload boundary to internal services, database systems, identity services, metadata endpoints, secrets stores, object storage, CI/CD systems, backup systems, monitoring systems, SaaS platforms, and management interfaces.

·        Preserve evidence required for exposure scoping, credential containment, user-delivery analysis, customer assurance, legal review, cyber insurance coordination, regulatory analysis, and executive reporting.

Incident Governance Layer

·        Maintain decision workflows for ASP.NET containment, machineKey remediation, WAF review, IIS forensic review, webroot restoration, credential rotation, user-exposure scoping, cloud-resource scoping, legal escalation, customer notification analysis, vendor escalation, and executive reporting.

·        Define escalation thresholds for suspicious ViewState-bearing request activity, IIS child-process execution, application-file modification, application-content tampering, credential access, outbound communication, user-side delivery, cloud-resource access, and incomplete telemetry.

·        Require cross-functional participation from security, application owners, infrastructure teams, endpoint teams, cloud teams, identity teams, vendor-management teams, legal, privacy, communications, customer assurance, and executive leadership.

·        Track evidence quality, confidence level, containment status, exposure scope, machineKey remediation status, credential rotation status, user-exposure scope, vendor dependency, and residual risk.

S35 — Defensive Control Mapping Matrix

Application Exposure Controls

·        Strengthen ASP.NET asset inventory, internet exposure tracking, ViewState-bearing workflow mapping, machineKey ownership, machineKey uniqueness validation, hosting model documentation, WAF placement validation, vendor-managed portal tracking, and patch or configuration governance.

·        Applies to internet-facing ASP.NET exposure, ViewState-dependent workflows, public request paths, authentication-adjacent workflows, administrative-adjacent workflows, LMS paths, upload paths, plugin-like paths, and incomplete asset ownership.

·        Reduces the likelihood that exposed ASP.NET paths remain vulnerable, unmanaged, or unprioritized.

MachineKey and Application Trust Controls

·        Strengthen machineKey governance, uniqueness validation, secure storage, rotation procedures, vendor-supplied configuration review, shared-key risk review, configuration ownership, and emergency remediation workflows.

·        Applies to static, reused, exposed, vendor-supplied, shared, or weakly governed machineKey material that can weaken trust in state-bearing ASP.NET requests.

·        Reduces the likelihood that malicious ViewState-bearing requests are trusted across one or more ASP.NET applications.

WAF and Web Protection Controls

·        Strengthen WAF rules, request normalization, request-body inspection where feasible, route-specific protections, rate limiting, administrative path restrictions, response anomaly monitoring, and allowed suspicious traffic review.

·        Applies to abnormal ViewState-bearing POST activity, unusual request sizes, repeated request variation, suspicious allowed traffic, request-size anomalies, WAF bypass attempts, and abnormal response behavior.

·        Reduces the likelihood that suspicious request manipulation reaches exploitable ASP.NET functionality without visibility or control.

ASP.NET and IIS Integrity Controls

·        Strengthen ASP.NET audit logging, IIS failed request tracing, application error monitoring, application pool monitoring, worker-process monitoring, authentication workflow monitoring, administrative workflow monitoring, and application configuration monitoring.

·        Applies to validation failures, application exceptions, failed request traces, application pool instability, w3wp.exe child-process execution, application pool identity behavior, and IIS-hosted execution anomalies.

·        Reduces uncertainty when determining whether the ASP.NET application and IIS server remained trustworthy after suspicious request activity.

Webroot and Content Integrity Controls

·        Strengthen file integrity monitoring, known-good baselines, JavaScript change monitoring, login-page monitoring, downloadable-component monitoring, external script reference monitoring, writable-directory restrictions, and deployment-path monitoring.

·        Applies to unauthorized ASPX files, DLLs, JavaScript changes, configuration changes, upload-path artifacts, plugin-like artifacts, temporary artifacts, external script references, fake component prompts, and web shell-like files.

·        Reduces the likelihood that application exploitation becomes durable webroot compromise or user-facing content tampering.

Credential and Cloud Controls

·        Strengthen secrets management, credential rotation, service-account least privilege, application pool identity governance, workload identity governance, IAM review, metadata access restrictions, object storage controls, managed database permissions, SaaS permissions, and cloud control-plane monitoring.

·        Applies to configuration-file access, database credential exposure, service-account token use, application pool identity abuse, cloud credential access, secrets retrieval, object storage access, managed database access, IAM changes, and cloud-hosted expansion.

·        Reduces blast radius when the ASP.NET or IIS workload boundary is affected.

User-Delivery and Endpoint Controls

·        Strengthen user-access telemetry, browser download visibility, secure web gateway coverage, endpoint detection coverage, browser child-process monitoring, proxy correlation, user-exposure scoping, and customer or student assurance workflows.

·        Applies to modified application content, fake component prompts, external script loading, suspicious downloads, browser-driven execution, beacon-like endpoint activity, and post-download malware behavior.

·        Reduces uncertainty when determining whether compromised application content exposed users or triggered downstream endpoint impact.

Network, Egress, and Transfer Controls

·        Strengthen DNS monitoring, proxy visibility, firewall policy, NDR coverage, egress restrictions, approved destination inventories, DLP coverage, unusual transfer monitoring, direct IP egress review, and external script-hosting visibility.

·        Applies to outbound callbacks, payload retrieval, archive transfer, unusual destination contact, dynamic DNS use, rare domain access, uncommon ports, external script retrieval, and cloud-hosted transfer paths.

·        Reduces the likelihood that post-exploitation activity can stage, retrieve, or move data without detection.

Audit and Evidence Controls

·        Strengthen retention, normalization, field mapping, asset correlation, source-to-workload linkage, application pool identity mapping, service-account mapping, user-to-device mapping, cloud context, vendor-support records, change-control records, and incident evidence preservation.

·        Applies to exposure scoping, user-impact determination, legal defensibility, customer assurance, notification analysis, cyber insurance coordination, vendor escalation, and incident reconstruction.

·        Reduces uncertainty when determining whether exploitation remained attempted, became successful, or expanded into business-impacting compromise.

Response and Governance Controls

·        Strengthen ASP.NET containment playbooks, machineKey remediation workflows, WAF review procedures, IIS forensic workflows, webroot restoration procedures, credential rotation workflows, user-exposure scoping, cloud scoping workflows, legal escalation, customer assurance, vendor escalation, and executive reporting.

·        Applies to suspected exploitation, confirmed IIS execution, application-file modification, credential exposure, user-side delivery, outbound communication, cloud expansion, customer-facing service risk, incomplete telemetry, and regulatory exposure.

·        Reduces response delay and improves executive decision readiness.

S36 — CyberDax Intelligence Maturity Assessment

Current Maturity Assessment

Moderate.

ASP.NET ViewState deserialization and shared machineKey exploitation defense requires more than WAF alerting or generic vulnerability management. Organizations with basic web logs, WAF events, and patch records may identify suspicious request activity, but they may struggle to prove whether IIS execution occurred, whether application files or JavaScript changed, whether a web shell-like artifact was placed, whether users were exposed to malicious content, whether credentials were accessed, or whether the incident expanded into identity, SaaS, or cloud-hosted resources. Mature defense requires integrated visibility across public request activity, ASP.NET and IIS behavior, endpoint and file evidence, credential access, outbound communication, user endpoint telemetry, cloud telemetry, change-control records, vendor-support records, and incident governance.

Maturity Strengths

·        Organizations with centralized WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, DNS, proxy, NDR, user endpoint, identity, cloud, asset, vulnerability, vendor-support, and change-control telemetry have a stronger foundation for detecting suspicious request-to-impact behavior.

·        Organizations with mature ASP.NET asset inventory, machineKey governance, WAF tuning, IIS logging, endpoint telemetry, file integrity monitoring, secrets management, workload identity controls, user-exposure scoping, and egress monitoring can reduce both likelihood and blast radius.

·        Organizations with established application-security, infrastructure, endpoint, cloud, identity, legal, privacy, customer assurance, vendor-management, and executive-governance workflows can make faster decisions when exploitation success or exposure cannot be ruled out.

Maturity Gaps

·        Many organizations do not maintain complete inventories of internet-facing ASP.NET applications, ViewState-bearing endpoints, machineKey ownership, machineKey reuse, hosting model, WAF placement, vendor ownership, application ownership, or business criticality.

·        WAF, CDN, proxy, and IIS logs may not retain enough request structure, request-size, request-body, normalization, bytes received, or upstream context to distinguish exploit attempts from benign malformed traffic.

·        ASP.NET and IIS audit logging may not capture enough validation, failed request, application pool, administrative workflow, configuration, or user-facing content detail to prove whether the application remained trustworthy.

·        File telemetry may not provide enough responsible-process, hash, signer, prior-state, path, application pool identity, or known-good baseline context to prove whether application files changed maliciously.

·        Hosted, vendor-managed, shared hosting, containerized, or platform-as-a-service environments may limit endpoint process, file, command-line, application pool identity, service-account, and workload-identity visibility.

·        Cloud telemetry may not be correlated to the affected ASP.NET workload boundary or exposed user population, making metadata access, secrets retrieval, object storage access, managed database use, SaaS access, or IAM changes difficult to attribute.

·        Incident-response teams may not have pre-built workflows for application-layer exploitation where malware may be absent but application trust, user-facing content, credentials, user endpoints, and customer assurance are material.

Maturity Improvement Priorities

·        Improve correlation between WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, network, user endpoint, identity, cloud, vulnerability, asset, deployment, vendor-support, and change-control telemetry.

·        Expand ASP.NET and IIS visibility for validation failures, failed request traces, application pool instability, application exceptions, authentication workflow anomalies, administrative workflow anomalies, configuration changes, and content changes.

·        Strengthen machineKey governance, uniqueness validation, secure storage, rotation procedures, vendor-supplied configuration review, and emergency remediation workflows.

·        Strengthen file integrity monitoring, known-good baselines, user-facing content monitoring, service-account governance, secrets management, credential rotation, and cloud workload controls for ASP.NET-hosting environments.

·        Establish executive-ready exposure-scoping workflows for suspected ASP.NET ViewState exploitation, shared machineKey abuse, IIS execution, application-file modification, application-content tampering, credential access, user-side delivery, outbound communication, cloud expansion, and customer-facing service risk.

Target Maturity State

Advanced.

The target maturity state is the ability to detect suspicious ASP.NET-facing request activity, validate whether the activity affected IIS-hosted execution, determine whether application files or user-facing content changed, identify web shell-like access or outbound communication, confirm whether credentials or secrets were accessed, assess whether users were exposed to malicious content, assess whether identity or cloud expansion occurred, and support legal, customer, regulatory, vendor-management, and executive decision-making from a single defensible evidence timeline. Mature organizations should be able to contain the request-to-IIS-to-application-content-to-user-impact chain before it expands into credential misuse, cloud-resource exposure, user endpoint compromise, customer-facing disruption, or broader business exposure.

S37 — Strategic Defensive Improvements

ASP.NET ViewState deserialization and shared machineKey exploitation risk should be addressed as a strategic internet-facing application, configuration-governance, credential, user-exposure, and cloud workload governance issue rather than a narrow ViewState alert. The organization should prioritize controls that reduce ASP.NET exposure, strengthen machineKey governance, limit IIS-hosted blast radius, protect credentials, improve application-content integrity, support user-exposure scoping, improve cloud containment, and support executive decision-making when exploitation success cannot be ruled out.

Strategic Application Exposure Improvements

·        Maintain authoritative inventory of internet-facing ASP.NET assets, ViewState-bearing endpoints, machineKey ownership, machineKey reuse patterns, hosting model, WAF placement, application ownership, vendor ownership, business criticality, and patch or configuration status.

·        Reduce unnecessary public exposure of administrative-adjacent paths, authentication-adjacent workflows, upload paths, plugin-like paths, test pages, legacy endpoints, and high-risk state-bearing functionality.

·        Require rapid machineKey validation, configuration review, patch validation, and compensating-control review for internet-facing ASP.NET applications supporting customer portals, LMS platforms, authenticated workflows, support functions, regulated content, partner access, or business-critical services.

·        Link vulnerability management, application ownership, machineKey governance, WAF coverage, vendor-support records, change-control records, and business criticality to executive risk tracking.

Strategic Detection and Telemetry Improvements

·        Expand WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, DNS, proxy, NDR, user endpoint, identity, cloud, asset, vulnerability, vendor-support, and change-control visibility for ASP.NET-hosting environments.

·        Normalize fields across request activity, application errors, failed request traces, process behavior, file activity, application pool identity, service account, user identity, device identity, source, destination, and cloud activity.

·        Improve correlation between suspicious request activity and downstream IIS execution, application errors, worker-process instability, file modification, web shell-like access, content tampering, credential access, outbound communication, user endpoint activity, and cloud-resource access.

·        Establish baselines for ASP.NET request behavior, ViewState-bearing endpoints, application pool behavior, administrative activity, file modification, user-facing content changes, outbound communication, user download activity, and cloud-hosted activity.

Strategic Application and IIS Hardening Improvements

·        Enforce ASP.NET configuration governance, machineKey governance, administrative path restrictions, service-account least privilege, application pool identity control, configuration hygiene, secure deployment practices, and administrative audit logging.

·        Harden IIS and ASP.NET runtime behavior through application pool isolation, restricted child-process execution, limited writable directories, script execution controls, upload restrictions, temporary directory controls, and secure hosting baselines.

·        Reduce webroot write and execution risk by restricting writable directories, preventing executable uploads, monitoring sensitive paths, hardening application-controlled paths, and enforcing file integrity monitoring.

·        Require change-control validation for application updates, configuration changes, content updates, JavaScript changes, downloadable component changes, plugin changes, courseware updates, deployment automation, vendor support, and emergency administrative activity.

Strategic Credential, User-Delivery, and Cloud Containment Improvements

·        Move ASP.NET secrets, database credentials, service-account tokens, API keys, deployment secrets, vendor-support credentials, backup credentials, and cloud credentials into managed secrets systems where feasible.

·        Enforce credential rotation and exposure review after suspected exploitation, unexplained IIS-hosted activity, suspicious file access, application-content tampering, or credential-adjacent behavior.

·        Restrict ASP.NET workload access to metadata services, secrets stores, object storage, managed databases, CI/CD systems, backup systems, monitoring systems, SaaS platforms, and cloud management-plane resources.

·        Improve workload identity governance, application pool identity governance, service-account least privilege, IAM review, object storage controls, managed database permissions, SaaS permissions, and cloud control-plane monitoring.

·        Build user-delivery scoping workflows for modified application content, suspicious downloads, fake component prompts, external script loading, browser execution chains, endpoint detections, and exposed user populations.

Strategic Response and Governance Improvements

·        Build response workflows for ASP.NET exploitation where malware may be absent but application trust, IIS execution, webroot content, credentials, user endpoints, vendor dependencies, or cloud resources may be affected.

·        Predefine escalation thresholds for suspicious ViewState-bearing request activity, IIS child-process execution, application-file changes, content tampering, credential access, outbound communication, user-side delivery, cloud expansion, customer-facing service risk, and incomplete telemetry.

·        Ensure security, application owners, infrastructure teams, endpoint teams, cloud teams, identity teams, vendor-management teams, legal, privacy, communications, customer assurance, cyber insurance, and executive leadership can operate from a shared evidence timeline.

·        Establish board-ready reporting for ASP.NET exposure, machineKey governance, exploitation confidence, IIS-hosted impact, application-content integrity, credential containment, user-exposure scope, cloud-hosting blast radius, vendor dependency, customer assurance, notification analysis, and residual risk.

·        Conduct tabletop exercises focused on public-facing ASP.NET exploitation, shared machineKey abuse, IIS execution, application-content tampering, credential exposure, user-side delivery, cloud expansion, incomplete audit evidence, and customer-facing service disruption.

S38 — Attack Economics & Organizational Impact Model

Adversary Cost Advantage

ASP.NET ViewState deserialization and shared machineKey exploitation creates favorable attacker economics because the exposure begins at internet-facing application infrastructure and may be reachable without phishing success, prior endpoint compromise, internal positioning, or valid user credentials. A vulnerable or weakly governed ASP.NET application can provide a high-leverage path into IIS-hosted execution, application files, webroot content, service credentials, downloadable components, user-facing workflows, and connected infrastructure.

The attacker’s cost remains comparatively low when public ASP.NET paths can be probed at scale and exploit validation can be attempted through response behavior, application errors, failed request traces, abnormal ViewState-bearing POST behavior, worker-process instability, file changes, outbound communication, or application-content changes. Economic leverage increases when exposed ASP.NET applications support LMS platforms, customer portals, authentication-adjacent workflows, partner portals, vendor-managed services, downloadable content, regulated records, or business-critical web services.

Defender Cost Disadvantage

Defenders face elevated cost because response cannot stop at WAF review, patch validation, or application restart. The organization must validate exposure, determine affected ASP.NET assets and ViewState-bearing workflows, review machineKey governance, reconstruct public request activity, assess WAF and proxy disposition, examine IIS and ASP.NET application behavior, validate webroot and application-content integrity, inspect endpoint and file telemetry, assess credential access, scope user exposure, and determine whether outbound communication, identity activity, SaaS activity, or cloud-resource access occurred.

The defender burden increases when request-body visibility is limited, IIS logs lack request-size or bytes-received detail, ASP.NET application logs are incomplete, failed request tracing is unavailable, endpoint telemetry is missing from IIS servers, webroot file integrity monitoring is weak, vendor-managed visibility is restricted, user endpoint telemetry is incomplete, workload identity mapping is weak, or change-control evidence is fragmented. Under those conditions, the organization may need broader exposure scoping, wider credential rotation, more extensive forensic review, earlier legal and privacy involvement, vendor escalation, customer or student assurance preparation, and executive governance before confirmed data exposure is established.

Operational Leverage for Attackers

Successful exploitation or credible suspected compromise can create outsized organizational impact because ASP.NET applications often sit at the intersection of public access, authenticated workflows, user-facing content, LMS services, customer portals, service credentials, application pool identities, downloadable components, and cloud-connected infrastructure. Manipulation of webroot files, JavaScript, login pages, authentication workflows, downloadable components, configuration files, service credentials, or application content can affect business operations even without ransomware, destructive activity, or a conventional malware-first intrusion.

Operational leverage increases when the ASP.NET workload has access to database credentials, service-account tokens, object storage, managed databases, deployment systems, backup systems, secrets stores, metadata services, CI/CD resources, SaaS platforms, or cloud control-plane functions. In those cases, attacker leverage can extend into credential containment, cloud scoping, user endpoint scoping, legal review, customer-facing service assurance, vendor-management escalation, and executive incident governance.

Organizational Impact Model

Low Impact Scenario

Low-impact exposure applies when activity is limited to attempted exploitation, blocked ViewState-bearing requests, malformed ASP.NET requests, limited application errors, or low-confidence probing. In this scenario, there is no confirmed IIS server-side execution, application-file modification, web shell activity, credential access, outbound communication, application-content tampering, user-side delivery, cloud-resource expansion, customer notification requirement, regulatory notification requirement, or material business interruption.

Moderate Impact Scenario

Moderate-impact exposure applies when suspicious ASP.NET-facing request activity is paired with IIS worker-process anomalies, application errors, unauthorized file modification, web shell-like access, JavaScript or login-page changes, outbound communication, user download activity, credential-risk indicators, or incomplete exposure confidence. This scenario does not require a public leak, confirmed extortion outcome, or enterprise-wide compromise, but it does require the organization to respond as if application content, IIS-hosted infrastructure, service credentials, user endpoints, or connected business workflows may have been exposed or manipulated.

High Impact Scenario

High-impact exposure applies when confirmed or strongly suspected exploitation affects application integrity, IIS server integrity, user-facing content, webroot files, login or authentication workflows, downloadable components, service credentials, user endpoints, customer or student trust, cloud-hosted resources, managed database access, identity systems, or connected business systems. This scenario may include confirmed server-side execution, web shell deployment, malicious content delivery, credential theft, persistence, outbound command-and-control-like communication, user malware execution, downstream identity abuse, customer-facing service disruption, notification analysis, regulatory exposure, extortion pressure, or extended application and infrastructure remediation.

Economic Pressure Points

·        Emergency ASP.NET exposure validation, ViewState-bearing endpoint review, machineKey governance review, configuration validation, and compensating-control assessment.

·        WAF, CDN, reverse proxy, load balancer, IIS web server, ASP.NET application, and failed request trace reconstruction.

·        IIS forensic review for worker-process instability, w3wp.exe child-process execution, application pool identity activity, command execution, file staging, credential access, outbound communication, and web shell-like behavior.

·        Webroot and application-content review for ASPX files, DLLs, JavaScript files, configuration files, login pages, downloadable components, external script references, user-facing prompts, upload paths, plugin-like paths, and temporary ASP.NET compilation artifacts.

·        Credential rotation for ASP.NET configuration secrets, database access, application pool identities, service accounts, deployment secrets, vendor-support credentials, backup credentials, API keys, and cloud credentials.

·        User-exposure scoping for employees, customers, students, contractors, partners, external users, managed endpoints, unmanaged devices, browser downloads, fake component execution, and endpoint detections after affected application access.

·        Cloud and identity scoping for metadata access, secrets retrieval, object storage access, managed database access, workload identity use, service-account activity, SaaS access, IAM changes, conditional-access events, and control-plane interaction.

·        Legal, privacy, cyber insurance, customer assurance, student notification, partner notification, regulatory, communications, vendor-management, and executive coordination where exposure cannot be quickly ruled out.

·        Longer-term remediation of machineKey governance, ASP.NET exposure management, WAF controls, IIS logging, ASP.NET application logging, file integrity monitoring, content integrity baselines, secrets management, egress controls, user-exposure workflows, and cloud workload boundaries.

S39 — Economic Impact & Organizational Exposure

Figure 7

Estimated Economic Exposure

ASP.NET ViewState deserialization and shared machineKey exploitation creates economic exposure by increasing the cost and urgency of response around internet-facing ASP.NET applications, IIS-hosted services, machineKey governance, webroot integrity, service credentials, user-facing content, and connected cloud or identity resources. The exploitation path creates business risk because suspicious ViewState-bearing request activity may require defenders to determine whether the activity remained scan noise, reached a vulnerable state-bearing workflow, affected IIS-hosted execution, modified application files or JavaScript, exposed credentials, delivered malicious content to users, produced outbound communication, or expanded into identity, SaaS, or cloud-hosted resources.

The highest economic exposure occurs when suspicious request activity affects business-critical ASP.NET applications supporting customer portals, LMS platforms, student access, authenticated workflows, partner portals, vendor-managed services, downloadable components, regulated records, or cloud-hosted business systems. In those environments, response may require emergency machineKey remediation, WAF and proxy review, IIS forensic review, ASP.NET application review, webroot integrity validation, user-facing content review, credential rotation, user endpoint scoping, egress analysis, cloud scoping, customer assurance, legal review, vendor escalation, and executive governance.

Low Impact Scenario

Estimated impact $300K to $1.5M.

Rapid assessment confirms that suspicious activity was limited to attempted exploitation, blocked ViewState-bearing requests, malformed ASP.NET requests, limited application errors, or low-confidence probing that was contained before confirmed IIS child-process execution, unauthorized file modification, web shell activity, credential access, outbound communication, application-content tampering, user-side malware delivery, or downstream infrastructure expansion. Affected assets are narrow, IIS and WAF logs are sufficient, endpoint telemetry supports a defensible timeline, legal review remains limited, and no confirmed sensitive data exposure, service disruption, customer notification requirement, regulatory notification requirement, or material business interruption is identified.

Moderate Impact Scenario

Estimated impact $3M to $15M.

Suspicious ASP.NET-facing request activity is paired with IIS worker-process anomalies, application errors, unauthorized file modification, web shell-like access, JavaScript or login-page changes, outbound communication, user download activity, credential-risk indicators, or incomplete exposure confidence. No public leak, confirmed extortion outcome, or enterprise-wide compromise is validated, but the organization must respond as if application content, IIS-hosted infrastructure, service credentials, user endpoints, or connected business workflows may have been exposed or manipulated.

High Impact Scenario

Estimated impact $18M to $75M or higher.

Confirmed or strongly suspected exploitation affects application integrity, IIS server integrity, user-facing content, webroot files, login or authentication workflows, downloadable components, service credentials, user endpoints, customer or student trust, cloud-hosted resources, managed database access, identity systems, or connected business systems. This scenario applies when the incident includes confirmed server-side execution, web shell deployment, malicious content delivery, credential theft, persistence, outbound command-and-control-like communication, user malware execution, downstream identity abuse, customer-facing service disruption, notification analysis, regulatory exposure, extortion pressure, or extended application and infrastructure remediation.

Annualized Risk Exposure

Estimated annualized risk exposure is $5M to $30M or higher.

Annualized risk exposure depends on the number of internet-facing ASP.NET assets, machineKey governance quality, business criticality of affected workflows, likelihood of successful exploitation, quality of IIS and WAF logging, endpoint and file telemetry coverage, user-exposure scope, credential-risk scope, vendor-managed visibility, customer assurance requirements, notification obligations, cloud-hosting exposure, and remediation complexity.

Operational Dependency

Operational exposure increases when ASP.NET applications support customer portals, LMS platforms, student access, public communications, authenticated workflows, partner access, support functions, downloadable components, regulated content, or other business-critical functions. The greater the dependency on the affected ASP.NET application, the greater the cost of containment, outage avoidance, user-exposure scoping, customer or student assurance, vendor coordination, and trust restoration.

Control Trust

Control trust depends on whether the organization can prove that machineKey remediation, WAF rules, request filtering, ASP.NET configuration controls, IIS hardening, endpoint controls, file integrity monitoring, content integrity baselines, credential protections, user-delivery controls, and cloud workload boundaries were effective before and after suspicious activity. Control trust decreases when security teams cannot distinguish blocked exploitation, attempted exploitation, successful exploitation, application-file modification, user-side delivery, and post-exploitation behavior.

Visibility Confidence

Visibility confidence depends on the ability to correlate WAF, CDN, reverse proxy, load balancer, IIS, ASP.NET application, endpoint, file, DNS, proxy, NDR, user endpoint, identity, cloud, asset, vulnerability, vendor-support, deployment, and change-control telemetry into a defensible timeline. Low visibility confidence increases investigation cost and may force broader exposure scoping.

Change-Control Confidence

Change-control confidence depends on whether machineKey changes, application updates, configuration changes, content updates, JavaScript changes, downloadable component changes, login-page changes, plugin changes, courseware updates, deployment activity, backup activity, vendor-support activity, and emergency maintenance can be explained through approved records. Weak change-control evidence increases the risk that legitimate administration and exploitation-related changes cannot be separated quickly.

Downstream Dependency

Downstream dependency increases when the ASP.NET workload has access to managed databases, service credentials, object storage, metadata services, secrets stores, CI/CD systems, backup systems, monitoring systems, SaaS platforms, identity services, or cloud control-plane resources. These dependencies increase blast-radius risk and raise the cost of credential review, user-exposure scoping, cloud scoping, and infrastructure validation.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when affected ASP.NET applications support customer records, student records, authenticated user data, employee-adjacent records, support records, regulated records, contractual data, payment-adjacent workflows, credentials, confidential business records, downloadable components, or public-facing service integrity. Exposure also increases when logs cannot prove whether sensitive records, credentials, application content, user-facing workflows, or downloadable components were accessed, exported, modified, or left untouched.

Residual Economic Risk

Residual economic risk remains after patching, mitigation, exposure removal, machineKey remediation, or vendor remediation because those actions reduce future exploitation risk but do not prove that pre-remediation exploitation did not occur. Systems exposed before mitigation still require historical review of request activity, ASP.NET application behavior, IIS telemetry, webroot and content changes, file activity, credential access, outbound communication, user endpoint activity, identity activity, and cloud-hosting activity.

Proof-of-Concept Behavioral Coverage Assessment

Detection Engineering Coverage Interpretation

The detection model is designed to cover proof-of-concept and post-disclosure exploitation behavior by focusing on the durable request-to-IIS-to-application-content-to-user-impact chain rather than a single exploit string, parameter name, URI path, source IP, user-agent, ViewState value, machineKey artifact, web shell filename, or proof-of-concept payload. Coverage is strongest when suspicious ASP.NET-facing request activity can be correlated to application errors, failed request traces, IIS worker-process behavior, application pool identity activity, file modification, web shell-like access, credential access, outbound communication, application-content tampering, user endpoint activity, or cloud-hosting activity.

Direct Coverage

Direct coverage applies when proof-of-concept or exploit-derived activity produces suspicious ViewState-bearing request activity against ASP.NET-facing functionality and at least one corroborating downstream signal. Directly covered behavior includes abnormal ViewState-bearing POST activity, unusual request size, abnormal bytes received, repeated request variation, endpoint-specific probing, suspicious allowed web activity, or error-to-success transitions followed by ASP.NET validation failures, IIS errors, failed request traces, worker-process instability, w3wp.exe child-process execution, unauthorized ASPX or DLL changes, JavaScript modification, web shell-like access, credential access, outbound communication, application-content tampering, user-side delivery, or cloud-resource interaction.

Coverage With Adaptation

Coverage with adaptation applies to related ASP.NET ViewState, shared machineKey, vendor-managed ASP.NET portal, LMS platform, WebForms, authentication-adjacent workflow, custom IIS-hosted application, and application-layer deserialization variants that preserve the same behavioral chain. Adaptation may require local schema mapping, ViewState-bearing endpoint baselining, WAF field validation, IIS log mapping, ASP.NET application log tuning, endpoint telemetry mapping, file integrity mapping, user endpoint telemetry mapping, cloud workload identity mapping, and environment-specific exception handling.

Non-Coverage Conditions

Non-coverage applies when exploitation leaves no observable request signal, no ASP.NET application signal, no IIS signal, no endpoint or file signal, no credential signal, no outbound communication, no user endpoint evidence, no identity or cloud telemetry, and no incident-response evidence. Non-coverage also applies when telemetry is missing, retention has expired, request and application logs are too incomplete to support correlation, or downstream activity cannot be tied to the affected ASP.NET workload boundary, exposed user population, stolen credentials, or user endpoint compromise.

Current Coverage Count

Current conservative coverage count:

·        Directly covered: 1 CVE.

·        Covered with adaptation: related ASP.NET ViewState, shared machineKey, vendor-managed ASP.NET portal, LMS platform, WebForms, authentication-adjacent workflow, custom IIS-hosted application, and application-layer deserialization variants where observable behavior aligns with the existing model.

·        Not covered: activity that does not produce the modeled request, application, IIS, file, credential, outbound, user endpoint, cloud, or impact behaviors in available telemetry.

Directly Covered

·        KnowledgeDeliver ASP.NET ViewState Deserialization / CVE-2026-5426.

Covered With Adaptation

·        Related ASP.NET ViewState exploitation, shared machineKey abuse, machineKey reuse exposure, vendor-managed ASP.NET portal compromise, LMS platform exploitation, WebForms exploitation, authentication-adjacent ASP.NET abuse, IIS-hosted application deserialization activity, and application-layer state manipulation where observable behavior includes suspicious ASP.NET-facing request activity, IIS anomalies, application-file changes, web shell-like access, credential access, outbound communication, user-delivery behavior, cloud-resource access, or operational impact.

Not Covered

·        Exploitation methods that produce no observable suspicious request activity, no ASP.NET application signal, no IIS anomaly, no application-file evidence, no credential access, no unusual egress, no user endpoint activity, no cloud activity, and no downstream impact in available telemetry.

Coverage Qualification

Coverage should be interpreted as behavior-led detection and response coverage, not universal proof-of-compromise coverage. The model can identify attempted exploitation, likely exploitation, and post-exploitation behavior when sufficient telemetry exists, but it cannot confirm compromise without incident-specific validation. Local production deployment still depends on exact telemetry availability, schema mapping, field validation, enrichment, exception handling, false-positive review, query-performance testing, and SOC triage readiness.

S40 — References

Vendor / Platform Documentation

Mandiant Vulnerability Disclosure — MNDT-2026-0009

hxxps://github[.]com/mandiant/Vulnerability-Disclosures/blob/master/2026/MNDT-2026-0009.md

Microsoft Security Blog — Code injection attacks using publicly disclosed ASP.NET machine keys

hxxps://www[.]microsoft[.]com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/

Vulnerability Records

NVD Record — CVE-2026-5426 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-5426

Known Exploited Vulnerabilities

CISA Known Exploited Vulnerabilities Catalog

hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Security Vendor Analysis

Google Cloud Blog — Exploitation of KnowledgeDeliver via ViewState Deserialization Vulnerability

hxxps://cloud[.]google[.]com/blog/topics/threat-intelligence/knowledgedeliver-viewstate-deserialization-vulnerability

Threat Tradecraft and Intrusion Patterns

MITRE ATT&CK Framework — Enterprise Matrix

hxxps://attack[.]mitre[.]org